Cost Management & Billing

This chapter turns Chapter 8's "observe what's happening" lens specifically onto cost — a topic this course has been foreshadowing since Chapter 1's honest note about CapEx-to-OpEx trade-offs, and touching repeatedly since (Chapter 3's pricing models, Chapter 4's lifecycle policies).

Why Cloud Cost Management Is Its Own Discipline

On-prem hardware cost is mostly fixed and predictable once purchased. Cloud cost is variable, driven directly by usage — meaning it can grow (or shrink) dynamically, sometimes unexpectedly. Chapter 1's CapEx-to-OpEx trade brings real flexibility, but it also removes the natural spending cap a big upfront hardware purchase used to provide — which is exactly why cost needs active, ongoing management rather than a one-time budgeting exercise.

How Cloud Billing Actually Works

Billing is usage-based, at a granularity that varies by resource type — compute is often billed per-second or per-hour, storage per GB-month, data transfer per GB. Monthly invoices aggregate usage across every service used. Organizations with multiple sub-accounts or projects (echoing Chapter 2's resource hierarchy — AWS Organizations, Azure Management Groups, GCP Billing Accounts + Projects) typically use consolidated billing, giving one centralized invoice across many accounts rather than a separate bill per account.

Pricing Models, Revisited From Chapter 3

Chapter 3 covered on-demand, reserved, and spot pricing specifically for compute. Broadening slightly: AWS also offers Savings Plans — committing to a dollar-per-hour spend level rather than a specific instance type, trading some of reserved pricing's discount depth for meaningfully more flexibility. Azure and GCP offer similar concepts (Azure Reservations/Savings Plans, GCP Committed Use Discounts). The general principle holds across all of them: the more you commit in advance — in time, and in specificity — the deeper the discount, and the less flexibility you retain.

Where Costs Actually Come From — The Usual Suspects

• Idle or oversized compute — instances left running unnecessarily, or sized larger than the workload actually needs (Chapter 3).
• Unattached/orphaned storage volumes — a VM was terminated, but its disk wasn't deleted, and keeps billing indefinitely (Chapter 4).
• Data transfer/egress costs — genuinely often underestimated; moving data out of a provider, or between regions, is frequently the surprising line item on a bill — much more so than inbound transfer, which is usually free or cheap.
• Unused load balancers or NAT gateways left provisioned after they're no longer needed.
• Forgotten dev/test environments — never torn down after a project ended, quietly accumulating cost for months.

Cost Anomalies & How to Investigate Them

A cost anomaly is an unexpected, unexplained spend spike. Each provider offers native anomaly-detection tooling (AWS Cost Anomaly Detection, Azure Cost Management anomaly alerts, GCP's budget-based alerting). Investigation almost always starts by breaking spend down — by service, by resource, by tag/label.

Budgets & Cost Alerts

Rather than discovering a runaway cost issue on next month's invoice, a budget threshold can trigger a notification — or, in stricter configurations, actually restrict further provisioning — as spend approaches or exceeds a defined limit. This is the cost equivalent of Chapter 8's alerting material: the same underlying pattern (a threshold plus a notification), applied to a different signal.

A Support-Relevant Billing Scenario

"Why is my bill higher this month?" — a practical investigation order: check the usual suspects list above first, then look at the cost breakdown by service/tag for the actual delta, then check for any pricing changes or newly provisioned resources around the time the increase began. Two specific gotchas this course has already covered are common concrete answers here: Chapter 3's stopped-VM-still-billing-for-storage scenario, and Chapter 4's archive-retrieval-cost surprise.

Hands-On Exercises