Cost Anomalies & Billing Support

A different but genuinely common category of ticket: unexpected cost. This chapter builds directly on cloud1-9's cost management foundations, turning that chapter's "usual suspects" list into a real, dedicated support investigation.

Restating the Foundation — Cloud1-9's Usual Suspects

Recall the list: idle/oversized compute, orphaned storage, data egress, unused load balancers/NAT gateways, forgotten dev/test environments. This chapter goes deeper into how to actually investigate each one as a real ticket.

The Billing Support Investigation Order

Echoing Chapter 2's connectivity flowchart and Chapter 3's IAM debugging order:

1. Confirm the time window of the increase precisely — which billing period, did it start suddenly or ramp gradually (Chapter 4's "what changed and when").
2. Break down spend by service first, then by resource/tag (cloud1-9's tagging material).
3. Cross-reference the identified resource(s) against recent provisioning/deployment history — was something new created around when the increase started.
4. Check the identified resource(s) against the specific usual-suspect patterns below.

Investigating Idle/Oversized Compute

Compare instance size/type against actual CPU/memory utilization metrics (cloud1-8) over a representative period. A genuinely common finding: an instance sized for an anticipated peak load that never materialized, running oversized 24/7 unnecessarily. The fix is rightsizing, not simply "turn it off," if the resource is still genuinely needed — just wrong-sized.

Investigating Orphaned Storage

List storage volumes not currently attached to any running instance, and cross-reference against recently terminated instances (cloud1-3's own stopped-VM-billing gotcha, taken further). A genuinely common real finding: a batch of disks left behind after an environment teardown that removed the compute but never the associated storage.

Investigating Data Egress Costs

Break down data transfer costs specifically by destination — cross-region, cross-AZ, or out to the internet — since these are priced very differently. A genuinely common real finding: a misconfigured backup/replication job sending far more data cross-region than intended, or a CDN/caching misconfiguration causing repeated re-fetching of the same data from origin rather than being served from cache — directly the scenario cloud1-9's own multi-cloud/hybrid egress warning anticipated.

Investigating Forgotten Dev/Test Environments

Cross-reference resource creation date and tags (or the lack of tags — cloud1-9's own tip-box) against any currently active project. A genuinely common real finding: an environment spun up for a now-completed or abandoned project, still running because nobody remembered to tear it down — often discoverable specifically because it lacks proper tagging in the first place, closing the loop on cloud1-9's own tagging argument in a concrete investigative context.

When the Cause Isn't a "Usual Suspect" — Pricing/Rate Changes

A genuinely distinct category worth naming separately: sometimes cost increases with no change in actual resource usage at all, because the provider changed pricing for a service, or a discount/committed-use agreement (cloud1-9's pricing-model material) expired and usage reverted to on-demand rates. Important to rule in or out early, since no amount of resource-level investigation explains a cost increase that's actually a pure pricing change.

Communicating Findings to a Customer

Tying back to Chapter 6's communication material: present findings clearly — what resource, why it's costing more, and the specific recommended action (delete/resize/re-tag), rather than a raw cost breakdown dump. Genuinely useful practice: distinguish clearly between "this is a legitimate cost from real, needed usage" and "this is something that can likely be safely reduced or eliminated," since customers need a different follow-up action for each.

Hands-On Exercises