Purchasing Options: On-Demand to Spot

By the end of this lesson you will be able to

• Explain how On-Demand, Reserved Instances, Savings Plans, Spot, Dedicated Hosts, Dedicated Instances and Capacity Reservations are billed, and what each one promises.
• Choose between Standard and Convertible Reserved Instances, the payment options, and Regional vs zonal scope.
• Pick the right Savings Plan (Compute, EC2 Instance, SageMaker AI, Database) and size the hourly commitment.
• Run Spot Instances safely: handle the rebalance recommendation and the two-minute notice, choose the interruption behaviour, and cancel a persistent request the right way.
• Choose a Spot Fleet or EC2 Fleet allocation strategy and explain why price-capacity-optimized is the default advice.
• Combine several options in one architecture, and answer the classic exam keywords (steady state, fault-tolerant, BYOL, capacity assurance).

#Same server, different prices

An m7i.large in one Region is the same virtual machine whichever way you pay for it. What changes is the deal you strike with AWS:

• How long you promise to keep using it (nothing, 1 year, 3 years).
• How much you pay before you start (nothing, part, everything).
• Whether AWS may take the server back (Spot) or must keep room for you (Capacity Reservations).
• Whether the physical machine is shared with other customers (default tenancy) or only yours (Dedicated).

The more certainty you give AWS, and the more risk you accept, the lower your price. Seven options come out of those four questions:

#On-Demand: pay as you go

On-Demand is what you get when you launch an instance and choose nothing else.

• Billing: per second, with a 60-second minimum, for Linux, Windows (including Windows with SQL Server), Red Hat Enterprise Linux (RHEL) and Ubuntu Pro. A few other operating systems, mostly commercial Linux distributions with their own licence fee, are still billed per full hour.
• You pay only while the instance is running. A stopped instance costs nothing for compute, but its EBS volumes are still billed.
• No upfront payment, no commitment, and the highest price per hour.
• Best for short-term, spiky or unpredictable workloads, for new applications whose behaviour you do not know yet, for development and testing, and for work that cannot be interrupted but does not run long enough to justify a commitment.

#Reserved Instances (RI)

A Reserved Instance is not a server. It is a billing discount that AWS applies automatically, every hour, to running instances that match it. You buy it for:

• an instance type (for example m7i.large), a platform (Linux, Windows…), a tenancy (default or dedicated) and a Region (plus an Availability Zone if it is zonal);
• a term of exactly 1 year or 3 years (3 years gives the bigger discount);
• a payment option: No Upfront, Partial Upfront or All Upfront (the more you pay at the start, the lower the total).

If no matching instance runs in a given hour, that hour of the reservation is simply wasted. You pay for the whole term either way.

#Standard vs Convertible

Choose Standard when you are sure what you will run for the whole term, Convertible when you want the commitment discount but expect to change instance families (for example, moving to a newer generation or to Graviton).

#Regional vs zonal scope

So a zonal RI is a discount and a capacity promise in one zone; a Regional RI is a more flexible discount with no capacity promise.

#The Reserved Instance Marketplace

If your plans change, you can sell unused Standard RIs to other customers on the Reserved Instance Marketplace, and you can buy someone else’s leftover term there (often shorter than 1 year). The rules worth knowing: only Standard RIs can be sold (never Convertible), you must have owned the RI for at least 30 days, at least one month of the term must remain, and AWS keeps a service fee from the sale.

#Savings Plans

A Savings Plan is a commitment to spend a fixed amount of money per hour (for example “$10 per hour of compute”) for 1 or 3 years. Every hour:

1. AWS applies your discounted rates to eligible usage until the hour’s commitment is used up.
2. Usage above the commitment is billed at normal On-Demand rates.
3. Commitment not used in that hour is lost: you pay the full hourly amount even if you ran nothing.

Payment options are the same as RIs: No, Partial or All Upfront (Database Savings Plans are the exception, see below). A Savings Plan cannot be sold or cancelled, and it never reserves capacity.

The trade-off is the same as for RIs: more flexibility, smaller discount. A Compute Savings Plan follows you if you move from x86 to Graviton, from EC2 to Fargate or from one Region to another; an EC2 Instance Savings Plan gives a few points more discount but stays with one family in one Region.

#Spot Instances

Spot Instances use spare EC2 capacity that nobody is paying full price for right now. Because AWS can take it back when On-Demand customers need it, it is sold at up to about 90% off the On-Demand price.

