How to cut an AWS bill that keeps climbing

The short answer

To cut an AWS bill that keeps climbing, work in a fixed order and do not skip a step. Get visibility before you touch anything, delete what is idle, right-size what is left against real utilization, and only then buy commitments. Most teams do this backwards: they buy Savings Plans first, lock in a discount on capacity they are about to delete, and wonder why the bill barely moved.

1. Visibility. Tag spend and put it on a per-team, per-service dashboard. You cannot cut what you cannot see.
2. Cleanup. Delete idle resources and schedule non-production off outside working hours.
3. Right-sizing. Match instance and database sizes to real utilization with headroom, not to a guess.
4. Commitments last. Buy Savings Plans and Reserved Instances only once the shape of spend is stable.

The rest of this page is how I run each step, drawn from a multi-client cost program I ran across Fintech, E-Commerce, and SaaS accounts.

Why the usual order is backwards

The instinct is to reach for the biggest visible lever first, which is usually a Savings Plan, because it promises a percentage off with one purchase. The problem is that a commitment is a bet that you will keep running that capacity for one to three years. If you commit before cleanup and right-sizing, you are paying up front to keep resources you should be deleting or shrinking. Order matters because each earlier step changes the baseline the next step measures against.

Step 1: visibility

You cannot cut what you cannot see, and on more than one account the only cost visibility was a monthly PDF from finance. Turn on cost allocation tags, enforce a small set of them (team, service, environment), and build a per-team and per-service view so spend has an owner. Cost Explorer plus tags gets you most of the way; a dashboard on top gives engineering leads and the CFO the same picture. Visibility is not the cut, but every later step needs it to target the right resource.

Step 2: cleanup

The biggest early wins are almost always the dullest: idle EC2 instances nobody remembers launching, oversized RDS left over from a load test months ago, unattached EBS volumes, and unused Elastic IPs. Deleting them is pure waste removal with no downside. The other fast win is scheduling: shutting non-production environments down nights and weekends is often one of the biggest recurring savings on an account, and it is a couple of hours of work with Lambda and EventBridge. None of this touches production behavior, which is why it goes first.

Step 3: right-sizing

Right-sizing is where you match what is running to what is used, and the trap is sizing off a single reading. Size against P95 utilization over a representative window, not a spot check, and leave headroom so you cut the fat without clipping real peaks. RDS is a frequent offender, often running at a fraction of its provisioned capacity. Do EC2, RDS, and ElastiCache in the same pass, and keep the metric window wide enough to catch weekly and monthly cycles.

Step 4: commitments last

Now that the baseline is clean and stable, commitments turn steady usage into a discount. Savings Plans fit compute that shifts across instance families; Reserved Instances fit stable workloads like a predictable RDS instance. Model the term and payment option before buying, because locking a multi-year plan to the wrong instance family is an expensive mistake to unwind. Done in this order, on a cost program I ran, Savings Plan coverage went from 0% to about 78% of eligible compute where it actually fit.

Unit cost is the real metric

Absolute spend is the wrong number to obsess over once you are growing. The metric that tells you whether the platform is healthy is unit cost: cost per order, per request, per active tenant. A bill that rises while cost per order falls is a business scaling well. A bill that is flat while cost per order climbs is waste hiding behind a stable total. Pick the unit that matches how the business makes money and track it, so a cost conversation is about efficiency, not just the top-line figure.

Guardrails so it stays down

Cleanup is a one-time event; guardrails are what keep the bill from drifting back up. Set AWS Budgets with SNS alerts at 80% and 100% of plan, turn on cost anomaly detection, and enforce tagging with Config rules so untagged spend cannot hide. Add S3 lifecycle policies (Infrequent Access at 30 days, Glacier at 90) for storage that quietly accumulates. Without these, an account drifts a few percent a month until you are back where you started.

What I will not promise

I will not quote a savings percentage before I have seen your billing and utilization data. The 30 to 40% typical range, and the up to 55% on a badly drifted account, are outcomes of what was already wrong, not a rate I can pledge sight unseen. What I will stand behind is a documented track record: ₹50L+/year in AWS waste removed for clients (~$60K+/year), from cost and reliability audits. A number promised before the data is a sales tactic, not an engineering estimate.

A reference FinOps setup on AWS

A pragmatic AWS-native shape needs no third-party platform to start. Cost allocation tags plus Cost Explorer feed a QuickSight dashboard split by team, service, and environment. AWS Budgets with SNS alerts and cost anomaly detection provide the guardrails. A small set of Lambda schedulers driven by EventBridge shut non-production down on a timetable, and Config rules keep tagging honest. Savings Plans and Reserved Instances sit on top only after the account is clean, so the discount is applied to capacity you actually intend to keep.

Common mistakes

• Buying Savings Plans first, before cleanup and right-sizing.
• Chasing the absolute bill instead of unit cost per order or request.
• Right-sizing off a single reading instead of P95 over a representative window with headroom.
• Cleaning up once, with no budgets, anomaly alerts, or tagging enforcement.
• Committing to a long term without modeling the instance family and payment option.
• Promising a savings percentage before anyone has seen the billing data.