Cloud Cost Optimization: Cut Your AWS Bill by 40%

The average company wastes 30-35% of its cloud spend on unused or over-provisioned resources, according to Gartner. For a company spending $100,000/month on AWS, that is $30,000-$35,000 per month being thrown away. Not on bad architecture decisions — on simple hygiene issues that take an afternoon to fix.

I have done cloud cost reviews for federal agencies and private companies. The pattern is consistent: the biggest savings come from four sources — commitments (switching from on-demand to reserved pricing), right-sizing (stopping the habit of over-provisioning), lifecycle policies (automating storage tier transitions), and waste elimination (deleting resources nobody is using). None of these require architectural changes. They all require attention.

This guide covers the specific techniques that produce the biggest savings, with real numbers so you can model the impact for your own environment.

Where Your AWS Money Actually Goes

The three categories that account for 80-90% of most AWS bills are compute (EC2, Lambda, Fargate), storage (S3, EBS, RDS storage, backup), and data transfer (egress to the internet, cross-region transfer, cross-AZ transfer). Optimizing these three categories produces the majority of savings.

Compute is almost always the largest cost center. EC2 instances running continuously on on-demand pricing are the primary target for Reserved Instance or Savings Plan commitments. Fargate and Lambda costs grow with usage but are typically harder to reduce without architectural changes.

Storage costs accumulate invisibly. EBS snapshots that have not been used in 18 months. S3 buckets full of logs that are never read but are stored in Standard tier. RDS storage that grew to 2 TB because auto-scaling was enabled and never reviewed. None of these are large individual charges — but they add up.

Data transfer is the most commonly overlooked cost. AWS does not charge for data into AWS (ingress). It charges for data out to the internet (egress), data between regions, and — in a less-known cost — data between Availability Zones within the same region. An application that places its EC2 instances in one AZ and its RDS read replicas in a different AZ within the same region pays cross-AZ transfer fees on every database read. At high volume, this can be thousands of dollars per month.

Use AWS Cost Explorer to break down your bill by service, region, and usage type. The "Top 5 cost-accruing services" view in the Cost Explorer dashboard shows immediately where to focus optimization effort.

Reserved Instances and Savings Plans: The Biggest Lever

The single most impactful cost optimization for consistent workloads is switching from on-demand pricing to committed pricing: either Reserved Instances or Compute Savings Plans. A 1-year commitment saves 30-40%. A 3-year commitment saves 60-72% for the most common instance types.

Compute Savings Plans (the modern approach): Commit to a specific dollar amount of hourly compute spend (e.g., $10/hour) for 1 or 3 years. AWS automatically applies the discounted rate to any EC2, Lambda, or Fargate usage that falls within your commitment. Unlike Reserved Instances, Savings Plans automatically apply to any instance type, size, or region — you do not need to choose specific instances upfront.

Reserved Instances (the legacy approach): Reserve a specific instance type (m5.xlarge, us-east-1) for 1 or 3 years. Discounts are slightly higher than Savings Plans for the exact instance type, but you lose flexibility. If your workload moves to a different instance type, your RI discount does not follow.

Example savings:

Instance Type	On-Demand/hr	1yr Savings Plan/hr	3yr Savings Plan/hr	Annual Savings (1yr)
m5.xlarge	$0.192	$0.128 (-33%)	$0.079 (-59%)	$560/instance
m5.2xlarge	$0.384	$0.256 (-33%)	$0.158 (-59%)	$1,119/instance
r5.xlarge	$0.252	$0.169 (-33%)	$0.104 (-59%)	$726/instance

The right time to buy Savings Plans: after your workload has been running in production for at least 2-3 months and you have confidence in your baseline instance usage. AWS Savings Plans recommendations in Cost Explorer show exactly what commitment level AWS recommends based on your trailing 7-30 days of usage.

Right-Sizing: Paying for What You Actually Use

Right-sizing means matching the instance size to actual workload requirements. Most EC2 instances run at 10-30% average CPU utilization — meaning the instance could be half the size with no performance impact. AWS Compute Optimizer analyzes usage patterns and provides specific right-sizing recommendations.

How to right-size:

1. Enable AWS Compute Optimizer (free) in your account. It analyzes CloudWatch metrics for EC2, Lambda, ECS, and EBS and provides specific over-provisioning findings.
2. Review the recommendations. Compute Optimizer classifies instances as Over-provisioned, Right-sized, or Under-provisioned with specific recommended instance types.
3. Validate the recommendation: look at the peak CPU and memory utilization, not just the average. An instance that averages 15% CPU but spikes to 85% at peak cannot be downsized the same as one that never exceeds 20%.
4. Test the change in staging before applying to production.
5. Change the instance type (requires a stop/start), update your Savings Plan commitment if needed, and monitor for 1 week.

Beyond EC2: Right-sizing applies to RDS instances, Elasticsearch domains, ElastiCache clusters, and Fargate task CPU/memory settings. A common source of waste: Fargate tasks provisioned with 2 vCPU / 4 GB memory for a service that consistently uses 0.2 vCPU / 512 MB. Moving to the correct task size saves 75% of the compute cost.

Spot Instances: 60-90% Off On-Demand Pricing

Spot Instances are spare EC2 capacity that AWS sells at 60-90% discounts compared to on-demand. The trade-off: AWS can reclaim spot instances with 2 minutes notice when capacity is needed for on-demand customers. For interruptible workloads, this discount is free money.

Workloads where spot is ideal:

