Cost Engineering

Cost is a design constraint, not a monthly report. The ten drivers that actually move an infrastructure bill, why the ones nobody predicts are always the ones that move bytes rather than store or compute on them, and how to make spend a signal an engineer reads.

An always-on instance bills for existing; a serverless invocation bills for happening. The crossover between those two shapes decides which one is cheaper, it moves with traffic, and nobody can tell you where it sits for your workload without measuring — which is why every number here is illustrative.

Allocated 100 CPU, using 12. The naive reading is that 88 units are wasted; the honest reading is that some of them are the reliability budget. Telling the two apart — and cutting only the second — is the difference between a saving and an outage at the next spike.

A 32 GiB instance with 4 GiB in use looks like an obvious eight-fold over-provision. It sometimes is. But average use is not a sizing input: size for the peak, then for what happens when a zone fails and its traffic lands on the survivors.

Breaking the bill down by service turns "infrastructure costs too much" into a conversation someone can act on. The mechanism is tagging, the hard part is the shared resources that resist attribution, and the honest output is an allocation rule everybody agreed to rather than a precise truth.

The line item that surprises everyone. Storing a terabyte is cheap; serving it repeatedly is not, and the meters sit on paths an architecture diagram draws as plain arrows — internet egress, cross-region replication, cross-zone chatter and the NAT you forgot processes every outbound byte.

Data gets colder with age and almost nothing deletes itself. Lifecycle policies move objects down the tiers automatically — and the archive tiers hide a trap, because they charge to read the data back, charge again if you delete it early, and take hours to return it.