> ## 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.
# How AWS Savings Plans and Reserved Instances Work
> A plain-language explanation of AWS commitment types — what they are, how they work, and how stacking multiple commitments maximizes coverage.
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.
For the full technical reference, see the official AWS documentation: [AWS Savings Plans User Guide](https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html) and [Amazon EC2 Reserved Instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html).
***
## 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:
| Service | Notes |
| ------------------------------------ | ----------------------------------------------------------------- |
| Amazon RDS | PostgreSQL, MySQL, MariaDB, Oracle, SQL Server — Gen 7+ instances |
| Amazon Aurora | Provisioned, Serverless v2, and I/O-Optimized |
| Amazon DynamoDB | Provisioned capacity and on-demand throughput workloads |
| Amazon ElastiCache | Valkey, Gen 7+ |
| Amazon DocumentDB | MongoDB-compatible |
| Amazon Neptune | Graph workloads |
| Amazon Keyspaces | Apache Cassandra-compatible |
| Amazon Timestream | Time-series workloads |
| Amazon OpenSearch Service | Search and analytics |
| AWS Database Migration Service (DMS) | Migration workloads |
Database Savings Plans apply primarily to **Generation 7 and newer instance families** (e.g., `r7g`, `m7i`, `r8g`). Organizations still running Gen 6 or earlier instances will not see coverage from a Database Savings Plan until those workloads are migrated to supported generations. If a significant portion of your database spend is on older instance families, migrating to Gen 7+ is a prerequisite to taking full advantage of this commitment type.
* **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:
| Service | Reserved Instance Type |
| ------------------ | -------------------------------- |
| Amazon EC2 | EC2 Reserved Instances |
| Amazon RDS | RDS Reserved DB Instances |
| Amazon Redshift | Redshift Reserved Nodes |
| Amazon ElastiCache | ElastiCache Reserved Cache Nodes |
| Amazon OpenSearch | OpenSearch Reserved Instances |
| Amazon MemoryDB | MemoryDB Reserved Nodes |
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.
| Term | Flexibility | Discount |
| ---------- | ------------------------------------- | -------------------------- |
| **1-year** | More flexibility to adjust at renewal | Moderate discount |
| **3-year** | Locked for a longer horizon | Deepest available discount |
### 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:
| Commitment | Term | Hourly rate committed | Running total covered |
| --------------------------------------------- | ---- | --------------------- | --------------------- |
| Compute Savings Plan (50% coverage) | 3-yr | \$5.00/hr | \$5.00/hr |
| EC2 Instance Savings Plan (m5, us-east-1) | 3-yr | \$2.00/hr | \$7.00/hr |
| EC2 Reserved Instance (m5.2xlarge, us-east-1) | 1-yr | \$1.00/hr | \$8.00/hr |
| Compute Savings Plan top-up | 1-yr | \$1.50/hr | \$9.50/hr |
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.
AWS processes these commitments automatically — you do not manage which commitment applies to which instance. AWS applies discounts in the priority order described above and assigns coverage to minimize your bill.
***
## Flexibility vs. Discount Depth
Choosing between Savings Plans and Reserved Instances involves a tradeoff:
| | Compute Savings Plan | EC2 Instance Savings Plan | Reserved Instance |
| ------------------ | ---------------------------------- | ------------------------------ | ----------------------------- |
| **Flexibility** | Highest | Medium | Lowest |
| **Discount depth** | Moderate | Higher | Highest |
| **Applies to** | Any compute | Specific family + region | Specific instance + region |
| **Portability** | Full | Within family | None |
| **Best for** | Broad coverage, evolving workloads | Stable families, known regions | Pinned, stable configurations |
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.
Pre-existing commitments purchased independently carry their financial risk with the customer until Cloud Capital replaces them. Once Cloud Capital purchases the replacement commitment, the risk transfers to Cloud Capital for that position.
Learn how Cloud Capital's GSR contractually backs the savings from every commitment it purchases on your behalf.
See how Cloud Capital structures the ladder proposal and manages the weekly review cadence with your team.