• CI/CD build agents (a failed build just restarts)
• Batch data processing pipelines (checkpointing handles interruptions)
• ML model training (save checkpoints, resume from last checkpoint)
• Dev/test environments (not user-facing, interruptions are acceptable)
• Auto-scaling groups with mixed instance types (On-Demand for baseline, Spot for burst)

Spot pricing example: m5.xlarge on-demand: $0.192/hour. m5.xlarge spot (US East): ~$0.04-$0.06/hour. For a CI/CD build farm running 500 hours/month of m5.xlarge capacity: on-demand costs $96/month, spot costs $20-30/month — 70-80% savings.

Spot best practices:

• Use Spot Fleet or Auto Scaling Group with multiple instance types and AZs. Diversification reduces interruption risk because capacity is rarely exhausted for all types simultaneously.
• Implement checkpointing in your workloads. Any batch job or ML training run should save progress every N minutes so an interruption only loses the last checkpoint interval.
• Use the Spot Instance interruption notice (2-minute warning via instance metadata) to gracefully drain work before termination.

Storage Optimization: S3, EBS, and RDS

S3 lifecycle policies, EBS snapshot cleanup, and RDS storage right-sizing are low-effort, high-impact storage cost optimizations that most teams skip because they are invisible until you look at the bill.

S3 optimization:

• Implement lifecycle policies for all S3 buckets — especially log buckets, backup buckets, and raw data buckets. Moving data from Standard to Glacier Instant after 90 days reduces storage cost by 83%.
• Review all buckets and delete abandoned data. Use S3 Storage Lens (free) to identify buckets with large amounts of data and zero recent access.
• Use S3 Intelligent-Tiering for buckets where access patterns are unpredictable.

EBS optimization:

• Delete orphaned EBS snapshots. Snapshots created by automated backup processes and never deleted accumulate over time. Use Data Lifecycle Manager to enforce retention policies.
• Delete unattached EBS volumes. When an EC2 instance is terminated, attached EBS volumes may remain. AWS Trusted Advisor flags unattached EBS volumes as a cost optimization finding.
• Right-size gp3 volumes. gp3 volumes let you configure IOPS and throughput independently of storage size. Many gp2 migrations to gp3 reduce cost 20% while delivering the same performance.

RDS optimization:

• Stop dev/test RDS instances when not in use. An RDS instance running 24/7 vs 8 hours/day is a 66% cost reduction.
• Review read replicas. Are all of them receiving read traffic? Unnecessary replicas are wasted compute.
• Use Aurora Serverless v2 for variable workloads. Aurora Serverless scales compute up and down in 0.5 ACU increments — far more cost-efficient than a fixed RDS instance with variable load.

Eliminating Waste: Idle Resources and Orphaned Assets

Every AWS account accumulates waste: EC2 instances that were created for one-off testing and never terminated, Elastic IPs not attached to running instances ($0.005/hour each = $3.65/month per unused IP), Load Balancers with no healthy targets, NAT Gateways with zero traffic, and RDS instances with no connections.

Systematic waste elimination approach:

Weekly: Review AWS Trusted Advisor cost optimization checks. Trusted Advisor flags: low-utilization EC2 instances, idle RDS instances, unused Elastic IPs, idle load balancers, and underutilized EBS volumes.

Monthly: Review the AWS Cost Anomaly Detection alerts. Set up anomaly detection with a threshold of 10% above baseline — unexpected spikes in any service indicate either a runaway workload or an infrastructure mistake.

Quarterly: Audit all EC2 instances with no CPU activity for 30+ days. Audit all S3 buckets for orphaned data. Delete all EBS snapshots older than your retention policy. Review all load balancers for zero-request periods.

Automation: Tag all resources at creation with owner, environment, and expiration date. Set up Lambda functions that terminate or stop untagged resources after 30 days. This prevents waste accumulation from one-off experiments that are never cleaned up.

Frequently Asked Questions

What is the fastest way to reduce an AWS bill today?

The fastest immediate action is to purchase Compute Savings Plans based on your current baseline compute usage. This produces 30-40% savings on EC2, Lambda, and Fargate with no architectural changes. AWS will show you the recommended commitment in Cost Explorer within minutes of enabling the service.

What is AWS Trusted Advisor?

Trusted Advisor is an AWS service that analyzes your account and provides recommendations across five categories: cost optimization, performance, security, fault tolerance, and service limits. The cost optimization checks include low-utilization EC2 instances, idle RDS instances, unused Elastic IPs, and underutilized EBS volumes. Basic Trusted Advisor checks are free; the full suite requires a Business or Enterprise support plan.

How much can I realistically save on AWS through optimization?

Most organizations can achieve 20-40% cost reduction through optimization without architectural changes. The breakdown is typically: 15-25% from Reserved Instances or Savings Plans, 5-15% from right-sizing, 5-10% from storage lifecycle policies, and 3-8% from eliminating waste. The exact savings depend heavily on how mature your current cost management practices are — organizations with no current optimization have more to gain.

What is the difference between Reserved Instances and Savings Plans?

Reserved Instances (RIs) commit to a specific EC2 instance type, size, and region for 1 or 3 years. Savings Plans commit to a specific hourly dollar amount of compute spend (not a specific instance type) for 1 or 3 years. Savings Plans are more flexible — they apply to any EC2, Lambda, or Fargate usage up to the committed amount — and are the recommended approach for most teams. RIs offer slightly higher discounts for specific instance types but require accurate capacity forecasting.

Note: Information in this article reflects the state of the field as of early 2026. Technology evolves rapidly — verify specific version numbers, pricing, and service availability directly with vendors before making decisions.