How to reduce AWS costs: a practical checklist

AWS cost reduction is not a one-time exercise and it should not begin with indiscriminate shutdowns. A useful optimization program connects every saving to a workload owner, a performance constraint, and a way to verify that the change did not create new reliability risk.

The opportunities below are ordered deliberately. Start with visibility and reversible cleanup. Move to rightsizing and architecture changes once you understand workload behavior. Purchase Savings Plans or reservations only after the underlying demand is stable.

1. Build a trustworthy AWS cost baseline

Start with the last three complete billing months, then inspect recent daily spend for changes hidden by monthly totals. Break down the largest services before reviewing individual resources. Include month-end jobs, traffic peaks, deployments, and seasonal events when choosing the utilization window; three months alone may not capture an annual peak.

Save the dates, account and region filters, currency, and cost basis alongside the report. AWS Cost Explorer offers different cost views: amortized cost spreads commitment fees over their term, while net amortized cost also reflects applicable discounts. Use the same basis before and after a change, and account separately for credits, refunds, tax, and one-off charges. A lower invoice after a credit does not establish a lower recurring run rate.

Start with AWS Cost Explorer and AWS Cost Optimization Hub. Cost Optimization Hub consolidates recommendations for rightsizing, idle resources, Savings Plans, and reservations across supported AWS services. Treat its estimated savings as a prioritized investigation list—not an instruction to implement every recommendation automatically.

Create a cost map that engineering can act on

• Break spend down by account, service, region, environment, and workload.
• Activate cost-allocation tags for owner, product, environment, and cost centre.
• Separate production, non-production, shared-platform, and unallocated spend.
• Record unit metrics such as cost per customer, transaction, build, or request where they are meaningful.

AWS documents how activated cost-allocation tags can feed Cost Explorer reports and budgets. The immediate objective is accountability: every meaningful cost should have an owner who can explain what business outcome it supports.

2. Remove idle and orphaned resources first

Idle-resource cleanup is usually the lowest-risk place to begin because it removes spend without changing the capacity of a healthy production workload. Verify ownership and recovery requirements before deletion, then work through:

• Unattached EBS volumes and snapshots outside the retention policy.
• Unused Elastic IP addresses and old load balancers.
• Stopped EC2 instances that still retain paid storage.
• Idle RDS instances, replicas, and non-production databases.
• Development environments running overnight or on weekends.
• Old container images, log groups, and backups with no expiry policy.

Use a quarantine window for uncertain resources: tag the item, notify its presumed owner, stop it when safe, monitor for impact, and delete it only after the agreed recovery window. This makes cleanup repeatable without turning cost optimization into an outage exercise.

3. How to reduce EC2 costs safely

EC2 cost reduction should use CPU, memory, network, disk, and application-level performance data. CPU alone is not enough for memory-heavy databases, network appliances, or workloads with bursty latency requirements.

Verify that memory data actually exists. Compute Optimizer can use memory metrics collected through the CloudWatch agent or supported external observability integrations; see its EC2 metrics requirements. Missing memory data is a reason to collect more evidence before approving a smaller instance.

Rightsize from observed demand

AWS Compute Optimizer analyzes resource configuration and utilization metrics to produce rightsizing recommendations and projected price-performance tradeoffs. Review the EC2 recommendation details, then validate the proposed instance family and size against peak traffic, memory headroom, storage throughput, network requirements, and recovery targets.

Match capacity to time and demand

• Schedule predictable non-production workloads to stop outside working hours.
• Use Auto Scaling groups so steady-state capacity does not need to cover every peak.
• Evaluate Graviton-compatible instance families after application and dependency testing.
• Use Spot Instances for interruption-tolerant workers, batch jobs, and flexible container capacity—not for workloads that cannot handle interruption.

Compare potential savings and performance risks

On small screens, scroll the table horizontally to see all four columns.

4. Worked example: test a smaller EC2 instance

Suppose a service has three replicas, each with 4 vCPUs and 8 GiB of memory. Across 28 representative days, including scheduled jobs and a known traffic peak, the highest observed five-minute CPU value is 30% and memory reaches 2.5 GiB per instance. This makes a 2-vCPU, 4-GiB instance in the same architecture a candidate for testing. Those observations alone do not prove it can handle shorter bursts or failover.

1. Check the candidate's network and EBS throughput, CPU credits where relevant, memory headroom, and application compatibility.
2. Test representative peaks and failure scenarios against agreed latency, error-rate, queue, and saturation limits.
3. Keep the previous configuration ready for rollback, then use an approved staged rollout with an owner watching the metrics.
4. Compare actual usage and effective cost after a representative observation period; record any extra capacity or costs needed to maintain performance.

