What Is an EC2 Spot Instance and How Are Discounts Set?

An Amazon EC2 Spot Instance is a purchasing option in Amazon Web Services that allows users to utilize spare compute capacity in the AWS cloud at steep discounts of up to ninety percent compared to standard On-Demand rates. This article explores the architecture of EC2 Spot Instances, the trade-offs involving two-minute interruption notices when AWS reclaims capacity, the long-term supply and demand algorithms that govern Spot pricing, and the exact mathematical methods used to calculate cost savings relative to On-Demand pricing.

Understanding Amazon EC2 Spot Instances

Amazon Elastic Compute Cloud (EC2) must maintain significant spare hardware capacity across all its global regions and Availability Zones to ensure that customers can launch On-Demand Instances whenever sudden traffic spikes occur. Rather than letting those idle servers sit unused, AWS offers this excess compute capacity as Spot Instances.

Functionally, a Spot Instance runs on the exact same physical infrastructure and offers identical performance, security, and configuration capabilities as an On-Demand or Reserved Instance. The critical distinction lies in the availability contract:

On-Demand Instances: You pay a fixed hourly or per-second rate and retain control of the instance until you explicitly terminate it.
Spot Instances: You pay a discounted, variable rate for unused capacity, but AWS can reclaim the instance at any time if capacity runs low for On-Demand or Reserved Instance customers.

When AWS needs to reclaim a Spot Instance, it issues a Spot Instance interruption notice exactly two minutes before terminating, stopping, or hibernating the instance. This two-minute window is broadcast via Amazon EventBridge and is also accessible directly from the instance metadata service at http://169.254.169.254/latest/meta-data/spot/instance-action.

Capacity Pools as the Unit of Allocation

To understand how Spot Instances are allocated and priced, you must understand Spot capacity pools. A Spot capacity pool is a set of unused EC2 instances that share the same:

Instance Type (for example, c6i.xlarge or m5.2xlarge)
Operating System (Linux/UNIX, Windows, Red Hat Enterprise Linux, or SUSE Linux)
Availability Zone (for example, us-east-1a vs. us-east-1b)

Each Spot capacity pool operates independently. For example, a c6i.xlarge running Linux in us-east-1a belongs to a completely separate capacity pool than a c6i.xlarge running Linux in us-east-1b. Both its spare capacity levels and its hourly Spot price fluctuate independently based on the specific supply and demand within that exact pool.

How Spot Pricing and Discounts Are Determined

Historically, prior to late 2017, EC2 Spot pricing operated like a real-time auction where customers placed competitive bids and prices spiked unpredictably whenever immediate demand exceeded supply. If the market price rose above a customer's maximum bid, their instance was terminated.

Under the modern EC2 Spot pricing model, Spot prices are set by Amazon EC2 and adjust gradually based on long-term trends in supply and demand for spare capacity within each specific Spot capacity pool, rather than real-time bidding wars.

Key Factors Driving the Spot Price

Long-Term Pool Supply and Demand: AWS evaluates historical and gradual shifts in how much spare capacity exists in an Availability Zone for a given instance family and how heavily customers are requesting that pool. Prices change slowly over days or weeks rather than minutes, providing predictable cost structures.
No Bidding Required: While you can still specify a maximum price you are willing to pay (capped at the On-Demand price by default), you never pay your maximum specified limit. Instead, every customer running in the same Spot capacity pool pays the exact same current Spot price in effect for that hour or second.
Capacity Reclaims Over Price Spikes: In the current pricing model, interruptions almost never occur because the price crossed a threshold. Instead, interruptions happen strictly when AWS runs out of spare physical hardware in that pool because On-Demand or Reserved Instance demand surged.
Generation and Regional Maturity: Older-generation instance types or regions with massive infrastructure footprints often have deeper reserves of spare capacity, leading to deeper and more stable Spot discounts (frequently reaching $70\%$ to $90\%$ off On-Demand). Newer or specialized GPU instances with high demand and tight supply typically exhibit smaller discounts (such as $30\%$ to $50\%$ off On-Demand).

Mathematical Formulation of the Spot Discount

Let $P_{\text{OD}}$ represent the fixed hourly On-Demand price for a given instance type and operating system in a region, and let $P_{\text{Spot}}(p, t)$ represent the Spot price for a specific capacity pool $p$ at time $t$.

The instantaneous Spot discount percentage $D(p, t)$ relative to On-Demand pricing is calculated as:

