Skip to main content

AWS Glossary

Reserved Instances vs Savings Plans

Comparison of AWS Reserved Instances and Savings Plans pricing models for cost optimization.

Definition

AWS offers two primary commitment-based discount models: Reserved Instances (RIs) and Savings Plans. Both exchange a one- or three-year commitment for lower rates versus on-demand, but they differ in flexibility. RIs bind to specific instance attributes (type, region, tenancy, OS for EC2; engine and class for RDS) unless you purchase Convertible RIs or use the RI Marketplace. Savings Plans bind to an hourly spend commitment and apply flexibly across eligible usage. Database Savings Plans (2025+) consolidate database commitment similarly. Most organizations use a blend: RIs or EC2 Instance Savings Plans for stable footprints, Compute Savings Plans for mixed or evolving compute.

When to use it

Reserved Instances fit when:

  • Workloads run predictable instance types in fixed regions for years (legacy databases, always-on app servers)
  • You want maximum discount on a known EC2 family via Standard RIs or EC2 Instance Savings Plans
  • RDS or ElastiCache usage is stable per engine and RI inventory is already operationalized

Savings Plans fit when:

  • Usage shifts between sizes, families, or compute services (EC2 ↔ Fargate ↔ Lambda)
  • You prefer automatic application without tracking reservation IDs
  • Database Savings Plans simplify multi-engine estates versus separate RDS/DynamoDB/ElastiCache RIs

When not to use it

  • Either model when usage is experimental or declining — on-demand plus right-sizing beats stranded commitment
  • RIs when you change instance families quarterly — Convertible RIs help but add complexity; Compute Savings Plans often win
  • Savings Plans when you need scheduled capacity windows only — Scheduled RIs (where available) or on-demand autoscaling may fit niche cases better
  • Committing based on peak traffic rather than baseline — both models punish overcommitment

Tips

  • Pull Cost Explorer RI and SP recommendations side by side before annual procurement cycles
  • Track utilization (RIs) and coverage/utilization (Savings Plans) in the same FinOps dashboard
  • Use the RI Marketplace to offload mistaken Standard RIs — not available for all commitment types
  • Layer Compute Optimizer first — commitments on oversized instances discount the wrong footprint
  • Document a renewal calendar 90 days before expiry — auto-renew defaults may not match next year’s architecture

Gotchas

Serious

  • Stranded RIs: Standard RIs on retired instance families bill at full commitment while workloads moved to Graviton or different sizes pay on-demand too.
  • Double commitment: Buying RIs and Savings Plans for the same baseline without analysis — usually one instrument should cover the floor.
  • Marketplace neglect: Teams pay for unused Standard RIs for months because nobody owns Marketplace listing.

Regular

  • Convertible RI exchanges have rules and fees — not “free flexibility.”
  • Savings Plans partial upfront vs no upfront changes cash flow, not always total discount — finance should model both.
  • Lambda and Fargate never receive EC2 RI discounts — a frequent procurement mistake in mixed serverless estates.

Official references

Need help with this topic?

Our AWS-certified team implements, audits, and optimizes these services in production — from Bedrock RAG pipelines to multi-account landing zones.