AWS Fargate Spot: Pricing, Savings, and When to Actually Trust It
Fargate Spot runs your ECS containers on spare AWS capacity — same runtime, same task definition, 50–70% cheaper. The reason most teams haven't turned it on: they're not sure what happens when AWS reclaims that capacity mid-request.
Below: real pricing math, the stopTimeout gotcha that costs teams their full 2-min window, and a workload grid so you can decide in 10 minutes.
What is Fargate Spot?
Fargate Spot is a capacity provider built into ECS. It runs your containers on spare AWS compute at a discount — the same Fargate runtime, the same task definition, no EC2 nodes to manage. When AWS needs that capacity back, your tasks get a two-minute warning and stop.
You enable it through a capacity provider strategy on your ECS cluster. No task definition changes. No new IAM roles. No ALB reconfiguration. The difference is purely in how AWS schedules your containers and what you pay.
What Fargate Spot actually costs
AWS publishes current Spot rates on the Fargate pricing page (the "Current Spot price" table, updated dynamically). The rates are not a fixed 70% discount — they adjust gradually based on long-term trends in supply and demand, per AWS. The range is 50–70% off on-demand; 70% is the ceiling, not the typical case.
| Architecture | vCPU / hr | GB / hr | 1 vCPU + 2 GB / mo |
|---|---|---|---|
| x86 on-demand | $0.04048 | $0.004446 | $36.04 |
| ARM on-demand | $0.03238 | $0.003560 | $28.84 |
| x86 Spot (50% off) | ~$0.0202 | ~$0.00222 | ~$18.02 |
| x86 Spot (70% off) | ~$0.0121 | ~$0.00133 | ~$10.81 |
| ARM Spot (50% off) | ~$0.0162 | ~$0.00178 | ~$14.42 |
| ARM Spot (70% off) | ~$0.0097 | ~$0.00107 | ~$8.65 |
On-demand rates: us-east-1, Linux, verified June 2026 from aws.amazon.com/fargate/pricing. Spot ranges are illustrative (50–70% off on-demand); actual rate varies — check the live Spot table on the same page. ARM savings apply if your container image is built for linux/arm64.
The interruption mechanics — and the stopTimeout gotcha
When AWS needs capacity back, it sends a two-minute warning — simultaneously:
stopCode: "SpotInterruption")Your container has that window to finish in-flight work, drain connections, and exit cleanly. If it doesn't exit within stopTimeout, ECS sends SIGKILL — hard stop, possible data loss.
The default stopTimeout is 30 seconds — not 120. AWS gives you a 2-minute warning, but unless you explicitly set stopTimeout: 120 in your task definition, ECS sends SIGKILL after just 30 seconds. You silently lose 90 seconds of grace window.
Source: AWS ECS docs — Fargate Spot termination notices (verified June 2026)
The no-fallback rule most teams discover the hard way
When Fargate Spot capacity is unavailable — during high-demand periods — ECS does not automatically switch your tasks to on-demand. AWS is explicit about this:
“Fargate doesn't replace Spot capacity with on-demand capacity.”
— AWS ECS Developer Guide, verified June 2026
What happens instead: ECS services retry launching tasks until Spot capacity returns. A service running a single Spot task will be interrupted and stay interrupted until AWS has spare capacity again.
The fix is the mixed capacity-provider strategy in the next section — not treating Spot as a drop-in replacement for on-demand.
Which workloads belong on Spot
The decision comes down to one question: can this workload restart cleanly from a 2-minute warning?
| Workload | Spot? | Notes |
|---|---|---|
| Dev environments | ✓ | Interruptions are low-stakes; restart is instant |
| Staging / preview environments | ✓ | Same — non-customer-facing |
| Batch / data pipeline tasks | ✓ | Design for retry; Spot is the default |
| CI runners | ✓ | Ephemeral by design — perfect fit |
| Stateless prod API (multi-task) | ~ | Mixed strategy: on-demand base + Spot weight |
| Single-replica service | ✗ | No fallback = interruption means downtime |
| Long stateful job / DB migration | ✗ | Can't checkpoint; 2-min warning is too short |
For stateless production APIs, use the mixed strategy below — not pure Spot. The Fargate on-demand pricing breakdown explains what you're paying per environment before Spot.
Mixed capacity-provider strategy
Set base=1 on FARGATE so at least one task is always on on-demand. Set weight=3 on FARGATE_SPOT for the rest. ECS fills the base first, then places ~75% of additional tasks on Spot. If Spot is interrupted, the on-demand base task stays up; ECS retries the Spot tasks.
Only one capacity provider can have a base value. At least one provider must have weight > 0. Max 20 capacity providers per strategy. Source: AWS ECS docs.
Spot + scheduling: where the real savings compound
Fargate Spot cuts your per-hour rate by 50–70%. Scheduling environments off at nights and weekends cuts your billable hours by ~65%. Stack them and the math gets interesting:
Spot is a rate lever you set once per cluster. Scheduling is an operations lever — it needs to run across 10+ environments, respect team hours, handle exceptions, and not wake up the on-call when it fires at 2am. That's the part Fortem handles.
Fleet Audit scans your ECS environments and shows exactly which services are Spot candidates, what they cost now, and what they'd cost on a schedule. Free, read-only, runs locally in 15 minutes.