How to Reduce AWS Costs: A Complete Guide

Understanding Your AWS Bill

Almost all AWS waste comes down to one thing: resources that run when nobody is using them. Your dev, staging, and QA environments are the worst offenders. They sit there at full price overnight and all weekend while everyone who touches them is asleep or off the clock.

So before you touch a single instance, find out where the money goes. Open Cost Explorer and group by service. For most teams EC2 and RDS are the whole story, and almost everything else is a rounding error. Then figure out how much of that EC2 and RDS spend is non-production. The gap between what you pay for and what you actually use is the number you are trying to shrink.

Right-Sizing Instances

Over-provisioning is the classic mistake. Someone picks an m5.xlarge during setup, the workload turns out to need a fraction of that, and the bill never gets revisited. If a box is sitting at 5% CPU, it could probably be an m5.large, and a burstable t3.medium might handle it fine.

Pull the last 30 days of CloudWatch metrics first: CPU, memory, network. AWS Compute Optimizer will do the analysis for you and hand back specific recommendations, which beats eyeballing graphs. When you do resize, go down one step at a time and watch what happens. Dropping two sizes in one move is how you end up firefighting a latency spike at 2am instead of saving money. For anything with spiky or variable CPU, the t3/t4g burstable family is usually a better fit than a fixed-size instance.

Reserved Instances and Savings Plans

For workloads that genuinely run 24/7 with predictable capacity, committing to a 1-year or 3-year term cuts the rate by 30 to 60% versus on-demand. The trade-off is flexibility, so it matters which instrument you pick.

Reserved Instances lock you to a specific instance type and region. Savings Plans are looser: they apply automatically across instance families, regions, and even some services, so you are not stuck if your architecture shifts. Unless you have a very specific reason to use RIs, Savings Plans are the safer default. Either way, start with a 1-year no-upfront commitment. That keeps your downside small while you learn how steady your usage actually is.

The discipline here is simple. Only commit to capacity you are certain will run continuously, which in practice means production. For everything else, a commitment just locks in spend on resources you should be turning off anyway.

Spot Instances

Spot Instances are spare AWS capacity sold at up to 90% off on-demand. The catch is that AWS can take them back with two minutes of warning, so they only work for things that can survive being killed mid-run: batch jobs, CI/CD pipelines, throwaway dev environments. Anything stateful, any database, anything that has to stay up, leave on on-demand.

If you want to lean on Spot at scale, run a Spot Fleet or EC2 Auto Scaling with mixed instance types so a single capacity reclaim does not take out your whole pool, and keep an on-demand baseline underneath for the parts that cannot blink.

Resource Scheduling

If you only do one thing on this list, schedule your non-prod. It is the fastest money you will ever save, and it costs you nothing in performance.

The math makes it obvious. A week has 168 hours. If your dev and staging resources only need to be up during business hours, they are idle for roughly 128 of them. Turn them off nights and weekends and you cut about 65% of their runtime costs without touching a single workload that anyone relies on. This is not optimization in the clever sense. It is just refusing to pay for time you do not use.

How you actually do it is the only real decision:

• Manual. Log in and stop and start things by hand. It is free, and it works exactly until the one Friday someone forgets, at which point you have paid for a whole idle weekend. Nobody sustains this.
• DIY with Lambda + EventBridge. Write your own automation. Full control, and now you own a small internal product: edge cases, on-call when the schedule misfires, the lot.
• Managed tools. Something like ParkMyAWS runs the scheduling for you. Connect the account, pick resources, set a schedule, done in minutes.

Whatever you choose, scheduling is the highest-ROI move available because it deletes pure waste rather than shaving a few percent off something useful.

Storage Optimization

Storage is the cost that creeps. Volumes, snapshots, and S3 objects pile up quietly, and nobody notices until the line item is suddenly real money.

The first thing to hunt down is unattached EBS volumes. These get orphaned when instances are terminated, and they keep billing every month for storage nothing is reading. Old EBS snapshots are the same story, so prune the ones you no longer need. On the S3 side, set lifecycle policies to push aging objects into cheaper classes like S3 Infrequent Access or S3 Glacier, and for buckets whose access patterns you cannot predict, let S3 Intelligent-Tiering make that call automatically.

Monitoring and Alerts

None of this stays fixed. You can do a clean-up sweep today and watch the bill climb right back as teams spin up new resources next quarter, which is why monitoring is part of the work rather than a follow-up to it.

Set up AWS Budgets with alerts at 80% and 100% so a spending spike reaches you while it is still cheap to fix. Check Cost Explorer weekly to spot trends and anomalies before they compound. And tag everything with environment, team, and project, because cost allocation only works when you can attribute spend, and the team that owns a resource is the only one positioned to question whether it should exist.

Start with the Quick Wins

You do not have to do all of this at once, and you should not try. There is a clear order of impact versus effort:

1. Schedule non-production resources. Immediate 65% savings on dev and staging for almost no work.
2. Right-size instances. Use Compute Optimizer data to walk over-provisioned boxes down a size.
3. Clean up storage. Delete unattached volumes, set lifecycle policies, prune snapshots.
4. Reserved Instances or Savings Plans. Lock in rates on the production workloads you know will keep running.

For most teams, scheduling alone is where the real return shows up. Get that running first, then layer right-sizing and commitment discounts on top of production once the obvious waste is gone.