EC2 Pricing Models (On-Demand, Reserved, Spot)
Key concepts
On-Demand for unpredictable
Reserved Instances commitment
Standard vs Convertible RI
Spot for fault-tolerant
Capacity Reservations
Overview
Amazon EC2 offers multiple pricing models to optimize costs based on workload characteristics. Understanding when to use each model is a core competency tested on the SAA-C03 exam and essential for designing cost-optimized architectures.
Core Concept
EC2 pricing follows a simple pattern: More commitment = More savings. On-Demand has no commitment (highest cost), Reserved Instances offer 1-3 year commitments (up to 72% savings), and Spot Instances use spare capacity (up to 90% savings but can be interrupted).
Exam questions often present scenarios requiring pricing model selection. Key signals: 'predictable/steady workload' → Reserved Instances, 'flexible/interruptible' → Spot, 'unpredictable/short-term' → On-Demand, 'need flexibility + savings' → Savings Plans.
Key Concepts
EC2 Pricing Model Comparison
On-Demand Instances
Description: Pay by the second (Linux) or hour (Windows) with no commitment
Key Characteristics:
- No upfront payment required
- No long-term commitment
- Pay only for what you use
- Can launch/terminate anytime
- Highest per-hour cost
Best Use Cases:
- Short-term, spiky workloads
- Development and testing
- Applications with unpredictable usage
- First-time workloads (before patterns known)
- Workloads that cannot be interrupted
Pricing Example (m5.large, us-east-1):
- ~$0.096/hour = ~$70/month = ~$840/year
Reserved Instances (RIs)
Description: Commit to 1 or 3-year term for significant discounts
Discount Levels: | Type | Term | Discount | |------|------|----------| | Standard RI | 1 year | Up to 40% | | Standard RI | 3 year | Up to 60% | | Convertible RI | 1 year | Up to 31% | | Convertible RI | 3 year | Up to 54% |
Payment Options:
- All Upfront: Largest discount, pay entire term upfront
- Partial Upfront: Medium discount, some upfront + monthly
- No Upfront: Smallest discount, monthly payments only
Best Use Cases:
- Steady-state production workloads
- Applications running 24/7
- Predictable capacity requirements
- Databases, core application servers
Pricing Example (m5.large, 3-year, All Upfront):
- ~$0.038/hour effective = ~$28/month = ~$333/year (60% savings)
Spot Instances
Description: Bid on spare EC2 capacity at steep discounts
Key Characteristics:
- Up to 90% discount vs On-Demand
- Can be interrupted with 2-minute warning
- Price fluctuates based on supply/demand
- No long-term commitment
Interruption Handling:
- 2-minute notification before termination
- Can be stopped/hibernated (if configured)
- Use Spot Instance interruption notice
Best Use Cases:
- Batch processing jobs
- Big data analytics
- CI/CD and testing
- Containerized workloads
- Stateless web applications
- Any fault-tolerant workload
Pricing Example (m5.large, us-east-1):
- ~$0.03/hour = ~$22/month (70% savings)
- Prices vary by instance type and AZ
Standard vs Convertible Reserved Instances
Standard vs Convertible Reserved Instances
| Feature | Standard RI | Convertible RI |
|---|---|---|
| Maximum Discount | Up to 72% | Up to 66% |
| Change Instance Family | No | Yes (exchange) |
| Change Instance Size | Yes (modify) | Yes (modify/exchange) |
| Change OS/Tenancy | No | Yes (exchange) |
| Sell on RI Marketplace | Yes | No |
| Region Scope Change | No | Yes (exchange) |
| Best For | Known, stable workloads | Evolving workloads |
RI Modification vs Exchange
Modify (Standard & Convertible)
- Change Availability Zone within region
- Change instance size within same family
- Split or merge RIs
- NO cost difference
Exchange (Convertible Only)
- Change instance family (e.g., m5 → c5)
- Change operating system
- Change tenancy
- Must result in equal or greater value
- Cannot exchange to lower value
Example Exchange:
- Have: 1x Convertible RI for c5.xlarge ($500 remaining)
- Want: c6g.xlarge ($600 remaining)
- Result: Pay $100 difference, get new RI
Capacity Reservations
On-Demand Capacity Reservations
Purpose: Guarantee EC2 capacity in a specific AZ
Key Features:
- Reserve capacity without RI commitment
- Pay On-Demand rate whether used or not
- Can be created/cancelled anytime
- Combine with RIs/Savings Plans for discounts
Use Cases:
- Disaster recovery capacity
- Guaranteed launch for critical workloads
- Event-driven scaling needs
- Compliance requirements
Pricing:
- Same as On-Demand hourly rate
- Pay even if capacity is unused
- Apply RI/Savings Plan discounts when combined
Zonal vs Regional RIs
Zonal RIs (Assigned to Specific AZ)
- Provides capacity reservation in that AZ
- Discount applies only to that AZ
- Guaranteed instance launch
Regional RIs (No AZ Specified)
- Discount applies across all AZs in region
- Size flexibility within instance family
- NO capacity reservation
- More flexibility, less guarantee
Best Practice:
- Use Regional for flexibility
- Use Zonal when capacity guarantee needed
- Consider On-Demand Capacity Reservations + Regional RI for both
Spot Instance Deep Dive
Spot Fleet & Spot Pools
Spot Fleet
- Collection of Spot (and optionally On-Demand) instances
- Define target capacity (instances or vCPUs)
- Specify multiple instance types and AZs
- Automatic replacement of interrupted instances
Allocation Strategies: | Strategy | Description | Best For | |----------|-------------|----------| | lowestPrice | Launches from lowest-price pool | Maximum cost savings | | capacityOptimized | Launches from pools with most capacity | Minimize interruptions | | diversified | Distributes across all pools | Balance of both |
Spot Pools:
- Each instance type + AZ = one pool
- Using multiple pools reduces interruption risk
- capacityOptimized strategy is generally recommended
{
"SpotFleetRequestConfig": {
"IamFleetRole": "arn:aws:iam::123456789012:role/spot-fleet-role",
"TargetCapacity": 20,
"SpotPrice": "0.05",
"AllocationStrategy": "capacityOptimized",
"LaunchSpecifications": [
{
"InstanceType": "m5.large",
"ImageId": "ami-12345678",
"SubnetId": "subnet-1a2b3c4d"
},
{
"InstanceType": "m5.xlarge",
"ImageId": "ami-12345678",
"SubnetId": "subnet-1a2b3c4d"
},
{
"InstanceType": "m4.large",
"ImageId": "ami-12345678",
"SubnetId": "subnet-1a2b3c4d"
}
]
}
}# Get current On-Demand pricing
aws pricing get-products \
--service-code AmazonEC2 \
--filters Type=TERM_MATCH,Field=instanceType,Value=m5.large
# Describe Reserved Instances
aws ec2 describe-reserved-instances \
--filters Name=state,Values=active
# Get Spot price history
aws ec2 describe-spot-price-history \
--instance-types m5.large \
--product-descriptions "Linux/UNIX" \
--start-time $(date -u -d "1 hour ago" +%Y-%m-%dT%H:%M:%S)
# Request Spot Fleet
aws ec2 request-spot-fleet \
--spot-fleet-request-config file://spot-fleet-config.json
# Create Capacity Reservation
aws ec2 create-capacity-reservation \
--instance-type m5.large \
--instance-platform Linux/UNIX \
--availability-zone us-east-1a \
--instance-count 10Pricing Model Decision Guide
EC2 Pricing Model Selection
| Workload Characteristic | Best Pricing Model | Discount | Notes |
|---|---|---|---|
| 24/7 production, known capacity | Standard RI (3-year) | Up to 72% | Maximum savings for steady workloads |
| 24/7 production, may change instance type | Convertible RI | Up to 66% | Flexibility to change configurations |
| Flexible compute needs | Compute Savings Plans | Up to 66% | Most flexible commitment option |
| Batch processing, fault-tolerant | Spot Instances | Up to 90% | Highest savings, can be interrupted |
| Dev/test, unpredictable usage | On-Demand | 0% | No commitment, maximum flexibility |
| Disaster recovery capacity | On-Demand Capacity Reservation | 0% | Guarantees capacity when needed |
| Mixed workload fleet | Spot Fleet + On-Demand base | Variable | Balance cost and reliability |
Best Practices
- Analyze Before Committing: Use Cost Explorer to understand usage patterns before purchasing RIs
- Use Savings Plans for Flexibility: When uncertain about instance types, prefer Compute Savings Plans
- Diversify Spot Pools: Use multiple instance types and AZs to minimize interruption risk
- Start with On-Demand: New workloads should start On-Demand until patterns are established
- Reserve Your Baseline: Use RIs for minimum steady-state, On-Demand/Spot for peaks
- Combine Strategies: Mix RIs/Savings Plans with Spot for optimal cost/reliability balance
- Monitor RI Utilization: Use Cost Explorer RI Coverage/Utilization reports
Common Exam Scenarios
Exam Scenario Decision Guide
| Scenario | Recommended Solution | Key Reasoning |
|---|---|---|
| Production database running 24/7 for 3 years | Standard RI (3-year, All Upfront) | Maximum discount for steady, predictable workload |
| Web application with steady traffic, might migrate to Graviton | Convertible RI | Flexibility to change instance family |
| Batch data processing, can restart if interrupted | Spot Instances with Spot Fleet | Maximum savings, workload is fault-tolerant |
| Development environment used 8 hours/day | On-Demand or Scheduled Reserved Instances | Not running 24/7, RIs less beneficial |
| Need guaranteed capacity for DR in specific AZ | On-Demand Capacity Reservation + Regional RI | Capacity guarantee plus discount |
| Uncertain workload, want savings without specific instance commitment | Compute Savings Plans | Flexible commitment, automatic discount |
| Auto Scaling group with baseline + peaks | RIs for baseline, On-Demand/Spot for scaling | Cost optimization with reliability |
| Short-term project (3 months) | On-Demand only | Commitment period exceeds project duration |
Common Pitfalls
Unused Reserved Instances
RIs require payment regardless of usage. Purchasing RIs for workloads that might be decommissioned or migrated results in wasted spend. Always verify workload stability before committing.
Wrong RI Scope Selection
Zonal RIs provide capacity reservation but less flexibility. Regional RIs offer flexibility but no capacity guarantee. Choose based on whether capacity guarantee or flexibility is more important.
Spot Without Interruption Handling
Spot Instances WILL be interrupted. Applications must handle 2-minute termination notices gracefully. Without proper interruption handling, Spot can cause application failures.
Standard RI Lock-in
Standard RIs cannot change instance family. Purchasing Standard RIs before architectural decisions are finalized can lock you into suboptimal instance types.
Capacity Reservation Costs
On-Demand Capacity Reservations charge whether used or not. Reserving capacity "just in case" without using it wastes money at On-Demand rates.
Related Services
Quick Reference
Pricing Comparison Summary
| Model | Discount | Commitment | Interruption | Best For |
|---|---|---|---|---|
| On-Demand | 0% | None | No | Flexibility |
| Standard RI | Up to 72% | 1-3 years | No | Steady workloads |
| Convertible RI | Up to 66% | 1-3 years | No | Evolving workloads |
| Spot | Up to 90% | None | Yes | Fault-tolerant |
| Savings Plans | Up to 66% | 1-3 years | No | Flexible compute |
Key CLI Commands
# Get RI recommendations
aws ce get-reservation-purchase-recommendation \
--service Amazon Elastic Compute Cloud - Compute
# Describe Spot price history
aws ec2 describe-spot-price-history \
--instance-types m5.large m5.xlarge \
--product-descriptions "Linux/UNIX"
# Purchase Reserved Instance
aws ec2 purchase-reserved-instances-offering \
--instance-count 1 \
--reserved-instances-offering-id OFFERING_ID
# Create Capacity Reservation
aws ec2 create-capacity-reservation \
--instance-type m5.large \
--availability-zone us-east-1a \
--instance-count 5
Test Your Knowledge
A company runs a production database that must be available 24/7 for the next 3 years. The database runs on a db.r5.2xlarge RDS instance. Which pricing option provides the GREATEST cost savings?
A data analytics team runs batch jobs that can be interrupted and restarted. The jobs typically complete within 2-4 hours and run daily. Which EC2 pricing strategy is MOST cost-effective?
A company has an application with a steady baseline of 10 instances but scales to 50 instances during peak hours (2 hours daily). Which combination is MOST cost-effective?
A company purchased Standard Reserved Instances for c5.xlarge but now wants to migrate to c6g.xlarge (Graviton). What should they do?