All cheat sheets
Computecheat sheet

Fargate Spot

Serverless containers on spare capacity for up to 70% off — same Fargate, but AWS can reclaim a task with a 2-minute SIGTERM warning. A near-instant win for batch, queue workers, CI/CD, and dev/test; keep production APIs On-Demand.

Last reviewed: July 14, 2026

Prefer step by step? Take the guided Fargate Spot walkthrough — free, anonymous, interactive.Have an AI assistant? Jump to the copy-paste audit prompt at the bottom of this sheet.

TL;DR: Fargate Spot is the same serverless-container platform (no instances to patch or manage) running on spare AWS capacity for up to 70% off — with the catch that AWS can reclaim a task on a 2-minute SIGTERM warning. For fault-tolerant work (batch, ETL, SQS workers, CI/CD builds, dev/test) it's a near-instant win with minimal downside; for user-facing APIs it's a recipe for failed requests. The whole game is: which of your containers can tolerate an occasional 2-minute interruption?

The numbers

  • Typically 50–70% off On-Demand Fargate — 1 vCPU + 2 GB ≈ $0.08/hr (~$58/mo) On-Demand vs $0.03/hr ($22/mo) Spot.
  • Worked example: 10 tasks (2 vCPU + 4 GB) 24/7 ≈ $1,168/mo On-Demand vs $365/mo Spot ($803/mo, ~$10K/yr) — still ahead even if 10% of tasks are interrupted and retry.
  • Interruption handling: AWS sends SIGTERM 2 minutes before termination; queue workers stop pulling and let the in-flight message become visible again, batch jobs resume from an S3 checkpoint.
  • Watch the interruption rate: under 5% is great, over 20% means tight regional Spot capacity — shift more to On-Demand.
  • Field examples: a nightly ETL (checkpoints every 10 min) saved ~$144/mo finishing 5–10 min later on interruption; a CI/CD pipeline of 200+ builds/day saved ~$75/mo with automatic retries developers barely noticed.

Do this

  1. Enable it via ECS Capacity Providers (a FARGATE_SPOT strategy, e.g. 70% Spot / 30% On-Demand) or an EKS Fargate profile with capacity type FARGATE_SPOT.
  2. Handle SIGTERM cleanly in every container — stop accepting new work, finish or return the current unit, exit before the 2-minute window closes; test it in dev before production.
  3. Match the split to tolerance — 100% Spot for fully fault-tolerant batch, 70/30–80/20 for tolerant-with-baseline, 100% On-Demand for critical user-facing services.
  4. Checkpoint batch progress to S3/DB so an interrupted job resumes instead of restarting; rely on the queue for SQS workers (interrupted messages just get re-picked-up).
  5. Set CloudWatch alarms on task terminations/interruption rate so a spike is caught before users notice.

Gotchas

  • No SIGTERM handling = killed mid-work — the #1 pitfall; implement and test signal handling first.
  • 100% Spot for critical workloads causes user-facing failures — a Spot interruption during a request fails it; keep production APIs On-Demand (or ≤10–20% Spot, closely monitored).
  • Unmonitored interruption rates hide problems until users complain — alarm on them.
  • Its edge over EC2 Spot is serverless (no instances to manage), not fewer interruptions or universal fit.

Skip this if

  • The service is a user-facing API or web service with uptime requirements, a long-running stateful task without checkpointing, or a real-time streaming pipeline a 2-minute gap would break — run it On-Demand (use Spot only for its staging/dev copies).
  • You want a cluster-wide mixed strategy — build it with ECS Capacity Providers; for larger batch fleets AWS Batch with Spot orchestrates interruptions for you, and Spot Instances covers the EC2 model.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account's Fargate usage for Fargate Spot savings.
Use the AWS CLI with READ-ONLY credentials. Do not create, modify, or
delete anything — report findings and recommended (unapplied) fixes only.

1. Inventory: aws ecs list-services / describe-services (capacityProvider
   strategy: FARGATE vs FARGATE_SPOT) and EKS Fargate profiles
   (FARGATE_SPOT capacity type). Flag On-Demand Fargate services.
2. Spot readiness: identify fault-tolerant workloads — batch/ETL with
   checkpointing, SQS queue workers, CI/CD build agents, dev/test — as
   Spot candidates. Exclude user-facing APIs, long-running stateful tasks
   without checkpoints, real-time streaming.
3. Interruption handling: confirm containers catch SIGTERM (stop pulling
   work, finish/return message, exit) before recommending Spot for a
   service.
4. Strategy + monitoring: recommend 100% Spot for fully fault-tolerant,
   70/30 or 80/20 for tolerant-with-baseline, 100% On-Demand for critical;
   recommend CloudWatch alarms on interruption rate (act if >20%).

Report a table: service | current | Spot-ready? | SIGTERM handled? |
recommended split | est. $/mo saved. Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The Fargate Spot walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough

More Compute cheat sheets

Amazon Lightsail

AWS with the training wheels on: fixed-price monthly bundles ($3.50–$40) that roll compute, storage, and data transfer into one predictable number. The right tool for WordPress, dev environments, and small apps — and the wrong one past ~16 GB RAM.

Auto Scaling Groups

Match EC2 capacity to real demand automatically — target-tracking, step, and scheduled policies plus a mixed On-Demand/Spot instances policy. Running 3 instances most of the day and bursting to 10 at peak beats 10 instances 24/7 by ~56%.

AWS Batch with Spot

Run batch and data-processing jobs at 70–85% off On-Demand by letting AWS Batch handle Spot interruptions for you — diversified pools, capacity-optimized allocation, and automatic retries. Set min_vcpus=0 and pick the right allocation strategy.

AWS Compute Optimizer

Free ML-driven rightsizing for EC2, Auto Scaling Groups, EBS, Lambda, and Fargate — reads CloudWatch metrics over 14 days and hands you specific downsizes with dollar figures and a performance-risk rating. Enable it, install the agent for memory, act monthly.