EC2 Spot Instances — up to 90% off, if you run the right workloads on them.

IWhat EC2 Spot actually is — spare capacity, not a separate product

Spot Instances are not a different class of hardware. They are ordinary EC2 instances — the same M, C, R, and accelerated families you already use — drawn from whatever capacity a given Availability Zone has sitting idle at that moment. You pay the Spot price, which floats with supply and demand but settles far below On-Demand. The trade you make for that discount is reclaimability.

At any moment, every AWS Availability Zone has some unused EC2 capacity — servers that were provisioned for peak On-Demand demand but aren't being rented right now. Rather than let that capacity sit idle, AWS sells it as Spot at a discount. When On-Demand demand rises and AWS needs that capacity back, it reclaims your Spot instances after sending a 2-minute interruption notice. That is the entire bargain: deep discount, in exchange for the possibility of a 2-minute eviction.

How deep is the discount? It varies by instance family, region, and Availability Zone, but the steady-state range is roughly 70–90% off the equivalent On-Demand rate. A general-purpose instance that lists at $0.10/hour On-Demand commonly runs $0.02–$0.03/hour on Spot. Always confirm the live number in the Spot price history (EC2 console → Spot Requests → Pricing history, or the `describe-spot-price-history` API) and the Spot placement score for current rates and capacity — they move.

Two clarifications that trip people up. First, pricing is no longer an auction. Years ago you set a "max bid" and competed; today the Spot price changes gradually based on long-term supply and demand, and you simply pay the current price. You can still set a maximum price, but the right default for most workloads is to leave it at the On-Demand price (the cap) so you are never interrupted for price reasons — only for genuine capacity reclamation. Second, a "Spot pool" is one specific combination of instance type + size + Availability Zone (e.g., `c7g.xlarge` in `us-east-1a`). Reclamations happen per pool. The whole reliability game is about not depending on any single pool.

The capacity signal worth knowing is the Spot placement score: AWS scores how likely a given region or AZ is to fulfill a Spot request of a given size and shape right now. Before you commit a large Spot fleet to a region, check the placement score — it tells you whether the capacity you need actually exists where you want it.

IIWhat is safe to run on Spot — and what absolutely is not

The single decision that determines whether Spot saves you money or causes an incident is workload fit. The question is never "is this important?" — plenty of important workloads run beautifully on Spot. The question is: "if one instance vanishes in 2 minutes, does the work survive?" If yes, it is a Spot candidate. If a lost instance means lost data or a hard outage with no graceful recovery, keep it off Spot.

Below is the practitioner's split. The "safe" column is not theoretical — these are the workloads that companies run on Spot at 60–90% Spot mix in production every day. The "not safe" column is the set where the 2-minute notice is genuinely not enough, or where the state lost on eviction is irreplaceable.

IIICapacity-optimized allocation + diversification — how Spot stays reliable

The difference between Spot that interrupts constantly and Spot that almost never interrupts is two settings: which allocation strategy you use, and how many pools you spread across. Get these right and real-world interruption rates for well-diversified fleets routinely sit in the low single-digit percent per month. Get them wrong — chase the absolute cheapest pool, depend on one instance type in one AZ — and you will feel every reclamation.

Allocation strategy. When your fleet needs more Spot capacity, AWS has to decide which pools to draw from. The strategy you choose controls that decision:

• capacity-optimized (the default you want) — AWS provisions from the pools with the most spare capacity right now — the pools least likely to be reclaimed soon. This minimizes interruptions and is the right default for the overwhelming majority of workloads. There is also "capacity-optimized-prioritized," which honors your instance-type priority list while still favoring deep-capacity pools — useful when some instance types suit your workload better than others.
• price-capacity-optimized — A balance: AWS weighs both the availability of capacity and the price, picking pools that are both deep and cheap. For many fleets this is now the best general-purpose choice — you keep most of the interruption resilience of capacity-optimized while shaving a bit more off the bill.
• lowest-price (usually a trap) — AWS picks the cheapest pools regardless of how thin their capacity is. The cheapest pool is often the one about to be reclaimed, so this strategy maximizes interruptions. Avoid it unless your workload is so trivially interruption-tolerant that you genuinely do not care.

Diversification. Allocation strategy only has good options to choose from if you give it many pools. Diversification means telling your fleet it can use many instance types across many Availability Zones, rather than pinning to one. Practical guidance: select a broad set of instance types that are interchangeable for your workload — multiple sizes (e.g., `xlarge` and `2xlarge`), multiple families that meet your vCPU/memory shape (e.g., `m6i`, `m6a`, `m7i`, `m7g`), and every AZ in the region. Ten or more pools is a healthy target; with that many, the reclamation of any single pool is absorbed by the rest, and AWS almost always has a deep pool to pull from. The attribute-based instance type selection feature lets you specify requirements ("≥ 4 vCPU, ≥ 8 GiB, current-gen") and have AWS expand that to the full matching set automatically, so you do not hand-maintain instance lists as new families launch.

