How to Reduce Your AWS Bill: A 30-Day Step-by-Step Guide

Almost every failed AWS cost programme I have seen failed on sequence rather than effort. A team gets a mandate to lower the AWS bill, sees that Savings Plans advertise the largest headline discount, buys coverage in week one, and then discovers in month three that a third of the committed spend is covering instances nobody needed. The commitment is not refundable. They have converted removable waste into contractual waste.

Work in this order instead: find the spend, delete what nobody is using, right-size what remains, and only then commit to the baseline that survived all three steps. Each step shrinks the thing the next step operates on, which is exactly what you want, because commitments are the only step you cannot undo.

The first two steps are free, reversible, and need no approval from finance. That matters when you are trying to build credibility for a cost programme: you can show a real reduction on the next invoice before you have asked anyone to sign a one-year commitment.

You cannot reduce a bill you cannot read. The AWS console bill by service is not enough, because the service-level view hides the two things that matter most: which team or workload owns the spend, and which usage type inside a service is driving it. A line that says EC2-Other is $40,000 tells you nothing until you can see that most of it is NAT Gateway data processing.

Enable Cost Explorer and switch on daily Cost and Usage Reports delivered to S3. CUR is the granular, hourly, resource-level dataset. Cost Explorer is the fast interactive view. You want both: Cost Explorer to answer questions in minutes, CUR to answer questions the console cannot express.

Then fix tagging, which is the step everyone postpones and everyone regrets postponing. Without an owner tag and an environment tag enforced on new resources, every future conversation about a cost spike ends in a hunt for whose thing it is. Activate the tags as cost allocation tags in the Billing console, otherwise they do not appear in CUR at all.

This is the most satisfying week, because everything here is spend on resources that are not serving traffic, not attached to anything, or not being read by anyone. Removing them cannot degrade performance, because they are not doing anything.

The reason this waste accumulates is not carelessness, it is asymmetry. Creating a resource is one click, and the person who created it moves on. Nothing in AWS ever tells you that the volume you detached eight months ago is still billing. It just keeps billing quietly, forever, in a line item nobody itemises.

Work through the list below systematically rather than opportunistically. On an account that has never been swept, this pass alone commonly finds a meaningful percentage of the bill, and it takes a day or two.

Right-sizing is where you reduce the cost of things you are genuinely using, which means it does carry risk and needs to be staged. The rule is to change one dimension at a time, in non-production first, with a metric you are watching and a rollback you have already written down.

Start with AWS Compute Optimizer, which analyses CloudWatch metrics and produces instance recommendations. Treat its output as a candidate list rather than a work order: it does not know about your seasonal peak, your failover headroom, or the batch job that runs on the last day of the month. Cross-check every recommendation against at least a full business cycle of metrics.

The largest structural saving in compute right now is usually architectural rather than dimensional. Moving a workload from x86 to Graviton, where AWS advertises "up to 40 percent better price performance" for equivalent instances, is often a bigger lever than shaving one instance size, and for interpreted languages and containerised services the migration is frequently just a rebuild.

When a team tells me they have already optimized and the bill is still high, the unexamined spend is usually data transfer. It hides badly. Much of it lands in a usage type called EC2-Other rather than in a service called "data transfer", so a service-level view of the bill simply does not show it as a category.

NAT Gateway is the sharpest edge here. It carries an hourly charge per gateway plus a per-GB data processing charge on everything that flows through it, and that per-GB charge applies even to traffic heading to AWS services in the same region. A chatty service pulling from S3 or DynamoDB through a NAT Gateway is paying a processing fee on every byte, for no reason.

The fix is usually VPC endpoints. A gateway endpoint for S3 and DynamoDB costs nothing and takes that traffic off the NAT path entirely. Interface endpoints for other services carry their own hourly and per-GB charges, so those need the arithmetic done rather than assumed, but the S3 and DynamoDB gateway endpoints are close to a free win.

Now, and only now, the discount instruments make sense. AWS advertises savings of "up to 72 percent" versus On-Demand on both Savings Plans and Reserved Instances, and after three weeks of cleanup you are finally applying that discount to a fleet you actually intend to keep.

Compute Savings Plans are the flexible option: they apply across instance family, size, region, operating system, and across EC2, Fargate and Lambda, at a slightly lower discount than the alternatives. EC2 Instance Savings Plans lock you to a family in a region for a higher discount. Databases have their own instrument since 2 December 2025: Database Savings Plans cover Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Timestream, Neptune, Keyspaces, DMS and OpenSearch at up to 35%. Redshift is not covered and still needs Reserved Nodes.

Do not buy your full baseline in one purchase. Cover the portion of usage you are most confident about, typically the floor of your last 60 to 90 days of production usage, and add coverage in tranches as confidence grows. Staggered expiry dates are also a real benefit, because it means you are never renegotiating your entire commitment position in a single month.

A one-time cut is not a result, it is a photograph. Every account I have watched regress had the same story: a successful optimization sprint, a proud slide deck, then nine months of new services launched by people who were not in the room. Costs return to trend within a quarter or two.

The durable version is a cadence with named owners and a standing agenda. It does not need to be heavy. It needs to be regular, and it needs someone accountable for each line rather than a diffuse sense of shared responsibility.

The other half of durability is prevention. Cost information has to reach engineers at the moment they are making the decision, not four weeks later in a finance review. That means anomaly alerts in the team channel, budgets per team, and cost estimates in infrastructure pull requests where the tooling supports it.

On an AWS account that has never been through a structured cost exercise, 20 to 35 percent within 30 days is a realistic range, and the majority of it comes from the free weeks rather than the commitment week. On an account that has already been optimized once, expect single digits and a lot more effort per percentage point.

What you should not expect is a single big lever. The bill comes down through a few dozen small, boring, individually unimpressive actions, which is precisely why it is usually left undone. Nobody gets excited about deleting snapshots. The snapshots keep billing anyway.

If you want the compressed version: turn on the data, delete what is idle, shrink what is oversized, commit to what is left, and put a monthly meeting in the calendar so it does not all come back.