How to cut your AWS bill by 30 percent: the ordered playbook

Quick answer

Run the levers in this order: delete, then resize, then schedule, then commit. Step 1, delete idle and orphaned resources (unattached EBS volumes at $0.08/GB-month, idle public IPv4 at $0.005/hr, unused load balancers at about $16/month each): typically 5 to 12 percent. Step 2, right-size over-provisioned EC2 and RDS: 10 to 20 percent of compute. Step 3, schedule non-production off outside working hours: 60 to 70 percent of dev/test compute. Step 4, buy Savings Plans over the reduced baseline: 20 to 30 percent more on what remains. Committing before deleting locks in waste, so never reverse the order.

Thirty percent is not an aggressive target on an AWS account that has never been through a cost pass. It is roughly what falls out of four ordered levers applied in sequence. The order matters more than the list, because each step shrinks the baseline the next one operates on. Buy a three year commitment first and you have just locked in the waste you were about to delete.

The sequence and what each step returns

Step	Lever	Typical saving	Effort
1	Delete idle and orphaned	5 to 12% of total	Days
2	Right-size compute and databases	10 to 20% of compute	2 to 4 weeks
3	Schedule non-production	60 to 70% of dev/test compute	1 week
4	Commit with Savings Plans	20 to 30% of remaining steady compute	1 day

Step 1: delete what nothing is using

Start here because it is pure margin with no performance risk. The standard hit list on AWS is unattached EBS volumes (gp3 bills $0.08 per GB-month whether or not a instance is attached, so a forgotten 500 GB volume is $40 a month), public IPv4 addresses (every one bills $0.005 per hour, about $3.60 a month, attached or not, since the 2024 pricing change), load balancers with no healthy targets (an ALB starts around $16.43 a month before LCU charges), old snapshots at $0.05 per GB-month, and NAT gateways in subnets that no longer route traffic at $0.045 per hour plus $0.045 per GB. Work the orphaned resource cleanup list account by account and expect 5 to 12 percent of total spend on a first pass.

The risk here is deleting something that looks idle but is a quarterly job or a disaster recovery asset. The control is a two stage process: tag candidates, wait 14 days, then delete. Snapshot before deleting any volume so a mistake costs $0.05 per GB-month rather than a data loss incident.

Step 2: right-size compute and databases

Most EC2 fleets are sized for a launch day that never repeated. Pull 14 days of CloudWatch data and flag anything whose p95 CPU is under 25 percent and whose p95 memory is under 50 percent. Dropping an m5.2xlarge at $0.384 per hour to an m5.xlarge at $0.192 halves that line, about $140 a month per instance. Do the same on RDS, where a db.m5.2xlarge to db.m5.xlarge step saves roughly $250 a month. Follow the guardrails in right-sizing without hurting performance: one size step at a time, memory bound workloads are resized on memory not CPU, and anything latency sensitive gets a week of observation before the next step.

Step 3: schedule everything that does not need to run at 3am

Development, staging, QA, and sandbox accounts are often 30 to 40 percent of an AWS bill and are used roughly 50 hours of the 168 hours in a week. Stopping them outside a 7am to 8pm weekday window removes about 70 percent of their runtime. On $30,000 a month of non-production compute that is more than $20,000 a month. Use instance schedulers or autoscaling group schedules, and note that stopped EC2 instances still bill their EBS volumes, so the saving is on compute only. Details in scheduled scaling for dev environments.

Step 4: commit only over the new baseline

Now, and only now, buy commitments. A one year no upfront Compute Savings Plan typically discounts on demand EC2 by around 28 percent, and a three year all upfront plan reaches the 60s. Cover 70 to 80 percent of your steady state hourly compute spend and leave the volatile top slice on demand or on Spot. The decision framework is in reserved instances versus savings plans, and the ongoing metric to watch is in coverage versus utilization.

Adding it up

On a $100,000 a month account with a typical shape, step 1 returns about $8,000, step 2 about $9,000 on a $60,000 compute base, step 3 about $12,000 on a $35,000 non-production base after the earlier steps overlap, and step 4 about $8,000 on what is left. Overlaps mean you do not simply add them, but 30 percent is a realistic landing point on a first pass, and the first three steps carry no lock in.

The risks worth naming

Deleting a resource that turns out to be load bearing is the main operational risk, mitigated by the tag and wait pattern. Right-sizing too aggressively causes latency regressions, mitigated by single step moves and a rollback plan. Scheduling breaks nightly CI, mitigated by exempting the CI account. Over-committing is the only lever with a multi year financial consequence, which is precisely why it comes last.

Keeping the 30 percent

Savings decay. Without a gate, the next quarter of Terraform merges rebuilds what you deleted. Price infrastructure changes in the pull request so a new oversized instance or an unscheduled environment shows its monthly cost before merge. Pair the cleanup with the ongoing discipline in the reduce cloud bill checklist and estimate every change against the resource catalog.

FAQ

Is a 30 percent AWS reduction realistic?

On an account that has never been through a structured cost pass, yes. Four ordered levers typically get there: deleting idle and orphaned resources (5 to 12 percent of total), right-sizing over-provisioned compute and databases (10 to 20 percent of compute), scheduling non-production environments off outside working hours (60 to 70 percent of dev/test compute), and buying Savings Plans over the reduced baseline (20 to 30 percent of remaining steady compute).

What order should I apply AWS cost levers in?

Delete, then resize, then schedule, then commit. Each step shrinks the baseline the next one operates on. Buying a three year commitment before deleting waste locks in that waste for the full term, which is the single most expensive sequencing mistake in cloud cost reduction. Commitments should always be the last lever, sized against the post-cleanup baseline.

What are the quickest AWS savings with no performance risk?

Deleting resources nothing is using: unattached EBS volumes at $0.08 per GB-month for gp3, public IPv4 addresses at $0.005 per hour (about $3.60 a month each whether attached or not), load balancers with no healthy targets starting around $16.43 a month, old snapshots at $0.05 per GB-month, and NAT gateways in subnets that no longer route traffic at $0.045 per hour plus $0.045 per GB processed.

How much can scheduling non-production environments save?

Non-production is often 30 to 40 percent of an AWS bill and is genuinely used for about 50 of the 168 hours in a week. Stopping it outside a 7am to 8pm weekday window removes roughly 70 percent of its compute runtime. On $30,000 a month of non-production compute that is over $20,000 a month. Note that stopped EC2 instances still bill their attached EBS volumes, so the saving is on compute only.

What are the risks of an aggressive AWS cost cut?

Deleting a resource that turns out to be load bearing, such as a quarterly job's volume or a disaster recovery asset, mitigated by tagging candidates and waiting 14 days before deletion. Right-sizing too aggressively causes latency regressions, mitigated by single size steps with a week of observation. Over-committing is the only lever with a multi year financial consequence, which is why it comes last.

How do I stop the savings from decaying?

Put a cost gate in front of infrastructure changes. Without one, the next quarter of Terraform merges quietly rebuilds what you deleted: new oversized instances, new unscheduled environments, new volumes. C3X prices Terraform changes in the pull request so the monthly cost of a change is visible before merge, which keeps a one time 30 percent cut from eroding back into the baseline over two or three quarters.

What to do next

Cut the bill, then keep it cut. C3X prices your Terraform changes before merge against a live resource catalog. Start with the quickstart.