Your AWS Bill Is Out of Control. Here's How to Cut It by 40%

Last quarter, a Series A startup came to us with a problem: their AWS bill had grown from $3,000/month to $18,000/month in six months, while their user base had only doubled. Something was very wrong.

After a week-long audit, we found $7,200/month in waste. Oversized instances. Forgotten dev environments running 24/7. Unattached EBS volumes. A NAT gateway processing terabytes of unnecessary traffic. Classic startup cloud waste, and the reason an infrastructure review usually pays for itself in the first month.

Here is the playbook we use to cut cloud costs by 30-50% without affecting performance.

Step 1: Know what you are spending

Enable AWS Cost Explorer and set up cost allocation tags. Tag every resource with at least three tags: environment (prod/staging/dev), service, and team. Without tags, your bill is a black box. With tags, you can see exactly which services and teams are driving costs.

Set up billing alerts at 50%, 75%, and 100% of your expected monthly spend. This takes five minutes and prevents surprise bills.

Step 2: Right-size your instances

Most startups run on instances that are 2-4x larger than they need. Pull up CloudWatch metrics for every EC2 instance and RDS database. If average CPU utilization is below 20%, you are overpaying.

Use AWS Compute Optimizer or a tool like Spot.io to get right-sizing recommendations. In our experience, right-sizing alone typically saves 20-30% on compute costs. A t3.xlarge running at 8% CPU should be a t3.medium. An r5.2xlarge database that never uses more than 4GB of RAM should be an r5.large.

Step 3: Kill zombie resources

Every startup has them: EC2 instances nobody remembers launching. EBS volumes detached from any instance. Elastic IPs not associated with anything. S3 buckets full of old deployment artifacts. Load balancers pointing to nothing.

Run a sweep of every resource in every region. Yes, every region. We once found a client running a $400/month instance in ap-southeast-1 that a former engineer had launched for testing and never terminated. Check for:

• Unattached EBS volumes ($0.10/GB/month adds up fast)
• Unused Elastic IPs ($3.65/month each)
• Idle load balancers ($16/month minimum each)
• Forgotten RDS snapshots older than 30 days
• Non-production environments running 24/7 that could be shut down nights and weekends

Step 4: Use Reserved Instances and Savings Plans

If you have been running the same workload for 3+ months and expect to continue for at least a year, buy a 1-year Reserved Instance or Savings Plan. The savings are 30-40% compared to on-demand pricing with no upfront payment, or up to 60% with full upfront payment.

Start with your databases. RDS instances rarely change size or type, making them perfect candidates for reservations. Then look at your core application instances.

Step 5: Optimize data transfer

Data transfer costs are the hidden killer on AWS bills. NAT gateway processing charges ($0.045/GB) are the most common culprit. If your NAT gateway is processing more than 1TB/month, investigate why.

Common fixes: use VPC endpoints for S3 and DynamoDB (free, eliminates NAT gateway traffic for those services), use internal load balancers for service-to-service communication, and put CloudFront in front of your application to reduce origin requests.

Step 6: Automate cost governance

Set up a monthly cost review meeting. It takes 30 minutes. Review the top 10 cost drivers, identify any unexpected increases, and assign action items. The goal is to make cost awareness part of your engineering culture, not a quarterly panic when the CFO asks why the bill is up 40%.

Use tools like Infracost to estimate the cost of infrastructure changes before they are deployed. This catches expensive mistakes in code review instead of on next month's invoice.

Measure cost per unit, not cost per month

The six steps above cut the bill once. What stops it climbing again is changing the number you report. A monthly total tells you nothing about whether spending is healthy, because a bill that goes from $18,000 to $24,000 while revenue triples is a good month. Pick a denominator that tracks the work your platform does and divide by it every month: cost per active tenant, cost per thousand API calls, cost per gigabyte ingested, cost per completed job. Whichever one you pick, keep it stable for at least a year so the trend means something.

Two numbers usually earn their place on the engineering dashboard. The first is infrastructure cost as a percentage of revenue, which is the figure your board and any future acquirer will ask about, and which for most B2B SaaS companies lands somewhere in the single digits to low teens depending on how compute-heavy the product is. The second is cost per unit of work, which is the figure your engineers can actually move. Report both. The first one keeps finance calm, the second one tells you whether an architecture change helped.

