AWS Spot Instance Price History: How to See 90 Days of Prices (Console, CLI, Python), Today's Real Savings, and Why the Cheapest Type Is Often the Most Interrupted

AWS Spot Instance price history shows what each instance type cost on Spot in each Availability Zone over the last 90 days, no further. You can see it in the EC2 console (Spot Requests, Pricing history), with aws ec2 describe-spot-price-history, or with boto3. Since 2017, Spot prices no longer jump around with bidding; AWS sets them and they change gradually with long-term supply and demand, so the history is mostly flat lines with occasional steps, and you never pay more than the On-Demand price. The surprise is that price is the less important number. What decides whether Spot works for you is how often an instance type gets interrupted, and in US East (N. Virginia) on October 22, 2026, AWS's Spot Instance Advisor puts 468 of 1,145 Linux instance types (41 percent) in its highest bucket, more than 20 percent interrupted per month, including popular choices like m5.large and c7i.large, while t3.large and i4i.large sit under 5 percent at similar or better discounts. So to choose well, look up the price history and the interruption rate together, be flexible across several instance types, and let an Auto Scaling group or EC2 Fleet with the price-capacity-optimized strategy pick for you. This page shows how to read both, with today's real numbers.

Jake's shop renders short repair videos for customers every night, a job that runs for an hour and can be restarted, and Ethan wanted it on Spot. He opened the price history, found the cheapest instance type in the list, and set it up. Three nights in a row the job was interrupted halfway. "Cheapest is not cheap if it never finishes," Jake said, reading the morning report. "And the cheapest pool is where everyone else goes too," Ethan said. This page is how Ethan picked the second time, using two numbers instead of one.

New to Spot? EC2 sells its spare capacity as Spot Instances at a large discount, with one condition: when EC2 needs the capacity back, it interrupts your instance with a two-minute warning. That makes Spot ideal for work that can stop and resume (batch jobs, rendering, CI builds, containers behind a load balancer) and a poor fit for a single database. Our pricing model decision tree compares Spot with Savings Plans and Reserved Instances.

How Spot pricing works today

A few facts make the price history make sense:

• AWS sets the price. Spot prices are set by Amazon EC2 and adjust gradually based on long-term trends in supply and demand. There is no auction and no bidding war; the dramatic spikes in old blog posts belong to the pricing model AWS replaced in 2017.
• Each pool has its own price. A Spot capacity pool is one instance type in one Availability Zone (with one operating system). m7i.large in us-east-1a and in us-east-1b are different pools with separate prices and separate availability.
• You pay the current Spot price for the pool your instance runs in, never more than the On-Demand price for that type.
• A maximum price is optional: by default it is the On-Demand price. Setting a lower maximum can stop your request from being fulfilled at all when the Spot price is above it, and does not make interruptions less likely, so most teams leave it at the default.
• Interruptions are about capacity, not price. EC2 reclaims Spot capacity when it needs it for On-Demand or other demand in that pool. A price that has not moved in weeks can sit next to frequent interruptions.

See the price history in the console

1. Open the Amazon EC2 console and choose the Region.
2. In the navigation pane, choose Spot Requests, then Pricing history.
3. For Graph, choose to compare by Availability Zones (one instance type across zones) or by Instance Types (up to five types in one zone).
4. Choose the instance type or types, the operating system (Platform) and the Date range, up to the last 90 days.
5. Hover over the graph to read the price at a point in time; the information blocks above the graph show that price and the average over the selected range.
6. Toggle Display normalized prices to see the price per vCPU, which is the fair way to compare a large with an xlarge.

The per-vCPU view is worth using whenever you compare across sizes or families: a bigger instance can be cheaper per vCPU on Spot, and if your work can use more cores per instance, fewer, larger instances may cost less in total.

Get the history from the CLI and Python

The CLI returns every price change in the range, newest first, for the types, zones and operating systems you filter on:

