.png)
Industry research consistently estimates that 27-32% of cloud spend goes to resources that deliver no business value — idle instances, oversized databases, on-demand pricing on workloads that have been stable for 18 months, and EBS volumes provisioned for peaks that never came. For a team spending $1M/year on AWS, that range represents $270,000-320,000 leaving the building every year. None of it requires a billing dispute or an architecture overhaul to recover. It requires configuration changes and the right purchasing decisions applied in the right order.
The nine strategies below are ranked by the typical percentage of annual spend they recover — starting with the one that moves the needle most.
Strategy 1: Buy Savings Plans or Reserved Instances on Stable Workloads
The single highest-leverage AWS cost reduction action available to any team running steady compute workloads. Savings Plans save 30-66% on EC2, Fargate, and Lambda. Reserved Instances save 33-72% on EC2 and RDS. Both are billing commitments — nothing about your infrastructure changes. You commit to a minimum hourly spend level, AWS reduces your per-unit rate in return.
The correct sequence: identify workloads that have run at predictable utilization for at least 30 days, calculate the stable baseline spend, commit at 70-80% of that baseline on a 1-year No Upfront Savings Plan to start. Review after 12 months. If utilization confirms stability, move to Partial or All Upfront for deeper discounts.
For Compute Savings Plans specifically: a single commitment covers EC2, Fargate, and Lambda simultaneously, across all instance families and regions. You do not need to specify which service gets the discount — AWS applies it automatically to the highest-discount usage first.
Expected savings: 30-66% on covered compute. Annual impact example: $500,000 in annual EC2 spend with 80% coverage under 1-year No Upfront Compute Savings Plan = $132,000/year recovered. Source: AWS Savings Plans documentation.
The Complete Guide to Compute Savings Plans (AWS and Azure) — Live
Strategy 2: Right-Size Every Instance Before Committing to a Discount
Buying a Reserved Instance or Savings Plan on an oversized instance locks in the waste for 1-3 years. A 33% discount on a db.r8g.2xlarge you only need at 40% CPU utilization saves less in absolute terms than a 33% discount on the correctly-sized db.r8g.xlarge — and the base compute rate is also lower.
The four CloudWatch metrics that identify over-provisioned EC2 and RDS instances: CPUUtilization (P90 below 40% signals over-provisioned compute), FreeableMemory (consistently above 25% of total RAM signals over-provisioned memory), DatabaseConnections (for RDS — confirm the smaller instance supports the connection ceiling), and NetworkIn/NetworkOut (to confirm the smaller instance’s network bandwidth covers peak traffic).
Rule of thumb: right-size first, then reserve. Spending 2-4 hours on CloudWatch analysis before purchasing RIs typically reduces the required RI count by 20-30% — and generates savings that compound for the full term of the commitment.
Expected savings: 15-30% on the affected instances by eliminating the over-provisioned compute before applying the RI discount on top.
On-Demand vs Reserved vs Spot: the complete AWS pricing model comparison
Strategy 3: Migrate to AWS Graviton Where Your Workloads Support It
Graviton3 (c7g, m7g, r7g) and Graviton4 (c8g, m8g, r8g) instances are 10-20% cheaper than equivalent Intel or AMD instances at list price. They also typically deliver better performance per dollar on workloads optimized for ARM. The discount applies before any RI or Savings Plan commitment — meaning the Savings Plan discount then applies on top of the already-cheaper Graviton base rate.
Most containerized workloads, web applications, and managed runtimes (Java, Python, Node.js, Go) run without modification on Graviton. Native compiled code and workloads with x86-specific dependencies (certain ML frameworks, older compiled binaries, specific kernel modules) require validation before migration.
For RDS specifically: Graviton4 (r8g) instances carry deeper RI discounts than Graviton3 (r7g) at identical on-demand rates. A db.r8g.xlarge 1-year No Upfront RI saves 33% versus the on-demand rate. The r8g also runs at a lower on-demand rate than the equivalent r7g in some regions. Migrate to the current Graviton generation before purchasing RIs.
Expected savings: 10-20% on compute at list price. Compounded with Savings Plans or RIs, the effective discount on Graviton versus non-Graviton on-demand can reach 50-65%. Source: AWS instance type documentation, Usage.ai RDS MySQL Graviton guide.
Strategy 4: Reserve Your Database Instances Separately
Compute Savings Plans do not cover RDS, ElastiCache, OpenSearch, Redshift, and DynamoDB. They require their own reservation products. Teams that buy a Compute Savings Plan expecting it to cover the database tier are leaving 33-69% of database compute savings uncaptured.
RDS Reserved Instances save 33-69% depending on engine, term, and payment option. The correct purchase sequence for databases: identify Extended Support exposure first (MySQL 5.7 and PostgreSQL 11 are in Year 3 Extended Support at $0.200/vCPU-hr — upgrade before reserving), convert non-production Multi-AZ to Single-AZ, right-size, then reserve.
For MySQL and PostgreSQL, buy Single-AZ RIs at the smallest size in the target family. This is the AWS-endorsed optimal strategy: Single-AZ RIs can cover both Single-AZ and Multi-AZ instances via normalization unit flexibility, and smaller-size RIs provide more deployment flexibility than larger ones.
Expected savings: 33-69% on database compute. For a fleet of 20 db.r8g.xlarge Multi-AZ instances, the difference between on-demand ($16,747/month) and 1-year No Upfront RI ($11,213/month) is $5,534/month, $66,408/year. Source: verified pricing from Vantage.sh May 2026.
RDS Reserved Instances: The Complete Guide
Strategy 5: Use Spot Instances for Interruptible Workloads
EC2 Spot instances offer 60-90% discounts on on-demand pricing for spare AWS capacity. When AWS needs the capacity back, you receive a 2-minute interruption notice and the instance is terminated. Workloads that can handle this gracefully — CI/CD, batch processing, ML training, data pipeline ETL, staging environments — are ideal Spot candidates.
Fargate Spot offers up to 70% off standard Fargate pricing for interrupt-tolerant ECS tasks. For batch processing workflows that can checkpoint and restart, Fargate Spot plus ARM architecture (20% additional discount) delivers the cheapest serverless container compute available on AWS.
The Spot pricing model requires workload design for interruption. Use Spot Fleet or Auto Scaling Groups with Spot instance diversification across multiple instance types and availability zones to minimize correlated interruption risk. For ML training specifically, checkpoint the training loop every N steps so a Spot interruption does not lose the full run.
Expected savings: 60-90% versus on-demand for covered workloads. A CI/CD fleet running 200 hours per month on c6i.8xlarge instances: on-demand $600.60, Spot approximately $60-90. Source: aws.amazon.com/ec2/spot/pricing — Spot prices fluctuate; verify current rates.
On-Demand vs Reserved vs Spot: when each pricing tier wins — Live
Strategy 6: Eliminate Idle Resources: The 30% Problem
While industry analysts estimates 30% of cloud spend goes to resources that deliver no business value. The most common categories: stopped EC2 instances that retain their EBS volumes and Elastic IP addresses, EBS volumes attached to stopped or terminated instances, RDS instances that were created for a project and never decommissioned, unused Elastic Load Balancers (each costs approximately $22/month at zero traffic), EBS snapshots from volumes that were deleted 18 months ago, and NAT Gateways in regions where no workloads are running.
The fastest audit: in AWS Cost Explorer, filter by EC2-Other to find EBS volumes, snapshots, and IP addresses. Run aws ec2 describe-volumes –filters Name=status,Values=available –query ‘Volumes[*].[VolumeId,Size,CreateTime]’ to list unattached EBS volumes. Run aws ec2 describe-addresses –query ‘Addresses[?AssociationId==null]’ to list unattached Elastic IPs ($0.005/hr when not attached).
For most accounts doing this audit for the first time, the idle resource cost is $500-5,000/month — all immediately recoverable with zero architectural change.
Expected savings: 10-30% of total AWS spend on a first audit. Recurring value is lower once idle resources are eliminated, but monthly discipline prevents accumulation.
AWS Cost Explorer for FinOps teams: utilization reports and idle resource detection — Live
Strategy 7: Optimize Storage Tiers — gp3 Over gp2, S3 Intelligent-Tiering
Two storage optimizations that require no performance sacrifice and recover immediate cost.
First: migrate EBS volumes from gp2 to gp3. General Purpose SSD (gp3) delivers the same baseline IOPS and throughput as gp2 at 20% lower cost — $0.08/GB-month versus $0.10/GB-month. And gp3 lets you provision IOPS and throughput independently, so you can right-size them separately. For RDS, gp3 is available and is the recommended storage type. Migration from gp2 to gp3 takes minutes with no downtime. Source: aws.amazon.com/ebs/pricing (verify — rates change).
Second: enable S3 Intelligent-Tiering for objects you access infrequently. Intelligent-Tiering automatically moves objects between Standard, Infrequent Access, and Archive Access tiers based on access patterns with no retrieval fees. For S3 buckets with mixed access patterns — some objects accessed daily, others accessed once a year — Intelligent-Tiering reduces storage costs by 30-68% on infrequently-accessed data without requiring manual lifecycle policy management.
Expected savings: 20% on EBS gp2 volumes immediately upon gp3 migration. 30-68% on qualifying S3 objects via Intelligent-Tiering. Combined, storage optimization typically recovers 5-15% of total AWS spend. Source: AWS EBS and S3 documentation (aws.amazon.com/ebs/pricing, aws.amazon.com/s3/pricing — verify, rates change).
Strategy 8: Audit Your Fargate Workloads and Apply Compute Savings Plans
Fargate is the most common source of unoptimized compute spend in 2026 because teams migrate to Fargate for operational simplicity and then forget to apply commitment discounts. Fargate runs at on-demand rates by default — a Compute Savings Plan must be explicitly purchased and applied.
Two actions: first, right-size Fargate task definitions. Pull Container Insights P95 CPU and memory utilization per task over 30 days. Most teams find actual usage is 30-60% below configured task size. Right-sizing 100 tasks from 1 vCPU / 2 GB to 0.5 vCPU / 1 GB saves $1,787/month at current Fargate rates ($35.74 vs $17.87 per task per month at 24/7 runtime). Second, purchase a Compute Savings Plan covering your stable Fargate baseline. A 1-year Compute Savings Plan saves approximately 20% on Fargate. A 3-year plan saves approximately 52%.
For high-utilization Fargate workloads that run 24/7 at steady load: evaluate migrating to EC2 launch type with Reserved Instances. EC2 at 80%+ utilization with a 1-year RI is consistently 30-50% cheaper than Fargate on-demand for equivalent compute.
Expected savings: right-sizing Fargate tasks alone typically saves 15-30% on Fargate compute. Adding a Compute Savings Plan saves an additional 20-52%. For 24/7 high-utilization Fargate workloads migrated to EC2 with RIs, total savings can reach 50-65% versus Fargate on-demand.
How Compute Savings Plans apply to Fargate — step-by-step — Live
Strategy 9: Automate Commitment Management to Eliminate the Analysis Lag
Manual commitment management has a structural problem: the analysis is episodic, the purchases are delayed, and the data is stale by the time commitments are bought. A FinOps engineer reviews Cost Explorer on the first Monday of the quarter, pulls coverage recommendations, waits 2-3 weeks for finance approval, and makes purchases based on usage data that is 4-6 weeks old. By then, workloads have changed, new services have launched, and some of the recommended instances have already been resized.
Usage.ai Insured Flex Commitments purchase Savings Plan-equivalent commitments automatically within parameters you approve. Recommendations refresh every 24 hours. Commitments carry a buyback guarantee: if workload changes make a commitment underutilized, Usage.ai provides cashback in real money — not credits. Fee: percentage of realized savings only. Zero savings means zero fee. Setup: 30 minutes, billing-layer access only, no infrastructure changes required.
Expected savings differential: 10-20 additional percentage points of realized savings versus manual management, applied to your full compute and database commit surface.
Autonomous Commitment Management: the end of manual RI and Savings Plan purchasing — Live
What Should You Prioritize First?
The nine strategies above deliver the most value in the order listed — but the right starting point depends on your current baseline. Here is a simple decision rule:
If you have no Savings Plans or Reserved Instances on stable workloads: start with Strategy 1. This is almost always the highest absolute dollar recovery available. Even a 1-year No Upfront Compute Savings Plan with zero analysis gets you 30% savings on covered compute immediately.
If you have Savings Plans but at under 70% coverage: run Strategy 2 (right-sizing) and Strategy 9 (automate) simultaneously. Under-commitment is usually a confidence problem. Automated management with a buyback guarantee on underutilization removes the reason teams under-commit.
If your EC2 and Savings Plans are optimized but the bill keeps growing: look at Strategies 4, 5, 7, and 8. Database costs, storage, and Fargate are the second-tier cost centers that mature FinOps programs reach after the compute commitment layer is handled.
If you have done all of the above: Strategy 6 (idle resource elimination) is the ongoing discipline that prevents new waste from accumulating. Monthly audit, monthly deletion, $0 ongoing cost.
Start your free savings analysis with Usage.ai
Frequently Asked Questions
1. How do I reduce my AWS bill immediately?
The fastest immediate actions: (1) Purchase a Compute Savings Plan on stable EC2 and Fargate workloads — saves 30-66% with zero infrastructure changes, active within minutes of purchase. (2) Migrate gp2 EBS volumes to gp3 — 20% cheaper, no performance change, takes minutes. (3) Identify and delete unattached EBS volumes and unused Elastic IPs — recover money wasted on idle resources immediately. These three actions together typically recover 25-40% of avoidable spend for teams that have not previously optimized.
2. How much can you save by optimizing AWS costs?
Gartner estimates 30% of cloud spend is waste for the average organization. In practice, teams implementing the full strategy stack above — commitment discounts, right-sizing, Graviton migration, database reservations, Spot, idle elimination, storage optimization, and automated management — typically achieve total savings of 40-60% versus unoptimized on-demand spend. The exact figure depends on workload mix, current commitment coverage, and how much idle spend exists.
3. What is the quickest way to save on AWS compute?
Buy a 1-year No Upfront Compute Savings Plan. Zero upfront cost, savings start immediately, no infrastructure changes. Cover your stable EC2 and Fargate baseline at 70-80% of your last 30 days of spend. AWS Cost Explorer shows the recommended commitment amount for a target coverage level. A 1-year No Upfront plan saves approximately 30-42% on covered EC2, 20% on Fargate, and 17% on Lambda duration. Verify current rates at aws.amazon.com/savingsplans/pricing — rates change.
4. Do Savings Plans cover RDS databases?
No. Compute Savings Plans cover EC2, Fargate, and Lambda only. RDS, ElastiCache, OpenSearch, Redshift, and DynamoDB require their own reservation products: RDS Reserved Instances (save 33-69%), ElastiCache Reserved Nodes, OpenSearch Reserved Instances, Redshift Reserved Nodes. The Database Savings Plan covers RDS, ElastiCache, and DocumentDB at up to 35% discount — less than full RDS RIs but with more flexibility across engines and regions.
5. How do I find idle AWS resources?
In AWS Cost Explorer, filter EC2-Other by usage type to identify EBS volumes, snapshots, and IP addresses. Run aws ec2 describe-volumes –filters Name=status,Values=available for unattached EBS volumes. Run aws ec2 describe-addresses –query ‘Addresses[?AssociationId==null]’ for unattached Elastic IPs. For unused load balancers: aws elbv2 describe-load-balancers, then check request counts in CloudWatch over the past 30 days. Any ALB with zero requests in 30 days at $22/month base cost is an immediate deletion candidate.
6. Should I use Reserved Instances or Savings Plans?
For EC2: Compute Savings Plans for flexibility (covers any instance family, region, size, plus Fargate and Lambda). EC2 Instance Savings Plans for stable single-family workloads needing maximum discount (up to 72%). For databases: RDS Reserved Instances (no Savings Plan equivalent except the Database Savings Plan at lower discount). For most teams: start with Compute Savings Plans for EC2 and Fargate, add RDS RIs for database tier. Source: Usage.ai Savings Plans vs Reserved Instances guide (live).
