concept

Cloud Pricing

How cloud providers charge, which dimensions dominate, and the pricing structures that reward architectural rather than operational responses.

cloudpricingegresscommitmentsspotcost

Definition

Cloud pricing has more dimensions than most designs account for, and the dimensions that dominate a bill are frequently not the ones the design optimised.

The dimensions

  • Compute — per second or hour, by instance type. Discounted heavily by commitment (reserved or savings plans) or by accepting interruption (spot), which can be 60–90% cheaper.
  • Storage — per gigabyte-month, by tier, plus per-request charges and retrieval charges on cold tiers.
  • Data transfer — the one that surprises people. Egress to the internet is charged; cross-region is charged; cross-availability-zone is charged in both directions; and traffic through NAT gateways and load balancers is charged per gigabyte processed.
  • Managed service units — per request, per provisioned capacity unit, per I/O operation. A serverless database billing per I/O makes an inefficient query pattern startlingly expensive.
  • Licensing passed through, often per core.

Where architecture beats operations

Right-sizing and commitments are operational levers with a bounded return. The architectural levers are larger:

  • Keep data movement inside a zone. Cross-zone chatter on every request is a recurring charge invisible under "networking" rather than attributed to the service causing it.
  • Use private endpoints rather than routing service traffic through a NAT gateway, which charges per gigabyte processed on traffic that never needed to leave the provider's network.
  • Put a CDN in front of anything served repeatedly, so cache hits are billed at CDN rates rather than origin egress rates.
  • Process data where it lives. Pulling data out for processing pays egress on every byte.
  • Design for spot where the workload tolerates interruption — batch, CI, stateless workers with graceful shutdown. This is the largest available discount and it is an architectural property, not a purchasing decision.

The commitment strategy

Commit to the stable base, run the variable portion on demand or on spot. Committing to the peak wastes money; committing to nothing pays the full rate on the base. And commit after right-sizing, or you have locked in the wrong sizes for a year.

Failure scenarios

  • Egress discovered at the first month-end bill.
  • Cross-zone traffic on every request from an architecture that ignores placement.
  • Committed to pre-optimisation sizes.
  • Serverless database costs driven by a query pattern, not by data volume.
  • Cost attributed to "networking" rather than to the workload generating it, so nobody owns it.

Interview question

"Which cloud pricing dimension most often surprises teams, and what architectural changes address it?"