Why your AWS bill keeps climbing after launch (and what to fix first)

An AWS bill rarely jumps in one go. It climbs a few percent every month until finance raises a ticket, and the meeting ends with "let's right-size EC2". This guide is for founders and CTOs whose AWS bill keeps climbing after launch. You get the five usual causes, the order to check them, and the fixes that bring spend down without breaking production.

The climb is rarely one problem. It is usually five small problems, compounding.

How launch defaults turn into a bigger bill

At launch, the architecture is small enough that nobody pays attention to cost surface. Logs are at default retention. AWS Lambda is at default memory. Amazon EC2 Auto Scaling groups are set to "what worked in staging." Storage is in one tier. There's no tag policy. There's no owner per resource.

Then traffic grows. The system handles it. That's why people remember the launch as a success. But every default that survived launch is now running in production at scale. And the bill grows with it.

Here are the five causes, in the order I check them.

1. Cost has no owner

This is almost always cause zero. If you open AWS Cost Explorer and you can't say in one sentence "this $X is for team Y's workload," you have an ownership problem before you have a cost problem.

Without tags and per-team allocation, every cost conversation becomes a meeting. Engineers don't know which line items are theirs. Finance doesn't know who to ask. So the bill grows in the gap.

The fix: require three tags across AWS Organizations (team, cost-center, env). Service control policies (SCPs) have no audit mode, so find the gaps first: the AWS Configrequired-tags rule or Tag Editor lists what is missing. Backfill existing resources. Then attach an SCP that denies create calls without the tags, using a Null condition onaws:RequestTag. Test it on a sandbox OU first; it blocks the request outright.

After that you can actually have the next four conversations.

2. Logs and traces keep growing

Amazon CloudWatch Logs is the cost surface nobody looks at because it doesn't show up under "EC2" or "Lambda." It shows up under "CloudWatch."

Default log retention is "Never expire." On a busy Lambda or Amazon ECS workload, that compounds fast. CloudWatch Logs can grow to close to a third of a bill, with the large majority of those logs beingINFOlines from libraries.

What to check:

• Default retention on every log group: set to 30 days, override per group
• Powertools for AWS Lambda or other structured logging: drop noisy fields server-side
• AWS X-Ray sampling: 100% in staging is fine; 5-10% in prod is enough
• Amazon VPC Flow Logs: destination, retention, and whether you query them

3. Retry storms and idle compute

Two patterns hide here. Both look "fine" in dashboards.

Retry storms. A flaky downstream causes Lambda to retry a failed asynchronous invocation twice by default, so one event becomes three attempts. Amazon SQS retries multiply that. Amazon EventBridge retries again. A single bad path can multiply your invocation count by 10x for the duration of an outage, and you pay for every invocation.

Idle compute. EC2 instances spun up for a one-off migration in 2024. Amazon RDS dev clusters that nobody stopped. Amazon Aurora Serverless v2 clusters with a minimum capacity above zero, so they never pause (Aurora Serverless v1 reached end of support on 31 March 2025). ECS services with desired count = 4 that handle the same load as 2.

The fix: Lambda destinations for failures instead of endless retries. Dead-letter queues (DLQs) on every SQS queue, each with an alarm. AWS Trusted Advisor's idle EC2 report: run it monthly. AWS Compute Optimizer recommendations applied to Auto Scaling groups.

4. Data sits in the wrong storage tier

Amazon S3 has six storage classes. Most teams use one, S3 Standard, forever.

If you're storing more than 1 TB and not using Intelligent-Tiering, you are paying for hot access on cold data. Same goes for Amazon EBS volumes: gp3 is cheaper than gp2 for the same performance, and almost nobody migrates.

Quick wins I look for:

• S3 lifecycle policies on log buckets: Standard → IA → Glacier
• S3 Intelligent-Tiering on any bucket >1 TB
• EBS gp2 → gp3 migration (same performance, cheaper)
• RDS snapshots from deleted databases (yes, they still cost)
• Unused EBS volumes left behind by terminated instances

5. Data transfer: egress and cross-AZ traffic

The last cause is the hardest to fix because it needs architecture changes, where the other four need config changes. Data transfer is the line item that grows with traffic, and AWS charges it three ways:

• Cross-AZ: traffic between AZs in the same region. Real cost on a multi-AZ ECS or RDS workload.
• Cross-region: replication or DR traffic.
• Internet egress: traffic out to users, including responses to API calls.

Amazon CloudFront in front of S3 reduces egress 10-100x. AWS PrivateLink instead of public endpoints removes NAT Gateway data costs. AZ-aware service placement reduces cross-AZ traffic for chatty services.

Spend the first three days on visibility, before any cuts

In a cost review, I spend the first three days on visibility. Optimization comes after.

1. Day 1: Pull Cost Explorer 90-day data by service, tag, and account. Pull Trusted Advisor reports. Run the AWS Cost and Usage Report (CUR) into Amazon Athena for line-item drill.
2. Day 2: Map untagged spend. Identify the top 10 cost line items. Cross-reference with engineering owners.
3. Day 3: Walk each top-10 with the owning team. Tag, confirm intent, mark for review.

Only after that do I propose changes. Anything earlier and you risk right-sizing something a team is about to ship into.

Which fixes to make first, ranked by impact and risk

This is the rough order of impact I would expect:

Skipping the first three and jumping to Savings Plans is how a bill keeps climbing: the commitment locks in the waste.

The right order is: visibility first, cleanup second, right-sizing third, commitments last. Architecture changes (egress, cross-AZ, caching) come in as a separate engagement once the obvious wins are booked.

One real number: across past freelance work, this approach delivered up to a 55% reduction in combined client spend on stable workloads. Typical reductions were 30-40%. Spiky and event-driven workloads saw less because they're already close to right-sized.

Found a likely cause in your bill? Follow theAWS cost optimization audit checklistto work through visibility, cleanup, right-sizing, and commitments in order.

Sources

Pages were read on 2026-10-27.

AWS documentation

• How Lambda handles errors and retries with asynchronous invocation, AWS Lambda Developer Guide: two more attempts after a function error, by default.
• Scaling to Zero ACUs with automatic pause and resume for Aurora serverless, Amazon Aurora User Guide: auto-pause at zero ACUs.
• [Announcement] Support for Aurora Serverless v1 ending soon, AWS re:Post (AWS staff post): end of support moved to 31 March 2025, with automatic upgrades on or after 7 April 2025.