Why did my AWS bill go up?

A list of common causes helps only once you know where to look. These five questions, asked in this order, take most investigations from “the bill went up” to a specific resource and the team that owns it. Each one uses data you already have in AWS Cost Explorer or in the Cost and Usage Report.

1. 1Compare like with like. Put two windows of the same length side by side — the last 14 days against the 14 before, or a full month against the previous one — on the same cost basis. If you buy Savings Plans or Reserved Instances, compare amortized cost, so an upfront payment does not look like a spike; and leave credits and refunds out (Cost Explorer’s charge-type filter), so their timing does not hide the change.
2. 2Find the service that moved. Group by service and sort by the difference, not by the total. The largest service on your bill is rarely the one that changed.
3. 3Find the kind of charge. Within that service, group by usage type. The usage type says what you are paying for — hours of an instance, gigabytes moved between Availability Zones, gigabytes through a NAT gateway, snapshot storage — and most of the causes below have a usage type of their own.
4. 4Find the day. Switch to daily granularity and look at the shape of the line (the next section reads it). A step on one day points to a change someone made; a slope points to growth.
5. 5Find the owner. Group the changed cost by linked account, then by your cost allocation tags — team, service, environment. Cost with no tag is an answer too: keep it as its own line instead of spreading it across teams, so nobody mistakes an unowned cost for a shared one.

• A step — the cost jumps on one day and stays up. Look for a deploy, a configuration change, a new resource, a commitment that ended or an extended-support charge that started that day. Your release history and AWS CloudTrail usually name it.
• A slope — the cost climbs a little every day. That is growth: traffic, data that accumulates, logs and snapshots that are never deleted.
• A spike that falls back — a batch job, a load test, a backfill or a one-off data transfer. Worth knowing about; rarely worth a fix.
• A jump on the first of the month — some charges post once a month, so a first-day jump is often a monthly fee rather than a change in usage.

Once you know the service, the usage type and the day, match them against these. Each entry says what to look for in Cost Explorer, so you can confirm the cause instead of assuming it.

• AWS Cost Explorer — the comparison and grouping above. The console is free of charge; its API is charged per request.
• AWS Cost Anomaly Detection — free. It learns your spending pattern, alerts on unusual spend, and lists the services, accounts, Regions and usage types that contributed most. A good first alarm.
• AWS Budgets — alerts when actual or forecast cost crosses a threshold you set.
• The Cost and Usage Report, delivered through AWS Data Exports — line-item detail, including resource IDs when you turn them on, for when the usage type is not specific enough.

What these tools leave to you is the explanation: putting the service, the usage type, the day and the owner together into one sentence someone can act on.

CloudJaeger is built around this question. It connects to AWS through a read-only IAM role whose policy is published before you connect, syncs the bill, and explains a change in the same order as above: which service moved and by how much, from which day, and which team owns it — with untagged spend kept as its own line. Every figure names its source and how fresh it is, and any saving it suggests stays labelled projected until your next bill confirms it.