aws ec2 describe-spot-price-history \
  --region us-east-1 \
  --instance-types m7i.large c7g.large \
  --product-descriptions "Linux/UNIX" \
  --start-time $(date -u -d '-7 days' +%Y-%m-%dT%H:%M:%SZ) \
  --query "SpotPriceHistory[].[Timestamp,AvailabilityZone,InstanceType,SpotPrice]" \
  --output table

The product description must match exactly: Linux/UNIX, Red Hat Enterprise Linux, SUSE Linux or Windows (with "(Amazon VPC)" variants for older listings). When you give a start time, the response also includes the last price change before it, which is the price in effect at the start of your range; a pool whose price did not change in the range shows just that one record. For a summary per pool, this boto3 script collects 30 days and prints the minimum, average and maximum:

import boto3, statistics
from datetime import datetime, timedelta, timezone

ec2 = boto3.client("ec2", region_name="us-east-1")
start = datetime.now(timezone.utc) - timedelta(days=30)

prices = {}   # (instance type, AZ) -> list of prices
pages = ec2.get_paginator("describe_spot_price_history").paginate(
    InstanceTypes=["m7i.large", "c7g.large", "m5.large"],
    ProductDescriptions=["Linux/UNIX"],
    StartTime=start,
)
for page in pages:
    for p in page["SpotPriceHistory"]:
        prices.setdefault((p["InstanceType"], p["AvailabilityZone"]), []).append(float(p["SpotPrice"]))

for (itype, az), vals in sorted(prices.items()):
    print(f"{itype:12} {az:12} min {min(vals):.4f}  avg {statistics.mean(vals):.4f}  max {max(vals):.4f}  changes {len(vals)}")

This average counts each price change equally rather than weighting by how long each price lasted, which is fine for spotting cheap and stable pools; for exact cost forecasts, weight by duration. In PowerShell, Get-EC2SpotPriceHistory -InstanceType m7i.large -ProductDescription "Linux/UNIX" does the same. You need the ec2:DescribeSpotPriceHistory permission, which most read-only policies include.

What Spot costs today: real us-east-1 numbers

Here is a snapshot for common types: the Spot price shown for US East (N. Virginia) on AWS's Spot pricing page on October 22, 2026, the On-Demand price from the EC2 price list published October 15, 2026, and the interruption bucket from the Spot Instance Advisor the same day. All Linux, per hour:

Read it two ways. On price alone, everything is a bargain: 40 to 78 percent off. On interruptions, the list splits: t3.large and i4i.large rarely get interrupted, while m5.large, c7i.large and r7i.large, some of the most popular general-purpose and compute types, are in the highest bucket. For a job that must finish in one piece, t3.large at 71 percent off with under 5 percent interruptions is a better deal than c7i.large at 66 percent off with more than 20 percent. Spot prices and interruption rates change, so treat this as a snapshot of how to read the numbers, not a price list to plan a year on.

Notice also that the savings column alone would point you to i4i.large and t3.micro, which are good deals only if they suit your work: i4i is a storage-optimized type with local NVMe disks, priced for that, and t3 types are burstable, which matters for sustained CPU work, as the worked selection below shows.

The same instance type in other Regions

Spot prices differ between Regions as much as between instance types. For m7i.large Linux on October 22, 2026, the Spot price shown per Region was:

• US East (Ohio): $0.0287 per hour
• US West (Oregon): $0.0404
• US East (N. Virginia): $0.0407
• Asia Pacific (Mumbai): $0.0478
• Europe (Ireland): $0.0679

Ohio was about 30 percent cheaper than Virginia for the same instance that day. If your workload does not depend on where it runs (rendering, batch processing, CI builds whose results go to S3), running it in a cheaper, calmer Region can beat any instance-type trick. Check the price history with --region set to each candidate, compare Spot placement scores across Regions, and remember data transfer: moving large inputs and outputs between Regions costs money, which can cancel the saving for data-heavy jobs.

The Spot Instance Advisor: the number that matters more

