Lesson 194 · AWS Learning Path

AWS 194: Savings Plans, Reserved Instances and Spot

Anil Jalela · Published Jan 5, 2026 · 8 min read

Why this lesson matters

Separate billing commitments, RI capacity benefits, Spot interruption, and workload scheduling from instance tenancy and architecture availability.

What you will be able to do

By the end, you can:

• explain savings plans, reserved instances and spot in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+------------------------------------------------+
|  Workload baseline and interruption tolerance  |
+------------------------------------------------+
                        |
                        v
+-------------------------------+
|  Purchase or capacity option  |
+-------------------------------+
               |
               v
+----------------------+
|    Eligible usage    |
+----------------------+
           |
           v
+-----------------------------------------------------------------+
|  Utilization, coverage, interruption, and replacement evidence  |
+-----------------------------------------------------------------+

Separate price commitment from capacity and interruption

Savings Plans and most Reserved Instance benefits are billing discounts; they do not launch resources or reserve capacity. EC2 Capacity Reservations reserve capacity but do not by themselves create a term discount. Spot uses spare capacity at a variable discounted price and can be interrupted. Combining a matching Capacity Reservation with eligible discount coverage is a deliberate two-control design.

Current Savings Plans also include service-specific families such as SageMaker AI. Always verify current eligible services, term/payment options and offering rules; plan families have evolved.

Coverage, utilization and commitment sizing

Commitment is consumed every hour whether matching usage exists or not and generally cannot be canceled casually. Buy only the durable baseline after rightsizing and removing waste. Model seasonality, migrations, Graviton adoption, Region changes, licensing and business decline.

• Utilization = how much purchased commitment was consumed. Low utilization means paid commitment waste.
• Coverage = how much eligible usage received a benefit. Low coverage means On-Demand exposure.
• Savings versus On-Demand is not cash savings if the workload would have been stopped, rightsized or removed.

Use Cost Explorer recommendations as input, not approval. Examine lookback period, hourly spend distribution and risk tolerance; layer commitments incrementally and retain On-Demand headroom. In consolidated billing, benefit sharing and payer settings affect which account receives discounts, so allocate amortized cost transparently.

Spot architecture

Spot interruption notice is short and not guaranteed enough time to complete arbitrary work. Design queue-backed/idempotent jobs, checkpointing, graceful termination handling, stateless services and mixed capacity. Diversify across instance types, sizes and AZs using attribute-based selection or flexible fleets; avoid a single cheap pool. Capacity-optimized strategies reduce interruption risk compared with choosing price alone.

Set Auto Scaling base/percentage strategy so required baseline can remain On-Demand while burst uses Spot. Protect critical control nodes and quorum-sensitive state. Test interruption, rebalance, duplicate delivery and partial work. Spot is inappropriate when one uninterrupted instance is the application.

Capacity and discount combinations

Use On-Demand Capacity Reservations for strict launch assurance in an AZ, targeted or open according to ownership. Savings Plans can discount eligible usage inside a reservation when attributes match, but unused reservation capacity may still cost. Regional RIs normally give size-flexible billing benefits under rules; zonal RIs tie attributes and capacity benefit more tightly. Never claim capacity from a billing report - inspect reservation matching and instance placement.

Architecture decision table

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open Cost Management, Savings Plans inventory, EC2 Reserved Instances, Spot requests and pricing history; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws savingsplans describe-savings-plans --query 'savingsPlans[].{Id:savingsPlanId,Type:savingsPlanType,State:state,Commitment:commitment,End:end}' --output table
aws ec2 describe-reserved-instances --filters Name=state,Values=active --output table
aws ec2 describe-spot-instance-requests --output table
aws ec2 describe-spot-price-history --instance-types m7g.large --product-descriptions 'Linux/UNIX' --max-items 20 --output table

Expected interpretation

Savings Plans and RIs can reduce eligible compute cost but create underuse risk. Spot is spare capacity that can interrupt; its architecture must checkpoint, diversify, and replace.

Practical work

Classify steady web baseline, variable API, nightly fault-tolerant batch, stateful database, and emergency capacity. Choose On-Demand, commitment, Spot, and any capacity reservation separately.

Diagnose this topic from its own evidence

• High commitment cost with low savings: inspect hourly utilization, eligibility, sharing, plan attributes and rightsizing changes.
• High utilization but high On-Demand spend: coverage is low; assess stable uncovered baseline rather than buying from one peak.
• Capacity launch fails despite Savings Plan: it is not a reservation; inspect AZ capacity/reservation/quota and diversify.
• Spot churn: inspect pool concentration, allocation strategy, instance requirements, interruption handling and checkpoint interval.
• Team disputes cost: use amortized/net allocation and document payer discount-sharing policy.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Separate billing commitments, RI capacity benefits, Spot interruption, and workload scheduling from instance tenancy and architecture availability.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Savings Plans, Reserved Instances, and Spot.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Savings Plans, Reserved Instances, and Spot.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid buying in a training account, treating a discount as capacity, or running irreplaceable state only on Spot.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

• Distinguish billing discount, capacity reservation and interruptible capacity.
• Compare current Compute, EC2 Instance and Database Savings Plans with RI and Spot choices.
• Calculate utilization versus coverage and size only the durable baseline.
• Design diversified interruption-tolerant Spot capacity with tested idempotency/checkpointing.
• Explain consolidated-billing allocation, amortization and commitment risk.

Official sources

• Savings Plans
• Savings Plans types
• EC2 purchase options