0Pricing
AWS Solutions Architect · Lesson

Reserved Instances, Savings Plans, and Spot

Commit to Reserved Instances or Savings Plans for steady workloads and use Spot Instances for interruption-tolerant batch and stateless tasks.

Reserved Instances, Savings Plans, and Spot is a free AWS Solutions Architect lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the AWS Solutions Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

EC2 Purchasing Models Overview

AWS offers multiple EC2 purchasing models that trade flexibility for cost savings. On-Demand charges by the second with no commitment — the most flexible but most expensive. Reserved Instances provide up to 72% savings for 1 or 3-year commitments. Savings Plans provide up to 66% savings with a flexible hourly spend commitment. Spot Instances use spare capacity for up to 90% savings but can be interrupted. Dedicated Hosts provide physical servers for licensing compliance at premium cost. Understanding each model is critical for SAA-C03 cost scenarios.

# EC2 pricing models (m5.large in us-east-1, approximate):
# On-Demand:        $0.096/hr ($70/month)
# 1yr RI (No Upf): $0.062/hr ($45/month) - 35% savings
# 1yr RI (All Upf): $0.051/hr ($37/month) - 47% savings
# 3yr RI (All Upf): $0.032/hr ($23/month) - 67% savings
# Spot:            $0.030-0.050/hr       - 50-70% savings

# Rule: RI/SP for steady state, Spot for burst/interruptible

Reserved Instances: Types and Payment Options

Reserved Instances (RIs) are a billing construct, not a specific instance — they provide a discount applied to matching On-Demand instances in your account. RI types: Standard RIs — highest discount (up to 72%) but cannot change instance family. Convertible RIs — lower discount (~54%) but can exchange for different instance family, OS, or tenancy. Payment options: No Upfront (monthly payments, lowest commitment), Partial Upfront (lower effective rate), All Upfront (lowest effective hourly rate). Choose Standard RIs for predictable, unchanging workloads.

# Purchase Reserved Instance
aws ec2 purchase-reserved-instances-offering \
  --reserved-instances-offering-id offering-id-here \
  --instance-count 5

# List RI offerings
aws ec2 describe-reserved-instances-offerings \
  --instance-type m5.large \
  --product-description 'Linux/UNIX' \
  --offering-type 'No Upfront' \
  --duration 31536000 \
  --query 'ReservedInstancesOfferings[].{Price:RecurringCharges[0].Amount,Class:OfferingClass}'

RI Scope: Regional vs Zonal

Reserved Instances have two scope options that affect flexibility. Regional scope provides the flexibility benefit of instance size flexibility within the same family — a regional m5 RI covers any size (m5.small, m5.large, etc.) in any AZ within the region. It does NOT reserve capacity. Zonal scope reserves capacity in a specific AZ (capacity reservation), ensuring instances are available during high-demand events, but has no instance size flexibility. Use regional scope unless you need guaranteed capacity (e.g., DR or strict SLA).

# Regional RI: flexible across sizes in a family
# 1x m5 regional RI covers:
# - m5.large (1.0 units)
# - 2x m5.medium (0.5 units each)
# - 0.5x m5.xlarge (2.0 units)

# Zonal RI: specific AZ, reserves capacity
# 1x m5.large in us-east-1a:
# - Only covers m5.large in us-east-1a
# - Guarantees capacity is available

# Most use cases: prefer REGIONAL for flexibility

Savings Plans: More Flexible Than RIs

Savings Plans are a flexible pricing model where you commit to a minimum hourly spend (in dollars) for 1 or 3 years. AWS automatically applies the discount to eligible usage. Two types: Compute Savings Plans (up to 66% savings) — apply to EC2, Lambda, and Fargate across any family, region, OS, or tenancy. EC2 Instance Savings Plans (up to 72% savings) — apply within a specific instance family in a specific region, offering higher discount for less flexibility. Savings Plans are recommended over RIs for most new commitments due to their flexibility.

# Purchase Compute Savings Plan
aws savingsplans create-savings-plan \
  --savings-plan-offering-id offering-id \
  --commitment 10.00 \
  --purchase-time '2026-07-01T00:00:00Z'

# $10/hr commitment covers:
# - EC2 instances (any family, region, OS)
# - Lambda invocations and duration
# - Fargate vCPU and memory

