An AWS bill rarely grows because the workload grew. It grows because nothing ever gets turned off, resources are provisioned for a peak that never returns, and storage sits on the wrong tier for years. The good news is that most of that is recoverable without touching reliability, as long as you work in the right order. Here is the sequence we use, including on our own account, where it cut the bill by more than half with zero downtime.
1. Start with a read-only audit, not a rebuild
Before changing anything, trace every line of the bill to the thing that uses it. Cost Explorer grouped by service, then by usage type, shows where the money actually goes. Turn on cost allocation tags so spend maps to teams and environments. The goal of this step is a list of suspects, not action. You cannot safely cut what you cannot attribute.
2. Right-size before you commit to anything
Oversized compute is the most common waste. AWS Compute Optimizer flags EC2 instances and volumes that are larger than their real usage. Right-size those first. The reason this comes before any Savings Plan is simple: if you commit to a one or three year term on an oversized fleet, you lock in the waste.
3. Turn off what nobody uses at night
Development, test, and staging environments rarely need to run outside business hours. A schedule that stops them in the evening and starts them in the morning removes roughly two thirds of their runtime cost with no effect on production. This alone often pays for the rest of the exercise.
4. Delete the orphans
Every long-lived account accumulates resources that are attached to nothing and owned by no one. The usual list:
- Unattached EBS volumes and the snapshots of instances that no longer exist
- Idle load balancers with no healthy targets
- Elastic IPs that are allocated but not associated, which bill by the hour
- NAT gateways left running in a VPC that no longer needs them
None of these serve traffic. All of them bill. Removing them is the safest saving available.
5. Put storage on the right tier
Most S3 data is written once and read rarely after the first weeks. S3 Intelligent-Tiering moves objects to cheaper tiers automatically based on access, and lifecycle rules can push genuinely cold data to Glacier for a fraction of the standard price. The same logic applies to old EBS snapshots and logs. Match the tier to how often the data is actually read.
6. Commit last, once the shape is stable
Only after right-sizing and cleanup should you buy Savings Plans or Reserved Instances for the steady baseline that remains. Commitments reward a workload you understand. They punish one you have not cleaned up yet. Finish by setting AWS Budgets with alerts so the next drift is caught in the month it starts, not at the next annual review.
The one rule underneath all of this
Measure before you cut, and change one thing at a time. Reliability is the point of the platform, so no saving is worth an outage. If you would rather not run this yourself, a read-only cost audit is where we start with every AWS client, and it does not require handing over write access.