How to Cut Your AWS Bill by 40% (Actual Steps)

Most AWS bills carry 20–50% waste. Not because anyone was careless, but because cloud spend grows quietly: an instance sized for a launch spike never gets scaled back, a test environment runs nights and weekends, a terabyte of snapshots from a deleted project just sits there billing you. The good news is that finding and removing that waste follows a repeatable order, and most of the savings come from steps that carry zero commitment risk.

This is the exact sequence we work through when we audit an account, highest return first. Do them in order: cleanup before right-sizing, right-sizing before commitments. Commit too early and you lock in a multi-year discount on resources you should have deleted.

1. Kill idle and orphaned resources

This is the fastest money and the safest, you are deleting things nothing depends on. Cloud accounts accumulate orphaned resources because deleting the parent (an instance, a project) often leaves the children (volumes, snapshots, IPs) behind, still billing.

The usual suspects, roughly in order of how often they surprise people:

• Unattached EBS volumes, the instance is gone but its disk lives on, billed per GB-month
• Stale EBS snapshots and old AMIs, backups of resources that no longer exist
• Unassociated Elastic IPs, AWS charges hourly for allocated IPs that are not attached to a running instance
• Idle load balancers with no healthy targets behind them
• NAT gateways in environments that no longer need outbound internet (these are quietly expensive)
• Old, low-access data sitting in S3 Standard instead of a cheaper storage class

You do not have to hunt manually. AWS Cost Explorer shows where the money goes, AWS Trusted Advisor flags idle and underutilized resources, and AWS Compute Optimizer analyzes utilization to recommend actions. Start there before writing any custom tooling.

2. Right-size compute

The default instinct is to over-provision "to be safe, " and it is the single biggest source of ongoing waste. The fix is boring and effective: look at actual utilization. Pull CloudWatch metrics over two to four weeks. If an instance never crosses ~20–40% CPU and memory under real load, it is a candidate to drop an instance size, which typically halves its cost with no user-visible impact.

Two things make right-sizing safe. First, change one size at a time and watch the metrics for a few days before the next step. Second, put autoscaling in front of anything with variable load, so you are sizing for the typical case and letting the platform absorb spikes, rather than paying for peak capacity 24/7.

Right-sizing is not about running things hot. It is about matching capacity to real demand, then letting autoscaling handle the spikes.

Also look at generation and family. Moving from an older instance generation to the current one (for example, an older general-purpose family to the latest, or from x86 to Graviton where your workload supports it) often gives better performance per dollar for a one-time migration effort.

3. Schedule non-production environments

Dev, staging, QA, and demo environments almost never need to run around the clock. If nobody touches them nights and weekends, they should not be running then. Business hours are roughly 12 hours × 5 days = 60 of the 168 hours in a week. Stopping non-prod outside those hours cuts its compute cost by roughly 60–65%.

You do not need anything fancy, an EventBridge schedule that triggers a Lambda to stop and start instances, or the managed AWS Instance Scheduler solution, handles it:

# EventBridge rule -> Lambda, or the managed AWS Instance Scheduler
# Stop non-prod at 8pm, start at 8am, weekdays only

# Stop (cron: 0 20 ? * MON-FRI *)
aws ec2 stop-instances --instance-ids i-0abc123 i-0def456

# Start (cron: 0 8 ? * MON-FRI *)
aws ec2 start-instances --instance-ids i-0abc123 i-0def456

Tag the instances that are safe to stop (for example, env=dev) and target the scheduler by tag, so new dev resources are covered automatically without editing the schedule.

4. Commit to Savings Plans, after the cleanup

Now, and only now, look at commitment discounts. Compute Savings Plans and Reserved Instances trade a 1- or 3-year commitment for 30–70% off on-demand pricing. The reason this comes fourth is simple: commitments apply to the baseline you run, so if you commit before cleaning up, you have locked in a discounted price on waste.

For most teams, Compute Savings Plans are the better default over Reserved Instances: they discount EC2, Fargate, and Lambda usage regardless of instance family or region, so a later right-sizing or migration does not strand your commitment. Commit to the stable floor of your usage, the amount you are confident you will always run, and leave the variable top layer on-demand or covered by autoscaling.

The numbers above are illustrative, not a promise, your mix of services and how far the waste has grown determines the real figure. But the shape is consistent across the accounts we see: most of the reduction lands before you commit a single dollar to a Savings Plan.

5. Set up guardrails so it stays fixed

Optimization is not a one-time project. Without guardrails, waste creeps back the moment attention moves elsewhere, a new team spins up oversized instances, a proof-of-concept never gets torn down. Three habits keep the savings:

• Cost-allocation tags on every resource (team, project, environment) so you can see who spends what
• AWS Budgets with anomaly detection, so a cost spike pings you before the invoice does
• A short monthly cost review, 30 minutes to catch drift while it is small

Tagging is the foundation: you cannot manage spend you cannot attribute. Enforce it with tag policies so untagged resources are the exception, not the rule.

The realistic outcome

Working through these five steps on an unoptimized account commonly lands a 30–50% reduction, and the majority of it comes from steps 1 to 3, which carry no lock-in and no stability risk. Commitments are the icing, not the cake. If you do nothing else, delete the orphans and right-size the obvious over-provisioning; that alone usually pays for the afternoon it takes.

If you want a second set of eyes, our FinOps and cost optimization work starts with a free assessment that quantifies the opportunity before you spend anything, and if the number is not worth acting on, we will tell you that too. For teams rethinking the underlying setup, well-architected AWS architecture prevents most of this waste from accumulating in the first place.