The reason this matters more than the one-off cleanup: a right-sizing pass gives you a step change that decays. Instances drift back up because someone hit a CPU ceiling during a launch and nobody dropped the size afterwards. Non-production environments multiply because every new engineer gets one. Unit cost tracking catches the drift within a month instead of at the next quarterly panic.

The line items that grow fastest and get audited least

Compute is the easiest thing to optimize and rarely the fastest-growing part of the bill after the first cleanup. Four categories tend to be bigger and less examined.

Observability. Logging, metrics and tracing bills scale with traffic and with how chatty your engineers made the application, and they are usually billed by a third party rather than by AWS, so they never show up in Cost Explorer. A team that logs every HTTP request at INFO with the full request body will pay more for the logs than for the servers producing them. Look at ingest volume by service, find the top three log producers, and ask whether anyone has queried those logs in the last ninety days. Sampling at the agent level and dropping health check logs typically cuts ingest by half without losing anything anyone reads. Do this before you negotiate the renewal, not after, because your committed volume is the thing you are negotiating.

Managed database sprawl. Every service that gets its own RDS instance carries a minimum spend, a multi-AZ standby, a backup retention cost and storage that only ever grows. Ten small Postgres instances at $180 each are far more expensive than one properly sized instance with ten schemas, and the operational argument for separation is usually weaker than it sounds at 50 people. Check storage allocation too. RDS storage does not shrink. A database that was scaled to 2TB during a bad migration keeps billing for 2TB forever unless you dump and restore.

Snapshot and backup accumulation. Automated snapshots with no lifecycle policy compound quietly. Seven daily snapshots of a 500GB volume is not a problem. Two years of daily snapshots of a 500GB volume, retained because nobody wrote the deletion rule, is a few thousand dollars a year for data nobody would ever restore. Set a retention policy that matches your actual recovery objective and your compliance obligation, then automate deletion. Write down the retention number, because your auditor will ask for it and "whatever the default was" is not an answer that survives a SOC 2 walkthrough.

Idle managed services. Kinesis streams with provisioned shards for a pilot that ended. OpenSearch domains running three nodes for an internal search feature two people use. MSK clusters sized for a throughput target you never hit. These do not appear in right-sizing tools because there is no CPU metric that screams. Find them by sorting the bill by service and asking the owning team what each one is for.

Kubernetes changes where the waste hides

If you run EKS or GKE, instance right-sizing measures the wrong layer. Your nodes can sit at 85 percent allocated while the actual containers use 15 percent of what they requested, and you will pay for the requests. Pod resource requests are the real cost lever, and they are almost always set by copying whatever the last service used.

Pull requested CPU and memory against actual usage for every deployment over a fourteen day window. The pattern is consistent: a handful of services are genuinely constrained, and everything else requests four to eight times what it consumes because an engineer picked a round number. Right-sizing requests, then letting the cluster autoscaler pack the nodes properly, routinely takes a third out of a Kubernetes bill without touching a single instance type.

Two cautions. Memory requests are not like CPU. A container that exceeds its memory limit is killed, so cutting memory requests aggressively converts a cost problem into an availability problem. Cut CPU requests hard, cut memory requests carefully, and set limits only where you have a reason. And check what your cluster runs when nothing is happening. Daemonsets for logging, service mesh sidecars and security agents can consume a fifth of every node before your application starts, which is a defensible cost as long as someone has decided it is worth it.

Commitments: how they go wrong

Reserved Instances and Savings Plans are the right move for stable workloads, and they are also the easiest way to lock in a mistake for three years. The failure pattern we see most often runs like this. A team buys a three-year commitment on x86 instances in the same quarter their platform team starts a migration to Graviton, which is cheaper per unit of work. Nine months later the migration lands, the on-demand cost drops, and the commitment keeps billing for capacity nobody uses. The migration savings and the stranded commitment cancel out, and the company has paid to stand still.

Rules that prevent this. Commit on one year rather than three unless your finance team specifically wants the deeper discount and your architecture is genuinely settled. Prefer Compute Savings Plans over instance-family reservations, because they follow you across instance types, sizes and regions and cost only a few percentage points more. Commit to your trough, not your average: cover the baseline you are certain about and let the peaks run on demand, because unused commitment is a hundred percent waste while on-demand is only a thirty percent premium. And check the roadmap before signing. If anyone is planning an ARM migration, a database engine change or a region consolidation in the next two quarters, wait.

When the cut breaks something