See the checks to make before switching instance sizes in our EC2 rightsizing example.

5. Optimize EBS, S3, RDS, and EKS together

EBS and snapshot hygiene

Look for unattached volumes, oversized provisioned IOPS, obsolete snapshots, and volumes whose type no longer matches the workload. Treat snapshot retention as a documented recovery policy instead of allowing backups to accumulate indefinitely.

S3 lifecycle and access patterns

S3 costs include storage, requests, retrieval, and data movement. Use access-pattern evidence before moving data between classes. AWS S3 cost-optimization guidance describes lifecycle rules, Intelligent-Tiering, and purpose-built storage classes. Include retrieval and transition fees, minimum storage durations, and recovery requirements in the comparison. Add expiry rules for temporary objects, incomplete multipart uploads, and logs that exceed their required retention.

RDS and database costs

Review instance class, storage, IOPS, replicas, Multi-AZ requirements, backup retention, and database connection patterns together. A smaller database instance is not a saving if it increases latency or moves the bottleneck into application retries.

EKS and container platforms

For EKS, connect pod requests to actual workload usage, then review node utilization and autoscaling. Requests influence scheduling and capacity allocation; CPU limits can cause throttling, while exceeding memory limits can cause a container to be killed. Review Kubernetes requests and limits separately, then optimize workload and node capacity together.

NAT Gateways and data transfer

Separate gateway hours, processed data, and transfer charges before changing routes. The AWS NAT Gateway pricing guidance helps identify which charges a change could affect. For suitable VPC-to-S3 traffic, an S3 gateway endpoint has no additional endpoint charge and can avoid routing that traffic through NAT. Interface endpoints have different pricing. Check routing and connectivity requirements, and include any remaining gateway hours and transfer costs in the estimate.

6. Buy Savings Plans and reservations last

Commitment discounts can be valuable for stable baseline usage, but they do not remove waste. Buying a commitment against oversized or unnecessary infrastructure can lock the wrong cost structure in place.

1. Remove idle resources and correct obvious configuration waste.
2. Rightsize workloads and observe the new baseline.
3. Separate stable usage from variable or interruptible capacity.
4. Model commitment coverage conservatively.
5. Track utilisation and renewal dates as owned financial decisions.

Savings Plans involve a spending commitment per hour for one or three years. Reducing covered usage does not automatically reduce that payment. Check whether freed coverage can serve other eligible usage, and avoid adding a rightsizing estimate to a commitment estimate that assumes the old resource size. Model the combined final configuration once.

7. Prevent the AWS bill from growing back

Savings decay when optimization remains a quarterly clean-up exercise. Add lightweight controls to normal engineering work:

• Budgets and anomaly alerts routed to accountable owners.
• Mandatory ownership and environment tags in Infrastructure as Code.
• Cost impact included in architecture and pull-request reviews.
• Expiry dates for temporary environments and experiments.
• A weekly review of unexpected spend and a monthly unit-cost review.
• A visible backlog ranked by saving, effort, and operational risk.

8. Verify savings after implementation

Keep three numbers separate: the estimated opportunity, the change in recurring effective cost, and the impact on the cash bill. A rightsizing change can release committed capacity without immediately reducing cash payments. Label the result accordingly.

1. Record the baseline. Save the reporting dates, resource scope, cost basis, commitment assumptions, traffic volume, and performance targets before making the change.
2. Log the rollout. Record what changed, its owner, deployment date, testing costs, and any rollback or replacement capacity.
3. Compare like-for-like periods. Include the same business cycles, use a complete observation window, and check cost per useful unit alongside total spend. Separate demand changes, credits, pricing changes, and unrelated releases.
4. Accept or revise the result. Verify reliability targets and costs across affected services. Record recurring savings separately from one-off implementation costs, and revisit the estimate if costs moved elsewhere.

For example, cost per 1,000 successful transactions equals the scoped cost divided by successful transactions, multiplied by 1,000. Use a unit that reflects the workload: reduced spend during a traffic drop is not by itself evidence of improved efficiency.

Our fintech AWS cost-reduction case study shows how infrastructure improvements, Terraform, and blue-green delivery helped a payments platform lower AWS costs and release faster.

9. A practical 30-day AWS cost-reduction plan

Common AWS cost-reduction mistakes

• Buying Savings Plans before removing idle or oversized capacity.
• Rightsizing from average CPU while ignoring peaks and memory.
• Deleting resources without ownership and recovery checks.
• Optimizing one service while moving cost into network or storage.
• Celebrating forecast savings without measuring realised spend.
• Treating FinOps as a finance-only responsibility.