AWS Reserved Instance & Savings Plan Optimisation: Eliminating On-Demand Waste
On-demand EC2 pricing is AWS's highest-margin revenue stream. Most enterprises are running workloads on-demand that should be covered by commitments — paying 30–72% more than necessary for compute. This paper delivers the methodology, decision framework, and purchasing strategy to eliminate that waste.
Executive Summary
Every hour that a workload runs on-demand when it could be covered by a Reserved Instance or Savings Plan is money transferred directly to AWS's margin. On-demand EC2 pricing carries a 30–72% premium over committed pricing — and for the average enterprise, 35–55% of compute spend is running on-demand without commercial justification. This isn't a niche optimisation opportunity; for enterprises spending $5M+ annually on AWS, the waste typically ranges from $750K to $2M per year in avoidable cost.
The instruments for eliminating this waste — Reserved Instances (Standard and Convertible) and Compute Savings Plans — are well understood in theory but poorly executed in practice. The commitment structures, flexibility trade-offs, term economics, and portfolio management requirements create complexity that most FinOps teams navigate by either under-committing (leaving savings on the table) or over-committing (creating stranded capacity). Both outcomes waste money. This paper provides the methodology to find the optimal commitment level and the purchasing strategy to maintain it.
The average enterprise runs 35–55% of its EC2 compute on-demand despite having stable, predictable workload patterns that qualify for committed pricing.
The gap isn't lack of awareness — it's lack of process. Commitment purchasing requires continuous analysis of utilisation patterns, regular purchasing cycles, and active portfolio management. Without a structured FinOps programme, on-demand becomes the default.
Compute Savings Plans have become the default recommendation — but they are not always the optimal instrument. Standard RIs deliver 5–15% deeper discounts for stable, well-understood workloads.
Savings Plans offer flexibility; Standard RIs offer maximum discount. The optimal portfolio typically combines both — Savings Plans for the flexible base layer, Standard RIs for stable workloads where the instance type is predictable.
Over-commitment — purchasing more capacity than needed — is as expensive as under-commitment, and significantly harder to unwind.
Stranded RIs generate zero savings. Stranded Savings Plans apply to whatever is running (which may not be the workload you intended) but lock capital that could be deployed more effectively. The commitment portfolio must be right-sized with the same rigour as the workloads themselves.
The RI Marketplace and Convertible RI exchange mechanism are underused tools that transform over-commitments from sunk costs into recoverable assets.
Standard RIs can be sold on the RI Marketplace. Convertible RIs can be exchanged for different instance types. Both mechanisms reduce the risk of commitment — but fewer than 20% of enterprises actively use them as part of their portfolio management strategy.
Commitment purchasing should be a continuous, monthly process — not an annual event. Quarterly or annual purchasing cycles leave 6–11 months of on-demand waste between decisions.
Workload patterns evolve continuously. New applications launch. Old ones decommission. Instance types change. A static, annual commitment purchase is obsolete within months. The most effective FinOps teams purchase commitments monthly, in small increments, informed by rolling utilisation analysis.
The Anatomy of On-Demand Waste
Understanding where on-demand waste occurs is the first step toward eliminating it. The waste is not uniformly distributed — it concentrates in specific patterns that are identifiable and addressable through targeted commitment purchasing.
The Three Layers of EC2 Spend
Enterprise EC2 spend typically divides into three layers. The stable base layer (40–60% of total compute) represents workloads that run continuously with predictable capacity requirements — production databases, application servers, backend services, and always-on infrastructure. This layer should be 90–100% covered by commitments. The variable layer (20–35% of total compute) represents workloads with predictable patterns but variable capacity — batch processing, development environments with business-hours usage, and seasonally-driven applications. This layer should be 50–80% covered by commitments targeting the baseline capacity. The ephemeral layer (10–25% of total compute) represents genuinely unpredictable or short-lived workloads — burst capacity, CI/CD pipelines, temporary environments, and experimental workloads. This layer should run on-demand or Spot instances — commitment is inappropriate.
The waste occurs when workloads in the stable base layer and the predictable portion of the variable layer run on-demand. In the average enterprise, 30–50% of stable base layer compute is running on-demand — generating zero value from the flexibility premium but paying for it every hour.
| Spend Layer | % of Total EC2 | Typical Commitment Coverage | Optimal Coverage | Waste Opportunity |
|---|---|---|---|---|
| Stable Base | 40–60% | 50–70% | 90–100% | High — deepest savings, lowest risk |
| Variable | 20–35% | 10–30% | 50–80% (baseline) | Medium — requires utilisation analysis |
| Ephemeral | 10–25% | 0–5% | 0% (use Spot) | Low — on-demand or Spot is appropriate |
Why the Waste Persists
On-demand waste persists for structural reasons, not informational ones. Fear of over-commitment causes FinOps teams to under-purchase — they'd rather pay the on-demand premium than risk stranded capacity. Organisational silos mean that the teams launching workloads don't communicate with the teams purchasing commitments — capacity grows without corresponding commitment growth. Instance type proliferation creates anxiety about locking into specific instance families that may become obsolete. Infrequent purchasing cycles (quarterly or annually) leave large gaps between commitment purchases during which new on-demand spend accumulates unchecked.
The On-Demand Premium by the Numbers
For a common instance type (m6i.xlarge in us-east-1), on-demand pricing is approximately $0.192/hour. A 1-year No Upfront Compute Savings Plan reduces this to approximately $0.121/hour — a 37% savings. A 3-year All Upfront Standard RI reduces it to approximately $0.074/hour — a 61% savings. For a single instance running 24/7/365, the annual cost difference between on-demand and a 3-year Standard RI is approximately $1,034. Multiply by hundreds or thousands of instances, and the waste is measured in millions.
Reserved Instances vs. Savings Plans: Understanding the Instruments
AWS offers three commitment instruments for EC2 compute, each with distinct mechanics, flexibility profiles, and discount depths. Understanding the differences is essential to building an optimal commitment portfolio.
Standard RIs commit to a specific instance type, platform (Linux/Windows), tenancy, and Availability Zone (or Region). They offer the deepest discounts — up to 72% off on-demand for 3-year All Upfront commitments. Instance size flexibility within the same family is supported for Linux/Unix RIs in regional scope.
Standard RIs can be sold on the RI Marketplace if no longer needed — the only commitment instrument with a secondary market. They cannot be exchanged for a different instance type.
Best for: Stable, well-understood workloads where the instance family is unlikely to change. Production databases, core application tiers, and long-running services with predictable capacity.
Convertible RIs offer slightly lower discounts than Standard RIs (approximately 5–10% less) but can be exchanged for different instance types, families, operating systems, or tenancies — as long as the exchange results in equal or greater value. This flexibility makes them suitable for workloads where the instance type may evolve.
Convertible RIs cannot be sold on the RI Marketplace. The exchange process is managed through the AWS console or API and can be executed at any time during the term.
Best for: Workloads that are stable in capacity but may change instance type — environments undergoing modernisation, workloads that may migrate to Graviton, or applications with evolving performance requirements.
Compute Savings Plans commit to a dollar-per-hour spend level rather than specific instances. The commitment applies automatically to any EC2 instance in any region, any family, any size, and any OS — plus Fargate and Lambda compute. Discount depth is lower than both Standard and Convertible RIs (typically 5–20% less than Standard RIs).
EC2 Instance Savings Plans offer slightly deeper discounts than Compute Savings Plans but are locked to a specific instance family in a specific region — a middle ground between flexibility and discount depth.
Best for: The flexible base layer of your commitment portfolio — covering compute spend that is predictable in aggregate but where the specific instance composition may shift. Also ideal for organisations early in their FinOps journey who want savings with minimal risk.
| Attribute | Standard RI | Convertible RI | Compute Savings Plan |
|---|---|---|---|
| Maximum Discount (3yr All Upfront) | Up to 72% | Up to 66% | Up to 60% |
| Instance Flexibility | Size flexibility within family (regional scope, Linux) | Full exchange to any instance type/family | Any instance, any family, any region |
| Service Coverage | EC2 only | EC2 only | EC2, Fargate, Lambda |
| Marketplace Resale | Yes — sell unused capacity | No | No |
| Modification/Exchange | Limited (AZ, scope, size within family) | Full exchange (equal or greater value) | N/A — applies automatically |
| Commitment Basis | Specific instance | Specific instance (exchangeable) | Dollar per hour |
| Payment Options | All Upfront, Partial, No Upfront | All Upfront, Partial, No Upfront | All Upfront, Partial, No Upfront |
The Graviton Dimension
AWS Graviton instances (arm64 architecture) offer approximately 20% better price-performance than equivalent x86 instances before any commitment discount is applied. When combined with commitment pricing, the cumulative savings versus on-demand x86 instances can exceed 75%. For enterprises planning Graviton migration, Compute Savings Plans provide the safest commitment path — they apply regardless of whether workloads run on x86 or Graviton. Conversely, Standard RIs locked to x86 instance types may become stranded as workloads migrate to Graviton.
The RI & Savings Plan Decision Framework
Choosing between Standard RIs, Convertible RIs, and Savings Plans is not a one-size-fits-all decision — it depends on workload stability, instance type predictability, planning horizon, and organisational FinOps maturity. The following framework maps the decision logic.
Is the workload stable and predictable for 12+ months?
Yes: This workload is a commitment candidate. Proceed to instrument selection. No: Run on-demand or Spot. Do not commit capacity to workloads with uncertain tenure or highly variable demand — the flexibility premium is justified.
Is the instance family likely to remain unchanged?
Yes (high confidence): Standard RI — maximum discount, locked to the instance family. Probably (moderate confidence): Convertible RI — strong discount with exchange flexibility. Uncertain: Compute Savings Plan — broadest flexibility, applies regardless of instance changes.
What is the appropriate term length?
3-year terms deliver the deepest discounts (40–72% off on-demand) but lock you in for 36 months. Appropriate for core infrastructure with high certainty. 1-year terms deliver moderate discounts (30–50%) with shorter commitment windows. Appropriate for workloads that are stable today but may evolve in 12–18 months. The optimal portfolio typically combines both — 3-year terms for the immovable base, 1-year terms for the confident-but-flexible layer.
What payment option maximises your economics?
All Upfront delivers the deepest discount — pay the entire term upfront and receive the maximum rate reduction. Requires capital availability. Partial Upfront balances discount depth with cash flow — pay roughly half upfront and the remainder monthly. No Upfront preserves cash entirely but delivers the shallowest discount. For most enterprises, Partial Upfront provides the optimal balance of discount depth and cash flow management.
"The optimal commitment portfolio is not 100% Savings Plans or 100% RIs. It's a layered strategy — Savings Plans for flexibility, Standard RIs for maximum savings on stable workloads, and on-demand for everything else."Redress Compliance — Cloud & FinOps Practice
The Commitment Optimisation Methodology
Right-sizing the commitment portfolio requires a data-driven approach that analyses historical utilisation, forecasts future demand, and builds the commitment stack in layers. The following methodology produces the optimal commitment level — maximising savings without creating stranded capacity.
Baseline Utilisation Analysis
Extract 90 days of hourly EC2 utilisation data across all accounts and regions. For each instance, calculate the average utilisation, minimum utilisation (the "floor" that represents the guaranteed base), and utilisation variability. Categorise every instance into the three spend layers: stable base, variable, and ephemeral. The stable base — instances running at 70%+ utilisation for 90+ consecutive days — is your primary commitment target.
Existing Commitment Audit
Inventory all current RIs and Savings Plans: type, term, payment option, remaining term, utilisation rate, and coverage. Identify stranded commitments (purchased but not fully utilised), expiring commitments (approaching term end), and coverage gaps (on-demand spend that should be committed). This audit reveals the current state — the gap between actual commitment and optimal commitment is the addressable opportunity.
Demand Forecasting
Project EC2 demand for the commitment term (1 or 3 years) based on application roadmaps, migration plans, decommissioning schedules, and organic growth. Factor in instance type changes (Graviton migration, generation upgrades) that could affect RI applicability. The forecast determines the safe commitment level — the capacity that will be consumed with high confidence throughout the term.
Commitment Stack Design
Build the commitment portfolio in layers. Layer 1 (bottom): Compute Savings Plans covering 60–70% of the projected stable base — maximum flexibility, minimum stranding risk. Layer 2: Standard RIs for specific high-confidence workloads where the instance family is locked — maximum discount on the most predictable capacity. Layer 3: Convertible RIs for moderate-confidence workloads that may change instance type. Residual: On-demand and Spot for everything else.
Financial Modelling
Model the total cost of the commitment stack against the current on-demand baseline. Calculate net savings, effective discount rate, commitment utilisation rate (the percentage of committed capacity that is actually consumed), and payback period for upfront payments. The target: 85–95% commitment utilisation with 40–55% effective discount across the portfolio.
Continuous Purchasing Programme
Implement a monthly commitment purchasing cadence — small, incremental purchases informed by rolling 30-day utilisation analysis. Each month, evaluate new on-demand spend that has stabilised, expiring commitments that need renewal, instance type changes that require commitment adjustment, and decommissioned workloads whose commitments should be sold or exchanged. Monthly purchasing eliminates the long gaps between decisions that annual purchasing creates.
7 Common Commitment Mistakes & How to Avoid Them
Even organisations with established FinOps practices make systematic errors in commitment management. These seven mistakes consistently erode savings — and all are preventable.
Over-Committing to a Single Instance Family
Annual Purchasing Cycles
100% Savings Plans, Zero RIs
Ignoring the RI Marketplace
Committing Without Right-Sizing First
All 3-Year Terms
No Multi-Account Commitment Strategy
The Purchasing Strategy: Building & Maintaining the Optimal Portfolio
The commitment purchasing strategy transforms the decision framework and optimisation methodology into a repeatable operational process that maintains optimal commitment coverage over time.
Establish the Baseline
Run the full optimisation methodology (Section 05) to establish the initial commitment portfolio. This is the one-time heavy lift: 90-day utilisation analysis, existing commitment audit, demand forecasting, and stack design. The output is a prioritised purchasing list with specific instrument types, term lengths, payment options, and quantities for each commitment.
Execute the Initial Purchase
Purchase the Layer 1 (Savings Plans) commitments first — these provide immediate, broad coverage with the lowest stranding risk. Then Layer 2 (Standard RIs) for confirmed stable workloads. Then Layer 3 (Convertible RIs) for moderate-confidence workloads. Stagger the purchases over 2–4 weeks to avoid committing the entire portfolio based on a single point-in-time analysis.
Implement Monthly Review Cadence
Every month, execute the commitment review cycle: analyse 30 days of utilisation to identify new on-demand spend that has stabilised, review expiring commitments (approaching term end within 60 days) for renewal or replacement, identify stranded commitments for Marketplace sale or Convertible exchange, and evaluate changes to the instance portfolio (new types, decommissions, right-sizing) that affect commitment alignment.
Purchase Incrementally
Based on the monthly review, purchase commitments in small, targeted increments — not large annual batches. Each purchase should be specific and justified: "12 × m6i.xlarge Standard RIs for the payments service, 1-year Partial Upfront" rather than "$500K of Compute Savings Plans." Incremental purchasing reduces risk, improves targeting, and keeps the portfolio continuously optimised.
Manage the Portfolio Actively
Treat the commitment portfolio as a financial asset that requires active management — not a set-and-forget purchase. Monitor commitment utilisation weekly. List stranded Standard RIs on the Marketplace immediately. Exchange Convertible RIs proactively when instance types change. Track the effective discount rate (actual savings ÷ theoretical maximum savings) as the primary performance metric — target 85%+ effectiveness.
Integrate with EDP Negotiation
For enterprises with an AWS Enterprise Discount Program (EDP), coordinate commitment purchasing with EDP economics. RI and Savings Plan spend counts toward EDP commitment attainment. The commitment portfolio should be designed to support EDP tier maintenance while maximising the per-instance discount. Over-commitment that exceeds EDP needs wastes capital; under-commitment that threatens EDP attainment risks tier-level discounts on the entire estate.
Recommendations: 7 Priority Actions
The following actions provide the structured approach to eliminating on-demand waste and building an optimal commitment portfolio.
Right-Size Instances Before Purchasing Commitments
Complete an instance right-sizing analysis across your entire EC2 estate before making any commitment purchase. Committing to over-provisioned instances locks in the waste at a discounted rate — which is still waste. Right-size first to reduce the base, then commit to the right-sized capacity. The compound savings typically exceed 50%.
Layer Your Commitment Portfolio
Don't default to 100% Savings Plans. Build a layered portfolio: Compute Savings Plans for the flexible foundation (60–70%), Standard RIs for maximum savings on stable workloads (20–30%), and Convertible RIs for moderate-confidence workloads (5–10%). The blended approach delivers both flexibility and maximum discount depth.
Implement Monthly Purchasing Cadence
Stop purchasing commitments annually. Implement a monthly cycle: analyse 30 days of utilisation, identify new commitment candidates, renew expiring commitments, and adjust for instance changes. Monthly purchasing keeps the portfolio continuously aligned with actual demand and eliminates the months-long gaps where on-demand waste accumulates unchecked.
Use the RI Marketplace — Both Directions
Sell stranded Standard RIs on the Marketplace immediately — don't wait for expiry. Recover 50–80% of remaining value. Additionally, check the Marketplace for discounted RIs before purchasing directly from AWS — available listings are often 10–20% below standard RI pricing.
Centralise Commitment Purchasing Across the Organisation
Establish a single FinOps function with visibility and purchasing authority across all AWS accounts. Enable RI and Savings Plan sharing across the Organisation. Centralised purchasing eliminates duplication, captures pooling benefits, and ensures the commitment portfolio is optimised against aggregate demand rather than individual account perspectives.
Coordinate Commitments with Your EDP Strategy
If you have an AWS Enterprise Discount Program, align commitment purchasing with EDP economics. RI and SP spend counts toward EDP attainment. Design the commitment portfolio to support EDP tier maintenance while maximising instance-level discounts. The two mechanisms are complementary — but only when deliberately coordinated.
Track Effective Discount Rate as the Primary Metric
Monitor the effective discount rate — actual savings achieved divided by theoretical maximum savings — as the primary performance metric for your commitment portfolio. Target 85%+ effectiveness. If the rate is below 80%, the portfolio has significant stranding or coverage gaps. If it's above 95%, you may be over-committed with insufficient flexibility buffer for workload changes.
How Redress Can Help
Redress Compliance's Cloud & FinOps Practice provides independent advisory on AWS commitment optimisation — from utilisation analysis and portfolio design through purchasing strategy and ongoing management. We maintain zero commercial relationships with AWS or any cloud broker.
Commitment Portfolio Assessment
Comprehensive audit of your existing RI and Savings Plan portfolio — utilisation rates, stranding exposure, coverage gaps, and savings effectiveness — with specific remediation recommendations.
Commitment Stack Design
Data-driven design of the optimal commitment portfolio — layered by instrument type, term length, and payment option — with financial modelling of savings, utilisation, and stranding risk.
Purchasing Programme Implementation
Design and implementation of a monthly commitment purchasing cadence — automated utilisation analysis, decision criteria, approval workflows, and portfolio performance tracking.
Right-Sizing Analysis
Instance-level right-sizing analysis across your EC2 estate — identifying over-provisioned capacity that should be resized before commitment purchasing to compound the savings.
EDP Integration Advisory
Coordination of commitment strategy with Enterprise Discount Program economics — ensuring the commitment portfolio supports EDP tier attainment while maximising instance-level savings.
Ongoing FinOps Governance
Monthly commitment portfolio review, performance reporting, and optimisation recommendations — ensuring the portfolio remains aligned with evolving compute demand.
100% Independent Advisory
Redress maintains zero commercial relationships with AWS, any cloud broker, or any FinOps tooling vendor. Our only relationship is with you — ensuring our recommendations maximise your savings, not anyone else's revenue.
Book a Meeting
Schedule a confidential consultation with our Cloud & FinOps Practice team. We'll review your current commitment portfolio and identify specific opportunities to eliminate on-demand waste.