The Spot Instance Advisor (on the AWS website, under EC2 Spot) shows, for each Region, operating system and instance type, the average saving over On-Demand and the frequency of interruption: how often Spot reclaimed capacity for that type over the past month, in five buckets, <5%, 5-10%, 10-15%, 15-20% and >20%. It also shows the vCPUs and memory of each type, so you can filter to what your workload needs.

The distribution in US East (N. Virginia), Linux, on October 22, 2026, across 1,145 instance types:

• <5%: 239 types
• 5-10%: 192 types
• 10-15%: 121 types
• 15-20%: 125 types
• >20%: 468 types

The overall average across all Regions and types is reported as under 10 percent, but the spread between types is what matters for you: the popular, newest-generation general-purpose types in the biggest Region are often the most contested, and older, larger, storage-optimized or less fashionable types are often the calmest. The advisor is the fastest way to find the calm ones, and the price history then tells you whether their price is stable.

Reading the price history: what a "good" pool looks like

When you look at 90 days for a few candidate pools, look for three things:

• A flat line well below On-Demand: a stable discount. Most pools look like this most of the time.
• Steps upward that stay up: demand in that pool is rising. Recent steps are a warning sign that interruptions may be rising too.
• Differences between zones: the same type can be noticeably cheaper in one Availability Zone. If your workload is not tied to a zone, the cheapest stable zone is worth using; if it is (data in one zone, for example), check that zone specifically.

It also helps to compare like with like. Look at the same 90-day window for every candidate, use normalized (per-vCPU) prices when sizes differ, and note the date you looked, because a pool that was calm in August can be crowded in October after a large customer moves in. Do not read the price as a forecast of interruptions. A pool can be both cheap and busy, which is exactly what Ethan's first choice was. Use the price history to estimate cost and to spot trends, the advisor to estimate interruptions, and a placement score (next section) to check that capacity exists for the size you want right now.

Spot vs On-Demand vs Savings Plans vs Reserved Instances

Most cost-conscious setups use all three: a Savings Plan for the base that never turns off, On-Demand for the critical part that must not be interrupted, and Spot for everything that can restart. The decision tree guide walks through the split.

A quick worked example of what Spot means for a bill: ten m7i.large instances running all month (730 hours) in US East (N. Virginia) cost 10 × $0.1008 × 730 = $735.84 On-Demand, and 10 × $0.0407 × 730 = $297.11 at that day's Spot price, a saving of about $439 a month. In US East (Ohio) at $0.0287, the same fleet would be about $209.51.

Spot placement scores: will my request actually be filled?

A Spot placement score estimates, on a scale from 1 to 10, how likely it is that a Spot request of a given size will succeed in a Region or Availability Zone. You give it your requirements (instance types or vCPU and memory attributes, and the target capacity), and it rates the Regions or zones:

aws ec2 get-spot-placement-scores \
  --instance-types m7i.large c7i.large t3.large m6i.large \
  --target-capacity 10 \
  --single-availability-zone \
  --region-names us-east-1 us-east-2 us-west-2

Run it with the exact list of types you plan to use and the capacity you really need; a score for 2 instances says little about 200. A high score says capacity is likely available for that mix now; it is not a guarantee, and it changes over time. The score improves dramatically when you list more instance types, which is the clearest demonstration of the main Spot best practice: flexibility is what gets you capacity. If your workload can run in more than one Region, scores also tell you where to go when your usual Region is tight.

How to choose Spot pools so jobs finish

1. Describe what you need, not one type: for example "4 vCPUs, 8 to 16 GiB of memory, x86 or ARM". Attribute-based instance type selection in Auto Scaling groups and EC2 Fleet lets you specify exactly that.
2. List many types across families and generations that meet it, ideally ten or more. Every extra type is another set of pools to draw from.
3. Use every Availability Zone your workload can run in.
4. Launch through an Auto Scaling group or EC2 Fleet with the price-capacity-optimized allocation strategy, the recommended choice: it picks the pools with the most spare capacity and, among those, the lowest prices. (Spot Fleet is a legacy API; use EC2 Fleet or Auto Scaling instead.)
5. Handle interruptions: watch for the two-minute notice and the earlier rebalance recommendation, checkpoint long jobs, and let the group replace interrupted instances (our two-minute warning guide shows the handler).
6. Check the price history of the pools you ended up in after a week, to confirm your cost estimate.

