AWS Price Model Adoptions: Reserved Instances & Savings Plans
Price model adoptions (for example, Reserved Instances, AWS Savings Plans)
AWS Price Model Adoptions: Reserved Instances & Savings Plans
This guide covers the strategic selection of AWS pricing models, focusing on the transition from traditional Reserved Instances (RI) to the more flexible Savings Plans (SP), essential for the AWS Certified Solutions Architect - Professional (SAP-C02) exam.
Learning Objectives
After studying this guide, you should be able to:
- Distinguish between On-Demand, Reserved Instances, and Savings Plans.
- Evaluate the flexibility trade-offs between Compute Savings Plans and EC2 Instance Savings Plans.
- Recommend a pricing model based on workload patterns (steady-state vs. spiky).
- Calculate the impact of payment options (No Upfront, Partial Upfront, Full Upfront) on total cost.
Key Terms & Glossary
- Steady-State Workload: An application that has a consistent level of resource usage over a long period (e.g., a core database).
- Tenancy: Refers to whether your instance runs on shared hardware or dedicated physical servers.
- Commitment: A contractual promise to pay for a specific amount of compute (measured in $/hour) for 1 or 3 years.
- Attribute Matching: The process where AWS applies a discount to a specific instance because it matches the Region, AZ, and Family of a reservation.
The "Big Idea"
In the cloud, you pay for flexibility. On-Demand pricing is the "retail price" for maximum flexibility. To reduce costs, you must trade some of that flexibility for a Commitment. Historically, this was done via Reserved Instances (inflexible, tied to specific hardware), but modern cost optimization relies on Savings Plans, which decouple the discount from the specific instance configuration, allowing your architecture to evolve without losing your financial benefits.
Formula / Concept Box
| Pricing Model | Commitment Term | Typical Savings | Primary Benefit |
|---|---|---|---|
| On-Demand | None (Pay-as-you-go) | 0% (Baseline) | No risk; ideal for spiky/new workloads. |
| Reserved Instance (RI) | 1 or 3 Years | Up to 75% | Capacity reservation in a specific AZ. |
| Compute Savings Plan | 1 or 3 Years | Up to 66-72% | Maximum flexibility (EC2, Fargate, Lambda). |
| EC2 Instance Savings Plan | 1 or 3 Years | Up to 72% | Higher savings; limited to a specific instance family. |
Hierarchical Outline
- Workload Analysis
- Steady State: Best for RIs or Savings Plans.
- Spiky/Unpredictable: Best for On-Demand.
- Interruptible/Batch: Best for Spot Instances.
- Reserved Instances (Legacy Preference)
- Standard RIs: High discount, low flexibility.
- Convertible RIs: Lower discount, allows changing instance families.
- Scope: Can be Zonal (reserved capacity) or Regional (no capacity guarantee).
- Savings Plans (Modern Preference)
- Compute Savings Plans: Applies to EC2, Lambda, and Fargate across any region.
- EC2 Instance Savings Plans: Requires commitment to a specific instance family in a region (e.g., M5 in US-East-1).
- Payment Options
- No Upfront: Lowest initial cost, highest hourly rate.
- Partial Upfront: Balanced approach.
- Full Upfront: Highest initial cost, lowest total cost over the term.
Visual Anchors
Decision Logic for Pricing Models
Savings vs. Commitment Risk
\begin{tikzpicture}[scale=0.8] \draw[->] (0,0) -- (6,0) node[right] {Commitment (Time/Rigidity)}; \draw[->] (0,0) -- (0,5) node[above] {Cost Savings (%)};
% On-Demand
\filldraw[blue] (0.5,0.5) circle (2pt) node[anchor=north west] {On-Demand (0\%)};
% Savings Plan
\draw[dashed, red, thick] (1,1) -- (4,3.5);
\filldraw[red] (4,3.5) circle (2pt) node[anchor=south east] {Savings Plans (72\%)};
% Reserved Instance
\filldraw[black] (5,4.5) circle (2pt) node[anchor=south east] {Standard RI (75\%)};
\node[draw, align=left] at (3, -1.5) {Higher commitment = Higher discount, but higher risk of unutilized waste.};\end{tikzpicture}
Definition-Example Pairs
- Compute Savings Plan: A commitment model that applies to any compute usage regardless of instance family, size, AZ, region, OS, or tenancy.
- Example: You commit to $10/hour. You start with EC2 m5.large in Virginia, then migrate to Lambda in Ireland. The discount follows the usage automatically.
- EC2 Instance Savings Plan: A commitment to a specific instance family within a specific region.
- Example: You commit to the T3 family in London. You can switch from t3.medium to t3.large, and the discount still applies, but it will not apply if you switch to the M5 family.
Worked Examples
Case Study: Stockholm Region m5.large Costing
Based on source data, let's compare the total cost of an m5.large instance for 3 Years using different models:
- Compute Savings Plan (Full Upfront):
- Cost: $1,392.84
- Scenario: Best if you plan to move some logic to AWS Fargate next year.
- Standard Reserved Instance (Full Upfront):
- Cost: $1,008.00
- Scenario: Best if you are 100% certain you will stay on m5 instances in that specific region.
- On-Demand (Comparison):
- Hourly rate: $0.102/hour.
- 3-Year total (approx): $2,680.56 ($0.102 * 24 * 365 * 3).
[!IMPORTANT] The Standard RI is cheaper than the Compute Savings Plan in this example ($1,008 vs $1,392), but the Savings Plan offers protection against changing your architecture to Lambda or Fargate.
Checkpoint Questions
- What is the primary advantage of a Compute Savings Plan over an EC2 Instance Savings Plan?
- True or False: Reserved Instances can provide up to 75% savings compared to On-Demand.
- Which payment option results in the lowest overall price for a 3-year term?
- If an application is "spiky" (e.g., a retail site during a 2-day sale), which pricing model is recommended?
▶Click to see answers
- Compute Savings Plans apply to Lambda and Fargate and work across any Region.
- True.
- Full Upfront.
- On-Demand (or potentially Spot if the workload is fault-tolerant).
Muddy Points & Cross-Refs
- RI vs. SP Capacity: Standard RIs, when bought for a specific Availability Zone, provide a Capacity Reservation. Savings Plans do NOT provide a capacity reservation by default. For guaranteed capacity with Savings Plans, you must use On-Demand Capacity Reservations.
- Convertible RIs: These are often confused with Savings Plans. Think of Convertible RIs as the "old way" to get flexibility, while Savings Plans are the "automated way."
Comparison Tables
| Feature | Reserved Instances | Savings Plans (Compute) | Savings Plans (EC2) |
|---|---|---|---|
| Applies to EC2 | Yes | Yes | Yes |
| Applies to Lambda/Fargate | No | Yes | No |
| Change Instance Family | Only if 'Convertible' | Yes (Automatic) | No |
| Change Region | No (Usually tied) | Yes | No |
| Capacity Reservation | Yes (if Zonal) | No | No |