How AWS Savings Plans and Reserved Instances Work

Documentation Index

Fetch the complete documentation index at: https://docs.cloudcapital.co/llms.txt

Use this file to discover all available pages before exploring further.

AWS offers significant discounts when you commit to a fixed level of spend over time. Two instruments deliver those discounts: Savings Plans and Reserved Instances. Understanding how each works — and how they layer together — is the foundation of an effective commitment strategy.

---

​

Savings Plans

A Savings Plan is a commitment to spend a fixed dollar amount per hour in exchange for a discount off On-Demand pricing. Unlike Reserved Instances, Savings Plans do not lock you to a specific instance type, region, or operating system — the discount applies automatically to eligible usage as it occurs. AWS offers two Savings Plan types relevant to most organizations:

​

Compute Savings Plans

The most flexible commitment type available. A Compute Savings Plan applies a discount to any EC2, Fargate, or Lambda usage — across any instance family, size, region, or operating system. If your compute footprint shifts over time (new regions, different instance types, container migrations), the Savings Plan coverage moves with it.

• Flexibility: Highest — applies across all compute regardless of type, region, or OS
• Discount depth: Typically lower than more specific commitment types for equivalent coverage
• Best for: Organizations with diverse or evolving compute workloads, or those who want broad coverage without predicting exactly how they will scale

​

EC2 Instance Savings Plans

A narrower commitment that locks in a specific EC2 instance family and region (for example, m5 instances in us-east-1). In exchange for that specificity, the discount is deeper — and the Savings Plan still applies across sizes and operating systems within that family.

• Flexibility: Medium — flexible within a family and region, but not across them
• Discount depth: Higher than Compute Savings Plans for the same family
• Best for: Workloads with a stable, known instance family profile in a fixed region

​

Database Savings Plans

A separate category of Savings Plan covering a broad range of AWS managed database services. Like Compute Savings Plans, the commitment is expressed as a fixed hourly rate and applies automatically across eligible database usage. Covered services include:

• Term: 1-year only (3-year terms are not available for Database Savings Plans)
• Best for: Organizations with significant managed database spend on Gen 7+ instance families

---

​

Reserved Instances

Reserved Instances (RIs) are a more targeted commitment type. Instead of committing to a fixed hourly spend rate, you commit to a specific instance configuration — service, instance type, region, and term. The tradeoff is precision versus flexibility: RIs typically deliver the deepest discounts available, but they are scoped to an exact resource profile. AWS supports Reserved Instances across several services: Unlike Savings Plans, RIs are applied directly to matching resource usage. If you purchase an r5.2xlarge RDS Reserved Instance in eu-west-1, the discount applies only to that specific configuration — any other instance type or region pays On-Demand pricing.

---

​

Terms and Payment Options

The term and payment option together determine the effective discount rate.

​

Term

Compute Savings Plans and EC2 Instance Savings Plans are available in 1-year or 3-year terms. Database Savings Plans are available in 1-year terms only. Reserved Instances are available in 1-year or 3-year terms across all supported services.

​

Payment Options

AWS offers No Upfront, Partial Upfront, and All Upfront payment options, with deeper upfront payments delivering marginally higher discounts in exchange for capital committed at purchase. Cloud Capital proposes No Upfront commitments by default. This preserves your organization’s capital flexibility while still delivering the full term discount — and aligns with Cloud Capital’s risk model, where the financial exposure sits with Cloud Capital rather than your balance sheet.

---

​

How Commitments Stack: The Coverage Ladder

No single commitment type covers everything. An effective commitment strategy layers multiple purchases — across types, terms, and resource categories — so that coverage builds incrementally as confidence in the forecast grows. AWS applies commitment discounts in a defined order when processing your usage:

1. Reserved Instances are applied first — against any usage that exactly matches the RI’s configuration (instance type, region, service)
2. EC2 Instance Savings Plans apply next — against remaining EC2 usage matching the committed family and region
3. Compute Savings Plans apply last — against any remaining eligible EC2, Fargate, or Lambda usage

This order means that more specific commitments take priority, and broader commitments serve as a flexible backstop that catches whatever the specific commitments do not cover.

​

The Hourly Commitment Ladder in Practice

A commitment ladder works by expressing each commitment as a fixed hourly rate — the amount of spend per hour that a given Savings Plan or RI will cover. As additional commitments are added, their hourly rates stack on top of prior commitments, progressively covering more of your total spend. Example: Layering compute coverage Suppose your EC2 baseline runs at $10.00 per hour of On-Demand spend: Cloud Capital leads with 3-year commitments where the forecast supports it — maximizing the discount on the most stable portion of spend. As coverage builds toward full commitment, shorter 1-year terms fill the remaining gap, preserving flexibility at the margin.

---

​

Flexibility vs. Discount Depth

Choosing between Savings Plans and Reserved Instances involves a tradeoff: A well-structured commitment strategy typically uses all three — with Reserved Instances for the most stable, predictable workloads; EC2 Instance Savings Plans for families with stable regional footprints; and Compute Savings Plans as a flexible overlay that catches everything else.

---

​

How Cloud Capital Uses These Instruments

Cloud Capital purchases Savings Plans and Reserved Instances on your behalf using this same layered approach. Each commitment proposal is structured to match the confidence level of your forecast:

• High-confidence, stable workloads → Reserved Instances or EC2 Instance Savings Plans for deeper discounts
• Broad compute coverage → Compute Savings Plans for flexibility
• Database services → Database Savings Plans or database-specific Reserved Instances

Cloud Capital absorbs the financial risk if your usage falls below a commitment level. Rather than over-committing to the highest-discount tier upfront, commitments are laddered in over time — stepping up coverage as the forecast is refined and confidence grows.

​

Existing Commitments at Onboarding

If your organization already holds AWS Savings Plans or Reserved Instances purchased before onboarding to Cloud Capital, those commitments are not abandoned. Cloud Capital monitors each existing commitment for its expiry date and tracks utilization throughout the remaining term. As each commitment approaches expiration, Cloud Capital proposes an optimized replacement using its proprietary algorithm — factoring in your current spend patterns, active engineering initiatives, business metrics, and the latest forecast. The goal is a seamless transition: existing savings are preserved without interruption, and each replacement is sized and structured to reflect where your infrastructure is heading, not just where it has been.