For Jake's render job, Ethan listed eleven types with 4 vCPUs and at least 8 GiB, across x86 and ARM, in an Auto Scaling group with price-capacity-optimized and checkpoints every five minutes. The job has not lost a night since, and the average price paid came out within a cent of the cheapest type he had picked the first time. "So being less picky is cheaper," Jake said. "Being less picky is what gets you anything at all," Ethan said.

Launching Spot from the CLI: one instance and a mixed group

For a single instance, add the market options to an ordinary run-instances call. This asks for a one-time Spot Instance that terminates when interrupted:

aws ec2 run-instances   --image-id ami-0123456789abcdef0 --instance-type t3.large --count 1   --subnet-id subnet-0abc1234 --security-group-ids sg-0def5678   --instance-market-options 'MarketType=spot,SpotOptions={SpotInstanceType=one-time,InstanceInterruptionBehavior=terminate}'

Interruption behavior can be terminate, stop or hibernate; stop and hibernate need a persistent request (SpotInstanceType=persistent) and an EBS-backed instance, and EC2 restarts the instance when capacity returns. A single-type request like this is the simplest way to try Spot, and also the least reliable, because it can only use one pool.

For anything real, use an Auto Scaling group with a mixed instances policy. This keeps one On-Demand instance as a base, runs everything above it on Spot, and lets the group choose among several types:

resource "aws_autoscaling_group" "render" {
  name                = "render-workers"
  min_size            = 0
  max_size            = 10
  desired_capacity    = 2
  vpc_zone_identifier = [aws_subnet.a.id, aws_subnet.b.id, aws_subnet.c.id]

  mixed_instances_policy {
    instances_distribution {
      on_demand_base_capacity                  = 1
      on_demand_percentage_above_base_capacity = 0
      spot_allocation_strategy                 = "price-capacity-optimized"
    }
    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.render.id
        version            = "$Latest"
      }
      override { instance_type = "t3.large" }
      override { instance_type = "m7i.large" }
      override { instance_type = "m6i.large" }
      override { instance_type = "c7i.xlarge" }
      override { instance_type = "m5.large" }
    }
  }

  capacity_rebalance = true
}

capacity_rebalance = true tells the group to launch a replacement when an instance receives a rebalance recommendation, before the interruption itself. Mixing x86 and ARM types needs a launch template per architecture (set on each override), because the AMI differs. In the console, the same settings live under the group's Instance type requirements or Manually add instance types, with Spot and Price capacity optimized chosen under purchase options.

Watching for interruptions: metadata and EventBridge

Your instance can see its own interruption coming. Two metadata paths matter, read with an IMDSv2 token:

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 300")

# returns 404 until an interruption is scheduled, then the action and time
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/spot/instance-action

# appears earlier, when the instance is at elevated risk
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/events/recommendations/rebalance

A small loop that checks every few seconds and, on a notice, saves progress and stops taking new work is enough for most batch jobs. Outside the instance, EventBridge receives an EC2 Spot Instance Interruption Warning event and an EC2 Instance Rebalance Recommendation event, which you can route to a Lambda function or a queue to drain the instance from a load balancer or reschedule its work. Our two-minute warning guide builds that pipeline step by step.

Checkpointing so an interruption costs minutes, not hours

The single best defense against interruptions is making them cheap. A job that saves its progress every few minutes loses only those minutes when it is interrupted, and the replacement instance picks up where it stopped:

• Split work into small units (one video, one file, one batch of records) and record each finished unit in S3 or DynamoDB; on start, skip units already done.
• Save state on a timer for long computations, for example model checkpoints every few minutes to S3.
• Use a queue: workers take a message, process it, and delete it only when done; an interrupted worker's message becomes visible again for another worker.
• Keep instances disposable: no data that exists only on the instance, configuration from Parameter Store, logs shipped as they are written.

