9.1 How cloud pricing actually works

What this is and why it exists

Cost is the part of cloud work that most courses skip and every employer notices. This lesson is not a price list — prices change monthly and any figure written here would be wrong by the time you read it. It is the shape of cloud pricing: what is metered, which choices change the rate, where the charges hide, and how to build an estimate before you deploy rather than discover one afterwards.

The vocabulary

• Metered — billed by measured usage rather than by a subscription.
• On-demand — the standard rate, with no commitment and no notice required to stop.
• Committed use — a lower rate in exchange for promising a level of usage for one or three years. Amazon sells Savings Plans and Reserved Instances, Azure sells Reservations and Savings Plans, Google sells Committed Use Discounts.
• Spot (or preemptible) — spare capacity at a large discount, which the provider may reclaim at short notice.
• Ingress — data coming in; egress is data going out.
• Request-based — billed per invocation and per unit of time used, as serverless functions are.
• Estimate — a figure you built from the provider's own calculator before deploying.

The mental model

Everything is metered, and there are only a few meters. Compute is billed by the time a machine exists, at a granularity now measured in seconds — which is what makes turning things off a real saving rather than a gesture. Storage is billed by what you hold per month, and separately by what you do with it: retrievals from colder tiers, and requests against object storage, are their own meters and can exceed the storage charge for a busy small dataset. Serverless is billed per request plus the memory-time each run consumed, which is why the memory setting is a cost dial as well as a speed one. Managed services add a service charge on top of the resources underneath. Learn which meters a service runs, and a price page becomes readable.

The rate you pay for compute then depends on how much certainty you give the provider, and this is the one axis worth understanding properly. On-demand is the most expensive and the most free: start and stop whenever, no commitment. A commitment — one year or three, for a level of usage — buys a substantially lower rate, and what you are trading is flexibility: you owe the commitment whether or not you use it, so it belongs on the steady baseline of a workload you are sure about, never on something you are still designing. Spot capacity is the cheapest of all and can be taken back at short notice, which makes it excellent for batch work that can be interrupted and resumed, and unusable for anything a person is waiting on. The sensible pattern for a mature system is all three: commitment for the floor, on-demand for the normal variation, spot for the interruptible work.

Then egress, which is the line item that surprises everyone and deserves its own paragraph. Data coming into a provider is typically free or nearly so; data going out is metered, and so is data crossing between regions and often between zones. That asymmetry is deliberate and it has architectural consequences you can act on: keep chatty components in the same zone, cache at the edge so that repeat traffic leaves once rather than every time, avoid designs that shuttle large datasets between clouds routinely, and check the transfer charges before choosing to serve large files from object storage directly to a wide audience. It is also the quiet cost of leaving a provider — the data was cheap to put in and is metered on the way out, which is worth knowing while you are still choosing.

Finally, the estimate, which is a skill rather than a formality. Every provider publishes a calculator; the useful practice is to list your resources before deploying, put them in, and write the monthly figure down. Two habits make the result honest. Include the things people forget — egress, the load balancer, the NAT gateway, backups, logs and their retention, the observability platform — because those are frequently a larger share of a small system's bill than the machines. And build two figures rather than one: the expected month and a bad month, where usage is several times higher, so that you find out now whether a traffic spike would be a nuisance or a catastrophe.

What you should now be able to explain or do

Name the meters behind compute, storage, object requests and serverless, and say which one the memory setting moves. Explain what you trade for a committed rate, and name the part of a workload it belongs on. Say what spot capacity is good for and what it must never carry. Explain the ingress-egress asymmetry and give three design choices that follow from it. Build a monthly estimate from a calculator, including the five things people leave out, and produce a bad-month figure alongside it.

Check yourself