AWS cost diagnosis
Your AWS bill is a number. Fifteen minutes turns it into a list of things to change.
Everything below is done in Cost Explorer, which you already have. No tooling to install, no read-only role to create, no access keys to hand anybody. It will not find everything, and the last section is honest about where it stops.
Start with the check if you want the method. Skip to the second section if the bill has moved and you need to know what caused it.
Can you explain your top three cost drivers?
Four passes over the same data, each one narrowing the question. The output is not a number, it is two or three usage types you can name and go and look at.
- 01
3 min
Group by Service, three months, monthly
Open Cost Explorer, set the range to the last three full months at monthly granularity, and group by Service. Write down the top five and what each costs. Most accounts are far more concentrated than people expect — the top three usually carry 70-80% of the bill, and everything below that is not worth your fifteen minutes.
- 02
5 min
Filter to the top service, group by Usage Type
This is the step that produces the actual answer, and the one people skip. "EC2" is not a finding. NatGateway-Bytes, EBS:VolumeUsage.gp2 and PublicIPv4:IdleAddress are findings — each names a specific thing you can go and change. Do this for the top two or three services only.
- 03
2 min
Group by Region
Spend outside your primary region is almost always unintentional: a test in another region, a service that defaulted somewhere else, a copied Terraform workspace nobody destroyed. It is rarely the largest number on the page, but it is usually the fastest thing to remove because nothing depends on it.
- 04
5 min
Switch the top usage type to daily
Same filter, daily granularity. You are looking for the shape. A step change means a deployment or a configuration change, and the date tells you where to look. A gradual ramp means growth, which may be entirely healthy. A flat line that never moves means capacity nobody is using.
The bill went up. Check these five first.
Traffic growth is the assumption and it is usually wrong, or at least incomplete. Step four above gives you a date. These are the five things that tend to be sitting on it, in the order they are worth checking.
- A deployment A step change on a specific date
- Correlate the date from step four against your deploy history. An instance class bumped for a load test, a replica count raised, a cache added — the change is usually deliberate and the failure is that nobody reverted it.
- A logging change CloudWatch rising independently of traffic
- Log level moved to DEBUG and stayed there, a new subsystem started emitting per-request logs, or retention was extended. CloudWatch bills you on ingestion, so this shows up immediately and keeps billing every month afterwards.
- Network path changes NatGateway-Bytes or cross-AZ transfer climbing
- A workload that used to reach S3 or DynamoDB over a gateway endpoint now goes out through the NAT gateway, or services that used to sit in one availability zone now talk across two. Neither change looks like a cost change when it is made.
- A new region Spend appearing in a region you do not run in
- Someone evaluated a service elsewhere, or a stack was deployed to a default region. The spend is often small per line but permanent, and it never appears in a service-level view because it is spread across several services.
- A scaling event that never unwound A step change with no corresponding step back down
- Autoscaling minimums raised during an incident, an RDS instance class increased to get through a migration, provisioned capacity set for a launch. The scale-up is remembered; the scale-down is not.
Where this check stops
Cost Explorer reports what you were billed. It does not know utilisation, so it cannot tell you that an instance is running at four percent CPU, and it cannot tell you which of two workloads sharing a usage type is the one worth changing.
And if most of your bill turns out to be model inference rather than the infrastructure around it, this is the wrong tool for the job — attributing spend per feature and per user is a different exercise.
It will also not tell you which of the changes you have just found are safe to make. That is usually the reason a list like this sits unactioned for months — not that the waste is hard to see, but that nobody is confident enough about production to touch it.
Get the change listTwo Cost Explorer exports, a change list you approve before anything is touched, and a fee of one month of the verified reduction.