The AWS cost optimization checklist we run before touching commitments

The fastest way to make a cloud bill permanently worse is to commit to Savings Plans before you have cleaned up what you are running. A one-year or three-year commitment against oversized instances simply locks in the waste at a discount. So before we model any commitment, we work through the same checklist on the live estate.

Start with what nobody is using

Every environment we review has resources that cost money and serve no traffic. They are not architectural problems, they are housekeeping, and they are the cheapest savings available because nothing has to be redesigned to remove them.

Unattached EBS volumes and the snapshots of long-deleted instances

Idle load balancers left behind by retired services

Elastic IPs that are allocated but not associated

Old AMIs and backup copies with no lifecycle policy

Non-production environments running 24/7 for a team that works 40 hours a week

Scheduling non-production environments down outside working hours is usually the single largest quick win. An environment that runs 50 hours a week instead of 168 costs roughly 70% less, and for development and staging that trade-off is almost always acceptable.

Then rightsize against real utilization

Instance sizes are usually chosen once, at launch, based on a guess. Two years later the workload has changed but the instance type has not. We pull at least two weeks of CloudWatch data — CPU, memory where the agent is installed, network and disk — and compare peak and sustained utilization against what is provisioned.

Rightsizing is not about running everything hot. It is about knowing your actual headroom instead of paying for headroom you assumed you needed.

Databases deserve particular attention here, because they are often the largest line item and the least frequently revisited. Moving from a general-purpose instance to a Graviton-based equivalent, or from provisioned IOPS to gp3 storage, routinely cuts database cost by a third with no application change at all.

Only then model commitments

Once the estate reflects what you actually need, the baseline is stable enough to commit against. We model Compute Savings Plans against that cleaned-up baseline, deliberately under-committing to the portion of usage we are confident is permanent, and leaving variable workloads on on-demand or Spot.

The last step is governance, because none of this holds without it. Tagging standards make cost attributable to a team, budgets and anomaly alerts catch regressions within days rather than at invoice time, and a monthly review keeps the conversation about cost ownership rather than surprise.