#How the Spot price is set

#Interruptions: the two signals

AWS interrupts a Spot Instance mostly because it needs the capacity back, much more rarely because the price rose above your maximum. Before it happens you may get two signals, both readable from instance metadata and both published as EventBridge events:

1. Rebalance recommendation: “this instance is now at elevated risk.” It often arrives earlier than the interruption notice, but it is not guaranteed. Auto Scaling groups and EC2 Fleet can react with Capacity Rebalancing: launch a replacement first, then drain the old instance.
2. Interruption notice: sent two minutes before AWS stops or terminates the instance. With the hibernate behaviour the notice is sent too, but hibernation starts at once, with no two-minute grace.

Both signals are sent on a best-effort basis, so AWS suggests checking instance metadata every few seconds, and the design must still survive an instance that vanishes without warning. Two minutes is enough to finish a request, save a checkpoint or deregister from a load balancer. It is not enough to finish an hour-long job, which is why Spot workloads must be able to resume or retry.

#Interruption behaviour: terminate, stop or hibernate

#One-time vs persistent requests

Every Spot Instance comes from a Spot request:

• A one-time request launches the instance once. When the instance is interrupted or terminated, the request is closed and nothing comes back.
• A persistent request stays open for as long as it is valid. If the instance is interrupted, or you terminate it, the request launches (or restarts) another one.

#What Spot is good for

The keywords from the exam are worth memorising: fault-tolerant, flexible start and end times, batch jobs, data analysis, image or media processing, build and test agents, stateless web servers behind a load balancer, big data and container clusters. If the job can stop and start again without losing anything important, it can run on Spot.

The owner’s notes give a classic scenario line: “an application performing big data analysis on a fleet of EC2 instances”. When the last line asks for the cheapest way to run that fleet, the answer is Spot Instances / Spot Fleet: the analysis is a batch job, and if one or two servers disappear mid-way another one simply redoes their part. (The same scenario also asks about placement, instance type and storage; those answers are in lessons 4.1, 4.5 and the EC2 storage chapter.)

#Spot Fleet and EC2 Fleet

Asking for one instance type in one zone is the riskiest way to use Spot: if that pool runs short, every instance you have goes at once. A fleet asks for a target capacity (a number of instances, or of virtual CPUs or memory) and gives AWS a list of acceptable launch pools: several instance types across several Availability Zones. It can also mix in On-Demand instances as a guaranteed base. The fleet keeps launching until it reaches the target capacity or your maximum total price, and with type maintain it replaces interrupted instances.

The allocation strategy decides which pools the Spot part uses:

#Dedicated Hosts and Dedicated Instances

Normal instances, whatever you pay, use shared tenancy: your virtual machine is one slice of a large physical server, and other customers’ machines may run beside it. You never learn how many physical sockets or cores that server has.

That is a problem for some enterprise software. Vendors such as Oracle or Microsoft (Windows Server, SQL Server) may license by physical socket or physical core, not by virtual CPU. To bring your own licence (BYOL) you must be able to see and count that hardware. The owner’s notes call this one of the most common and trickiest exam questions:

A vendor licence for a database bills by physical cores and socket visibility. Which purchasing option gives that visibility? → Dedicated Hosts.

Dedicated Hosts are the most expensive way to run EC2, so they only make sense when licensing or compliance demands them.

#On-Demand Capacity Reservations (ODCR)

A Capacity Reservation keeps room for a number of instances of one type, platform and tenancy in one Availability Zone, starting now (or on a future date) and lasting as long as you want:

• No term: create it, cancel it any time (future-dated reservations carry a minimum commitment period you choose when you book).
• Charged at the On-Demand rate whether you run instances in it or not: an empty reservation costs exactly as much as a full one.
• No discount by itself. To lower the price, combine it with Regional Reserved Instances or Savings Plans: their discount applies to the instances in the reservation.
• Instances use it automatically (open matching) or only when they name it (targeted matching).

For short-term GPU needs (training a model for a few days), EC2 Capacity Blocks reserve GPU instances for a set period, paid in advance.

#How to choose

#Mixing options in one architecture

Real systems combine several options. A typical online shop:

