Cloud Fundamentals
Intermediate 14 min read Cloud Fundamentals

Cloud Economics

Why the bill looks like that — and how to keep it sane

Cloud billing is a mix of on-demand price, commitments, data-transfer, and idle waste. The discipline of making cloud cost predictable is unit economics plus continuous rightsizing.

cloud economicspay-as-you-goreserved capacitydata egressunit costwaste
Prerequisites: What is Cloud Computing? Cloud Service Models
Before we start

What you will learn

  • Break a cloud bill into compute, storage, network and services components
  • Explain on-demand vs committed pricing and when each wins
  • Institute tagging, budgets and unit-cost reviews
In 60 seconds

Cloud pricing is utility pricing with commit options. You pay per unit used; committing to predictable, sustained usage earns discounts. The two biggest silent costs are idle resources and data egress.

Introduction

What is this?

Cloud economics is the practice of understanding and steering what the cloud costs: on-demand hourly/secondary rates for compute, per-GB pricing for storage, per-GB transfer (ingress cheap, egress expensive), per-request service charges, and commitment discounts (reserved/savings plans/committed-use) for predictable usage. Because everything is metered, cost leaks from idle resources, over-provisioning and unplanned egress — which are control problems, not pricing problems.

Motivation

Why do you need it?

  • The on-demand bill is an honest mirror of utilization — and usually shows embarrassing waste.
  • Committed capacity (reservations) can save 30-60% on steady-state workloads if you commit smartly.
  • Data egress is where organizations blow budgets; it's priced per GB and flows out at the edges.
  • The 'unit economics' mindset makes cloud costs a product metric, not a finance surprise.
Think about it

Mental model

Imagine

Buying groceries in small trips vs a fridge stocked by discount box stores

Think of

On-demand vs reserved cloud capacity

Small trips (on-demand) are flexible and waste less if plans change. A discount membership (reservation) saves a lot on the items you reliably consume — but you must really consume them.

Mechanics

How it works

  • An instance's on-demand price × utilization hours produces your compute line; idle-but-running instances still bill.
  • Reservations/savings plans apply a discounted rate to a committed amount of compute; the discount works across zones/sizes.
  • Storage bills per allocated or used GB across tiers (hot→archive), plus per-operation fees for object storage.
  • Data egress bills per GB leaving the provider; ingress is usually free, inter-region and egress-to-internet are not.
  • Budgets, tags and anomaly alarms surface drift before the month ends rather than at billing day.

The anatomy of a cloud bill.

Compute
Storage
Network
Services
Commitments
Real world

In production

  • An e-commerce company commits 60% of its stable baseline on savings plans, keeps the spike-prone 40% on-demand and spots a budget anomaly the month a partner started streaming data out.
  • A data platform tags by team and publishes a unit-cost dashboard: cost per row processed, so a performance improvement shows as a real money line.
  • A startup moves a rarely-used analytics cluster from always-on VMs (bills 24/7) to a serverless warehouse (bills only query time) and cuts cost 70%.
Guidelines

Best practices

  • Tag every resource (cost-center, environment, owner) at creation, enforced by policy.
  • Right-size before you reserve: commit only to what metrics prove is sustained.
  • Make cost a review item in every pipeline/CI merge that provisions resources.
  • Measure unit cost (cost per order, per request, per user) so cost tracks value, not just usage.
Watch out

Common mistakes

  • Reserving capacity for workloads that turn out to be bursty — the 'discount' becomes wasted committed money.
  • Ignoring egress: two apps in one region talking to the 'cloud' still pay nothing, but reading across regions does.
  • Letting idle dev/test environments run 24/7 while everyone's 'at lunch'.
  • Treating cost as a finance problem instead of an engineering feedback loop.
Root cause analysis

Common issues

Error
Bill doubled with no traffic change
Root cause

An unattached volume, orphaned snapshot or oversized instance was left behind a feature flag

Fix

Run idle-resource sweeps: list volumes with no attach, snapshots older than N days, and instances with low CPU.

Error
Egress line is enormous
Root cause

An integration pulls large datasets across regions or to the internet per run

Fix

Move data consumers into the same region, or route bulk transfer through cheaper channels (e.g. CDN/bulk endpoints).

Error
Reservations show 0% utilization but huge upfront cost
Root cause

Committed to a class/region that the workload stopped using

Fix

Commit only after steady-state is proven; buy smaller, shorter commitments for uncertain workloads.

When things break

Debugging tips

  • When the bill jumps, diff spending by service and by tag between last month and this month first.
  • Anomaly alarms catch a spike (e.g. a teammate left a 72-core instance running) before the close-out.
  • Check 'unused' resources: EBS volumes attached to nothing, elastic IPs, and snapshot copies still bill.
  • Use provider cost tools' 'find savings' / recommendations but verify against actual utilization before acting.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which of these is usually the cheapest part of cloud data movement?

2

A stopped/storage-only resource never appears on your bill.

Go deeper

Official documentation

AWS — Pricing fundamentals
docs
Azure — Pricing overview
docs
Google Cloud — Pricing calculator
docs