DEV Community: Aman Singh

AWS Data Transfer Costs: How to Cut Your Egress Bill Without Rebuilding Your Stack

Aman Singh — Tue, 09 Jun 2026 13:45:18 +0000

For a workload moving 50 TB/month to the internet, AWS egress alone runs roughly $2,100/month at standard rates before you add cross-AZ traffic, NAT Gateway processing fees, and inter-region replication. At mid-to-large scale, data transfer regularly accounts for 10–20% of total AWS spend.

The reason it gets missed: AWS buries most of these charges inside "EC2-Other" in Cost Explorer rather than surfacing them as a dedicated line item. By the time teams notice, the meter has been running for months.

This guide covers every pricing dimension, where to find these charges in your bill, and how to reduce them without a full architecture rewrite.

How AWS Data Transfer Billing Actually Works

Three rules define the billing model:

Data in is always free. Ingress from the internet, on-premises, or another cloud carries no charge.
Data out is always charged. Any byte leaving AWS to the internet, to your data center, or to another Region carries a per-GB rate.
Internal traffic charges depend on topology. Same-AZ, private IP: free. Cross-AZ or cross-Region: metered, even between services you own.

The four boundaries that generate charges:

Internet egress: data leaving AWS to the public internet (largest category for most teams)
Cross-AZ traffic: $0.01/GB each direction within the same Region
Cross-Region traffic: ~$0.02/GB for US Region pairs, higher for APAC/South America
On-premises traffic: varies by whether you use the public internet, Direct Connect, or VPN

All rates approximate. Verify at Amazon EC2 On-Demand Pricing rates change.

Cross-AZ Traffic: The Line Item That Compounds Silently

Cross-AZ traffic is $0.01/GB each direction round-trip costs $0.02/GB. That sounds trivial. At production scale it is not.

A three-tier application running 10,000 requests/second with a 10 KB average payload, routing between an ALB in one AZ and EC2 instances in another, generates:

10,000 req/sec × 10 KB = 100 MB/sec of cross-AZ traffic
100 MB/sec × 3,600 sec × 730 hours/month = ~263 TB/month
263 TB × $0.01/GB × 2 directions = ~$5,260/month in cross-AZ charges alone

The fix is AZ-affinity routing: ensure EC2 instances, RDS read replicas, and ElastiCache nodes are in the same AZ as the workloads consuming them. AWS now allows cross-zone load balancing to be disabled independently on ALBs and NLBs for stateless workloads, disabling it is often the fastest single reduction with zero performance impact.

Service-by-Service Egress Breakdown

EC2: Tiered pricing $0.09/GB for the first 10 TB/month, dropping progressively at higher volumes. A common misconfiguration: using public or Elastic IP addresses for same-Region EC2-to-EC2 communication triggers $0.01/GB each direction even within the same AZ. Always use private IPs for intra-VPC traffic.

S3: Same tiered rates as EC2 for internet egress. S3 to EC2 in the same Region is free. S3 to CloudFront is free (the correct architecture for content served at scale). Transfer Acceleration adds $0.04–$0.08/GB on top of standard for long-distance uploads.

RDS: Internet egress follows the same tiered rates. Multi-AZ replication between primary and standby is free. Cross-Region read replica replication is not these are different features with different billing treatment.

Lambda: Charges standard EC2 egress rates for internet-bound traffic. Same-Region calls over private endpoints are free.

ElastiCache: Redis clusters with cross-AZ replicas incur $0.01/GB on every write replication. Use same-AZ reader endpoints where read latency tolerates it.

NAT Gateway: The Surprise Multiplier

NAT Gateway charges $0.045/GB for every byte it processes in addition to, not instead of, EC2 internet egress charges. An EC2 instance routing traffic through NAT Gateway pays:

$0.045/GB (NAT processing) + $0.09/GB (EC2 egress) = $0.135/GB total for the first 10 TB

For traffic accessing AWS services from private subnets S3, DynamoDB, SSM, CloudWatch replace NAT Gateway routing with VPC Gateway Endpoints. They are free, require only a route table update, and eliminate the NAT processing charge entirely.

If you want the full breakdown of egress reduction options ranked by ROI, it's covered in detail here How to Reduce AWS Egress Costs

How to Find Data Transfer Costs in Your AWS Bill

AWS Cost Explorer buries most data transfer charges inside "EC2-Other." Here is the exact workflow to surface them:

Open Cost Explorer. Set date range to last 3 months, granularity to Monthly.
Group by Service. Identify the "EC2-Other" line item.
Filter to EC2-Other only. Change Group by to Usage Type.
Look for usage types containing DataTransfer, InterZone, Regional, or NatGateway.
For deeper analysis, use the AWS Cost and Usage Report (CUR) — query lineitem_usagetype via Athena to break down charges by resource ID.

The operation codes to know: DataTransfer-Out-Bytes (internet egress), InterZone-In/InterZone-Out (cross-AZ), DataTransfer-Regional-Bytes (cross-Region), NatGateway-Bytes.

CloudFront vs Direct EC2/S3 Egress

CloudFront reduces internet egress in two ways: lower per-GB rate ($0.0085/GB from US/EU edge locations vs $0.09/GB from EC2), and origin-to-CloudFront transfer is free when the origin is an AWS service in the same Region.

For a media workload serving 100 TB/month:

EC2/S3 direct egress: 100 TB × $0.07/GB (50–150 TB tier) = $7,000/month
CloudFront egress: 100 TB × $0.0085/GB = $850/month

That is $6,150/month before factoring in CloudFront's cache hit rate reducing origin traffic.

CloudFront is not always the answer. For API traffic with low cacheability, high cache-miss rates eliminate the savings advantage. For workloads under 1 TB/month, the operational overhead may not justify the reduction.

Direct Connect vs Internet Egress: Break-Even Math

Direct Connect data transfer over a private virtual interface costs $0.02/GB for US Regions vs $0.09/GB for internet egress, a 78% reduction on the egress rate.

Break-even calculation:

1 Gbps dedicated connection: ~$216/month (US port charge) + partner/colocation fees
Egress savings: $0.09 – $0.02 = $0.07/GB saved
Break-even volume: $216 ÷ $0.07 = ~3 TB/month

If your workload consistently moves more than 3–4 TB/month between your data center and AWS, Direct Connect typically pays for itself on egress savings alone before factoring in latency and reliability improvements. Verify at AWS Direct Connect pricing.

Architecture Decision Tree for Data Transfer Cost Reduction

Is your data transfer cost above $500/month?

If yes, identify the largest line item:

Internet Egress (DataTransfer-Out-Bytes):

Serving web content or assets? → Move to CloudFront. S3-to-CloudFront is free. CloudFront egress ~$0.0085/GB vs $0.09/GB.
Traffic going to on-premises? → Evaluate Direct Connect (break-even ~3–4 TB/month).
Neither? → Review application-level compression and caching.

Cross-AZ (InterZone-In / InterZone-Out):

ALB/NLB spreading traffic across AZs? → Disable cross-zone load balancing or implement AZ-affinity.
EC2 instances using public IPs for same-Region communication? → Switch to private IP addressing within VPC.

NAT Gateway (NatGateway-Bytes):

Traffic accessing AWS services (S3, DynamoDB, SSM)? → Replace with VPC Gateway Endpoints (free for S3 and DynamoDB).
Internet access from private subnets? → Consider NAT Instance for lower-volume workloads, or one NAT Gateway per AZ.

Cross-Region (DataTransfer-Regional-Bytes):

Replication traffic? → Evaluate whether workloads can colocate.
Serving global users? → Route through CloudFront edge instead of origin-to-user.

Worked Example: 3-Tier Web App at Scale

Setup: E-commerce platform, us-east-1, 3 AZs, 50,000 active users/day ALB serving 100 GB/day, EC2 fleet across mixed AZs, RDS Multi-AZ, S3 for product images (500 GB/day), ElastiCache Redis cluster (3 nodes, 3 AZs).

Before optimization; estimated monthly data transfer bill:

ALB internet egress: 3 TB @ $0.09/GB → $270
S3 internet egress: 15 TB @ $0.085/GB → $1,275
Cross-AZ EC2-to-EC2: 5 TB @ $0.01/GB × 2 → $100
NAT Gateway (SSM/CloudWatch): 2 TB @ $0.045/GB → $90
ElastiCache cross-AZ replication: 1 TB @ $0.01/GB × 2 → $20
Total: ~$1,755/month

Changes applied:

S3 content moved behind CloudFront (S3-to-CloudFront free, CloudFront egress $0.0085/GB)
VPC Gateway Endpoint for S3 added (eliminates NAT Gateway on S3 API calls)
AZ-affinity enabled on ALB (reduces cross-AZ EC2 traffic by ~70%)
ElastiCache readers placed in same AZ as app servers

After optimization; estimated monthly data transfer bill:

ALB internet egress: 3 TB @ $0.09/GB → $270
CloudFront egress (replaces S3 direct): 15 TB @ $0.0085/GB → $127.50
Cross-AZ EC2-to-EC2 (reduced): 1.5 TB @ $0.01/GB × 2 → $30
NAT Gateway (reduced): 0.5 TB @ $0.045/GB → $22.50
ElastiCache cross-AZ (same-AZ placement): 0.2 TB @ $0.01/GB × 2 → $4
Total: ~$454/month

Estimated saving: ~$1,300/month (~74% reduction) from architecture changes alone. All rates are approximate verified at aws.amazon.com/pricing.