• Web tier in an Auto Scaling group: a few On-Demand instances as the always-on base, covered by a Compute Savings Plan; extra instances for busy hours on Spot, spread over many instance types with price-capacity-optimized. If a Spot instance is interrupted, the load balancer simply sends traffic to the others.
• Database: never Spot. On EC2, a 3-year Reserved Instance; on a managed service, its own reservations or a Database Savings Plan.
• Nightly reports and image processing: Spot, with checkpoints to S3.
• A big sale day: Capacity Reservations in two Availability Zones for that week, discounted by the existing Savings Plan.
• A licensed commercial database billed per core: a Dedicated Host.

The rule of thumb: commit to the baseline, use Spot for what can be interrupted, pay On-Demand for the rest.

#Try it yourself

# 1. Recent Spot prices for one instance type in every AZ of the Region
aws ec2 describe-spot-price-history \
  --instance-types m7i.large \
  --product-descriptions "Linux/UNIX" \
  --start-time "$(date -u -d '-1 day' +%Y-%m-%dT%H:%M:%S)" \
  --query 'SpotPriceHistory[].[AvailabilityZone,SpotPrice,Timestamp]' --output table

# 2. Launch one Spot instance from a persistent request that stops (not terminates) when interrupted
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 --instance-type m7i.large --count 1 \
  --instance-market-options '{"MarketType":"spot","SpotOptions":{"SpotInstanceType":"persistent","InstanceInterruptionBehavior":"stop"}}'

# 3. Find the request behind the instance, then CANCEL THE REQUEST FIRST, then terminate
SIR=$(aws ec2 describe-instances --instance-ids i-0abc1234def567890 \
  --query 'Reservations[0].Instances[0].SpotInstanceRequestId' --output text)
aws ec2 cancel-spot-instance-requests --spot-instance-request-ids "$SIR"
aws ec2 terminate-instances --instance-ids i-0abc1234def567890

# 4. Compare 1-year Standard RI offerings (31536000 seconds = 1 year)
aws ec2 describe-reserved-instances-offerings \
  --instance-type m7i.large --product-description "Linux/UNIX" \
  --offering-class standard --instance-tenancy default \
  --min-duration 31536000 --max-duration 31536000 \
  --query 'ReservedInstancesOfferings[].[OfferingType,Scope,FixedPrice,RecurringCharges[0].Amount]' --output table

# 5. Reserve capacity for two instances in one AZ (billed at On-Demand rate until cancelled)
CR=$(aws ec2 create-capacity-reservation \
  --instance-type m7i.large --instance-platform Linux/UNIX \
  --availability-zone us-east-1a --instance-count 2 \
  --instance-match-criteria open --query 'CapacityReservation.CapacityReservationId' --output text)
aws ec2 cancel-capacity-reservation --capacity-reservation-id "$CR"   # stop paying for it

In step 2, a persistent request launched by run-instances must use the stop or hibernate behaviour. If you skip step 3’s cancel and only terminate the instance, check the console a minute later: the request launches a new one.

#Summary

Key takeaways

• On-Demand: no commitment, highest price, per-second billing (60-second minimum) for Linux, Windows, RHEL and Ubuntu Pro; does not guarantee capacity.
• Reserved Instances: a billing discount for 1 or 3 years on one configuration, up to about 72% (Standard) or 66% (Convertible). No/Partial/All Upfront. Zonal RIs also reserve capacity; Regional RIs give size flexibility but no capacity. Only Standard RIs can be sold on the Marketplace.
• Savings Plans: commit $/hour for 1 or 3 years; usage above it is On-Demand, unused commitment is lost. Compute (EC2 anywhere + Fargate + Lambda, up to ~66%), EC2 Instance (one family in one Region, up to ~72%), SageMaker AI, Database (1 year, no upfront). No capacity reservation.
• Spot: spare capacity, up to ~90% off, price set by long-term supply and demand (no bidding). Rebalance recommendation (early, not guaranteed), then a two-minute interruption notice. Terminate (default), stop or hibernate (stop/hibernate need a persistent request). Cancel a persistent request before terminating its instances. Never for databases.
• Fleets: many pools, optional On-Demand base; price-capacity-optimized is the recommended strategy, lowest-price the riskiest.
• Dedicated Hosts: a whole server, sockets/cores visible, BYOL, placement control, most expensive. Dedicated Instances: no hardware shared with other accounts, nothing more.
• Capacity Reservations: capacity in one zone, any duration, full On-Demand price whether used or not; add Savings Plans or Regional RIs for a discount.
• Commit to the baseline, Spot for the interruptible part, On-Demand for the rest.

Self-check: EC2 purchasing options32 questions