Ace Cloud Interviews
Home/AWS Tutorial/Savings Plans
💰

AWS Cost Management

Savings Plans

Flexible pricing model offering up to 72% savings on compute in exchange for commitment

AWS Savings Plans are a flexible commitment-based pricing model that offer discounts of up to 72% compared to On-Demand rates in exchange for committing to a consistent amount of compute usage (measured in $/hour) for 1 or 3 years. Unlike Reserved Instances, Savings Plans automatically apply to any matching compute usage across services, instance families, and regions, making them significantly easier to manage. For cloud engineers, understanding Savings Plans is essential for cost optimization interviews and real-world FinOps work.

Savings Plans Types - Compute vs EC2 Instance vs SageMaker

AWS offers three types of Savings Plans with different levels of flexibility and corresponding discount levels:

TypeApplies ToFlexibilityMax DiscountBest For
Compute Savings PlansEC2, Fargate, LambdaAny instance family, size, region, OS, tenancyUp to 66%Most organizations - maximum flexibility
EC2 Instance Savings PlansEC2 only (specific family in specific region)Any size and OS within a committed family/regionUp to 72%Stable workloads in a specific region with known instance family
SageMaker Savings PlansSageMaker ML instancesAny instance family, size, region, componentUp to 64%ML-heavy workloads with consistent SageMaker usage

The key trade-off is discount depth vs flexibility. EC2 Instance Savings Plans give the deepest discount but require you to commit to a specific instance family in a specific region. Compute Savings Plans are more flexible but offer a slightly lower discount.

💡

Compute Savings Plans are generally the recommended choice for most teams because they handle instance type changes, region migrations, and workload shifts automatically. The discount difference vs EC2 Instance Savings Plans is small (66% vs 72%) and the operational savings from not managing per-family commitments is worth it.

How Savings Plans Apply to Your Bill

Savings Plans work by reducing your hourly compute bill as usage is matched against your commitment. The mechanics are important to understand for interviews:

When you purchase a Savings Plan at $10/hour, AWS looks at your compute usage each hour and applies the Savings Plans rate to usage up to $10/hour of commitment. Usage beyond your commitment falls back to On-Demand pricing.

ScenarioWhat Happens
Usage < commitmentYou pay the full commitment. Unused commitment is wasted - no refund.
Usage = commitmentAll usage covered at discounted rate. Perfect utilization.
Usage > commitmentCommitment covers usage up to $10/hr at discounted rate. Excess is On-Demand.

Priority order when multiple discount mechanisms exist:

PriorityMechanismNotes
1Reserved Instances (RIs)Applied first to matching usage
2EC2 Instance Savings PlansApplied next to matching EC2 usage
3Compute Savings PlansApplied to remaining eligible usage
4On-DemandCharged for any remaining usage
⚠️

If you have both RIs and Savings Plans, the RI is always applied first. This means your Savings Plans utilization will look lower if RIs are covering usage the Savings Plan would otherwise cover. Track both RI coverage and Savings Plans coverage together.

Commitment Terms and Payment Options

Savings Plans come in 1-year and 3-year terms, each with three payment options. The payment option affects the effective hourly rate:

Payment Option1-Year Discount (approx)3-Year Discount (approx)Cash Flow Impact
All UpfrontHigher discountHighest discount (up to 66%/72%)Large upfront payment, zero ongoing charges
Partial UpfrontMedium discountHigh discountUpfront + monthly charges
No UpfrontLower discountMedium discountMonthly charges only, no upfront commitment

Break-even analysis for Compute Savings Plans (approximate):

OptionOn-Demand RateSavings Plans RateMonthly Savings on $10k/moUpfront Cost to Break Even
No Upfront 1yr$10,000~$7,400$2,600None - immediate savings
All Upfront 1yr$10,000~$6,800$3,200Pay ~$81,600 upfront for year
No Upfront 3yr$10,000~$6,200$3,800None - immediate savings
All Upfront 3yr$10,000~$5,400$4,600Pay ~$194,400 upfront for 3 years
💡

For most companies, No Upfront 1-year Savings Plans offer the best balance of savings and risk. They avoid locking up capital, allow annual reassessment of commitment levels, and still provide substantial discounts over On-Demand.

Savings Plans vs Reserved Instances

Both Savings Plans and Reserved Instances offer commit-to-save discounts, but they work differently. Understanding when to choose each is a common interview topic.

DimensionSavings PlansReserved Instances
Commitment unit$/hour of compute spendSpecific instance type in specific region
Applies toEC2, Fargate, Lambda (Compute SP)EC2, RDS, Elasticache, Redshift, OpenSearch
FlexibilityAutomatically applies across families/regions/servicesConvertible RIs offer some flexibility; Standard RIs are rigid
Discount depthUp to 66-72% for computeUp to 72% for EC2; varies by service
RDS coverageNo - Savings Plans do not cover RDSYes - RDS Reserved Instances available
Management overheadLow - commitment in $/hr, auto-appliesHigher - must manage per instance-type inventory
MarketplaceCannot be sold on Reserved Instance MarketplaceStandard RIs can be sold on Marketplace

When to choose Reserved Instances over Savings Plans:

ScenarioUse RI Because
RDS databasesSavings Plans do not cover RDS - must use RDS Reserved Instances
Elasticache, RedshiftNo Savings Plans equivalent - RIs are the only commitment option
Very stable EC2 workloadsStandard EC2 Instance Savings Plans match RI discount but Convertible RIs can be exchanged
Need to resell unused capacityStandard RIs can be listed on the Reserved Instance Marketplace

Purchasing Strategy and Coverage Targets

A common mistake is committing too aggressively and ending up with low utilization. The recommended approach is to start conservative and increase commitments over time.

Use the AWS Savings Plans purchase recommendation in Cost Explorer:

bash
# Get Savings Plans purchase recommendations via CLI
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS

# Check current Savings Plans utilization
aws ce get-savings-plans-utilization \
  --time-period Start=2024-05-01,End=2024-06-01

# Check Savings Plans coverage
aws ce get-savings-plans-coverage \
  --time-period Start=2024-05-01,End=2024-06-01 \
  --granularity MONTHLY

Coverage target guidelines:

Coverage TargetRisk ProfileReasoning
70-80% coverageConservativeLeaves buffer for workload reduction without wasted commitment
80-90% coverageBalancedGood savings while maintaining flexibility for 10-20% fluctuation
90%+ coverageAggressiveMaximum savings but risk of underutilization if workloads shrink
⚠️

Savings Plans cannot be cancelled after purchase. If your EC2 usage drops significantly (e.g. you decommission a large service), you will continue paying the hourly commitment rate for the full term even if you have nothing to apply it to. Always purchase based on your minimum expected usage, not average usage.

🎯

Interview Focus Points

  • 1What is the difference between Compute Savings Plans and EC2 Instance Savings Plans? When would you choose one over the other?
  • 2Savings Plans vs Reserved Instances - which would you recommend for a company running EC2, RDS, and Fargate workloads?
  • 3What happens to your Savings Plans commitment if you shut down a service and your hourly spend drops below your commitment amount?
  • 4How does the Savings Plans coverage metric differ from the utilization metric? Which should you optimize for?
  • 5A team has 70% Savings Plans utilization - is that good or bad? What should they do about it?
  • 6Can you cancel a Savings Plan after purchase? What are your options if you over-committed?
  • 7How does AWS apply discounts when you have both Reserved Instances and Savings Plans active simultaneously?
  • 8Walk me through how you would decide the right commitment amount when purchasing Savings Plans for a new environment.