You can't cut what you can't see. Before any optimization, you must attribute every dollar to a project, an environment, a team. Without tags, Cost Explorer shows you one opaque block “EC2: $12,000” and you're blind.
Enable Cost Allocation Tags in the billing console, otherwise your tags won't show up in reports. It's the step everyone forgets.
Always in this order: clean up the obvious waste first (free, no risk), then commit on what remains.
Staging environments running nights and weekends, detached EBS volumes, unused elastic IPs. Immediate gain, zero risk.
Oversized instances running at 5-10% CPU. Dropping one size halves the line, with no perceived impact.
On stable, predictable load (the baseline running 24/7), a 1-year commitment pays -40% to -50% vs on-demand.
For interruption-tolerant tasks (batch, workers, CI): up to -90%. Never for the database or checkout.
Rightsizing is done on metrics, not on a hunch. Look at average CPU and memory over 30 days: an instance at 6% CPU for a month is an obvious candidate.
Drop one size at a time and watch for 48h. AWS Compute Optimizer gives ready-made recommendations — use them as a starting point, not as gospel.
A client store, monthly bill before/after the playbook. No feature removed, no perf degradation — just waste cut and commitments placed well.
From $11,800 to $5,900 a month — exactly half. The first two (free) levers did most of the work.
The real trap isn't the first optimization, it's the drift. Hidden costs quietly return — I wrote a separate piece on it: the 5 lines that wreck your bill.
Once the waste is cleaned up, the question becomes: what to commit to, and how? Three models coexist and I almost always combine them. The rule I keep repeating to teams: commit on what's predictable, keep on-demand for breathing room, and push the disposable onto Spot.
Commit in $/hour, not per instance.
The older model, still useful.
AWS's official comparison table is crisp on percentages and flexibility: Compute Savings Plans and Reserved Instances. Key point: a Savings Plan never applies to Spot usage or to what's already covered by an RI.
Spot gives access to AWS's spare capacity at up to -90% vs on-demand, in exchange for a single constraint: the instance can be reclaimed with two minutes' notice. So never the database or checkout — but perfect for batch, workers, CI, rendering. The key to surviving interruptions is diversity: AWS recommends being flexible across at least 10 instance types per workload and using the `price-capacity-optimized` allocation strategy in an Auto Scaling group.
Never fail Spot over to on-demand "to compensate": AWS explicitly discourages it, it can actually trigger more interruptions on your other Spot instances. Fault-tolerant architecture first, savings second. Details: Best practices for Amazon EC2 Spot.
After compute, two levers almost always slip under the radar even though they're nearly free to enable: the right S3 storage class and the migration to Graviton.
On most buckets, a large share of objects is never read again after a few weeks: logs, exports, client uploads, backups. Leaving them in S3 Standard means paying the most expensive rate for dormant data. S3 Intelligent-Tiering fixes this hands-off: it automatically moves an object to a cheaper tier after 30 days without access, then to Archive Instant Access after 90 days — and pulls it back instantly if it's read again.
Intelligent-Tiering shines when access patterns are unknown or shifting — the default case on a scale-up. The mechanism and exact thresholds are documented here: How S3 Intelligent-Tiering works. For known lifespans (logs to delete at 90 days), a plain lifecycle policy stays simpler and cheaper.
Graviton instances (AWS's in-house ARM processor) cost up to 20% less than their x86 equivalents, for the same performance and up to 60% less energy. On a baseline running 24/7, that's a cut that stacks with the Savings Plan on top. The migration cost? Often zero for managed services (RDS, ElastiCache) or multi-arch containerized workloads; sometimes a rebuild for natively compiled code.
I always start with managed services and stateless workers: low risk, immediate gain. The official figures and the estimation tool are here: AWS Graviton.
A budget with an 80% alert catches the overrun — but too late, and only if you set the threshold right. AWS Cost Anomaly Detection goes further: a machine learning model learns your normal spend pattern (per service, account, tag) and alerts you when a line deviates, with root-cause analysis by service, account, region or usage type. That's what catches a forgotten test instance or a bucket blowing up before it costs a whole month.
The service is free and sets up in minutes with AWS-managed monitors that automatically track new accounts and tags. Getting started: Getting started with AWS Cost Anomaly Detection.