Skip to content

Cloud Cost Basics

8-minute read. Assumes you've read What is cloud computing?.

The one-line answer

Cloud turns a capital purchase into a per-second rental, which is enormously flexible and means your bill is now a direct consequence of engineering decisions made by people who never see it.

What you actually pay for

Almost every cloud bill decomposes into the same five things:

Dimension Charged on Notes
Compute Instance size multiplied by time it exists Runs whether or not it is doing anything
Storage Gigabytes stored per month Cheap per GB, and it accumulates forever unless something deletes it
Network egress Data leaving the provider or crossing regions Ingress is usually free; egress is where surprises live
Requests and operations Per API call, per million Individually trivial, occasionally enormous at scale
Managed service premium The convenience of not operating it yourself A managed database costs more than the VM it replaces, and less than the engineer

The most common surprise on a first serious bill is egress, because nothing in a local development environment charges for network traffic and nothing warns you.

Why bills grow without anyone deciding to spend more

  • Nothing turns itself off. A development environment left running over a weekend costs the same as production traffic.
  • Storage never shrinks. Snapshots, old backups, logs at debug level, and orphaned volumes accumulate silently.
  • Autoscaling has no ceiling by default. A retry storm can scale a fleet into a very large number.
  • Cross-zone and cross-region traffic is charged, and a chatty microservice architecture spread across zones pays for every internal hop.
  • Idle managed services still bill: a provisioned database at 2% utilization costs the same as at 80%.
  • Logs and metrics are charged per GB ingested, and verbose logging at scale can rival compute cost.

The pricing models

Model Discount Commitment Fits
On demand None None Unpredictable or short-lived workloads
Spot / preemptible Very large, often 60-90% Can be reclaimed with little notice Fault-tolerant batch, CI, stateless workers
Reserved instances / committed use Substantial 1 or 3 years Steady baseline load
Savings plans Substantial Spend commitment, flexible across services Steady spend with changing shape

The practical pattern: cover your steady baseline with a commitment, handle variable load on demand, and run interruptible work on spot. Committing to your peak wastes money; committing to nothing leaves a large discount unclaimed.

The levers that actually move a bill

In rough order of impact per unit of effort:

  1. Turn things off. Non-production environments outside working hours. Frequently 20-30% of a bill with no performance consequence.
  2. Right-size. Instances are routinely provisioned for a peak that never arrives. Check actual utilization before renewing anything.
  3. Fix storage lifecycle. Move old objects to cheaper tiers automatically, expire what nobody reads, and delete orphaned volumes and snapshots.
  4. Commit to the baseline. Once your steady-state usage is understood, a commitment is a discount for work you were going to do anyway.
  5. Reduce egress. Keep chatty services in the same zone, cache at the edge, and compress.
  6. Trim observability. Sample traces, filter debug logs before ingestion, tier retention.
  7. Adopt spot for anything that tolerates interruption.

Notice that the first three cost nothing and require no architectural change.

Making cost visible

You cannot manage what nobody can see.

Tagging is the foundation: every resource labeled with an owner, environment, and cost center. Untagged resources become unattributable spend that nobody feels responsible for, and retroactive tagging is painful, so enforce it at creation with policy.

Showback reports each team's spend without billing them. Chargeback actually bills them. Showback changes behavior in most organizations; chargeback is heavier and worth it only where the organization genuinely wants teams to feel the price.

Budgets and alerts are the cheapest safety net there is. Set them low enough to be noticed, on every account, on the day the account is created.

Anomaly detection catches the shape of problem a fixed threshold misses: a service that doubles its spend while remaining under budget.

Unit economics

A total bill going up is not automatically bad. A bill going up while serving twice the traffic is efficiency improving.

The measure worth tracking is cost per unit of business value: cost per order, per active user, per thousand requests, per model inference. It converts a finance conversation into an engineering one and reveals whether growth is profitable.

Architecture decisions that determine cost

Most of a bill is decided by design, not by procurement:

  • Serverless versus always-on: scale-to-zero is dramatically cheaper for spiky or low-volume workloads and more expensive at sustained high volume
  • Data locality: keeping compute next to data avoids cross-region egress entirely
  • Storage tiering: hot, infrequent access, and archive tiers differ by an order of magnitude
  • Instance family: ARM-based instances often cost less for the same throughput
  • Multi-region: doubles a lot of cost, and is sometimes required by the availability target and sometimes just assumed

FinOps in one paragraph

FinOps is the practice of making cost a shared engineering responsibility rather than a finance report. Three phases repeat: inform (visibility, tagging, allocation), optimize (right-size, commit, eliminate waste), and operate (governance, budgets, continuous improvement). The cultural point is that the people who create cost are the people who can reduce it.

What to look at next