\[D(p, t) = \left( \frac{P_{\text{OD}} - P_{\text{Spot}}(p, t)}{P_{\text{OD}}} \right) \times 100\%\]

Equivalently, this can be expressed as:

\[D(p, t) = \left( 1 - \frac{P_{\text{Spot}}(p, t)}{P_{\text{OD}}} \right) \times 100\%\]

Conversely, if you know the current advertised discount percentage $D(p, t)$ for a pool, the effective hourly rate $P_{\text{Spot}}(p, t)$ is:

\[P_{\text{Spot}}(p, t) = P_{\text{OD}} \times \left( 1 - \frac{D(p, t)}{100} \right)\]

Calculating Total Workload Cost and Savings

For Linux and Ubuntu instances, EC2 Spot Instances are billed in one-second increments with a $60\text{-second}$ minimum. Suppose a fleet runs $N$ instances across $K$ distinct capacity pools over a workload duration, where instance $i$ in pool $p_i$ runs for $T_i$ seconds (where $T_i \ge 60$). Assuming the gradual Spot price $P_{\text{Spot}}(p_i)$ remains constant during the job execution, the total Spot cost $C_{\text{Spot}}$ is:

\[C_{\text{Spot}} = \sum_{i=1}^{N} P_{\text{Spot}}(p_i) \times \left( \frac{T_i}{3600} \right)\]

The equivalent On-Demand cost $C_{\text{OD}}$ for the exact same runtime is:

\[C_{\text{OD}} = \sum_{i=1}^{N} P_{\text{OD}}(p_i) \times \left( \frac{T_i}{3600} \right)\]

The net monetary savings $S$ achieved by utilizing Spot capacity is therefore:

\[S = C_{\text{OD}} - C_{\text{Spot}} = \sum_{i=1}^{N} \left( P_{\text{OD}}(p_i) - P_{\text{Spot}}(p_i) \right) \times \left( \frac{T_i}{3600} \right)\]

Numerical Example

Consider a general-purpose m6i.xlarge Linux instance in us-east-1 with an On-Demand price of:

\[P_{\text{OD}} = \$0.192 \text{ per hour}\]

Suppose the current Spot prices across three Availability Zones in that region are:

us-east-1a: $P_{\text{Spot}} = \$0.0672 \text{ per hour}$
us-east-1b: $P_{\text{Spot}} = \$0.0576 \text{ per hour}$
us-east-1c: $P_{\text{Spot}} = \$0.0768 \text{ per hour}$

Using the discount formula for us-east-1b:

\[D(\text{us-east-1b}) = \left( 1 - \frac{0.0576}{0.192} \right) \times 100\% = (1 - 0.30) \times 100\% = 70\%\]

If you run a distributed data processing cluster of $N = 50$ instances in us-east-1b for $10\text{ hours}$ ($36000\text{ seconds}$):

\[C_{\text{OD}} = 50 \times \$0.192 \times 10 = \$96.00\]

\[C_{\text{Spot}} = 50 \times \$0.0576 \times 10 = \$28.80\]

\[S = \$96.00 - \$28.80 = \$67.20\]

Note that if AWS interrupts a Spot Instance during the very first hour because of a capacity reclaim, AWS does not charge for that partial hour of usage prior to termination (though if you stop or terminate the instance yourself, standard per-second billing applies).

Best Practices for Maximizing Spot Discounts and Availability

Because both prices and interruption rates vary across capacity pools, relying on a single instance type in a single Availability Zone increases the risk of workload interruption. AWS recommends the following architectural strategies:

Instance Flexibility: Configure your Auto Scaling groups, Amazon EKS node groups, or EC2 Fleet to allow multiple compatible instance families and generations (for example, m5.xlarge, m5a.xlarge, m6i.xlarge, and m6a.xlarge).
Use the price-capacity-optimized Allocation Strategy: When launching Spot Instances via EC2 Auto Scaling or EC2 Fleet, select the price-capacity-optimized strategy. This instructs AWS to automatically identify the deepest capacity pools with the lowest interruption risk first, and then choose the pools offering the lowest Spot price among those highly available options.
Respond to Rebalance Recommendations: Before the mandatory two-minute interruption notice is issued, EC2 emits an EC2 Instance Rebalance Recommendation signal when a Spot Instance is at an elevated risk of interruption. Orchestration tools like Karpenter or AWS Node Termination Handler can listen for this early warning to proactively provision a replacement Spot Instance in a healthier pool and drain workloads gracefully before the two-minute clock even begins.