Cost work causes incidents, and pretending otherwise is how teams end up with a rule that says nobody touches infrastructure sizing again. The predictable failures are worth planning for.

Right-sizing on average CPU misses burst workloads. An instance that averages 12 percent may hit 100 percent every night during a batch job, and the smaller instance will miss its window. Always look at the p95 and the maximum alongside the mean, and look at a full month so you catch the month-end run. Burstable instance types have a second trap: t-family credits accumulate at low utilization and drain during sustained load, so a t3 that looks comfortable in a graph can fall off a cliff under a traffic spike and stay there.

Killing an unattached volume or an old snapshot is only safe if you know what it was. Before deleting anything, tag it with a deletion date thirty days out, detach or stop rather than terminate where you can, and see who complains. The cost of holding a $40 volume for another month is nothing next to discovering it held the only copy of a dataset a data scientist needed.

Shutting non-production environments overnight breaks whatever runs overnight, which is usually the nightly integration test and whichever colleague is in a different time zone. Announce the schedule, provide a documented way to wake an environment, and exempt anything with a scheduled job. When you make the change, do it one environment at a time, and put an alarm on error rate and latency before you touch anything so that you can attribute a regression to the change instead of arguing about it.

Account structure, tagging and the compliance overlap

Tagging fails in every company that treats it as a policy rather than a control. People do not tag resources because they are asked to. They tag resources because untagged resources cannot be created. Use a service control policy or a Terraform module that requires the three tags at creation time, then run a weekly report of untagged spend and send it to the team that owns the account. Aim for less than five percent of spend untagged and treat anything above that as a broken pipeline rather than a people problem.

Separate accounts per environment are the cleanest form of tagging, because the account boundary does the attribution for you and nobody can forget it. That structure pays a second dividend when a customer asks for a SOC 2 report or an ISO 27001 certificate. A production account that contains only production, with its own identity boundary and its own logging, is dramatically easier to scope and evidence than one account holding production, staging and three experiments. We have seen audit scope shrink and audit fees with it because a company happened to have organized its accounts sensibly for cost reasons a year earlier. If compliance is on your horizon, the account restructuring you are considering for billing clarity is the same work, so do it once. Our compliance practice starts from the same architecture diagrams a cost review produces.

What the cleanup itself costs you

An honest budget for this work has three lines. Discovery is the cheap part: a week of one senior person with read-only access across every account and region produces the findings list. Implementation is where the time goes, and it lands on your engineers, not on a spreadsheet. Right-sizing twenty services, adding lifecycle rules, restructuring accounts and rewriting Terraform modules is typically four to eight engineer-weeks spread over a quarter, and it competes with the product roadmap. Governance is the ongoing part: half an hour of someone's week to check the anomaly alerts, plus the monthly review meeting.

Set the threshold before you start. Below roughly $8,000 a month of cloud spend, a structured cost program is hard to justify, because a fifty percent saving is $4,000 a month and the engineering time to capture it costs more than that in the first year. Below that line, do the free version: turn on billing alerts, delete the obvious zombies, put dev environments on a schedule, and revisit in six months when the bill is bigger.

When you should not hire anyone for this

Most cloud waste at Series A is found by one competent engineer with two uninterrupted days, Cost Explorer grouped by service, and permission to ask why each of the top ten line items exists. If nobody on your team has ever done that, do that first. You will find a large share of the savings and you will learn where your money goes, which is worth more than the report an outsider hands you.

Do not buy a cost audit if your bill is growing because your product is growing and your unit cost is flat. That is what a working business looks like. Buying an optimization project because the absolute number went up is how teams end up spending engineering weeks to shave a percentage off a line that was never the problem.

Be skeptical of percentage-of-savings pricing. It creates a strong incentive to recommend three-year commitments, which book a large paper saving immediately and hand you a rigid cost base right when a growing company most needs flexibility. If you use a provider on that model, exclude commitment purchases from the fee basis.

And if you are about to raise, or a buyer has asked for a security report, do the work in the order that unblocks revenue. Infrastructure cost shows up in diligence, but it has never killed a round on its own. A missing SOC 2 stalls deals every week. If you have one quarter of engineering slack and both problems, spend it on the one your customers are asking about, and tell us honestly which that is when you get in touch. Ongoing cost governance is a reasonable thing to fold into a retainer once the first pass is done, but it is a poor reason to start one.