AWS Cloud Cost Optimization Guide

Cost work fails when it starts with commitments. Buying savings plans for a workload you are about to re-architect locks in the wrong shape for a year. The order below exists because each step changes the input to the next.

Step 1 — Attribution before action

You cannot manage spend you cannot attribute. Enforce a small tag set — service, environment, team, cost-centre — through Terraform and reject untagged resources in CI. Enable Cost and Usage Reports and split shared costs (networking, cluster overhead, observability) with an explicit rule rather than leaving them unallocated.

Step 2 — Remove waste

• Unattached EBS volumes, old snapshots and orphaned load balancers.
• Idle non-production environments running 24/7 — schedule them down outside working hours.
• Over-retained logs: CloudWatch retention set to 'never expire' is a slow, compounding bill.
• NAT Gateway data processing for traffic that should use VPC endpoints.
• Cross-AZ chatter between services that could be zone-aware.

Step 3 — Rightsize against observed usage

Rightsize using p95 utilisation over at least four weeks, with explicit headroom, not average utilisation over a week. Do the same for managed databases: an RDS instance sized for a launch-day spike two years ago is one of the most reliable savings we find. On Kubernetes, container requests are usually the real target — cluster cost is driven by requests, not usage.

Step 4 — Storage and data transfer

• S3 lifecycle policies and Intelligent-Tiering for objects with unpredictable access.
• gp2 to gp3 migration, with IOPS provisioned only where measured.
• CloudFront in front of origins serving repeated content, to cut egress.
• VPC endpoints for S3, ECR and other high-volume AWS services.

Step 5 — Commitments, last

Only after the workload shape is stable should you commit. Cover the floor of your usage, not the peak: compute savings plans for the steady baseline, Spot or on-demand for the variable layer. Re-evaluate quarterly, and never commit to capacity for a system with a migration scheduled inside the term.

Step 6 — Keep it from regressing

Savings decay without guardrails. Budgets with alerts per team, anomaly detection on unusual spend, cost estimation on infrastructure pull requests, and a monthly review where spend is discussed next to usage. The goal is not a one-off cut; it is making cost a visible property of engineering decisions.

The architectural drivers

Everything above is operational. The large numbers usually sit in architecture: chatty service-to-service calls across zones, a database doing work that belongs in a cache, per-tenant infrastructure that should be shared, or a data pipeline reprocessing history nightly because incremental processing was never built. Those changes take engineering time — which is exactly why the savings estimate has to be weighed against effort before anyone starts.