AWS Cost Optimisation — 8 Actions That Cut Cloud Bills by 40-60%

A fintech startup in Mumbai was spending $28,000 per month on AWS. After a two-week audit, they discovered three things: development EC2 instances running 24/7 with 4% average CPU, S3 traffic routing through NAT Gateway instead of a free VPC Endpoint, and no Savings Plans despite running the same workload for 14 months. Three changes brought the bill to $16,000. No architecture changes. No application refactoring. Just fixing configuration decisions made in a hurry that nobody ever revisited.

AWS cost problems are almost always a collection of small waste points that accumulate over months. This guide walks through the eight highest-impact actions in order of effort and return.

Action 1 — Rightsize EC2 Instances Before Buying Any Commitments

Buying Reserved Instances or Savings Plans on oversized instances locks in waste at a discount. Rightsize first, then commit.

Cost Explorer → Rightsizing Recommendations shows every EC2 instance running below 40% CPU utilisation over the past 14 days with a specific recommendation:

A team with 20 oversized instances finding an average $80/month saving per instance saves $1,600/month — before buying any commitments.

Memory metrics require the CloudWatch Unified Agent on EC2. Enable it on every production instance:

After rightsizing, your Savings Plan commitment is sized correctly — you are not locking in discount on compute you do not need.

Action 2 — Buy Compute Savings Plans for Steady Workloads

On-Demand EC2 is the most expensive pricing option on AWS. Any workload that has been running for more than 2 months with a predictable pattern should have Savings Plans coverage.

The recommendation engine in Cost Explorer does the work for you:

Start conservative — commit to 80% of your baseline usage, not your peak. Spiky traffic above the commitment is charged at On-Demand rates, which is fine. The commitment covers your stable floor.

Compute Savings Plans apply automatically. When you switch instance types or regions, the discount follows. No manual reassignment like Reserved Instances require.

Action 3 — Fix NAT Gateway Charges for S3 and DynamoDB

NAT Gateway charges $0.045 per GB processed. Every private EC2 instance accessing S3 through NAT Gateway pays this fee for traffic that never needed to touch the internet.

The fix is a VPC Gateway Endpoint — free to create, instant, and reduces NAT costs for S3 and DynamoDB to zero:

For a team with 15 TB/month of S3 traffic from private EC2:

Two CLI commands. Eight thousand dollars per year saved.

Action 4 — Tag Everything, Then Charge Teams for Their Usage

Without tags, Cost Explorer shows you what you are spending. With tags, it shows you who is spending it. The difference is the ability to hold teams accountable.

Mandatory tag policy:

Enforce tags with AWS Config:

Once tags are in place, use Cost Explorer to generate per-team cost reports monthly. When the backend team sees they spent $3,400 in dev last month, they become motivated to schedule dev instances correctly.

Action 5 — Schedule Non-Production Instances Off Overnight

Development and staging instances are typically used during business hours only. Running them 24/7 wastes 65% of their cost.

Deploy AWS Instance Scheduler from the AWS Solutions Library — one CloudFormation stack:

Then tag instances with the schedule:

Action 6 — Move S3 Data to the Right Storage Class

Teams frequently store everything in S3 Standard regardless of how often it is accessed. Logs written 90 days ago and never read again continue paying Standard prices.

Check what you are actually paying per storage class:

Set lifecycle rules to move data automatically:

A team storing 50 TB of logs that are rarely accessed after 30 days:

Action 7 — Use Spot Instances for Batch and Non-Critical Workloads

Spot Instances offer up to 90% savings on EC2. AWS can reclaim them with a 2-minute warning, making them unsuitable for stateful production services — but ideal for batch processing, data transformation, and CI/CD build agents.

Specify multiple instance types in your Spot Fleet — the more options you give AWS, the higher the probability of getting Spot capacity at any given time. For batch workloads that can checkpoint and resume, Spot Interruption Handling with a 2-minute warning handler is the standard pattern.

Action 8 — Enable Cost Anomaly Detection

Cost anomaly detection uses ML to learn your normal spending patterns and alert you within hours when something unusual happens.

With a threshold of $20, you are alerted any time a service spends $20 more than expected in a day. A forgotten GPU instance, a misconfigured S3 replication rule, a runaway Lambda function — caught within 24 hours instead of at month-end invoice.

Trade-offs and Alternatives

Production Implementation Guidelines

Execute in this order — each step builds on the previous:

• Enable Cost Anomaly Detection immediately — this is free and catches future problems.
• Tag all resources before anything else — you cannot optimise what you cannot attribute.
• Rightsize EC2 using Cost Explorer recommendations before buying any commitments.
• Buy Compute Savings Plans covering 80% of your steady baseline compute.
• Create VPC Gateway Endpoints for S3 and DynamoDB in every VPC — free, instant.
• Deploy Instance Scheduler for dev and staging environments.
• Set S3 lifecycle rules on all log and archive buckets.
• Move batch processing to Spot Instances starting with lowest-risk workloads.

REMEMBER THIS

**References and Further Reading** * [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) — pricing analysis and rightsizing recommendations * [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) — ML-based resource recommendations * [Instance Scheduler on AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/) — automated start/stop solution