# Savings Plans apply AFTER Reserved Instances
# Check coverage in Cost Explorer > Savings Plans

Choosing Between RI and Savings Plans

Key differences to guide your choice: RIs are better when you need capacity reservations (zonal RI), when you have very predictable workloads that won't change instance family, or when your older account has many existing RIs. Savings Plans are better for most new commitments because they automatically apply to new instance types (e.g., Graviton) without needing to exchange RIs. AWS recommends Savings Plans as the modern replacement for Compute RIs. For RDS, ElastiCache, and Redshift, Reserved Instances are still the mechanism (no Savings Plans for these services).

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

# Response shows:
# OnDemandCost: $5,000 (not covered)
# SpendCoveredBySavingsPlans: $10,000
# CoveragePercentage: 66%

# Recommendation:
# If coverage < 60%, consider purchasing more
# If coverage > 85%, you may be over-committed

Spot Instances: Deep Discounts with Interruption

Spot Instances use spare AWS EC2 capacity and are priced dynamically based on supply and demand — typically 60-90% below On-Demand. AWS can reclaim Spot Instances with a 2-minute warning when it needs the capacity. Best use cases: big data processing (EMR), CI/CD build agents, stateless web applications with ELB, machine learning training (checkpoint model to S3 on interruption), and batch processing jobs that checkpoint progress. Design applications to handle 2-minute termination warnings gracefully.

# Check Spot instance interruption notice
# From inside EC2 instance via Instance Metadata Service
curl http://169.254.169.254/latest/meta-data/spot/termination-time
# Returns: 2026-06-21T15:00:00Z if interruption is coming
# Returns 404 if no interruption

# Handle in your application:
# 1. Poll this endpoint every 5 seconds
# 2. On 2-min notice: checkpoint work to S3
# 3. Terminate gracefully
# 4. AWS terminates the instance 2 minutes after notice

Spot Instance Strategies and Diversification

To maximise Spot availability and minimise interruptions, use diversification: request multiple instance types across multiple AZs. A single Spot pool (specific instance type + AZ) can be interrupted simultaneously. Using mixed instance ASGs with many instance types (m5.large, m5a.large, m4.large, c5.large) dramatically reduces interruption risk — when one pool is reclaimed, the ASG replaces with another type. Use capacity-optimized allocation strategy to automatically pick the deepest pool (lowest interruption risk).

# ASG with diversified Spot pools
aws autoscaling create-auto-scaling-group \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateId": "lt-12345",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "m5.large"},
        {"InstanceType": "m5a.large"},
        {"InstanceType": "m4.large"},
        {"InstanceType": "c5.large"},
        {"InstanceType": "c5a.large"}
      ]
    },
    "InstancesDistribution": {
      "SpotAllocationStrategy": "capacity-optimized",
      "OnDemandPercentageAboveBaseCapacity": 0
    }
  }'

Spot for Batch and Data Processing

Batch workloads are ideal for Spot because they can be interrupted and resumed. AWS Batch natively manages Spot capacity, retrying failed jobs automatically and targeting optimal Spot pools. Amazon EMR lets you mix On-Demand master nodes (for reliability) with Spot core/task nodes (for savings). Managed Node Groups in EKS can use Spot instances, and Kubernetes' node-level graceful termination handles the 2-minute warning. These managed services abstract the complexity of Spot interruption handling.

# EMR cluster with On-Demand master + Spot workers
aws emr create-cluster \
  --instance-fleets \
    InstanceFleetType=MASTER,TargetOnDemandCapacity=1,InstanceTypeConfigs=[{InstanceType=m5.xlarge}] \
    InstanceFleetType=CORE,TargetSpotCapacity=10,InstanceTypeConfigs=[{InstanceType=m5.xlarge},{InstanceType=m5a.xlarge}],LaunchSpecifications={SpotSpecification={TimeoutAction=SWITCH_TO_ON_DEMAND,TimeoutDurationMinutes=10}}

# SWITCH_TO_ON_DEMAND: if Spot unavailable after 10 min,
# provision On-Demand instead (ensures job completes)

Combining Purchasing Models