A note on mixing architectures: Graviton (ARM) Spot pools are frequently the deepest and cheapest of all, because Graviton supply is plentiful and demand is still catching up. If your workload runs on ARM (or you can build multi-arch images), adding Graviton instance types to your diversification set both lowers cost and improves Spot availability. That is a direct overlap with the Graviton migration lever covered elsewhere in this cluster.

IVSpot in Auto Scaling Groups and EKS (Karpenter)

You almost never request raw Spot instances by hand in production. You let an orchestrator manage the fleet, request Spot capacity, react to interruptions, and replace evicted instances. The two orchestrators that matter for most teams are Auto Scaling Groups (for general EC2 fleets) and Karpenter (for EKS/Kubernetes). Both implement capacity-optimized allocation and diversification natively.

Auto Scaling Groups with a mixed instances policy. A modern ASG does not have to be single-instance-type or single-purchase-option. A mixed instances policy lets one ASG span many instance types and split capacity between On-Demand and Spot with explicit knobs:

• On-Demand base capacity — a fixed floor of On-Demand instances that always exist regardless of Spot availability. This is your "never lose this" baseline (e.g., enough to serve minimum traffic).
• On-Demand percentage above base — for capacity beyond the base, what fraction is On-Demand vs Spot. Set, say, 20% On-Demand / 80% Spot so the elastic layer is mostly cheap Spot but every scale-out still adds a little stable capacity.
• Spot allocation strategy — set to capacity-optimized or price-capacity-optimized (per the previous section).
• Instance type list (or attribute-based selection) — the diversified set of pools the ASG may draw from across all AZs.
• Capacity Rebalancing — when enabled, the ASG proactively launches a replacement when AWS signals an instance is at elevated risk of interruption, before the 2-minute notice even fires, so the new instance is warm by the time the old one is reclaimed.

VHandling interruptions gracefully — the 2-minute drill

Reliable Spot is not about avoiding every interruption — it is about making each interruption boring. When AWS decides to reclaim an instance, it gives you three signals and a 2-minute window. A workload that listens for those signals and drains cleanly within the window experiences interruptions as a non-event. A workload that ignores them experiences them as dropped requests and lost jobs.

There are three mechanisms to listen for, in increasing order of lead time:

• Rebalance Recommendation (earliest warning) — An EventBridge / instance-metadata signal that fires when AWS judges an instance is at elevated risk of interruption — often well before the 2-minute notice. It is your cue to proactively start draining and bring up a replacement while you still have plenty of time. Auto Scaling Capacity Rebalancing and Karpenter both act on this automatically.
• Spot Instance Interruption Notice (the 2-minute warning) — Delivered via instance metadata (the `instance-action` endpoint) and EventBridge. This is the hard 2-minute countdown to termination. Your shutdown logic must fit inside it: stop taking new work, finish or checkpoint in-flight work, deregister from the load balancer, flush logs, and exit.
• EC2 instance termination (the deadline) — After the 2 minutes, the instance is reclaimed (stopped or terminated depending on your request type). Anything not drained or checkpointed by then is lost — which is exactly why the previous two signals exist.

What "draining cleanly" looks like in practice depends on the workload. For a web tier: catch the notice, deregister the target from the ALB/NLB target group so the load balancer stops routing to it, let in-flight requests complete (connection draining), then terminate. For a queue worker: stop pulling new messages, finish (or return-to-queue) the current message, then exit — the message's visibility timeout means anything unfinished simply reappears for another worker. For a batch / training job: write a checkpoint to S3 on the notice so the job resumes from the last checkpoint elsewhere. For Kubernetes: the node is cordoned and drained, pods get their graceful termination period, and the scheduler places them on surviving or new nodes.

A practical robustness tip: keep your graceful-shutdown work comfortably under 120 seconds. If draining a web instance takes 90 seconds of connection draining, you have only 30 seconds of slack — keep request timeouts and drain windows tuned so you never run past the deadline. And always design for the case where the notice does not arrive at all (rare, but possible under sudden hardware failure): idempotent jobs, replicated state, and health-check-driven replacement mean even a no-notice loss is survivable.

VISpot + On-Demand + Savings Plans — the blended strategy

All-Spot is a beginner's framing. The mature compute-cost strategy layers three purchase options so each covers the part of the workload it suits best: Savings Plans for the predictable baseline you commit to, On-Demand for the unpredictable spikes you cannot pre-commit and cannot risk on Spot, and Spot for the elastic, interruption-tolerant bulk. Done right, the blended bill is dramatically lower than any single option while staying as reliable as your most stable layer.

Think of your compute demand as three layers stacked on top of each other:

Layer 1 — the committed baseline (Savings Plans / Reserved capacity). The floor of compute you run 24/7 and are confident you will keep running for 1–3 years. Cover it with a Compute Savings Plan (flexible across EC2, Fargate, and Lambda) or, for a deeper discount on a stable shape, an EC2 Instance Savings Plan. Savings Plans give up to ~70%+ off On-Demand in exchange for an hourly spend commitment, but — critically — they are a billing construct, not a capacity guarantee, and they cannot be interrupted. This is the layer you never want on Spot. (See the Savings Plans page in this cluster for the full commitment math.)

