The AWS bill is an architecture diagram

Most teams read the AWS bill as a finance document. It is a better engineering document.

Every line is a decision someone made, usually months ago, often under deadline, sometimes by accident. Reading it properly is one of the highest-yield hours available to an engineering lead, and almost nobody spends it.

Start with the line you cannot explain

Open Cost Explorer, group by service, and look at the top five. For each one, answer in a sentence what it is doing and why it costs that much.

The interesting item is the first one where the answer is vague. In our experience it is usually NAT gateway data processing, cross-AZ transfer, or CloudWatch ingestion, and in all three cases the cost is a symptom of an architectural choice nobody consciously made.

NAT gateway charges appearing high usually means private-subnet services are calling S3 or DynamoDB over the internet path instead of a VPC endpoint. That is a configuration change measured in minutes.

Cross-AZ transfer means chatty services are spread across availability zones for a redundancy benefit nobody has actually reasoned about.

CloudWatch ingestion means someone set an application to debug level and never set it back.

None of those are finance problems. They are design facts that happen to have a price tag attached, which is the only reason anyone noticed them.

The bill tells you what is actually running

Ask a team what their system consists of and you get the mental model. Ask the bill and you get the truth.

The gap between those two is where the surprises live: the staging environment nobody turned off, the RDS instance that was meant to be temporary, the load balancer sitting in front of nothing, the snapshots from a migration in 2024 that are still accruing storage.

This is not really about the money. A forgotten RDS instance is also a forgotten attack surface, a forgotten patching obligation, and an unknown that someone will eventually find in a security review. The cost is just the thing that makes it visible.

Tagging is not bureaucracy

The reason most teams cannot read their bill is that everything lands in one undifferentiated pile.

A minimal tagging policy, enforced in your infrastructure code rather than requested in a wiki page, changes this entirely. Environment, service, and owner is enough. With those three tags you can answer "what does this feature actually cost to run" and "which team owns this spend", and both questions turn out to drive better engineering decisions than they do budget ones.

Enforce it at creation time. A tagging policy that relies on people remembering is a tagging policy that describes about sixty percent of your resources.

The review that pays for itself

Once a month, one engineer, one hour. Look at the top movers since last month, explain each one, and write down anything unexplained.

Half the time you find nothing and the hour was insurance. The other half you find a service that has been misconfigured since launch, and you find it because the bill noticed before anyone else did.