With these in place, the interruption frequency in the advisor becomes a cost factor rather than a risk, and you can use cheaper, busier pools with confidence.

Spot myths that cost people money

• "You have to bid." No bidding since 2017; you pay the current price.
• "Prices spike to 10 times On-Demand." They cannot exceed On-Demand.
• "Setting a lower maximum price protects me from interruptions." It does not; it only stops your request from launching when the price is above your maximum.
• "A stable price means few interruptions." Price and interruptions are separate; check the advisor.
• "The cheapest type is the best choice." The cheapest popular type is often the most contested; diversify.
• "Spot is only for huge companies." One restartable nightly job, like Jake's renders, is a perfectly good use.

The EC2 console's Spot Requests page also has a Savings summary that shows how much you have saved compared with On-Demand for your Spot usage, which is a useful number to show whoever pays the bill.

Spot for containers: EKS, ECS and Fargate

• EKS: managed node groups can use Spot capacity (with several instance types per group), and Karpenter can choose between Spot and On-Demand per node with its capacity type setting. Keep system components and anything stateful on On-Demand nodes.
• ECS on EC2: use a capacity provider backed by an Auto Scaling group with a mixed instances policy like the one above, and turn on Spot instance draining so tasks are moved off an instance when it receives the interruption notice.
• Fargate Spot: runs ECS tasks on spare Fargate capacity at a discount, with the same two-minute warning delivered to the task; a capacity provider strategy that mixes FARGATE and FARGATE_SPOT keeps a reliable base.

Containers are often the easiest way to adopt Spot, because the scheduler already expects tasks to come and go. The cluster just has to keep a base of reliable capacity for the tasks that must always run.

Windows and other operating systems on Spot

Spot is available for Windows, Red Hat Enterprise Linux and SUSE too, with the license cost included in the Spot price, so the discount is smaller in dollar terms. On October 22, 2026 in US East (N. Virginia), m7i.large on Spot was $0.0407 an hour for Linux and $0.1021 for Windows, and t3.large $0.0242 and $0.0359. When you query the history for Windows, use --product-descriptions "Windows", because each operating system has its own price history and its own capacity.

A worked selection: picking pools for a 4-vCPU job

Here is the comparison Ethan made for the render job, which needs 4 vCPUs and at least 8 GiB of memory, with October 22, 2026 data for US East (N. Virginia), Linux, sorted from calmest to busiest:

Three lessons jump out. The calmest pools are not the newest families: c6a, m6a and the ARM c7g and c6g sit in the 5-10 percent bucket at 52 to 60 percent off, while the newest Intel types are in the busiest bucket. The very cheapest Spot price, m5.xlarge at $0.0582, comes with the highest interruption rate. And the standout row, t3.xlarge at 74 percent off and under 5 percent interruptions, has a catch for this job: it is a burstable type, so it can only run above its baseline CPU while it has credits. A render that keeps all four cores busy either gets throttled (Standard mode) or pays surplus credit charges (Unlimited mode, $0.05 per vCPU-hour on Linux), which can erase the discount. Burstable types are great Spot choices for spiky work, poor ones for sustained CPU.

Ethan's final list was the calm and mid rows that are not burstable, plus c6i and c7i as extra pools the allocation strategy could use when the calm ones were full. Rather than typing names, you can describe the requirement and let EC2 find matching types with attribute-based selection, in an Auto Scaling group's launch template override:

override {
  instance_requirements {
    vcpu_count {
      min = 4
      max = 4
    }
    memory_mib {
      min = 8192
      max = 16384
    }
    burstable_performance = "excluded"
    cpu_manufacturers     = ["intel", "amd"]
  }
}