Layer 2 — the interruption-tolerant elastic layer (Spot). The large, variable portion of demand that scales with traffic, jobs, or batch volume and tolerates a 2-minute eviction. This is where Spot earns its 70–90% discount. The bigger and more stateless this layer is, the more Spot saves you.

Layer 3 — the safety valve (On-Demand). The thin top slice for sudden spikes you did not commit to and cannot safely place on Spot, plus the On-Demand fallback when a Spot pool momentarily cannot fulfill capacity. You pay full price here, but it is a small fraction of total hours, and it guarantees you never fail to scale.

The reason commitments and Spot are complementary rather than competing: a Savings Plan discount applies to whatever eligible compute you run, and AWS applies it to your On-Demand usage first (your baseline), where the discount is largest relative to the rate. Spot already prices below the Savings-Plan-discounted rate, so you do not "waste" a Savings Plan by also running Spot — the commitment soaks up the baseline, Spot handles the elastic surplus more cheaply still, and On-Demand catches the rest. The honest tradeoff to keep in view: commitments reduce flexibility (you owe the hourly spend for the full term whether or not you use it), so you size the Savings Plan to the baseline you are genuinely confident about and let Spot + On-Demand flex above it.

VIISpot for Fargate — Spot economics without managing instances

You do not need to run EC2 yourself to get Spot pricing. Fargate Spot brings the same spare-capacity discount to serverless containers — you specify a task and AWS runs it on spare capacity at a steep discount, with the same 2-minute interruption notice, and you never touch an instance, an AMI, or a node group.

On Amazon ECS, a service or task can run on the FARGATE_SPOT capacity provider instead of (or blended with) the regular FARGATE provider. Fargate Spot tasks cost substantially less than standard Fargate — commonly around 50–70% off — and behave like Spot in every other respect: when AWS needs the capacity back, it sends a SIGTERM plus a task-state change with roughly 2 minutes for the task to shut down gracefully before SIGKILL. The fit rules are identical to EC2 Spot: stateless services behind a load balancer, queue workers, batch and scheduled tasks — yes; the single stateful task you cannot lose — no.

The clean pattern on ECS mirrors the EC2 blend: define a capacity provider strategy that places a base number of tasks on regular FARGATE (your always-on floor) and the remainder on FARGATE_SPOT (the elastic, interruptible bulk), with a weight ratio controlling the split. You get most of the cost of Spot with the operational simplicity of Fargate — no instance fleet, no patching, no Karpenter to operate. For teams without the appetite to run and tune EC2 Spot fleets, Fargate Spot is frequently the highest return-on-effort Spot win available, because the orchestration is entirely AWS-managed.

EKS users can also schedule pods onto Fargate via Fargate profiles, though Fargate-on-EKS does not currently offer a Spot price tier the way ECS does — for Spot economics on EKS, the EC2-backed Karpenter/managed-node-group path covered above is the route. The decision tree is simple: containers on ECS → Fargate Spot for the easy win; containers on EKS that need Spot → EC2 node pools via Karpenter; raw VM fleets → ASG mixed instances policy.

VIIISpot vs On-Demand vs Savings Plans — side by side

These three are not competitors to choose between — they are layers to combine. But to combine them well you need to see clearly what each one trades. The table below is the at-a-glance version; the section above explains how they stack.

IXWhy a partner architects Spot adoption (often AWS-funded)

Spot is high-leverage but it is not set-and-forget. Choosing the diversification set, wiring capacity-optimized allocation, building interruption handling into every workload, configuring Karpenter or the ASG mixed instances policy correctly, and sizing the Savings Plan baseline so commitments and Spot complement rather than collide — that is a real engineering project. It is also exactly the kind of work AWS will frequently fund.

AWS funds partner-led cost-optimization and Well-Architected engagements through its partner programs — the partner is paid through AWS, and a Well-Architected Review (the Cost Optimization pillar in particular) can unlock remediation credits that offset the rework. For qualifying, credit-eligible engagements, that means a vetted partner can architect your Spot adoption, implement the interruption handling and orchestration, and set up the Savings-Plan baseline, and you cut your bill for $0. The honest framing: AWS-funding applies to qualifying engagements; where it does not, it is still a vetted-partner referral that pays for itself many times over in the savings — a 50–65% cut on compute spend dwarfs the cost of the work.

CloudRoute's role is the routing layer: you tell us your stack and your bill, and we match you to an AWS partner with a real Spot / FinOps track record — not a generalist. They run the audit (Compute Optimizer, Cost Explorer, the Spot placement scores, your interruption tolerance per workload), produce the blended-strategy plan, and do the rework. CloudRoute is paid a commission by the partner; you are not in that payment loop. The same engagement typically folds in the rest of this cluster's levers — right-sizing, Graviton migration, Savings Plans — because a competent cost review never optimizes compute in isolation.