Want to see your actual number? You can run a free AWS savings estimate in 60 seconds [Usage.ai Savings Calculator(https://www.usage.ai/blogs/aws/guides/usage-ai/savings-calculator-launch/)]

Common Mistakes

Using public IPs for intra-VPC communication. EC2 instances communicating via public or Elastic IP addresses within the same Region trigger $0.01/GB even in the same AZ. Use private IP addresses for all intra-VPC traffic.

NAT Gateway for AWS service access. Routing S3, DynamoDB, SSM, CloudWatch, or SQS traffic through NAT Gateway costs $0.045/GB in processing fees that are completely avoidable with VPC Gateway or Interface Endpoints.

Cross-Region replication without traffic modeling. Multi-Region active-active architectures, DynamoDB Global Tables, S3 Cross-Region Replication all generate cross-region transfer charges that need to be explicitly budgeted.

Ignoring ElastiCache cross-AZ replication costs. Redis clusters with replicas in multiple AZs generate $0.01/GB on replication traffic. Place reader endpoints in the same AZ as application instances for read-heavy workloads.

Confusing Multi-AZ RDS with Cross-Region read replicas. Multi-AZ RDS replication between primary and standby is free. Cross-Region read replica replication is not. Different features, different billing.

How Data Transfer Optimization Connects to Compute Commitment Strategy

Reducing data transfer costs and reducing compute costs use different levers but they interact.

When you restructure for same-AZ placement, your EC2 fleet size per AZ increases while total instance count stays the same. When you add CloudFront, origin EC2 load drops. These architecture changes alter your compute baseline and a more stable, predictable baseline is easier to commit against.

Teams that have completed a data transfer optimization pass typically see EC2 utilization patterns stabilize, which makes commitment purchasing recommendations more accurate. After optimizing your transfer architecture, committing the stabilized compute baseline through an automated platform captures an additional 30–50% reduction on top of the transfer savings already achieved.

Usage.ai automates commitment purchasing for EC2, RDS, Lambda, and other services refreshing recommendations every 24 hours vs the 72+ hour refresh cycle of Cost Explorer's native tools. Insured Flex Commitments carry no multi-year lock-in: commitments adjust quarterly, and underutilized commitments are covered by a buyback guarantee paid in cash, not credits.

This matters specifically for teams mid-optimization: your compute baseline is still shifting as you move workloads to the same AZ, add CloudFront, and remove NAT Gateway traffic. A platform that penalizes commitment size changes is the wrong tool when architecture is in flux. See how Usage.ai handles dynamic workloads.

Which of these do you see most consistently underestimated on AWS bills cross-AZ traffic, NAT Gateway fees, or something else entirely?

For the complete technical breakdown, read the full article here → AWS Data Transfer Costs

Autonomous Commitment Management: How to Stop Managing Cloud RIs Manually

Aman Singh — Thu, 04 Jun 2026 11:25:07 +0000

Most FinOps teams manage cloud commitments the same way they managed email in 2003: by hand, on a schedule, with whatever information was available at the time. A senior engineer opens AWS Cost Explorer on the first Monday of the quarter, pulls a Savings Plans and Reserved Instances report, eyeballs coverage gaps, and submits a purchase request to finance. Three weeks later, if approval comes through, the purchases are made.

By then, the usage patterns that informed the analysis are six weeks old. The instances that drove the gap may have been resized. New workloads have been launched that were not in the original model. The commitments purchased reflect a point-in-time snapshot of a continuously changing system.

This is not a process problem. It is an architecture problem. Manual commitment management is the wrong tool for a continuously changing environment.

What Is Autonomous Commitment Management?

Autonomous commitment management is the continuous, automated operation of your entire cloud commitment portfolio: analyzing usage, identifying coverage gaps, purchasing the optimal commitment instruments, monitoring for underutilization, and adjusting coverage as workloads change all without requiring manual review cycles or human approval for each transaction.

The word "autonomous" is precise here. It does not mean "makes recommendations for humans to approve." It means the system executes purchasing decisions within defined parameters based on observed usage data, the same way auto-scaling executes instance launches based on observed CPU metrics. The human role shifts from executing commitment purchases to setting the parameters and reviewing outcomes.

A complete autonomous system covers the full lifecycle:

Analysis: Continuous evaluation of on-demand vs committed usage, operating on hourly or daily data rather than the 72+ hour refresh cycles that AWS Cost Explorer provides.
Purchasing: Automated acquisition of the correct commitment type, term length, and payment option based on workload stability signals.
Monitoring: Tracking utilization of each commitment and detecting when usage patterns shift.
Adjustment: Modifying the portfolio as workloads change via RI exchanges, natural expiration, or buyback.
Protection: Buyback guarantees on underutilized commitments, removing the financial risk that makes teams hesitant to commit.

If you want to understand where AWS Cost Explorer falls short for commitment work, we covered its limitations in detail here AWS Cost Explorer: Advanced Guide for FinOps Teams

Why Manual Commitment Management Fails at Scale

The case against manual commitment management is not about laziness or incompetence. It is about information latency, cognitive load, and risk tolerance.

Failure 1: 72-Hour Data Lag Compounds Into Weeks of Missed Savings

AWS Cost Explorer's recommendations refresh every 72 hours or longer. A team that reviews Cost Explorer on Monday morning is looking at data that was current on Friday. If a new RDS cluster launched Saturday afternoon, it is not in Monday's recommendations.

Usage.ai refreshes its commitment analysis every 24 hours. Against Cost Explorer's 72-hour refresh, the gap is 3 days per review cycle. At $6,000–12,000 per day in uncovered on-demand spend for a mid-size fleet, a 3-day lag compounds to $18,000–36,000 in avoidable charges per analysis cycle. Over a year of quarterly reviews: $72,000–144,000 in unnecessary spend from data lag alone.

*Failure 2: Fear of Over-Commitment Limits Coverage to 25–40%
*
FinOps teams asked to justify a commitment purchase to finance face an asymmetric risk: if usage drops, they are blamed for wasting committed spend. If they under-commit, nobody notices the missed savings. This asymmetry creates a systematic bias toward conservative commitments.

Research from nOps published in 2026 finds that manual management teams typically achieve 25–40% savings on compute, compared to 45–55% for teams using automated commitment management. The gap is not explained by tool quality, it is explained by human risk aversion that manual processes require.

Autonomous commitment management eliminates this by providing a financial backstop. When commitments are backed by buyback guarantees and cashback on underutilized capacity as Usage.ai Insured Flex Commitments provide the risk of recommending a commitment drops to zero.

Failure 3: The Commitment Surface Is Too Large for Manual Management

When RI management meant EC2 Reserved Instances, manual management was difficult but tractable. In 2026, AWS alone covers: EC2 Reserved Instances, Compute Savings Plans, EC2 Instance Savings Plans, RDS Reserved Instances (6 engines), ElastiCache Reserved Nodes (3 engines), DynamoDB Reserved Capacity, OpenSearch Reserved Instances, Redshift Reserved Nodes, Database Savings Plans, and SageMaker Savings Plans. Each has different eligibility rules, term lengths, payment options, and size flexibility mechanics.

Add Azure Reservations and GCP Committed Use Discounts and the tracking burden becomes untenable. A FinOps team with one or two engineers cannot optimize the full commitment surface manually and still have time for architectural work.

How Autonomous Commitment Management Works

Continuous Usage Signal Ingestion

The foundation is hourly ingestion of actual cloud usage data, not Cost Explorer's aggregated recommendations. This means pulling from the Cost and Usage Report, parsing hourly on-demand usage by service, instance type, region, and account, and maintaining a rolling time series of consumption patterns.

The signal must be granular enough to distinguish a stable baseline from a variable peak. An average daily CPU utilization of 40% does not tell you whether you have a stable 40% baseline or a 20% baseline with daily spikes to 60%. Hourly data tells you. Quarterly averages do not.

Baseline Extraction and Commitment Sizing

The system extracts the commitment-eligible baseline typically the P50–P70 of hourly usage. Committing to the P50 ensures the commitment is fully utilized in the majority of hours while allowing the remaining hours to overflow to on-demand.

Sizing must account for service-specific mechanics. For RDS, size flexibility means a family-level reservation covers any size in the family proportionally. For DynamoDB, reservations are purchased in 100 RCU/WCU blocks. For ElastiCache, the Valkey migration bonus means Redis OSS reservations cover 20% more Valkey nodes. These mechanics change the optimal commitment quantity per service.

24-Hour Refresh and Continuous Adjustment

The commitment portfolio is re-evaluated every 24 hours against the latest usage signal. If baseline usage grows, the system identifies uncovered on-demand spend and purchases additional commitments. If baseline usage shrinks, it identifies over-committed positions and responds via exchanges, natural expiration, or buyback.

Cashback and Buyback Protection

Usage.ai Insured Flex Commitments deliver 30–60% savings without multi-year lock-in, $0 upfront, and cancel-anytime with a buyback guarantee. Underutilized commitments are returned as cashback real money, not credits.

The buyback guarantee is what makes autonomous purchasing safe at scale. When underutilized commitments generate cashback rather than waste, the system can purchase at the correct utilization level without the conservative bias that manual processes require. The result is higher coverage, higher savings, and lower financial risk simultaneously.

The Business Case

Coverage Gap Closure

Typical coverage gap for manual management: 30–40% of committable spend is uncovered on-demand. For a team with $500,000/month in committable AWS spend:

35% coverage gap = $175,000/month on-demand
At 50% average savings rate = $87,500/month in avoidable spend, $1,050,000/year
Autonomous management at 90%+ coverage shrinks the gap to 10% or less
Additional savings from gap closure: $750,000/year

Engineering Time Recovery

A FinOps engineer managing RDS RIs, ElastiCache Reserved Nodes, Savings Plans, and EC2 RIs manually spends 8–16 hours per month on analysis, purchase preparation, and finance approval coordination. At $150,000/year fully-loaded cost, that is $12,500–25,000/month on a task that autonomous systems handle without human intervention.

Recovered time goes to architectural optimization, cost allocation improvements, and strategic FinOps work that automation cannot replace.

Risk Reduction

Manual commitment management carries three categories of financial risk that autonomous systems eliminate or transfer:

Over-commitment risk: managed by buyback guarantees
Under-commitment risk: managed by continuous coverage analysis and automated purchasing
Expiration risk: managed by continuous monitoring with automated renewal

Autonomous Commitment Management Across the AWS Data Tier

The database tier is where most teams have the widest coverage gaps. For the full mechanics of each service RDS Reserved Instances: Engine-by-Engine Pricing and Commitment Guide

RDS Reserved Instances

Usage.ai monitors RDS instance utilization across all engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server) with 24-hour refresh. For each engine, the platform evaluates instance family utilization, identifies stable baseline consumption eligible for 1-year or 3-year terms, and purchases the optimal reserved instance configuration. Size flexibility mechanics for MySQL, PostgreSQL, and Oracle BYOL are factored into purchase sizing.

For teams on EOL engine versions in Extended Support, Usage.ai surfaces the Extended Support surcharge as an urgent cost alert: MySQL 5.7 and PostgreSQL 11 entered Year 3 Extended Support in March 2026, doubling the per-vCPU surcharge that is not reduced by reserved instances. RDS Extended Support Pricing: Staying on Old Engine Versions

ElastiCache Reserved Nodes

ElastiCache reserved nodes for Redis OSS, Valkey, and Memcached are optimized using the same continuous analysis. Since October 2024, ElastiCache reserved nodes offer size flexibility within the same instance family. Usage.ai incorporates this into purchase sizing, buying family-level reservations that cover the baseline across all node sizes in use. The Valkey migration bonus is also factored: Redis OSS reservations cover 20% more Valkey nodes via normalization units after engine migration. ElastiCache Reserved Nodes: Redis, Valkey and Memcached Pricing Guide

DynamoDB Reserved Capacity

DynamoDB reserved capacity for read and write capacity units is purchased in 100 RCU/WCU blocks. Usage.ai monitors ConsumedReadCapacityUnits and ConsumedWriteCapacityUnits metrics via CloudWatch to identify the stable P60 baseline and purchases the appropriate number of 100-unit blocks. GSI write amplification is factored into the write capacity analysis: a table with 3 GSIs consumes 4x the application write volume, requiring 4x the reservation relative to application-level write metrics. DynamoDB Reserved Capacity: Read and Write Throughput Pricing Guide

The Zero Lock-In Architecture

The most common objection to any commitment management system is lock-in risk. What if usage drops 40% after a major customer churns? What if the team migrates from MySQL to Aurora? What if a cost-cutting initiative forces a 30% fleet reduction?

Usage.ai Insured Flex Commitments carry no multi-year lock-in obligation. They are quarterly-adjustable, cancel-anytime structures backed by a buyback guarantee. If usage patterns shift, commitments adjust in the next quarterly cycle. If a commitment becomes underutilized because a workload is deprecated, Usage.ai buys it back and returns the value as cashback real money, not credits.

This is structurally different from buying native AWS Reserved Instances directly. AWS RIs are non-refundable and non-cancellable. A 3-year All Upfront RI on an instance that gets deprecated in month 6 costs you 2.5 years of committed spend on a non-existent workload. The buyback guarantee eliminates this risk, making it possible to commit aggressively at the utilization levels that maximize savings without the tail risk of stranded commitments.

What the Data Shows

Research published by nOps in May 2026, analyzing commitment coverage across their managed fleet, found that teams relying on manual RI purchasing achieve an average commitment coverage of 40% of their committable compute spend. Teams using automated management platforms reach 85–95% coverage.

For a $1M/month AWS bill where 60% is committable compute and database spend:

Manual coverage at 40% = $240K/month in commitments, $360K/month on-demand
Autonomous coverage at 90% = $540K/month in commitments, $60K/month on-demand
The 50-point coverage improvement at a 50% average discount rate = $150K/month in additional savings, $1.8M/year

The Database Tier Gap

Teams that have strong EC2 RI coverage of 70–80% often have RDS RI coverage of 20–40% and ElastiCache coverage in single digits. The data tier represents 20–35% of total AWS spend for most production applications. Usage.ai's unified approach treats the data tier with identical analysis rigor to compute. Teams onboarding with strong EC2 coverage but weak database coverage typically see the largest immediate savings from database tier commitment purchases in the first 30 days.

Getting Started

Moving from manual to autonomous commitment management does not require a long implementation project. The transition is operational within 30 minutes.

Step 1: Connect at the billing layer. Usage.ai connects through read permissions on cost and usage data, and write permissions to purchase commitment instruments. No infrastructure access, no agent installation, no changes to running workloads.

Step 2: Set coverage parameters. Define which accounts and services to cover, the utilization threshold for commitment eligibility (typically P60–P70 of hourly consumption), preferred payment options, and any exclusions.

Step 3: Review the baseline analysis. Usage.ai analyzes the last 30–60 days of usage and presents the commitment opportunity: current coverage rate, gap to optimal coverage, projected additional savings, and the specific purchases it would make in the first 24 hours.

Step 4: Enable autonomous purchasing. Switch from recommendation mode to autonomous mode. Commitment purchases execute automatically within the parameters you set. You review weekly summary reports showing purchases made, coverage changes, savings delivered, and any cashback from underutilized commitments.

Most teams see significant coverage gap closure in the first 7–14 days. By day 30, the commitment portfolio reflects the current usage baseline with 85–95% coverage. Realized savings rate typically increases by 15–25 percentage points versus the manual baseline.

If you've moved from manual to autonomous commitment management or tried to and ran into friction what was the blocking issue? Finance approval cycles, trust in the tooling, or something else?

Read the full architecture and optimization breakdown here → Autonomous Commitment Management: The End of Manual RIs

How to Save 33-69% on Your RDS Bill with Reserved Instances

Aman Singh — Wed, 03 Jun 2026 13:28:31 +0000

Every RDS database running on-demand is paying a premium for flexibility that most production databases do not need. Reserved instances eliminate that premium by trading a scheduling commitment for a pricing discount. You agree to run a specific database type for 1 or 3 years AWS charges you 33-69% less for it.

Getting the most out of RDS RIs requires more than clicking "Purchase RI" in the console. The teams that extract maximum savings understand size flexibility mechanics, avoid reserving oversized instances, know which engines get flexibility and which don't, and monitor utilization so underused reservations get caught early.

What an RDS Reserved Instance Actually Is

An RDS RI is not a physical server or a specific database instance. It is a billing discount that AWS applies automatically when a running database's attributes match the reservation.

At purchase you specify: engine (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora), instance family, deployment type (Single-AZ or Multi-AZ), region, term (1-year or 3-year), and payment option (No Upfront, Partial Upfront, All Upfront). AWS then applies the reserved rate to any matching running database in your account no tagging, no assignment, no config change required.

Key mechanic: the RI is a billing artifact, not a resource. Nothing changes about your database. If you delete the database, the RI keeps billing until the term expires. This is why buying the right RI matters, an unused RI that matches nothing is pure waste.

How Much Do RDS RIs Actually Save?

Savings range from ~33% on 1-year No Upfront to up to 69% on 3-year All Upfront, depending on engine and instance family. Using verified MySQL on Graviton4 rates in US East (Vantage.sh, May 2026, sourced from AWS API):

db.r8g.large Single-AZ: $0.239/hr on-demand → $0.160/hr reserved. Saves $692/year.
db.r8g.xlarge Single-AZ: $0.478/hr on-demand → $0.320/hr reserved. Saves $1,384/year.
db.r8g.xlarge Multi-AZ: $0.956/hr on-demand → $0.640/hr reserved. Saves $2,768/year.

A fleet of 10 db.r8g.xlarge Single-AZ instances at 1-year No Upfront: $13,840/year in savings. Verify current rates at aws.amazon.com/rds/mysql/pricing — rates change.

The biggest absolute savings come from reserving your largest and most stable instances first. Prioritize by monthly on-demand cost, not by percentage savings.

For a full engine-by-engine pricing breakdown, the RDS Reserved Instances pricing guide covers every engine and payment option in detail.

Does RDS Have Convertible Reserved Instances?

No and this is one of the most common points of confusion for teams coming from EC2 RI management.

EC2 offers Standard and Convertible RIs. RDS offers only Standard. There are no Convertible RDS Reserved Instances. What RDS does offer is size flexibility, which is a different mechanic entirely. If you need flexibility to change configurations mid-term, use 1-year terms or evaluate the AWS Database Savings Plan.

Size Flexibility: Which Engines Get It and How It Works

Size flexibility lets a single RI cover multiple database sizes within the same family, using normalization units:

A db.r8g.xlarge RI (8 units) automatically covers 2x db.r8g.large (4 units each), or 4x db.r8g.medium (2 units each), or any combination totaling 8 units. It also covers 50% of a db.r8g.2xlarge the remaining 50% bills at on-demand.

Engines with size flexibility: MySQL, MariaDB, PostgreSQL, Aurora, Oracle BYOL.

Engines without size flexibility: Microsoft SQL Server (LI or BYOL), Oracle License Included. These require exact-size reservations. A db.r8g.xlarge SQL Server RI covers only db.r8g.xlarge SQL Server nothing else.

This distinction matters enormously for SQL Server and Oracle LI teams. Every size change requires a new RI purchase. For MySQL, PostgreSQL, and MariaDB, size flexibility provides coverage continuity even after downsizing or splitting instances.

The Six-Step Purchase Process

Step 1: Right-Size Before You Reserve Anything

Reserving an oversized database locks the waste in for 1-3 years. A 33% discount on an instance running at 40% utilization saves less than the same discount on a correctly-sized instance at 80%.

Run a 30-day CloudWatch analysis before purchasing any RI. Four metrics matter:

CPUUtilization: P90 below 40% = over-provisioned on compute
FreeableMemory: consistently above 25% of total RAM = over-provisioned on memory
DatabaseConnections: check against the max_connections ceiling for the proposed smaller size
BufferCacheHitRatio: above 99% = working set fits in current buffer pool, downsizing RAM may be safe

The financial case for right-sizing first: a db.r8g.xlarge RI saves $1,384/year. A db.r8g.large RI saves $692/year AND the base compute is $692/year cheaper. Right-sizing before reserving doubles the effective savings on that oversized instance.

Step 2: Check Extended Support Status Before Purchasing

If any target database is running MySQL 5.7 or PostgreSQL 11, stop. These are in Year 3 Extended Support since March 1, 2026 ($0.200/vCPU-hr surcharge). The Extended Support charge is not reduced by reserved instances.

For a db.r8g.xlarge MySQL 5.7 (4 vCPUs): Extended Support = 4 × $0.200 × 730 = $584/month. The RI saves $115/month. You are saving $115 while paying $584 unnecessarily. Upgrade to MySQL 8.0 or 8.4 first — the engine upgrade delivers 5× the savings of the RI.

Step 3: Audit Deployment Type Before Purchasing

Single-AZ and Multi-AZ RIs are purchased separately and cover only their matching type. A Single-AZ RI on a Multi-AZ instance saves nothing.

Audit your fleet first:

aws rds describe-db-instances \
--query 'DBInstances[*].[DBInstanceIdentifier,MultiAZ,DBInstanceClass]' \
--output table

While you're here: catch non-production databases incorrectly running Multi-AZ. Dev and staging almost never need HA. Converting them to Single-AZ before reserving saves the Multi-AZ premium on top of the RI discount.

A deeper look at when Multi-AZ is actually worth the cost RDS Multi-AZ vs Single-AZ: the cost of high availability.

Step 4: Buy at the Smallest Normalization Unit for Maximum Flexibility

For engines with size flexibility, purchasing at the smallest instance size you might ever need gives you the most flexible coverage at the same total commitment.

Example: you need 8 normalization units of r8g coverage.

Option A: 1x db.r8g.xlarge RI
Option B: 2x db.r8g.large RIs

Both cost the same total. But if you later right-size one xlarge to large, Option B continues covering both large instances with zero waste. Option A leaves excess units and partial on-demand billing.

Caveat: this only applies to engines with size flexibility (MySQL, PostgreSQL, MariaDB, Aurora, Oracle BYOL). For SQL Server and Oracle LI, purchase exactly the size you are running.

Step 5: Choose the Payment Option That Matches Your Situation

No Upfront: Zero capital today. ~30-33% savings. 1-year only. Best for first-time RI purchases or lower-confidence workloads.
Partial Upfront: Moderate lump sum plus reduced monthly charges. ~35-50% savings. 1-year or 3-year. Best for most production databases.
All Upfront: Full term cost paid at purchase. ~45-69% savings. Best for your most stable, longest-running production databases.

Practical rule: start with 1-year No Upfront on your first RI purchase for any database. Review utilization after 12 months. If the RI was fully utilized and the database is still running in the same configuration, renew at Partial or All Upfront for the deeper discount.

Step 6: Monitor Utilization Monthly and Act on Underuse Early

An RI covering a running database generates savings. An RI whose matching database was deleted or resized generates waste. Monthly monitoring catches this early.

In AWS Cost Explorer: Reservations > Utilization Report, filter for Amazon RDS. A well-managed fleet should show above 90% utilization across the board. Any RI below 80% deserves immediate investigation.

CLI equivalent:
aws ce get-reservation-utilization \
--time-period Start=[start],End=[end] \
--granularity MONTHLY \
--filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Relational Database Service"]}}'

When you find an underutilized RI: check if a matching instance exists elsewhere in the account. If not, consider launching a new database with matching attributes to consume the RI until expiry. For Standard RIs (which is all RDS offers), you cannot exchange them for different configurations the RI runs to term.

The Correct Order of Operations

Most teams optimize RI purchasing first and fix expensive underlying problems later. The right sequence:

Eliminate Extended Support charges first. MySQL 5.7 or PostgreSQL 11 in ES Year 3? Upgrade before reserving.
Convert non-production Multi-AZ to Single-AZ. Dev and staging don't need HA. Converting 10 instances saves $14,016/year before any RI is purchased.
Right-size using 30 days of CloudWatch data. Downsize over-provisioned instances before committing.
Migrate to current Graviton generation (r8g, m8g) if still on r7g or older.
Purchase RIs on the clean, right-sized fleet. Start with 1-year No Upfront on highest-spend instances.
Monitor utilization monthly. Catch underused reservations before they run to term.

Usage.ai Flex Reserved Instances executes this entire sequence automatically surfacing Extended Support exposure, identifying non-production Multi-AZ, evaluating utilization before recommending reservations, and purchasing the optimal RI within your approved parameters.

Recommendations refresh every 24 hours versus Cost Explorer's 72-hour cycle. If any reserved instance becomes underutilized, Usage.ai provides cashback in real money.

What's been the biggest source of wasted RI spend in your RDS fleet underutilized reservations, wrong deployment type, or reserving before right-sizing?

Read the full architecture and optimization breakdown here → How to Save on RDS Reserved Instances: A Quick Guide

What Is the Difference Between Cloud Cost Optimization and Cloud Cost Management?

Aman Singh — Wed, 03 Jun 2026 11:18:11 +0000

Cloud cost management and cloud cost optimization are often used interchangeably but they solve different problems. Understanding the distinction matters if you want to actually move the needle on your cloud bill.

Cloud cost management is about visibility and control: tracking spend, allocating costs to teams, setting budgets, and reporting on where cloud dollars go.

Cloud cost optimization is about action: reducing infrastructure costs through rightsizing, eliminating waste, and purchasing discounted commitments like Savings Plans or Reserved Instances.

Most organizations start with management tools. They build dashboards, implement tagging, and get spend reports by service and team. That foundation is necessary but it doesn't reduce the bill on its own.

What Cloud Cost Management Actually Covers

Cost management gives you the financial picture. The core components:

Cost visibility and reporting: dashboards showing total spend, spend by service (compute, storage, databases), trends over time, and cost by team or environment
Cost allocation and tagging: mapping infrastructure costs to the teams that generate them using resource tags like team:payments or environment:production
Budgeting and forecasting: monthly budgets, historical trend forecasting, and alerts when spending crosses thresholds
Governance and financial controls: spending alerts, approval processes for high-cost resources, and usage policies for dev environments

These mechanisms create financial accountability. Engineers see their costs. Finance can report on cloud spend. Anomalies get caught faster.

What they don't do is tell you what to change or make those changes automatically.

What Cloud Cost Optimization Actually Covers

Optimization picks up where management leaves off. Common strategies:

Rightsizing: analyzing CPU, memory, and network utilization to downsize overprovisioned instances without impacting performance. Most cloud environments provision for peak load, which means they're running oversized the majority of the time.

Eliminating idle resources: unused VMs, unattached storage volumes, forgotten load balancers, dev environments left running overnight. These accumulate fast in large organizations.

Storage tiering: moving infrequently accessed data to lower-cost storage tiers using lifecycle policies, so you only pay premium rates for data that needs high availability.

Auto-scaling: dynamically adjusting capacity based on real-time demand instead of running fixed infrastructure at all times.

Purchasing commitments: the highest-leverage lever of all.

For a deep dive into how these strategies work in practice, check out How Cloud Cost Optimization Actually Works (Beyond Dashboards & Discounts)

The Biggest Lever: Commitment Coverage

Savings Plans and Reserved Instances from AWS (and equivalent programs on GCP and Azure) offer substantial discounts compared to on-demand pricing in exchange for committing to a baseline level of usage over time.

Commitment coverage measures the share of eligible usage billed under those discounted rates:

Commitment Coverage = Usage covered by commitments / Total eligible usage

If $60K of a $100K/month compute bill runs under commitments, coverage is 60%. Higher coverage means a larger portion of infrastructure runs at discounted rates.

The challenge is that commitments introduce utilization risk. If usage drops below what was committed, you're paying for capacity you're not consuming. This is why many organizations deliberately keep coverage low and leave significant savings on the table.

Modern optimization platforms address this by automating commitment analysis and purchasing, and by providing cashback protection when committed usage goes underutilized. That removes the main reason teams hesitate to increase coverage.

Why Visibility Alone Doesn't Reduce Your Bill

A cost management dashboard might surface that compute represents 70% of your cloud spend. It does not tell you:

whether those workloads are sized correctly
whether any of those instances are idle
whether commitments should be purchased and at what level

That gap between knowing and acting is where most cloud waste persists. Manual optimization reviews are slow and hard to scale. By the time a recommendation gets reviewed and acted on, usage patterns may have already shifted.

If you're weighing whether to build internal tooling versus using a dedicated platform for this, the tradeoffs are covered in detail here The FinOps Build vs Buy Dilemma: A Practical Guide

The FinOps Progression

Most organizations follow this path:

Cost visibility: understand where spending occurs
Cost governance: implement budgets and allocation policies
Cost optimization: improve efficiency and pricing
Automation: continuously optimize at scale

Management handles steps one and two. Optimization handles steps three and four. Both are necessary but the savings come from the latter.

Best Practices That Combine Both

Establish complete tagging coverage before attempting optimization: you can't rightsize what you can't attribute
Monitor utilization continuously, not quarterly: cloud environments change faster than periodic reviews can track
Base commitment purchases on predictable baseline usage, not peak demand
Automate where possible: manual reviews don't scale, and optimization platforms can respond to usage changes faster than humans can
Embed cost awareness in engineering workflows: developers who see the financial impact of infrastructure decisions make better architectural choices

What's the biggest gap your team has run into between your cost visibility tools and actually reducing your cloud bill?

Continue with the complete technical article here → What Is the Difference Between Cloud Cost Optimization and Cloud Cost Management?

Usage.ai Introduces a Free AWS Savings Calculator That Reads Your Actual Bill Not Just Your Guesses

Aman Singh — Mon, 01 Jun 2026 09:27:06 +0000

Cloud cost optimization just got a whole lot more accessible. Usage.ai has rolled out a free AWS Cost Optimization Savings Calculator that removes one of the biggest friction points in cloud finance: not knowing where to start.

The tool is designed for engineering leads, DevOps teams, and finance managers who suspect they're overspending on AWS but don't have the time or the internal data clarity to quantify it. And unlike most tools in this space, it doesn't ask you to already know your numbers before it gives you one.

The Problem With Every Other Cloud Cost Tool

Here's something most cloud vendors won't say out loud: the majority of cloud savings calculators are built for people who don't actually need them.

To get an answer from a traditional savings estimator, you typically need to know your Reserved Instance coverage percentage, your per-service monthly breakdown, your DevOps headcount and hourly billing rate, and more. That's a significant amount of internal research just to find out if you're overpaying.

Meanwhile, the average AWS team overpays by anywhere between 30 and 40 percent every single month and most of them never get a concrete number to bring to a budget or procurement conversation.

Usage.ai's new calculator flips this entirely. Rather than asking you to describe your cloud environment, it simply reads your AWS bill and tells you the answer.

"The dirty secret of cloud savings tools is that they've always asked the people with the problem to already know the answer," said Kaveh Khorram, CEO of Usage.ai. "Your AWS bill already contains the truth. We just built a tool that reads it."

Three Ways to Get Your Savings Number

The calculator is built around flexibility. Teams can get their estimate in whichever way fits how much time and data they have available:

Method 1: Quick Slider Estimate A benchmark-driven slider that gives you a ballpark savings figure instantly. No uploads, no data required. Ideal when you just need a rough number for an internal discussion.

Method 2: Upload Your AWS Invoice Drop in a PDF copy of your AWS bill and the calculator returns a savings estimate based on your actual spend patterns not industry averages. No AWS account connection required.

Method 3: Cost Explorer CSV (Most Accurate) Export a CSV from AWS Cost Explorer, upload it, and receive a per-service, per-region savings breakdown with up to 92% accuracy. This is the path for teams that need a number a CFO or finance committee can act on.

All three options are completely free, require no AWS account access, no login, and involve no sales conversation.

Try the AWS Savings Calculator here.

What Happens After You Get Your Number

The calculator is the entry point, not the endpoint. Teams that want to go beyond estimation and start realizing actual savings can connect their AWS account to Usage.ai's platform through a read-only IAM role billing and usage data only, with zero access to workloads or production infrastructure.

From there, the platform monitors usage in real time and applies commitment-based discounts dynamically, delivering pricing equivalent to a 3-year Reserved Instance commitment without the 3-year lock-in.

The pricing model is structured to remove every reason to delay:

No setup fees
No subscriptions or minimums
Charges are based only on realized savings if you save nothing, you pay nothing

Usage.ai also offers what it calls an Insured Commitments model: if your usage drops below a purchased commitment level, the company refunds the difference as cashback or cloud credits. That means the demand risk that has historically made long-term AWS commitments a liability for finance teams is fully absorbed.

Who This Is Built For

The calculator is particularly relevant for:

Engineering and platform teams managing AWS spend without dedicated FinOps resources
Finance and procurement leads who need a credible savings number before initiating vendor conversations
CTOs and VPs of Engineering preparing for budget reviews or board discussions on infrastructure costs
Startups and scale-ups running lean teams who know they're overpaying but haven't had a fast way to prove it

A Few Fast Facts

Free to use no account creation, no credit card
Results in under 60 seconds
SOC 2 Type II certified platform
Covers AWS, Azure, and GCP cost optimization (platform-level)
Headquartered in New York City

Get Started

If your AWS bill has been feeling uncomfortably large or if you simply can't tell whether it should, this calculator is the fastest way to find out.

Start your free savings estimate.

Teams looking for a more personalized deep-dive can also schedule a 15-minute session with the Usage.ai team directly from the site.

To read the original press release published by Usage.ai, click here

What Is the Difference Between Cloud Cost Optimization and Cloud Cost Management?

Aman Singh — Fri, 29 May 2026 13:37:20 +0000

Cloud cost management is about visibility and control: tracking spend, allocating costs to teams, setting budgets, and reporting on where cloud dollars go.

Cloud cost optimization is about action: reducing infrastructure costs through rightsizing, eliminating waste, and purchasing discounted commitments like Savings Plans or Reserved Instances.

What Cloud Cost Management Actually Covers

Cost management gives you the financial picture. The core components:

Cost visibility and reporting: dashboards showing total spend, spend by service (compute, storage, databases), trends over time, and cost by team or environment
Cost allocation and tagging: mapping infrastructure costs to the teams that generate them using resource tags like team:payments or environment:production
Budgeting and forecasting: monthly budgets, historical trend forecasting, and alerts when spending crosses thresholds
Governance and financial controls: spending alerts, approval processes for high-cost resources, and usage policies for dev environments These mechanisms create financial accountability. Engineers see their costs. Finance can report on cloud spend. Anomalies get caught faster.

What they don't do is tell you what to change or make those changes automatically.

What Cloud Cost Optimization Actually Covers

Optimization picks up where management leaves off. Common strategies:

Eliminating idle resources: unused VMs, unattached storage volumes, forgotten load balancers, dev environments left running overnight. These accumulate fast in large organizations.

Storage tiering: moving infrequently accessed data to lower-cost storage tiers using lifecycle policies, so you only pay premium rates for data that needs high availability.

Auto-scaling: dynamically adjusting capacity based on real-time demand instead of running fixed infrastructure at all times.

Purchasing commitments: the highest-leverage lever of all.

For a deep dive into how these strategies work in practice, check out How Cloud Cost Optimization Actually Works (Beyond Dashboards & Discounts)

The Biggest Lever: Commitment Coverage

Commitment coverage measures the share of eligible usage billed under those discounted rates:

Commitment Coverage = Usage covered by commitments / Total eligible usage
If $60K of a $100K/month compute bill runs under commitments, coverage is 60%. Higher coverage means a larger portion of infrastructure runs at discounted rates.

Why Visibility Alone Doesn't Reduce Your Bill

A cost management dashboard might surface that compute represents 70% of your cloud spend. It does not tell you:

whether those workloads are sized correctly
whether any of those instances are idle
whether commitments should be purchased and at what level

If you're weighing whether to build internal tooling versus using a dedicated platform for this, the tradeoffs are covered in detail here The FinOps Build vs Buy Dilemma: A Practical Guide

The FinOps Progression

Most organizations follow this path:

Cost visibility: understand where spending occurs
Cost governance: implement budgets and allocation policies
Cost optimization: improve efficiency and pricing
Automation: continuously optimize at scale

Management handles steps one and two. Optimization handles steps three and four. Both are necessary but the savings come from the latter.

Best Practices That Combine Both

Establish complete tagging coverage before attempting optimization: you can't rightsize what you can't attribute
Monitor utilization continuously, not quarterly: cloud environments change faster than periodic reviews can track
Base commitment purchases on predictable baseline usage, not peak demand
Automate where possible: manual reviews don't scale, and optimization platforms can respond to usage changes faster than humans can
Embed cost awareness in engineering workflows: developers who see the financial impact of infrastructure decisions make better architectural choices

What's the biggest gap your team has run into between your cost visibility tools and actually reducing your cloud bill?

Continue with the complete technical article here → What Is the Difference Between Cloud Cost Optimization and Cloud Cost Management?

How Compute Savings Plans Work (Step-by-Step)

Aman Singh — Fri, 29 May 2026 12:37:49 +0000

Most people understand that a Compute Savings Plan saves money on cloud compute. Far fewer understand the precise mechanism which matters, because getting the commitment amount wrong in either direction costs real money.

Too high: you pay for committed hours you do not use. Too low: you miss savings on usage that could have been covered. The difference between a well-sized Savings Plan and a poorly-sized one can easily be tens of thousands of dollars per year on a mid-size fleet.

This guide walks through the exact mechanics, hour by hour, with worked examples on both AWS and Azure.

Step 1: You Choose a Commitment Amount

Before anything else, you decide how much per hour you want to commit. This is the single most important decision in the entire process. Everything else is automatic, the discount application, the coverage calculation, the billing.

The commitment amount is a dollar figure: $X per hour. It represents a minimum spend level. You are telling the cloud provider: every hour for the next 1 year (or 3 years), I guarantee I will use at least this much compute.

The right commitment amount is your stable baseline, not your average and not your peak. Pull your last 30 days of hourly compute spend. Sort the values. Find the P70 or P75: the spend level you are at or above for 70–75% of hours. That is roughly where your commitment should sit.

Why P70–P75 and not the average? Because the average includes your peak hours and your quietest hours equally. If you commit to the average, you generate wasted commitment in the bottom 50% of hours. At P70, you are paying for unused commitment in only 30% of hours and those hours only waste the difference between actual usage and committed amount, not the full committed amount.

If you want to understand how commitment-based discounts work across AWS, Azure, and GCP, we covered the full landscape here What Are Commitment-Based Discounts in Multi-Cloud Services?

Step 2: The Cloud Provider Applies Discounted Rates

Once you have an active Savings Plan, the cloud provider applies discounted rates to your eligible compute usage every hour. There is no matching step, no rule to write, no instance to tag. The discount applies automatically.

On AWS, the discount applies to EC2 instance hours, Fargate compute, and Lambda duration charges. On Azure, it applies to Virtual Machine compute, AKS node pool VMs, Azure Functions Premium, Container Instances, and App Service Premium v3.

The provider starts by applying the discount to usage with the highest savings rate first. If you are running an m5.xlarge (60% savings rate) and a c5.xlarge (58% savings rate) simultaneously, the m5 gets the Savings Plan rate applied first, then the c5, until you hit your committed hourly amount.

Reserved Instances are applied before Savings Plans. If you have an EC2 RI for a specific instance type, that RI discount applies first. The Savings Plan then covers the remaining eligible usage. RIs handle the stable, specific-configuration core; Savings Plans handle everything else.

Step 3: Usage Up to Your Commitment Is Billed at the Discounted Rate

The discounted rate applies to your eligible usage hour by hour, up to your committed amount.

Example: You have committed to $5.00/hour on AWS. In a given hour, you run compute that would cost $8.00 at on-demand rates.

Your Savings Plan covers the first $5.00 worth of compute at the discounted rate
At 60% savings, that $5.00 of on-demand compute costs you approximately $2.00–$2.50
The remaining $3.00 of on-demand usage is billed at standard rates
Your total bill for that hour: ~$5.00–$5.50 instead of $8.00

Step 4: Usage Above Your Commitment Is Charged at On-Demand Rates

The Savings Plan only covers usage up to your committed amount. Any usage above that threshold in a given hour is billed at normal on-demand rates, as if you had no Savings Plan at all.

This is not a penalty, it is the intended design. Your Savings Plan committed to a base level of spend. Additional usage above that base is flexible, on-demand capacity you have not committed to.

If your usage regularly exceeds your commitment by a significant margin, you have an under-committed Savings Plan. Savings Plans stack each new purchase on top of the previous ones, so you can add a second commitment at any time. You cannot modify an existing commitment upward.

Step 5: Unused Commitment Is Charged Regardless

This is the step most people underestimate. If you commit to $5.00/hour and your actual compute usage in a given hour is only $2.00, you still pay $5.00. The $3.00 of unused commitment is charged and does not carry forward.

There is no rollover. Each hour is independent. An unusually quiet Monday at 3am does not benefit from unused commitment banked during peak Tuesday hours.

This is exactly why sizing the commitment conservatively matters. For every dollar you over-commit during low-usage hours, you pay that dollar with zero return. If you over-commit by $1.00/hour and run 720 hours in a month, that is $720/month in pure waste even as your Savings Plan discount is working correctly during busy hours.

Step 6: The Discount Renews Every Hour, Automatically

The Savings Plan does not need to be activated, refreshed, or managed after purchase. Every single hour for the duration of your term, the cloud provider checks your eligible compute usage, applies the discounted rates up to your committed amount, and charges the remainder at on-demand rates.

You do not need to update anything when you change instance types, launch in new regions, or migrate workloads. The discount follows automatically this is the core advantage of Savings Plans over Reserved Instances.

One scenario requiring attention: if you stack a new Savings Plan on top of an existing one, the combined committed amount across all active plans represents your total hourly commitment. Keep track to avoid unintentional over-commitment.

How AWS and Azure Apply Savings Plan Discounts Differently

The core mechanics are nearly identical. But there are two important differences.

*AWS: Reserved Instances First, Then Savings Plans
*
AWS applies discounts in a strict order: RIs first, then Savings Plans. The practical benefit is that RIs and Savings Plans genuinely complement each other. Purchase RIs for the stable, known-configuration core of your fleet. Use a Savings Plan for the flexible remainder. The combined strategy captures near-maximum savings across your entire compute footprint.

Azure: Reservations First, 3-Year Plans Before 1-Year Plans

Azure follows the same principle Reservations before Savings Plans. But Azure adds a second rule: if you have both 3-year and 1-year Savings Plans active simultaneously, the 3-year plan is applied first (higher discount). This maximizes the benefit from your most valuable commitments before the less-valuable ones are consumed.

Azure also processes each hour completely independently. If you use $100 of eligible compute and your commitment is $80, Azure prices $80 at the Savings Plan rate and the remaining $20 at pay-as-you-go. If you only use $60 in an hour but commit $80, you lose $20 worth of benefit if it does not roll over.

If you are weighing term length, the tradeoffs between 1-year and 3-year commitments go deeper than just the discount percentage How to Choose Between 1-Year and 3-Year AWS Commitments

How to Size Your Commitment Correctly

One number determines whether your Savings Plan generates net savings or net waste: the commitment amount.

Pull 30–60 days of hourly compute spend. In AWS Cost Explorer, filter by EC2/Lambda/Fargate and export at hourly granularity. In Azure Cost Management, export VM compute at daily granularity (divide by 24 for an hourly proxy).

Find the P70 of your hourly spend. Sort all hourly values lowest to highest. Find the value at the 70th percentile. Set your initial commitment at or slightly below this number.

Do not use the AWS or Azure recommendation directly. Both platforms provide Savings Plan recommendations. These optimize for coverage, not for avoiding over-commitment. The platform recommendation will often suggest a higher commitment than your P70 calculation. Trust your own math.

Start conservative, then layer up. First purchase: commit at P65–P70. Review utilization after 30 days. If utilization is consistently above 95%, add a second commitment on top. Savings Plans stack, you can layer additional commitments without modifying or cancelling the first.

Where Usage.ai Fits In

Every step above is something your team has to do manually today: pull the data, calculate the P70, validate the recommendation, submit the purchase, monitor utilization, respond when usage drops, renew before expiration. Each step is not complicated in isolation but together, they add up to 8–16 hours of FinOps work per month, per cloud.

Usage.ai automates this entire process. The platform analyzes hourly compute spend with a 24-hour data refresh (versus Cost Explorer's 72-hour cycle), calculates the correct commitment level, and purchases automatically within your approved parameters. If a commitment becomes underutilized because your workload drops, Usage.ai provides cashback in real money not credits.

The fee model is a percentage of realized savings only. If Usage.ai saves nothing, you pay nothing.

How does your team currently handle Savings Plan sizing manual P70 calculations, native AWS/Azure recommendations, or something else? Curious whether others have found a middle ground that works.

Continue reading the full technical analysis here → How Compute Savings Plans Work (Step-by-Step)

AWS Database Savings Plans: What DB Teams Need to Know

Aman Singh — Wed, 27 May 2026 13:00:45 +0000

AWS expanded its Savings Plans portfolio with Database Savings Plans, a spend-based discount model for managed database services that can cut costs by up to 35%. This is the first time the Savings Plans model has extended beyond compute, and it changes how DB teams can commit to long-term database spend.

Usage.ai added native support for Database Savings Plans in January 2026.

What Are AWS Database Savings Plans?

Instead of committing to a specific instance class, engine, or Region (like Reserved Instances require), you commit to a consistent hourly spend amount for a one-year term. AWS automatically applies discounts across all eligible usage up to that committed amount, every hour, without manual action.

The model mirrors how Compute Savings Plans work but applied to the database layer for the first time. It covers both provisioned and serverless database usage.

How the commitment works

Commit to a dollar amount per hour for 1 year
AWS applies discounts to eligible usage each hour, prioritizing where it delivers the most value
Usage beyond the committed amount is charged at standard on-demand rates
A single plan can cover an RDS instance in one Region and an Aurora instance in another no separate RIs needed

Payment options

Database Savings Plans are No Upfront only billed as monthly charges over the 1-year term. There's no All Upfront or Partial Upfront option, which is a structural difference from Compute and EC2 Instance Savings Plans. AWS offers a separate "Advance Pay" billing feature for pre-payment of monthly charges, but this isn't a payment option on the Savings Plan itself.

Which AWS Services Are Covered?

Database Savings Plans apply across these managed database services:

Amazon Aurora: Gen 7+ provisioned instances (db.r7, db.r8g, db.m7 families), Aurora Serverless v2, Aurora DSQL
Amazon RDS: Gen 7+ provisioned instances (db.r7, db.r8g, db.m7 families)
Amazon DynamoDB: On-demand throughput (up to 18% savings); provisioned capacity (up to 12% savings)
Amazon ElastiCache: Valkey engine only (Gen 7+ provisioned and Serverless). Standard Redis and Memcached still require Reserved Nodes.
Amazon DocumentDB: Gen 7+ provisioned instances and DocumentDB Serverless
Amazon Neptune: Gen 7+ provisioned instances and Neptune Serverless
Amazon Neptune Analytics: Added March 2026
Amazon Keyspaces: On-demand and provisioned throughput
Amazon Timestream: InfluxDB instances (LiveAnalytics not covered)
Amazon OpenSearch: Serverless and Gen 7+ provisioned instances (expanded March 2026)
AWS DMS: Gen 7+ replication instances and DMS Serverless

Older instance families (db.m5, db.r5, db.r6g, etc.) are not eligible and still require Reserved Instances.

If you want to understand how these two commitment types compare across every relevant factor, we covered the full decision framework here AWS Savings Plans vs Reserved Instance

How Database Savings Plans Differ From Reserved Instances

Reserved Instances require you to specify at purchase the exact instance class, database engine, deployment type, and AWS Region. All four must match the running workload for the discount to apply. Change any one of them and the RI no longer applies.

Modern database environments regularly resize, upgrade instance generations, migrate engines, or shift from Single-AZ to Multi-AZ. Each is a routine decision, but each can strand an RI and create unexpected cost exposure.

Database Savings Plans decouple the discount from configuration. Committed spend follows actual usage rather than a specific setup that may change.

A few key structural differences:

Flexibility: RIs break on config changes; Savings Plans follow spend through routine changes
Max discount: RIs offer up to 40%+ for 3-year All Upfront; Database Savings Plans offer up to 35% (serverless) or up to 20% (provisioned Gen 7+)
Term: RIs support 1-year or 3-year; Database Savings Plans are 1-year only
Billing order: RIs are applied first each billing hour; Savings Plans apply second, to remaining eligible usage
Coverage automation: RIs must match configuration exactly; Savings Plans apply automatically across eligible spend

For DynamoDB, it's worth noting you cannot combine Database Savings Plans with DynamoDB reserved capacity on the same workload.

What's the Financial Impact?

Discount ranges by deployment model:

Serverless (Aurora Serverless v2, Aurora DSQL, ElastiCache Serverless for Valkey, DocumentDB Serverless, Neptune Serverless, OpenSearch Serverless) up to 35%
Provisioned Gen 7+ instances (Aurora, RDS, ElastiCache Valkey, DocumentDB, Neptune, DMS, Timestream InfluxDB) up to 20%
DynamoDB / Keyspaces on-demand throughput up to 18%
DynamoDB / Keyspaces provisioned throughput up to 12%

Beyond the headline discount, the stronger financial argument is reducing stranded RI cost. When an RI becomes stranded because an instance was resized or upgraded, you keep paying for the RI while also paying on-demand rates for the new configuration. For large database environments with frequent change, the avoided waste from stranded RIs can equal or exceed the small discount difference between the two commitment models.

What Changes If You're Currently Using Reserved Instances?

Existing RIs continue functioning normally for the remainder of their term with no disruption, no immediate action required.

The decision point comes at renewal. Teams should evaluate how often their databases resize, change capacity modes, or shift deployment models. If the answer is frequently, the flexibility of a spend-based commitment is likely worth the small discount difference compared to an RI.

For the full breakdown of how Usage.ai automates RI and Savings Plan optimization How Usage.ai Works: RIs, SPs & Zero-Risk Savings

Getting Started: A Practical Sequence

Audit your current database inventory Catalog every managed database service on AWS service type, instance family and generation, engine, deployment model, Region, and current coverage status.
Identify eligible workloads RDS and Aurora need Gen 7+. ElastiCache needs Valkey. DynamoDB, Neptune, DocumentDB, Keyspaces, Timestream, and DMS are broadly eligible. Ineligible workloads stay on RIs or on-demand.
Analyze consumption patterns Look at hourly spend data over at least 90 days to understand stability and set a reasonable commitment level. Usage.ai automates this using your AWS Cost and Usage Report data.
Model commitment options Evaluate expected coverage ratio, projected savings, and financial risk at different commitment levels. Manual spreadsheet modeling works for small environments but breaks down quickly at scale.
Purchase and monitor Buy through the AWS console or API. Monitor coverage levels regularly. Usage.ai tracks this continuously and surfaces adjustment recommendations before gaps become cost issues.

Reserved Instances required predicting exactly what you'd run, on which engine, in which Region, for the next one to three years. Database Savings Plans replace that with a simpler question: how much are you likely to spend?

Most DB teams can answer that confidently. And with spend-based commitments now covering the full managed database stack, the operational overhead of tracking instance-specific commitments drops significantly.

How is your team currently handling database commitment strategy sticking with RIs, moving to Savings Plans, or running a mix? Would love to hear how others are thinking about this transition.

Read the complete deep dive here → AWS Database Savings Plans Explained for DB Teams

7 Cloud Optimization Strategies to Survive Holiday Traffic Spikes

Aman Singh — Tue, 26 May 2026 10:57:33 +0000

Holiday traffic is unforgiving. Last year, many retailers saw seasonal traffic jump over 250% during peak hours and a 1-second slowdown was enough to reduce conversions by nearly 10%.

The brands that held up weren't necessarily running the biggest infrastructure. They were the ones with the smartest optimization going in.

Here are 7 strategies to get your cloud ready before holiday demand hits.

1. Run a Holiday-Focused Historical Load Analysis

Before optimizing anything, understand how your systems actually behaved during past peak seasons. A 6–12 month historical load analysis shows you what "normal" looks like against your holiday surge behavior.

Review these key metrics:

Traffic patterns: which days and hours consistently spiked
CPU and memory utilization: how quickly resources saturated at peak
API call volume: endpoints that historically struggled under load
Sales-event trends: Thanksgiving, Black Friday, year-end comparisons This gives you a reliable holiday baseline for smarter scaling decisions and fewer surprise cost spikes.

2. Right-Size Before the Surge

Up to 35% of cloud resources run over-provisioned throughout the year. During peak season, that waste compound autoscaling builds on top of whatever you already have allocated.

Right-sizing creates a clean baseline so every unit of holiday scaling is justified. Review:

Underutilized instances running at <30% CPU or memory
Over-provisioned services like oversized API nodes or background workers
Idle dev/test environments that don't need holiday-level capacity
Old instance families that cost more and perform worse than modern equivalents

3. Align Autoscaling Rules With Actual Demand Patterns

Most autoscaling policies are tuned once and forgotten. During the holidays, traffic spikes earlier, lasts longer, and recovers more slowly. If your rules don't reflect that, you'll either scale reactively or excessively.

Quick audit checklist:

Threshold sensitivity; if cooldown periods are too long, autoscaling lags behind real demand and you spill into On-Demand
Scaling step sizes; adding one instance at a time during heavy load means your system is always catching up
Predictive or pre-warming logic; checkout, search, and payment APIs often need capacity before the spike arrives
Instance family alignment; scaling into uncommitted families can reduce Savings Plan/RI coverage by 20–40%

4. Strengthen Database, Caching, and API Performance

Databases, caching layers, and internal APIs are usually first to buckle under holiday load. Last year, retailers reported 40–60% of peak-season latency came from bottlenecks in these layers alone.

Targeted optimizations:

Audit slow query paths; unindexed fields or unoptimized joins cause cascading slowdowns at scale
Tune cache TTLs and add layer-2 caching; holiday traffic patterns are repeatable; teams that tuned caching saw 20–40% lower backend latency
Review API concurrency capacity; gateways often hit concurrency ceilings before compute limits do
Pre-warm critical services; search, recommendations, payment processors, and inventory checkers all struggle with cold starts during sudden 2–3× surges

5. Use Spot and Mixed Instance Policies for Non-Critical Workloads

Not every workload needs On-Demand reliability. Spot instances and mixed instance groups let you run scalable workloads at 60–90% lower cost without touching customer-facing systems.

Move batch jobs, catalog updates, data pipelines, and ML retraining to Spot
Use mixed-instance Auto Scaling Groups to pull from whichever capacity pool is most available
Implement checkpointing or queue-based architecture so workloads resume if a Spot instance is reclaimed
Keep checkout, search, login, and payments on On-Demand or committed capacity

6. Refresh Your Commitments Before Peak Season

Outdated Savings Plans or Reserved Instances during holiday traffic often fail to cover the burst capacity your workloads actually need.

Check instance family alignment, even a small drift like moving from C5 to C7g can reduce coverage significantly
Forecast your holiday baseline, if you're expecting a 2–3× spike, your commitments should reflect that; short-term 1-year or flexible Compute Savings Plans can cover seasonal bursts
Restrict ASG/Kubernetes scaling to committed families to avoid On-Demand spillover
Rebalance underutilized RIs or Savings Plans before the surge hits If you want to understand how commitment coverage and right-sizing work together to reduce cloud waste, we covered it in detail here Cloud Cost Optimization with Usage.ai

7. Monitor Cost and Performance in Real Time During Peak Windows

Optimization work loses impact fast if no one's watching during the busiest hours. Weekly dashboards aren't enough; you need live visibility across cost and performance.

Track autoscaling behavior as it happens unexpected scaling events often signal backend stress or capacity misalignment
Alert on On-Demand spillover if uncommitted instances start running, costs can spike before you notice
Watch API latency, error rates, and queue depth small latency increases during peak hours translate directly to cart drop-offs
Monitor hourly cost burn rate holiday surges shift consumption patterns dramatically; know your spend trajectory in real time

Scaling for the holidays isn't just a capacity problem, it's a cost and efficiency problem too. The teams that come out ahead are the ones who treat optimization as prep work, not a reaction.

What's the biggest challenge your team faces when scaling for peak season is it the cost unpredictability, the autoscaling behavior, or something else entirely?

Access the complete technical write-up here → 7 Cloud Optimization Strategies You Need Before Holiday Traffic Hits

AWS vs Azure vs GCP: A Real Cloud Pricing Comparison

Aman Singh — Tue, 26 May 2026 09:31:24 +0000

Choosing between AWS, Azure, and Google Cloud isn't just about picking the cheapest hourly rate. All three providers offer scalable compute, storage, and networking, the real differences show up in how discounts are structured, how commitments work, and how much risk you absorb when usage shifts.

This comparison focuses on those mechanics: pricing models, commitment flexibility, and what "savings" actually means once you factor in coverage and utilization.

How Each Provider Structures Pricing

All three providers stack pricing in the same basic layers: on-demand at the top, then commitment-based discounts, then interruptible capacity, then enterprise agreements. But the way those layers interact differs.

On-demand is the baseline provision resources, pay per second or per hour, no lock-in. It's also the most expensive and the ceiling against which every discount is measured. Rates are region-specific, so a US-East instance can look meaningfully different from the same instance in Europe-West.

Commitment discounts are where the structural differences emerge.

AWS offers Reserved Instances (locked to a specific instance family and region) and Savings Plans (spend-based, flexible across instance types). Savings Plans are generally the more practical option for modern workloads. Discounts can reach up to 72% vs on-demand for 3-year terms.
Azure offers Reserved VM Instances and a Savings Plan for Compute. It also has Azure Hybrid Benefit; if your org already holds Windows Server or SQL Server licenses, you can apply them to reduce effective compute rates. This creates a pricing advantage for Microsoft-heavy shops that doesn't appear in raw rate comparisons.
GCP offers Committed Use Discounts (resource-based or spend-based) plus Sustained Use Discounts automatic rate reductions for VMs that run most of the billing month, no commitment required. This is unique: GCP blends utilization-based discounts with optional longer-term commitments.

Spot/preemptible capacity exists across all three but should be treated as probabilistic capacity, not a commitment substitute. Deep discounts, but workloads must tolerate interruption.

If you're trying to understand how Savings Plans differ from Reserved Instances, we covered the tradeoffs in detail here AWS Savings Plans vs Reserved Instances: A Practical Guide

"Equivalent" Instances Aren't Always Equivalent

The instinct in any pricing comparison is to match specs 4 vCPU, 16 GB RAM and compare hourly rates. That's a reasonable start, but it misses a few variables that actually matter.

Processor generation differs within and across providers. AWS offers Intel, AMD, and Graviton (ARM) variants. Azure ties D-series generations to specific CPU types. GCP supports Intel, AMD, and custom Google processors. Two instances with matching vCPU counts may not deliver the same single-thread performance or network throughput which means a cheaper hourly rate could require more instances to handle the same workload.

Regional pricing variance is significant on all three platforms. A provider that looks cheaper in the US-East might be more expensive in Europe-West. For globally distributed architectures, region selection can matter as much as instance family choice.

Billing granularity is broadly per-second across modern AWS, Azure, and GCP instances but rounding behavior across thousands of scaling events can still accumulate in elastic workloads.

Attached costs block storage, network egress, load balancers, monitoring are often excluded from compute comparisons but are part of the real workload cost.

For context on how cloud budgeting tools fit into this AWS Budgets vs Cost Explorer: Key Differences Explained

Commitment Modeling: Where the Real Numbers Live

Public pricing pages show on-demand rates. In practice, most production environments run a mix of on-demand, 1-year commitments, 3-year commitments, and spot capacity.

The economic outcome depends on two things: discount depth and coverage ratio.

Coverage ratio = Committed capacity / Eligible usage

If you run 500 instances and commitments cover 350 of them, coverage is 70%. The remaining 30% runs on-demand.

Blended rate = (Covered usage × discounted rate + Uncovered usage × on-demand rate) / Total usage

To make this concrete assume a 500-instance, 24/7, US-East workload at $840K annual on-demand cost, with a 30% discount for 1-year and 55% for 3-year commitments:

100% on-demand: $840,000
50% coverage, 1-year: ~$714,000 (~15% savings)
75% coverage, 3-year: ~$558,000 (~33% savings)
85% coverage, 3-year: ~$516,000 (~39% savings)

The key takeaway: a 55% discount at 85% coverage produces 39% overall savings not 55%. Coverage multiplies or limits the impact of the discount rate.

Utilization Risk: The Variable Most Comparisons Skip

Commitments assume stability. Workloads don't stay flat over 1–3 year periods.

If you purchase commitments against a 500-instance baseline and usage drops to 420 by year three, you're paying for ~100% of committed capacity against 88% of actual demand. Unused commitments don't disappear; they're sunk costs that erode your realized savings.

This is why mature FinOps teams treat commitments as a portfolio, not a one-time purchase. Practical approaches include laddering 1-year and 3-year terms, staggering purchase dates, mixing spend-based and resource-based commitments, and maintaining partial on-demand exposure as a buffer.

The question shifts from "what's the deepest discount available?" to "what coverage level optimizes effective cost under uncertainty?"

The Risk Transfer Model

Newer tooling in the market has started to address the structural problem of underutilization risk. Historically, if commitments were underused, the customer absorbed the entire cost. Platforms like Usage.ai operate as commitment automation layers across AWS, Azure, and GCP they handle continuous recommendation refresh, coverage optimization, and in some models, introduce cashback or protection if commitments go underused. That shifts part of the utilization risk away from the engineering team.

This reflects a broader shift in how cloud pricing comparison should be framed: it's not just about the provider's published discount, but about how effectively commitments are managed over time.

What Actually Drives the Cost Difference

At enterprise scale, the economic gap between AWS, Azure, and GCP often narrows once commitments are modeled. The larger variance in effective cost tends to come from:

How much of the workload is safely covered
How accurate utilization forecasts are
How flexible commitments are when architecture changes
Whether underutilization risk is absorbed internally or managed through tooling

Published pricing is one variable. Commitment strategy and operational discipline are usually the bigger levers.

What's been your experience? Does provider choice or commitment strategy have more impact on your actual cloud bill?

Explore the end-to-end breakdown here → Cloud Pricing Comparison: AWS vs Azure vs GCP (A Technical Cost Modeling Guide)

Identifying Idle and Underutilized AWS Resources: Signals, Metrics, and Patterns

Aman Singh — Tue, 26 May 2026 08:42:25 +0000

Idle resource detection is still one of the highest-ROI levers in cloud cost optimization. Even mature FinOps orgs see silent waste accumulate because resources drift from their original purpose, ownership fragments, and migrations leave infrastructure behind.

The problem isn't awareness. It's complex. Modern AWS environments span dozens of accounts, multiple regions, and distributed teams. Idle instances, unused storage, stale load balancers, and abandoned network components don't break anything so they go unnoticed until the budget damages compounds.

This post covers the exact signals and metrics to detect idle and underutilized resources by service type, plus how to operationalize detection at scale.

What Counts as Idle or Underutilized?

Idle means no meaningful compute, network, or storage activity over a defined period: a Lambda with zero invocations, an EC2 instance with negligible CPU and network traffic, an unattached EBS volume still generating charges.

Underutilized means the workload exists, but allocated capacity far exceeds actual consumption EC2 running at 10% CPU for weeks, overprovisioned RDS with minimal connections, GPUs deployed for sporadic batch jobs.

Underutilization usually comes from oversizing, conservative defaults, or bad assumptions about peak demand. Idle resources come from operational anti-patterns: forgotten experiments, incomplete decommissioning, or zombie infrastructure left behind after deployments.

Detection Signals by Service

1. EC2 Instances (Low CPU, Memory, Network)

An EC2 instance is idle when CPU stays under ~10–15%, network throughput is negligible, and disk operations approach zero over 14–30 days.

Detection tools:

CloudWatch metrics: CPUUtilization, NetworkIn/Out, VolumeReadOps/WriteOps
AWS Compute Optimizer rightsizing insights
AWS CLI: describe-instances with utilization tags

These show up most often in dev/test environments, lift-and-shift migrations, and orphaned nodes from Auto Scaling Groups.
**

Stopped EC2 With Billing Attachments**

A stopped EC2 looks harmless but retains chargeable components:

Attached EBS volumes (especially gp3 with provisioned throughput/IOPS)
Elastic IPs detached from running instances
Orphaned snapshots
Marketplace AMI subscription fees (for subscription-priced AMIs hourly-priced AMIs only bill when running)

Use describe-volumes, describe-addresses, and describe-snapshots to enumerate all dependent artifacts for instances stopped longer than 7 days.

3. Idle Load Balancers (ALB/NLB/CLB)

ALBs, NLBs, and Classic LBs incur hourly charges even with zero traffic. An idle LB shows zero ActiveConnectionCount, no healthy registered targets, and no request volume.

Check CloudWatch metrics (ActiveConnectionCount, RequestCount, HealthyHostCount) and use describe-load-balancers + describe-target-health to find LBs with no registered targets. These accumulate heavily in Kubernetes environments where service deletions don't automatically clean up associated AWS load balancers.

4. Lambda Functions With Zero Invocations

Inactive Lambda functions still generate indirect costs through CloudWatch log groups, retained log storage, and any provisioned concurrency. A function is idle when it shows zero or near-zero Invocations over 30–90 days.

Use the Lambda console Monitor tab or list-functions + get-metric-statistics via CLI. Always verify event sources (API Gateway, S3 notifications, EventBridge rules) before deleting some functions that handle infrequent but critical workflows.

5. Idle NAT Gateways

NAT Gateways are one of the most common sources of silent waste, steady hourly charges plus data processing fees, regardless of active traffic.

Look for near-zero BytesProcessed and ActiveConnectionCount in CloudWatch, then validate which route tables still point to the gateway. Many idle NAT Gateways persist after VPC refactoring or application migrations where engineers update routes but don't remove the original gateway.

6. EBS Volumes and Snapshots

A volume is idle when it's unattached for 7+ days, shows no read/write operations, or was provisioned with gp3 throughput/IOPS settings that exceed actual workload requirements. Snapshots accumulate silently when automated backup processes retain long chains without pruning.

Use describe-volumes and describe-snapshots to surface unattached volumes, low-activity volumes, and snapshot sprawl.
**

Elastic Network Interfaces (ENIs)**

Unattached ENIs rarely incur significant direct cost, but they create operational overhead, clutter VPCs, and can complicate subnet scaling and security group management.

Filter ENIs in the available state via describe-network-interfaces, then confirm zero traffic using VPC Flow Logs queried through CloudWatch Logs Insights or Athena.

8. S3 Buckets and Storage Classes

Idle S3 spend shows up as cold data sitting in expensive storage classes buckets with little or no read activity over 30–90 days, objects that never transitioned to lower-cost tiers, and accumulated logs or exports no longer referenced by any application.

Use S3 Storage Lens for high-level activity trends, and query S3 server access logs through Athena to identify cold prefixes. Apply Lifecycle Policies to transition objects to Standard-IA, Glacier, or Deep Archive or delete obsolete buckets entirely.

If you're weighing commitment strategies for the resources you do use, we covered the tradeoffs in detail here AWS Savings Plans vs Reserved Instances: A Practical Guide to Buying Commitments

9. RDS, Aurora, ElastiCache, Redshift

Database and caching services are frequently overprovisioned because teams size for peak conditions that rarely materialize. An instance is underutilized when it consistently shows CPU below ~5–10%, minimal active connections, and low read/write throughput.

Watch for replica drift read replicas or cluster nodes persisting after the workload that justified them has scaled down or changed architecture. Use describe-db-instances, describe-cache-clusters, and describe-clusters to flag sustained low activity.

10. Kubernetes Node Underutilization

EKS clusters carry hidden waste when node capacity exceeds actual pod demand. Look for low CPU/memory consumption, low pod density, or workloads requesting far more resources than they consume (conservative requests preventing efficient pod packing).

Analyze resource requests vs. actual usage through Prometheus, CloudWatch Container Insights, or the Kubernetes Metrics API.

Detecting Idle Resources at Scale

Single-account detection is straightforward. Multi-account detection is not.

Triangulated Detection

A single CloudWatch metric rarely classifies a resource as idle with confidence. Combine:

CloudWatch Metrics: consumption signals (CPU, network, ops, connections)
CloudTrail Events: API activity revealing creation, modification, or operational intent
VPC Flow Logs: confirms whether a resource still participates in active network paths

Metrics show consumption. Events and logs reveal intent.

Multi-Account Strategy

Idle detection at scale requires centralizing telemetry through AWS Organizations, AWS Cost Explorer, or custom ingestion pipelines aggregating CloudWatch and CloudTrail activity. Mandatory tagging policies (via AWS Config or SCPs) are critical without consistent owner, team, environment, and lifecycle tags, and cleanup accountability breaks down.

CLI and Automation Scripts

Automated scripts using AWS CLI or boto3 can scan entire regions or accounts in seconds:

Query EC2 instances filtered by low CPU over the last 14–30 days
List unattached EBS volumes and idle snapshots across all regions
Enumerate Lambda functions with zero invocations over a defined window
Check NAT Gateways with minimal BytesProcessed

These can run on a schedule via Lambda or Step Functions and push findings to Slack, Jira, or a FinOps dashboard.

Policy-Based Continuous Detection

Ad-hoc audits don't prevent waste from returning. AWS Config rules can:

Flag EC2 instances with no network activity for 7 days
Detect EBS volumes in available state
Ensure S3 buckets have lifecycle policies
Validate required cost-allocation tags

Config rules can auto-remediate (snapshot and delete an unattached volume) or trigger alerts for human review. Combined with guardrails in AWS Organizations, this shifts idle detection from reactive cleanup to proactive prevention.

Choosing between 1-year and 3-year commitments affects how aggressively you can rightsize after cleanup we broke down the decision here How to Choose Between 1-Year and 3-Year AWS Commitments

Keeping Costs Low After Cleanup

Removing idle resources solves one half of the problem. The other half is ensuring you're not overpaying for the resources you keep.

Usage.ai handles this with Flex Commitments, a dynamic purchasing engine that continuously adapts to real usage patterns across AWS, Azure, and GCP. Once your team remediates idle infrastructure, Usage.ai adjusts commitments so your new usage baseline is always covered at the lowest effective rate. It also issues rebates on unused commitment portions, which native cloud commitments don't do.

The loop: identify and remove idle resources → Usage.ai re-optimizes commitments against the new baseline → as workloads evolve, it adjusts again automatically.

What's the biggest source of idle waste you've found in your AWS environment and what finally surfaced?

Continue reading the full technical analysis here → How to Identify Idle & Underutilized AWS Resources: A Comprehensive Technical Guide for 2026

Effective Savings Rate (ESR): The Cloud Savings Metric That Replaced Coverage and Utilization

Aman Singh — Tue, 26 May 2026 07:43:18 +0000

Your RI coverage is 85% and your AWS bill is still climbing. ESR explains why coverage metrics lie to you, how to calculate the number that actually tells the truth, and what to do once you have it.

What Is Effective Savings Rate (ESR)?

Effective Savings Rate (ESR) is a FinOps KPI that measures the true ROI of cloud discount instruments. Introduced by ProsperOps co-founder Erik Carlin in 2019, it's now a FinOps Foundation standard under the Rate Optimization capability and AWS embedded it natively in 6the Cost and Usage Dashboard's Summary Billing tab.

Before ESR, FinOps teams tracked two proxy metrics:

Coverage: what percentage of your resources have a discount applied? Says nothing about whether it's actually saving you money.
Utilization: what percentage of purchased commitments are being consumed? Says nothing about whether you bought the right amount or type.

ESR answers the real question: what is the net percentage discount you're receiving across your entire eligible cloud spend, after accounting for coverage, utilization, and discount rate simultaneously?

The Formula

There are two equivalent forms:

Form 1 (Division):

ESR = 1 – (Actual Spend / On-Demand Equivalent Spend)

Form 2 (Savings):

ESR = Cloud Savings Generated / On-Demand Equivalent Spend

What each term means:

On-Demand Equivalent (ODE) Spend: the theoretical cost of running your exact workloads at full on-demand pricing with zero discounts. Your denominator. It only changes when actual resource usage changes.
Actual Spend Including Discounts: what you actually paid after all discount instruments are applied, including amortized upfront RI costs.
Cloud Savings Generated: ODE minus Actual Spend.

A $1M ODE with $700K actual spend = $300K savings = 30% ESR.

ESR is multiplicative. Improving coverage, utilization, or discount rate all move it but they interact. 90% coverage with 70% utilization and a 30% discount rate will underperform 70% coverage with 95% utilization and a 40% discount rate. ESR captures the net outcome of all three.

How to Calculate ESR from AWS CUR

The AWS Cost and Usage Report (CUR) is the right data source. Native dashboards give approximations; CUR gives you the exact number.

Prerequisites:

CUR enabled with resource-level granularity
Report includes amortized costs
Filtered to commitment-eligible services: EC2, Fargate, Lambda, RDS, ElastiCache, Redshift, OpenSearch

Step 1: Sum lineItem/NetAmortizedCost for your target services → Actual Spend

Step 2: Sum pricing/publicOnDemandCost for the same line items → ODE Spend

Step 3: ESR = 1 – (Net Amortized Cost / Public On-Demand Cost)
/* Run against your CUR Athena table */

SELECT
bill_billing_period_start_date AS billing_period,
SUM(line_item_net_amortized_cost) AS actual_spend,
SUM(pricing_public_on_demand_cost) AS ode_spend,
ROUND(
(1 – SUM(line_item_net_amortized_cost) /
NULLIF(SUM(pricing_public_on_demand_cost), 0))
* 100, 2
) AS esr_percent
FROM your_cur_table
WHERE
line_item_product_code IN (
'AmazonEC2', 'AmazonRDS', 'AmazonElastiCache',
'AmazonRedshift', 'AWSLambda'
)
AND pricing_public_on_demand_cost > 0
GROUP BY 1
ORDER BY 1 DESC;

Common errors to avoid:

Using blended cost instead of net amortized cost blended averages rates across an org and doesn't reflect actual commitment discounts
Including data transfer, support, or marketplace charges, they have no commitment-eligible on-demand equivalent and will deflate your ESR
Forgetting upfront RI costs lineItem/NetAmortizedCost handles amortization automatically; unblended cost does not
Calculating over a single day billing timing causes daily ESR to swing wildly; always use a full calendar month

ESR for Azure and GCP

The formula is identical across all three clouds. The data sources differ.

Azure:

Actual Spend: CostInBillingCurrency from usage detail export
ODE Spend: PayGPrice × Quantity from the same export
Commitment types: Azure Reservations, Azure Savings Plans
Native ESR view: Cost Management Rate Optimization view (verify at portal.azure.com)

GCP:

Actual Spend: cost field in Cloud Billing BigQuery export
ODE Spend: on_demand_cost from the same export
Commitment types: Committed Use Discounts (CUDs)
Native ESR view: None as of Q1 2025 must calculate from BigQuery

Azure and GCP field names change periodically. Verify against official documentation before building any calculation pipeline.

Industry Benchmarks: What Good Actually Looks Like

ProsperOps published a 2024 benchmarking report analyzing $1.5B+ in annualized AWS compute spend across hundreds of organizations all sourced from prospect accounts before adopting any optimization tool.

0% Median ESR. Half of all organizations save nothing on compute.
23% 75th percentile. Above average for active FinOps teams.
46% 98th percentile. World-class. Requires sophisticated automation.
-9% Minimum observed. Overcommitment costs more than on-demand.

The 0% median is the most important number. At $500K/year in compute spend, moving from 0% to 25% ESR saves $125K annually without touching architecture or rightsizing.

Dollar impact of ESR improvement: Annual Savings = Annual Compute ODE Spend × ESR Improvement. A 5 percentage point improvement on $10M/year = $500K saved annually.

Why High Coverage Does Not Mean High ESR

This is the most common misconception in cloud cost optimization. Teams hit 85% RI coverage, present it in a quarterly review, and then find their bill went up anyway.

Compare two environments, both at $1M/month ODE spend:

Environment A: 75% coverage, 100% utilization, 30% discount → $225K saved → 22.5% ESR
Environment B: 100% coverage, 55% utilization, 30% discount → $165K saved → 16.5% ESR

Environment B has higher coverage. Environment A has higher ESR. The difference is utilization: Environment B bought 100% coverage but only consumed 55% of it. The stranded 45% is still charged, reducing net savings.

Coverage is a process metric. ESR is an outcome metric.

Six Reasons Your ESR Is Low

No commitments at all: 53% of AWS organizations use zero Savings Plans or Reserved Instances. ESR is 0% by definition.
Low coverage on high-spend resources: Commitments applied to smaller workloads while the largest, most expensive resources run on-demand.
Overcommitment and low utilization: Utilization below 70–80% means stranded commitment hours are pulling ESR toward negative.
Wrong instance family or region: Standard RIs are instance-family-specific. Buying m5 RIs when workloads migrated to m6i means zero coverage but full charges.
Suboptimal commitment type: Choosing 1-year No Upfront when 3-year Partial Upfront delivers 20+ percentage points higher discount. Coverage exists; savings don't.
Stale recommendations: AWS Cost Explorer refreshes every 72+ hours. Usage shifts within that window create coverage gaps invisible to the recommendation engine until the next refresh.

How to Improve ESR

If coverage is below 60%: Sort your CUR by pricing/publicOnDemandCost descending. The top 20% of resources typically represent 60–70% of total ODE. Start with Compute Savings Plans they apply across EC2, Fargate, and Lambda regardless of region, family, or OS, with 66% of the maximum available discount and maximum flexibility.

If utilization is below 80%: Let commitments expire without renewal, exchange Convertible RIs for instance types you're actually running, or sell Standard RIs in the AWS RI Marketplace. For Savings Plans, there's no exchange either to absorb the waste until expiry or recover value through a cashback platform.

If discount rate is below 25%: AWS EC2 Compute Savings Plans deliver ~40% savings on 1-year No Upfront and up to 66% on 3-year All Upfront. Moving from 1-year No Upfront to 3-year Partial Upfront on stable workloads can add 15–25 percentage points to effective discount rate directly.

If recommendations refresh slowly: For dynamic workloads, the 72+ hour AWS Cost Explorer lag is a measurable, recurring ESR drag. Faster data loops mean coverage adjustments happen closer to when usage actually changes.

Tracking cadence: ESR is a lagging indicator, measured monthly, not daily. Track at three levels: total ESR, ESR by service group (EC2/Fargate separate from RDS), and ESR by account in a multi-account org. An average of 28% across 10 accounts can hide one account at -5% dragging down nine accounts averaging 32%.

Usage.ai customers across 300+ enterprises have closed this gap. Motive reduced annual cloud spend by $5.2M. EVGo (NASDAQ: EVGO) saved $2.3M annually. Secureframe saved $480K and reinvested it directly into product growth.

What ESR Cannot Measure

Commitment risk: ESR shows savings performance, not whether those savings are protected if usage drops. The -9% minimum in the benchmark data came from real organizations that committed aggressively and then saw usage fall. ESR recorded what happened. It couldn't be prevented.

Cashback vs. credits: Some platforms compensate for underutilized commitments with real-money cashback spendable anywhere; others with vendor-locked credits redeemable only against future spend on the same cloud. ESR treats both identically.

Exit cost exposure: ESR measures ongoing savings rate while a tool runs. It doesn't measure financial obligations triggered by stopping. Some platforms include contractual terms that trigger fee obligations on unrealized future savings if a customer exits before commitment terms expire. Completely invisible in ESR.

What Comes After ESR: Insured Commitment Rate (ICR)

Insured Commitment Rate (ICR), introduced by Usage.ai, extends ESR by adding cashback recovered on underutilized commitments to the numerator:

ICR = (Cloud Savings + Cashback Recovered) / ODE Spend

ICR is always ≥ ESR because cashback is additive. When every commitment is fully utilized, ICR equals ESR. When utilization drops and cashback kicks in, ICR exceeds ESR by exactly the value recovered.

ESR can go negative. ICR cannot every underutilized commitment is offset by real-money cashback rather than absorbed as a loss.

For the full comparison with worked examples ESR vs ICR: The Savings Metric That Does Not Go Negative

Start with ESR. Know your number. Then ask whether the savings you've built are as durable as they look on paper.

What's your current ESR, and which of the six root causes have you run into most often?

Explore the full operational breakdown here → Effective Savings Rate (ESR): The Complete FinOps Guide to Calculating and Improving Your Cloud Savings ROI