With this override, the group considers every current x86 type with exactly 4 vCPUs and 8 to 16 GiB that is not burstable, including new types as AWS releases them, and the price-capacity-optimized strategy picks among their pools. To include ARM types as well, add a second launch template with an ARM AMI and its own override. Fewer names to maintain, more pools to draw from: it is the low-effort version of being flexible.

GPU instances on Spot

GPU pools are smaller and busier than general-purpose ones, and the discounts are smaller too. In US East (N. Virginia) on October 22, 2026: g4dn.xlarge was $0.3149 on Spot against $0.526 On-Demand (40 percent off, 10-15 percent interruptions), g5.xlarge $0.4669 against $1.006 (54 percent off, more than 20 percent), g6.xlarge $0.475 against $0.8048 (41 percent off, more than 20 percent) and g6e.xlarge $1.3754 against $1.861 (only 26 percent off, more than 20 percent). Most GPU types sat in the busiest bucket.

That makes GPU Spot worthwhile mainly for work that checkpoints often: model training that saves every few minutes, batch inference over a queue, rendering. List several GPU types and sizes that your code can use, check more than one Region (GPU capacity varies a lot between them), and keep latency-sensitive inference on On-Demand or reserved capacity. For short, scheduled GPU needs, a reserved block of capacity can be more predictable than Spot when you cannot afford to wait.

Track your own interruption rate

The advisor tells you about a type in general; your own numbers tell you about your setup. Send the EC2 Spot Instance Interruption Warning events to a CloudWatch Logs log group with an EventBridge rule, and you have a record of every interruption with its instance type and zone. A weekly look at the count per type shows which pools are hurting you, and a CloudWatch alarm on a sudden jump warns you that a pool has become crowded, often before jobs start missing deadlines. If one type dominates your interruptions, remove it from the group's list and let the allocation strategy use the others.

When Spot is the wrong answer

Spot saves the most money when it fits, and costs the most time when it does not. Skip it, or keep it to a small slice, when:

• the work cannot stop mid-way and cannot be checkpointed (a long database migration, a one-off manual task);
• you run a single instance that customers depend on, like Jake's booking server;
• you need exactly one instance type in one zone and nothing else will do;
• your team has no time to build interruption handling yet; start with Savings Plans and come back to Spot later.

How you are billed for Spot

• You pay the Spot price of your pool for the time your instance runs, billed per second for Linux (with a one-minute minimum), like On-Demand.
• If EC2 interrupts and terminates a Linux instance, you are billed for the seconds it ran. Your EBS volumes, data transfer and other services are billed normally.
• Spot discounts are not combined with Savings Plans or Reserved Instances; those apply to On-Demand usage. Use Spot for the flexible part of your capacity and commitments for the steady base.
• Burstable types (t3, t4g) launched on Spot in Unlimited mode can add surplus credit charges if they burst immediately and run briefly; for short Spot jobs on burstable types, use Standard mode.
• Spot capacity counts against a separate Spot vCPU quota per Region; requests that are open but unfulfilled count too until canceled. Our vCPU quota guide shows how to raise it.

Which workloads should use Spot

Spot instances are exactly the same as On-Demand while they run; the only difference is that they can be taken back. That makes the question "what happens if this machine disappears with two minutes' notice?":

• Great fits: batch and data processing, rendering and transcoding, CI/CD build agents, stateless web or API servers behind a load balancer, containers on ECS or EKS with several tasks, high-performance computing with checkpointing, and test environments.
• Possible with care: long-running jobs without checkpoints (add them), single-instance development machines (accept occasional restarts), GPU training (checkpoint often, use several types).
• Poor fits: single databases, single-instance production servers, anything that cannot tolerate a sudden stop.

For container platforms, mixing Spot and On-Demand capacity in the same cluster, with the critical baseline on On-Demand, gets most of the savings with little risk. Our ECS on EC2 vs Fargate guide covers the container cost side, and Fargate Spot applies the same idea without managing instances.

Export history for your own analysis

