Cargando...
Cargando...
Flexible, commitment-based pricing that slashes compute costs by up to 66% — no reservation headaches
AWS Savings Plans are a flexible pricing model that offers significant discounts on AWS compute usage in exchange for a commitment to a consistent amount of usage (measured in $/hour) for a 1 or 3 year term. Unlike Reserved Instances, Savings Plans automatically apply to eligible usage across instance families, sizes, operating systems, and regions (depending on plan type), making them far easier to manage. They are the modern, recommended replacement for many Reserved Instance use cases and are managed through AWS Cost Explorer.
Reduce AWS compute costs by committing to a minimum hourly spend in exchange for deeply discounted rates — without locking into specific instance types or configurations
Use When
Avoid When
Compute Savings Plans
Applies to EC2 (any family, size, AZ, region, OS, tenancy), AWS Fargate, and AWS Lambda. Most flexible plan type. Up to ~66% savings vs On-Demand.
EC2 Instance Savings Plans
Applies to a specific EC2 instance family in a specific region (e.g., M5 in us-east-1). Offers deeper discounts (up to ~72%) than Compute Savings Plans in exchange for less flexibility.
SageMaker Savings Plans
Applies to SageMaker ML compute usage. Separate from Compute Savings Plans. Up to 64% savings on SageMaker.
Automatic application to eligible usage
AWS automatically applies Savings Plans discounts to eligible usage — no manual assignment needed unlike Reserved Instances
Shareable across AWS Organization
Savings Plans purchased in the management (payer) account can be shared with all member accounts in an AWS Organization via Cost Explorer
Managed via AWS Cost Explorer
Purchase, track, and get recommendations for Savings Plans directly in Cost Explorer — no separate console
Savings Plans recommendations
Cost Explorer analyzes your last 7, 30, or 60 days of usage and recommends optimal commitment amounts
Capacity reservation
CRITICAL: Savings Plans do NOT reserve capacity. If you need guaranteed capacity in a specific AZ, use On-Demand Capacity Reservations separately.
Convertible Reserved Instance-like flexibility
Compute Savings Plans provide similar flexibility to Convertible RIs but are simpler to manage — no exchange process required
Applicable to Spot Instances
Savings Plans do NOT apply to Spot Instance usage — Spot already has its own deep discount mechanism
Applicable to Dedicated Hosts
Savings Plans do NOT apply to Dedicated Host usage
Applicable to Reserved Instance usage
Savings Plans do NOT stack on top of Reserved Instances — RI discounts are applied first, then Savings Plans cover remaining On-Demand usage
Utilization and coverage reports
Available in Cost Explorer to track how well your Savings Plans are being utilized and what percentage of spend is covered
Queuing future Savings Plans
You can queue a Savings Plan to start when a current one expires, enabling seamless transitions
Savings Plans Purchase and Optimization Workflow
high freqUse Cost Explorer's Savings Plans recommendations feature to analyze historical usage (7/30/60 days), identify optimal commitment amounts, and purchase directly. Monitor utilization and coverage reports in Cost Explorer to ensure plans are being fully used and adjust future commitments accordingly.
Organization-wide Savings Plans Sharing
high freqPurchase Savings Plans from the management (payer) account to automatically share discounts across all member accounts. This maximizes utilization by pooling diverse workloads. Individual member accounts can be excluded from sharing if needed via Cost Explorer settings.
Baseline + Burst Cost Optimization
high freqCommit to Savings Plans for your predictable baseline compute (e.g., minimum fleet size that always runs), then let Auto Scaling handle burst capacity using On-Demand or Spot Instances. This hybrid approach optimizes cost without over-committing.
Serverless and Container Cost Optimization
high freqCompute Savings Plans uniquely cover Fargate and Lambda in addition to EC2. Organizations running mixed workloads (containers + serverless + VMs) can use a single Compute Savings Plan to discount all three, simplifying cost management vs. managing separate RIs.
Savings + Guaranteed Capacity
high freqCombine Savings Plans (for pricing discounts) with On-Demand Capacity Reservations (for guaranteed capacity in a specific AZ). The Capacity Reservation charges On-Demand rates, and the Savings Plan discount is applied on top to reduce that cost. This achieves both goals: savings AND capacity guarantee.
RI + Savings Plans Coexistence
high freqExisting Reserved Instances and Savings Plans can coexist. RI discounts are applied first to matching usage, then Savings Plans cover remaining eligible On-Demand usage. Organizations typically maintain existing RIs until expiry and use Savings Plans for new commitments going forward.
Commitment Monitoring and Alerting
medium freqUse AWS Budgets with Savings Plans utilization budget type to alert when your Savings Plans utilization drops below a threshold (e.g., alert if utilization < 80%), ensuring you're getting value from your commitments and can adjust purchasing strategy.
Savings Plans commit to a $/hour spend rate — NOT to specific instances, vCPUs, or GB of RAM. If a question describes committing to a dollar amount per hour, that's Savings Plans. If it describes committing to a specific instance type/count, that's Reserved Instances.
Savings Plans do NOT provide capacity reservations. If an exam scenario requires guaranteed capacity in a specific Availability Zone (e.g., disaster recovery, compliance), you MUST use On-Demand Capacity Reservations. Savings Plans only provide a pricing discount.
Compute Savings Plans cover EC2 (any family/size/region/OS), Fargate, AND Lambda — making them the only savings mechanism that spans VMs, containers, and serverless. EC2 Instance Savings Plans cover ONLY a specific EC2 instance family in a specific region. Know which plan type covers which services.
Billing application order matters: Reserved Instance discounts are applied FIRST, then Savings Plans discounts, then On-Demand pricing. Savings Plans and RIs do NOT stack — you get one or the other on any given unit of usage.
Savings Plans NEVER provide capacity reservations — they are pricing discounts only. Any scenario requiring guaranteed capacity in a specific AZ needs On-Demand Capacity Reservations, not Savings Plans.
Only Compute Savings Plans cover EC2 + Fargate + Lambda. EC2 Instance Savings Plans cover only one EC2 instance family in one region. SageMaker Savings Plans cover only SageMaker. Match the plan type to the workload mix in the scenario.
Billing order: Reserved Instances discounts apply FIRST, then Savings Plans discounts apply to remaining eligible usage. They do not stack on the same usage unit. Savings Plans commitment is in $/hour, not instance counts.
For maximum discount: choose 3-year term + All Upfront + EC2 Instance Savings Plans (for EC2-only workloads) or Compute Savings Plans (for mixed workloads). For maximum flexibility with still significant savings: choose Compute Savings Plans. Know the trade-off triangle: discount depth vs. flexibility vs. capital outlay.
Savings Plans purchased in the AWS Organizations management account are shared across ALL member accounts by default. This pooling effect improves utilization. A member account's Savings Plans are NOT automatically shared to other accounts unless purchased at the payer level.
Unused Savings Plans commitment is wasted — you pay for committed $/hour regardless of actual usage. Over-committing is a real cost risk. Cost Explorer recommendations help right-size commitments based on historical usage patterns.
Savings Plans do NOT apply to: Spot Instances, Dedicated Hosts, Reserved Instance charges, or usage covered by the Free Tier. If an exam question asks about discounting Spot usage, Savings Plans is a wrong answer.
AWS Budgets supports a specific 'Savings Plans utilization' budget type that alerts when your utilization falls below a defined threshold. This is different from a cost budget. Know the different AWS Budgets types: cost, usage, reservation utilization/coverage, Savings Plans utilization/coverage.
Common Mistake
Savings Plans and Reserved Instances are interchangeable — they both just give you discounts on EC2
Correct
They are fundamentally different mechanisms. Reserved Instances commit to specific instance configurations (type, region, AZ, OS, tenancy) and can provide capacity reservations. Savings Plans commit to a $/hour spend rate and NEVER provide capacity reservations. Savings Plans are more flexible and cover more services (Fargate, Lambda) but cannot guarantee capacity.
This is the #1 confusion on certification exams. The key differentiators: (1) RIs can reserve capacity, Savings Plans cannot. (2) Savings Plans cover Fargate and Lambda, most RIs do not. (3) Savings Plans commit to spend rate, RIs commit to resource configuration. When a scenario requires capacity guarantee → RI or Capacity Reservation. When a scenario requires flexibility across instance types → Savings Plans.
Common Mistake
Purchasing a Savings Plan means AWS will automatically ensure you always have enough instances running to meet your commitment
Correct
AWS does the opposite — it applies the discounted rate to whatever compute you actually use up to your commitment amount. If you use LESS than your committed $/hour, you still pay the full committed amount but get no additional instances. Savings Plans are purely a pricing construct, not a resource provisioning mechanism.
Candidates confuse 'commitment' with 'provisioning.' The commitment is financial (you agree to spend at least X$/hour), not operational (AWS does not spin up resources on your behalf). Over-commitment wastes money; under-commitment means you're paying On-Demand rates for the excess.
Common Mistake
Compute Savings Plans only apply to EC2 — just like EC2 Instance Savings Plans
Correct
Compute Savings Plans apply to EC2 (any instance family, size, region, OS, tenancy), AWS Fargate (ECS and EKS), AND AWS Lambda. EC2 Instance Savings Plans apply ONLY to a specific EC2 instance family in a specific AWS region. This is a critical distinction — Compute Savings Plans are the only way to get Savings Plan discounts on serverless (Lambda) and container (Fargate) workloads.
Exam questions frequently present mixed-workload scenarios (EC2 + Lambda + Fargate) and ask which savings option covers all three. The answer is always Compute Savings Plans. EC2 Instance Savings Plans would leave Lambda and Fargate at On-Demand pricing.
Common Mistake
Savings Plans discounts stack on top of Reserved Instance discounts for the same usage
Correct
Discounts do NOT stack. AWS applies Reserved Instance discounts first to matching usage. Only the remaining usage (not covered by RIs) is then eligible for Savings Plans discounts. You cannot get both an RI discount AND a Savings Plans discount on the same unit of compute usage.
Understanding the billing hierarchy prevents confusion about expected savings calculations. In exam cost optimization scenarios, if a workload already has RI coverage, adding a Savings Plan won't increase the discount on that specific workload — it would only help cover additional On-Demand usage.
Common Mistake
You need to specify which EC2 instances or workloads your Savings Plan should apply to when purchasing
Correct
Savings Plans automatically apply to eligible usage — there is no assignment or allocation step. AWS billing automatically identifies eligible usage and applies the discounted rate. The only choices you make at purchase time are: plan type, commitment amount ($/hour), term (1 or 3 year), and payment option.
This is a key operational advantage over Reserved Instances, which require matching specific instance attributes. The automatic application makes Savings Plans much simpler to manage but also means you cannot control which specific workloads receive the discount (AWS optimizes for maximum customer savings).
Common Mistake
A Savings Plan purchased in a member account automatically shares benefits with other accounts in the AWS Organization
Correct
Savings Plans sharing within an AWS Organization only works when the plan is purchased from the management (payer) account, OR when sharing is explicitly enabled. A plan purchased in a member account benefits only that member account by default unless the management account has enabled sharing and the member account opts in.
For exam scenarios about maximizing Savings Plans utilization across an organization, the correct answer always involves purchasing from the management account. This allows the organization's diverse workloads to collectively consume the commitment, improving utilization rates.
COMMIT = Cost-Only Model, Makes IT flexible: Savings Plans commit to COST ($/hr), not to specific resources — unlike RIs which commit to specific Instances
The 3 Cs of Savings Plans: Compute (most flexible, covers EC2+Fargate+Lambda), Constrained-EC2 (EC2 Instance SP, one family/region, deepest EC2 discount), and Cloud-ML (SageMaker SP)
SNAP = Savings Plans Never Allocate (capacity) or stack (with RIs) — remember what Savings Plans do NOT do
Discount order mantra: 'RIs eat first, Savings Plans eat second, On-Demand pays full price' — billing hierarchy in three words
Payment discount ranking (most to least savings): 'All → Partial → No' upfront, just like 'All in beats Part way beats No commitment' in poker
CertAI Tutor · · 2026-02-22
In the Same Category