Reserved Instances vs Savings Plans: which to buy

Reserved Instances and Savings Plans are the two main ways to pre-pay for AWS compute at a discount. Both lock you into a commitment in exchange for lower prices. The differences matter, and AWS keeps adding new options (EC2 Instance Savings Plan, Compute Savings Plan, SageMaker Savings Plan), which makes the decision harder than it used to be.

This post walks through the four main commitment products, what each covers, the actual discount math, and which one to pick for a given workload.

The four commitment products

Compute Savings Plans

The most flexible. Covers EC2, Lambda, and Fargate at the same discount rate. Applies regardless of instance family (m5, m6i, m7g all work), region, OS, or tenancy. Up to 66% off on-demand at the 3-year all-upfront tier.

Right when: your workload mix might change over the term (e.g., migrating from EC2 to Fargate, or from m5 to m7i, or shifting regions). Right for most production accounts.

EC2 Instance Savings Plans

Same model as Compute Savings Plans but locked to a single instance family per region. m5 in us-east-1 specifically. In exchange for the lock-in, the discount is slightly higher (up to 72% at 3-year all-upfront).

Right when: you have stable EC2 usage in one family that won't change. Less flexible than Compute Savings Plans for marginal additional discount.

Standard Reserved Instances

The original commitment product. Locks to a specific instance configuration: instance type, region, OS, tenancy, AZ (optional). Up to 72% off at 3-year all-upfront. Most flexible cancellation option in the form of the Reserved Instance Marketplace (though resale prices are usually unfavorable).

Right when: you have a Standard RI strategy already in place and renewals make sense. For new commitments in 2026, Compute Savings Plans are usually the better choice unless you specifically need capacity reservation (which RIs include and SPs don't).

Convertible Reserved Instances

Standard RIs with the ability to exchange for a different configuration during the term. Less discount than Standard RIs but more flexibility. Convertible RIs and Compute Savings Plans serve similar purposes; SPs are usually simpler.

The discount math

Approximate discounts vs on-demand, for a typical m6i.xlarge in us-east-1:

• 1-year no-upfront Compute SP: ~27% off
• 1-year all-upfront Compute SP: ~32% off
• 1-year all-upfront EC2 Instance SP: ~40% off
• 1-year all-upfront Standard RI: ~42% off
• 3-year no-upfront Compute SP: ~52% off
• 3-year all-upfront Compute SP: ~63% off
• 3-year all-upfront EC2 Instance SP: ~68% off
• 3-year all-upfront Standard RI: ~72% off

The marginal discount from "more flexible" to "less flexible" is about 5-7 percentage points at each tier. The marginal discount from no-upfront to all-upfront is similar.

Worth knowing: the actual dollar difference between Compute SP and Standard RI at the same term is small at typical scale. For an m6i.xlarge running 24/7 over 3 years, 3-year all-upfront Compute SP saves ~$2,650 vs on-demand; 3-year all-upfront Standard RI saves ~$3,025. The $375 difference per instance is real but the lock-in cost (you can't migrate to m7i mid-term) often outweighs it.

What Savings Plans don't cover

Compute Savings Plans cover EC2, Lambda, and Fargate. That's it.

For these services, you need service-specific Reserved Instances or Capacity Reservations:

• RDS (including Aurora): RDS Reserved Instances
• Redshift: Redshift Reserved Instances
• ElastiCache: ElastiCache Reserved Cache Nodes
• OpenSearch: OpenSearch Reserved Instances
• DynamoDB: Reserved Capacity (for provisioned mode)
• MemoryDB: Reserved Nodes
• SageMaker: SageMaker Savings Plans (separate from Compute)

Each service has its own commitment product, its own discounts, its own constraints. The discount tiers are usually similar to compute commitments but the operational model varies (some have AZ scoping, some have payment options, etc.).

For RDS specifically, see the aws_db_instance catalog for how to configure Reserved Instances in c3x-usage.yml.

How to decide what to commit

Three steps from "we should do this" to "purchase":

1. Identify your baseline

Use AWS Cost Explorer's "Savings Plan recommendations" view or Cost Optimization Hub. Both compute a baseline level of sustained compute usage over the past 30/60/90 days.

The recommended commit is usually conservative — around your p10 or p20 of daily compute spend over the lookback window. This is your baseline. Above-baseline traffic stays on-demand, which is fine.

2. Pick the term length

1-year commitments are right when:

• You're early in the AWS migration and usage patterns are still settling
• You're not confident the workload will exist in 3 years
• You want some discount but maximum flexibility

3-year commitments are right when:

• You have stable baseline workloads you're certain will continue
• You have cash for upfront payment or are comfortable with monthly
• The 25-percentage-point extra discount matters at your scale

For most teams just starting commitment strategy, 1-year is the safer first step. Roll into 3-year on the second renewal if the workload is still there.

3. Pick the payment option

No-upfront: monthly billing, no cash outlay. Smallest discount.

Partial-upfront: pay 50% upfront, get monthly billing on the rest. Middle discount.

All-upfront: pay 100% at purchase. Largest discount.

The discount difference between no-upfront and all-upfront is typically 5-7 percentage points. Whether that's worth the cash outlay depends on your cost of capital. For most teams, no-upfront or partial-upfront is fine; the discount math doesn't materially favor all-upfront unless your cost of capital is very low.

Common mistakes

Buying too much

Over-committing means paying for capacity you don't use. The unused portion of a Compute Savings Plan still applies (it covers the lowest-cost equivalent compute, so the dollar value isn't lost as long as you have any matching compute), but you pre-paid for it. Standard RIs that don't match running instances waste fully.

Buying for peak, not baseline

If your workload scales 5x during business hours, don't commit to peak. Commit to off-peak baseline. The scaling above baseline should run on-demand or, better, on Spot.

Forgetting service-specific commitments

Teams buy Compute Savings Plans, look at the bill, and miss that RDS, Redshift, and ElastiCache aren't covered. Each of those has separate Reserved Instances that need to be purchased separately.

Buying right before migrating

Don't commit to 3-year Standard RIs on m5 if you're planning to migrate to m7i or Graviton. The RIs lock you in. Use Compute Savings Plans for migration-friendly commitments.

How to model commitments in C3X

c3x estimates with discount applied when you specify the commitment in c3x-usage.yml:

# c3x-usage.yml
resource_usage:
  aws_instance.api:
    purchaseOption: "savings_plan"
    purchaseOptionTerm: "1yr"

  aws_db_instance.postgres:
    purchaseOption: "reserved"
    purchaseOptionTerm: "1yr"
    offeringClass: "no-upfront"

c3x applies the appropriate discounted rate from the AWS Pricing API. The estimate output shows the discounted hourly rate and the total monthly cost, with the discount level documented.

For more on the broader workflow including CI integration and diffing committed vs on-demand pricing, see how to estimate AWS costs from Terraform.

FAQ

The summary

For most teams in 2026:

1. Start with a 1-year no-upfront Compute Savings Plan at your baseline usage. Flexible, decent discount, low commitment risk.
2. Layer in service-specific RIs for stable RDS, Redshift, ElastiCache workloads. Same 1-year no-upfront approach.
3. Renew into 3-year commitments on the next cycle if the workload is still there and you want the deeper discount.
4. Don't touch Standard RIs unless you have a specific reason. The flexibility cost is real and the discount delta is modest.

For per-resource pricing including commitment options, see the resource catalog. Most entries document how to configure purchaseOption in c3x-usage.yml.