If you want longer trends than 90 days, collect them yourself: schedule a small job (a Lambda function on an EventBridge schedule, for example) that runs the boto3 script above daily for your candidate types and appends the results to an S3 bucket or a DynamoDB table. After a few months you have your own history, for exactly the pools you care about, without depending on the 90-day window. Some third-party sites publish longer histories too; treat them as a guide and confirm current prices in your own account, because prices differ by zone, operating system and time.

Spot terms in plain English

• Capacity pool: one instance type, in one Availability Zone, with one operating system. Prices and interruptions are per pool.
• Interruption: EC2 taking the instance back (terminate, stop or hibernate) after a two-minute notice.
• Rebalance recommendation: an earlier signal that an instance is at elevated risk of interruption.
• Allocation strategy: how a fleet or Auto Scaling group chooses pools; price-capacity-optimized balances availability and price.
• Spot placement score: a 1-to-10 estimate of how likely a request of a given size is to succeed in a Region or zone.
• One-time vs persistent request: a one-time request ends when its instance is interrupted; a persistent one is resubmitted, which is what lets stop and hibernate behaviors bring the instance back.
• Frequency of interruption: the Spot Instance Advisor's measure of how often a type was interrupted over the past month.

A one-page Spot checklist

1. Confirm the workload can stop at any moment and resume.
2. List at least ten instance types that fit, across families, sizes and, if possible, architectures.
3. Check each type's interruption frequency in the advisor and its price history for recent steps.
4. Check Spot placement scores in your Region, and in one or two alternatives.
5. Launch through an Auto Scaling group or EC2 Fleet with price-capacity-optimized and capacity rebalancing.
6. Handle the two-minute notice and the rebalance recommendation; checkpoint long work.
7. Keep a small On-Demand or Savings Plan base for anything that must always run.
8. Review your interruption log and your Spot savings monthly, and adjust the type list.

Spot price and capacity problems, by symptom

The price history shows only one point for a pool

The price did not change in your range; the single record is the price in effect at the start. That is normal for a stable pool.

describe-spot-price-history returns nothing

The product description does not match exactly (use "Linux/UNIX"), the instance type is not offered in that Region or zone, or the start time is more than 90 days ago.

My Spot request stays open and never launches

No capacity in the pools you allowed, or a maximum price below the current Spot price. Add instance types and zones, and remove a low maximum price.

"InsufficientInstanceCapacity" for Spot

The pool has no spare capacity right now. Diversify across types and zones and use price-capacity-optimized; our capacity guide covers the workarounds.

Spot instances are interrupted every night

You are in a busy pool. Check the Spot Instance Advisor, add calmer types, and let the allocation strategy pick.

"MaxSpotInstanceCountExceeded" or a vCPU limit error

You hit the Spot vCPU quota for the Region. Cancel stale open requests and request a quota increase.

The bill is higher than the Spot price suggested

EBS, data transfer, NAT gateways and other services are billed separately, and burstable instances in Unlimited mode can add credit charges. Check Cost Explorer by usage type.

My t3 Spot instances cost more than expected

Burstable instances in Unlimited mode charge for surplus CPU credits when they run above baseline. Use Standard mode, or a non-burstable type for sustained CPU work.

Spot requests fail in one Region but work in another

Capacity differs between Regions. Check Spot placement scores across Regions and, if your workload allows, run where capacity is available.

Spot price is close to the On-Demand price

That pool is in high demand. Choose other types or zones; a pool at nearly On-Demand price is also likely to be interrupted.

Spot Instance price history: frequently asked questions

A month later, the render job's Spot bill was a third of what On-Demand would have cost, and its interruptions had dropped from three a week to one or two a month, each one absorbed by a checkpoint and a replacement instance. Jake asked whether he should move the booking server to Spot too. "The renders can wait two minutes," Ethan said. "Your customers cannot."

Revision note. Written October 22, 2026, with Spot prices, Spot Instance Advisor data and On-Demand prices for US East (N. Virginia) of that week. "Don't put all your eggs in one basket," the proverb says; with Spot, spread them across many pools.