The most cost-optimised architectures combine all three purchasing models: Savings Plans or RIs cover the steady-state baseline (the minimum number of instances always running), On-Demand covers predictable but variable overflow capacity, and Spot handles unpredictable burst traffic or batch workloads. In an ASG, set the On-Demand base capacity to your minimum reliable instances (covered by SP/RI) and configure the scaling increment to use Spot. This hybrid approach maximises savings while maintaining reliability.

# Hybrid ASG: On-Demand base + Spot burst
# Savings Plan covers On-Demand baseline cost
aws autoscaling create-auto-scaling-group \
  --mixed-instances-policy '{
    "LaunchTemplate": { ... },
    "InstancesDistribution": {
      "OnDemandBaseCapacity": 4,
      "OnDemandPercentageAboveBaseCapacity": 0,
      "SpotAllocationStrategy": "capacity-optimized"
    }
  }' \
  --min-size 4 --max-size 40 --desired-capacity 8

# 4 On-Demand instances (covered by Savings Plan)
# Additional instances = 100% Spot (cheapest burst)

Monitoring Commitment Utilisation

After purchasing RIs or Savings Plans, monitor their utilisation to ensure you are using what you paid for. Cost Explorer RI/SP utilisation reports show the percentage of your committed capacity being used. A utilisation below 80% means you are wasting money on unused commitments. Investigate whether workloads have been terminated or resized. For RIs, you can sell unused RIs on the AWS Marketplace to recover some cost. For Savings Plans, there is no secondary market — ensure you are confident in the commitment before purchasing.

# Check Savings Plans utilisation
aws ce get-savings-plans-utilization \
  --time-period Start=2026-06-01,End=2026-06-21 \
  --granularity DAILY \
  --query 'SavingsPlansUtilizationsByTime[].{Date:TimePeriod.Start,Utilization:Utilization.UtilizationPercentage}'

# Also check: Cost Explorer > Savings Plans > Utilization report
# Target: >80% utilisation
# If <80%: you over-committed or workload shrank

Dedicated Hosts and Dedicated Instances

Dedicated Hosts allocate a physical EC2 server dedicated to your account, allowing you to use your existing per-core or per-socket software licenses (Windows Server, SQL Server, Oracle). Dedicated Hosts can be significantly expensive but are required for certain software licensing agreements. Dedicated Instances are a lighter version — instances run on hardware dedicated to your account but you do not control the specific host. Neither is recommended purely for security isolation (use VPC isolation and SGs instead); they are licensing compliance tools.

# Allocate Dedicated Host for Oracle licensing
aws ec2 allocate-hosts \
  --quantity 1 \
  --instance-type m5.xlarge \
  --availability-zone us-east-1a \
  --auto-placement on \
  --host-recovery on

# Dedicated Host pricing is per host per hour
# Dedicated Instances: $2/region/hr + instance price

# Use Dedicated Host when:
# - Oracle/SQL Server socket-based licensing
# - Windows Server with own license
# - Compliance requires physical server isolation

Quick Check

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

Lesson Recap

In this lesson you learned: Savings Plans are more flexible than Reserved Instances and apply to EC2, Lambda, and Fargate, Spot Instances provide up to 90% savings for interruption-tolerant workloads, and combining Savings Plans for baseline with Spot for burst achieves maximum cost optimisation. Monitor utilisation of your commitments to ensure you are using what you paid for. Next up we explore Cost Explorer, Budgets, and cost allocation tags.

Frequently asked questions

Is the “Reserved Instances, Savings Plans, and Spot” lesson free?

Yes — the full text of “Reserved Instances, Savings Plans, and Spot” is free to read here on the web, and the AWS Solutions Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the AWS Solutions Architect course, upgrade to CoddyKit PRO.

What will I learn in “Reserved Instances, Savings Plans, and Spot”?

Commit to Reserved Instances or Savings Plans for steady workloads and use Spot Instances for interruption-tolerant batch and stateless tasks. You practise AWS Solutions Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start AWS Solutions Architect?

No prior experience is required. AWS Solutions Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Reserved Instances, Savings Plans, and Spot” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this AWS Solutions Architect lesson?

Yes. Every AWS Solutions Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Right-Sizing and Compute Optimizer
  2. Reserved Instances, Savings Plans, and Spot
  3. Cost Explorer, Budgets, and Cost Allocation Tags
  4. S3 and Data Transfer Cost Optimisation
← Back to AWS Solutions Architect