Cost, Scaling & Billing Reasoning

The plain-language idea

Almost every AWS service bills on some combination of three axes: provisioned capacity (an EC2 instance running, whether busy or idle), actual usage (a Lambda invocation, a gigabyte scanned by a query), and data transfer (moving data out of AWS to the internet, which costs money in a way moving it in usually doesn't). Understanding which axis a service bills on is what predicts whether a design choice is going to be cheap or expensive at scale — before the bill arrives, not after.

See it in a real thing: the same feature, two very different bills

A "resize this image on upload" feature:

• As Lambda, billed per invocation and per millisecond: idle time costs nothing. A feature used occasionally costs close to nothing between uses.
• As an always-on EC2 instance, billed per hour whether it's processing an image or sitting idle: the exact same feature, used the exact same amount, costs the same whether it runs once a day or a thousand times, because the bill is for the instance existing, not for the work it does.

Neither is universally right — this is the same tradeoff from this track's compute-options lesson, just viewed through cost specifically instead of operational control: spiky, infrequent usage favors the pay-per-use model; constant, high, predictable usage favors paying for fixed capacity, because at high enough sustained volume, per-invocation pricing adds up past what a fixed instance would have cost.

What people usually miss

Watch out

• Data transfer OUT of AWS costs money; transfer IN, and transfer between most services within the same region, typically doesn't. This asymmetry is why architectures try to keep data processing close to where the data already lives (the same region, the same VPC) — moving large amounts of data out to users or to another cloud is where transfer costs concentrate.
• A recursive or retrying failure can turn a small bug into a large bill, fast. A Lambda function that errors and gets automatically retried, which itself triggers another invocation that also errors, is a real, documented cost-incident pattern — not a hypothetical edge case, which is why AWS Budgets/alerts (billing alarms, conceptually the same mechanism as the CloudWatch alarms from this track's monitoring lesson) exist specifically to catch this before it becomes a surprise.
• Reserved/Savings Plans trade flexibility for a discount, not "some services are just cheaper." Committing to a specific instance type or a minimum spend for 1-3 years earns a real discount over on-demand pricing — appropriate for a known, stable baseline load, not for a workload whose shape isn't understood yet.
• The free tier is time-limited and usage-capped, not permanent. A design validated against free-tier limits during development can behave completely differently, cost-wise, the moment real traffic exceeds those caps — free tier is for learning and prototyping, not a load-bearing assumption for a cost model.

Why this matters in interviews

"How would you estimate the cost of this architecture before building it?" is a real systems-thinking question, and the strong answer identifies which billing axis each component sits on (provisioned vs. per-use vs. data transfer) and reasons about traffic shape — rather than treating cost as something to find out only after the bill arrives.