Reading a cloud bill, and controlling it before it arrives

Why this matters

Billing is a first-class objective on this exam and it surprises people. It is there because cost is the operational dimension that is unique to cloud: on owned hardware, capacity is a purchase made once and an engineer never thinks about it again; in a cloud, every architectural decision is also a recurring financial one, and nobody but the practitioner is in a position to notice.

This is also the objective with the most immediately useful content in the whole course. Everything here is applicable the first week of a cloud job, and much of it is invisible until someone shows you.

The lesson

The line items that surprise people: egress, inter-zone traffic, idle addresses, snapshots

A cloud bill is mostly unsurprising: compute hours, storage gigabytes, managed service charges. The surprises are consistent across providers and worth knowing by name.

• Egress. Data leaving the provider's network to the internet. Inbound is typically free, outbound is not, and it is the classic surprise because it scales with success rather than with anything you provisioned.
• Inter-zone and inter-region traffic. Traffic between availability zones is usually chargeable in both directions. A chatty application spread across zones for resilience pays for that resilience per gigabyte, continuously. Cross-region is more expensive again.
• NAT gateway processing. Charged per hour and per gigabyte. Container image pulls, operating system updates and backups to public endpoints all flow through it by default, and a private endpoint removes the charge entirely.
• Idle allocated resources. Unattached disks left behind by deleted instances. Reserved static addresses not attached to anything — often billed only when idle. Load balancers with no targets. Provisioned IOPS on a stopped volume.
• Snapshots and old image versions. Individually trivial, created automatically, never deleted by anyone, and compounding for years.
• Logging and monitoring. Ingestion and retention of verbose logs is a genuinely large line item in mature estates, and it grows with the fleet.
• Support plans and licensing bundled into instance hours, which is why two instances of identical size can cost different amounts.

The pattern: you are billed for allocation, not usage. Almost every surprise above is something allocated and forgotten.

Chargeback and showback, and the tagging discipline both depend on entirely

Two words the exam expects you to distinguish precisely:

• Showback reports what each team, project or environment consumed. It is informational; no money moves.
• Chargeback actually bills the consumption back to that team's budget.

Showback changes behaviour through visibility; chargeback changes it through consequence. Showback is the usual starting point because it needs no financial process, and it is where most organisations stop.

Both rest entirely on tagging — the habit introduced in the lab lesson. Without consistent tags, a bill is a list of resource identifiers and cannot be attributed to anyone. With them, cost can be sliced by team, environment, application or cost centre.

Making tagging real requires enforcement, because voluntary tagging decays:

• Tag policies that require specified keys on creation.
• Guardrails that refuse to create untagged resources — the only approach that actually holds.
• Tagging applied in infrastructure as code, so it is not a human step.
• Regular reports of untagged spend, which is the measure of whether the discipline is working.

Untagged resources are also, almost always, the orphaned ones — so the untagged report doubles as the waste report.

Budgets, alerts and quotas as three different controls doing three different jobs

These are routinely confused and the distinction is squarely examinable.

• A budget is a target figure with reporting against it. It observes.
• An alert notifies when actual or forecast spend crosses a threshold. It tells you; it stops nothing. Spending continues after the email.
• A quota or service limit caps how much of a resource can exist. It prevents. This is the only one of the three that stops the spend.

So if a question asks how to detect overspend, the answer involves budgets and alerts. If it asks how to prevent it, the answer is quotas, service limits, or policy that refuses creation.

Use them together:

• Alerts on forecast as well as actual, so you hear about a trend before month end.
• Quotas on the expensive resource types, especially in non-production accounts, sized to what the team legitimately needs.
• Separate accounts or subscriptions per environment, which makes both attribution and limits trivial and contains the blast radius of a mistake.

Reserved and committed-use discounts, and the commitment risk they carry

Commitment-based discounts trade flexibility for a substantially lower rate: commit to a quantity of compute for one or three years and pay less per hour.

The variants, in increasing flexibility and decreasing discount:

• Standard reservations of a specific instance type in a specific region — the deepest discount and the least flexible.
• Convertible or flexible reservations, exchangeable for other types.
• Spend-based commitments — commit to an hourly spend rather than a configuration, and the discount applies across whatever you run.

The risks, which are what a scenario will test:

• Architectural change. Committing to instances and then moving to containers or serverless leaves a commitment for capacity you no longer use. Spend-based commitments hedge this.
• Committing before right-sizing, which locks in the waste. Objective 1.7's order — turn off, right-size, then commit — exists for this.
• Over-committing. A commitment covering peak rather than baseline pays for idle capacity. Cover the steady baseline and leave the peak on-demand.
• Regional and family lock, where a standard reservation stops applying because the workload moved.

The sound default is a commitment covering the reliable baseline, with on-demand for variation and spot for interruptible work.

Cost anomaly detection, and the forgotten resource it is there to catch

The last control is the one that catches what the others miss: something unexpected started costing money and nobody has looked at the bill yet.

Cost anomaly detection learns normal spending patterns per service and account and flags statistically unusual changes, rather than absolute thresholds. That distinction matters — a budget alert fires only when the total crosses a line, so a new $300-a-month resource inside a $10,000 budget never triggers anything. Anomaly detection notices the shape change.

What it typically catches:

• A large instance started for a test and left running
• A runaway automation or recursive function invoking itself
• A misconfigured log level multiplying ingestion volume
• Data transfer that started taking an expensive path — the private-endpoint failure from objective 1.3
• Resources created in an unexpected region, which is also a security signal

Pair it with a monthly discipline that takes minutes:

1. Sort spend by service and compare against last month.
2. Review the untagged and unattached reports.
3. Check coverage and utilisation of any commitments.
4. Delete something.

A resource nobody can explain is a resource to be deleted, and the tagging discipline is what makes "nobody can explain it" a defensible conclusion rather than a guess.

What to take into the exam

• You are billed for allocation, not usage. Idle addresses, unattached disks, empty load balancers and old snapshots are the classic waste.
• Egress, inter-zone traffic and NAT processing are the transfer charges people forget. Private endpoints remove the NAT charge.
• Showback informs; chargeback bills. Both depend entirely on tagging, and tagging only holds if it is enforced at creation.
• Budgets and alerts detect. Quotas and limits prevent. If the question says prevent, do not answer with an alert.
• Commit to the baseline, not the peak, and right-size before you commit.
• Anomaly detection catches proportionally small but unexpected spend that a budget threshold never sees.