AWS Fargate: What It Is and When to Use It

Definition

AWS Fargate is a serverless compute engine for containers that runs with Amazon ECS and Amazon EKS. You package your application as a Docker image, define CPU and memory requirements, and Fargate starts the right-sized microVM to run it — without you provisioning, patching, or scaling any EC2 instances. You pay per second for the compute your tasks actually use.

How It Works

Fargate is an execution environment, not a standalone service. You consume it through either ECS or EKS:

• ECS + Fargate — in an ECS task definition you set launchType: FARGATE or attach a Fargate capacity provider. Every task runs on its own isolated microVM.
• EKS + Fargate — you attach a Fargate profile to an EKS cluster. Pods matching the profile's namespace/label selector schedule onto Fargate instead of EC2 nodes.

Under the hood, each Fargate task gets:

• Its own Firecracker-based microVM — strong kernel-level isolation per task, unlike shared-kernel containers.
• Its own Elastic Network Interface (ENI) in your VPC (awsvpc mode), with a private IP and optional Security Groups.
• Configurable ephemeral storage and an IAM task role for least-privilege AWS API access.

You never see or manage the underlying hosts — Fargate is opaque capacity that scales to whatever your tasks request.

Key Features and Limits

• Task sizes: 0.25, 0.5, 1, 2, 4, 8, or 16 vCPU paired with matching memory from 0.5 GiB up to 120 GiB. Supported combinations depend on the vCPU size.
• Architectures: Linux on x86_64 and on Arm64 (Graviton); Windows Server on x86_64 for ECS.
• Ephemeral storage: 20 GiB by default, up to 200 GiB configurable per task.
• Networking: awsvpc mode only — every task has its own ENI and private IP.
• Persistent storage: EFS volumes (mount-point attach) for ECS; EFS, FSx for Lustre, and S3 Mountpoint for EKS pods.
• IAM: each task has a task execution role (for AWS to pull images / write logs) and an optional task role (for your code).
• Fargate Spot: interruptible capacity at up to 70% off, with a 2-minute warning. Supported on ECS; EKS Fargate does not support Spot.
• Observability: CloudWatch Logs, Container Insights, X-Ray sidecar, OpenTelemetry (ADOT).
• Security: tasks run with kernel-level isolation; pods run in their own microVM. Vulnerability scanning via Amazon Inspector for the image in ECR.

Limits and gotchas

• No GPU support on Fargate (use EC2 launch type with G- or P-family instances).
• No privileged containers or custom kernel modules.
• Longer cold-start than Lambda (tens of seconds to start a task), so not ideal for very bursty traffic.
• EKS Fargate pods are limited in features — DaemonSets, HostPort, some CSI drivers, and certain security contexts are not supported.
• Data-transfer and ENI-creation overhead can add up at very high churn rates.

Common Use Cases

1. Web APIs and microservices — container workloads where you don't want to run EC2 capacity.
2. Scheduled / batch jobs — invoke tasks via EventBridge or Step Functions without a warm worker pool.
3. CI/CD runners — ephemeral build and test environments that scale to zero between pipelines.
4. Event-driven data processing — long-running jobs that exceed Lambda's 15-minute limit but don't justify managing EC2 instances.
5. Low-ops small teams — startups and internal platforms that want containers without a platform team for EC2/K8s nodes.
6. Secure multi-tenant workloads — the per-task microVM gives strong isolation between customers.

Pricing Model

Fargate bills per second (1-minute minimum) on two dimensions:

1. vCPU-seconds — based on the task's CPU allocation and runtime.
2. GB-seconds of memory — based on the task's memory allocation and runtime.

Additional dimensions:

• Ephemeral storage above the 20 GiB free tier — per GB-second.
• Architecture: Linux Arm (Graviton) is roughly 20% cheaper than x86. Windows Fargate is noticeably more expensive due to licensing.
• Fargate Spot: up to 70% cheaper for fault-tolerant workloads on ECS.
• Compute Savings Plans: 1-year or 3-year commitments reduce on-demand Fargate by up to 52%.

Data transfer, ALB/NLB, CloudWatch Logs, and ECR storage are separate charges.

Pros and Cons

Pros

• Zero server management — no AMIs, no Auto Scaling Groups, no patch cycles.
• True per-task autoscaling — if you need one more task, you get one more microVM.
• Strong isolation — each task runs on dedicated virtualization.
• Predictable per-task pricing — capacity planning is replaced by task sizing.

Cons

• More expensive per vCPU than well-utilized EC2 Reserved or Spot capacity.
• No GPU / custom kernel options.
• Task start latency (tens of seconds) is higher than a warm EC2 node.
• EKS Fargate has feature gaps compared to EC2 nodes.
• Fine-grained cost attribution requires diligent tagging.

Comparison with Alternatives

| | Fargate | EC2 launch type | Lambda | | --- | --- | --- | --- | | Unit of work | Container task / pod | Container task / pod | Function invocation | | Server management | None | You manage instances | None | | Max runtime | Unlimited | Unlimited | 15 minutes | | Cold start | Tens of seconds | Node launch (minutes) | 100 ms – few seconds | | Pricing | Per vCPU-second + GB-second | Per instance-second | Per request + GB-second | | GPU support | No | Yes (P/G/Inf/Trn families) | No | | Spot-like discount | Fargate Spot (~70% off) | EC2 Spot (~90% off) | N/A | | Best for | Stateless containers without node management | Sustained workloads, GPU/specialized hardware | Event-driven short code |

Rule of thumb: start on Fargate; move heavyweight, steady-state workloads to EC2 once the price difference becomes meaningful and you have the operational bandwidth.

Exam Relevance

• Solutions Architect Associate (SAA-C03) — recognizing Fargate as the "no server management" container option; Fargate vs EC2 trade-offs.
• Developer Associate (DVA-C02) — awsvpc mode, task IAM role vs execution role, ephemeral storage configuration, Fargate Spot on ECS.
• DevOps Professional (DOP-C02) — capacity providers, mixed Fargate + Fargate Spot + EC2 strategies, deployment patterns.

Common exam trap: a scenario asks for a container workload that must not manage EC2 capacity — the answer is Fargate, not ECS-on-EC2 or EKS-on-EC2.

Frequently Asked Questions

Q: Is Fargate cheaper than EC2 for running containers?

A: Not usually at steady state. Per vCPU-hour, Fargate is more expensive than an equivalently sized EC2 instance, especially when you compare Fargate to EC2 with Reserved Instances or Spot. The trade-off is the cost of managing EC2 yourself — patching, right-sizing, bin-packing, ASG rules. For small-to-medium workloads or teams without platform engineering, Fargate is usually cheaper in total cost of ownership. For large, steady fleets, EC2 with Savings Plans or Spot often wins.

Q: What is Fargate Spot and when should I use it?

A: Fargate Spot provides tasks on interruptible capacity at up to 70% off On-Demand Fargate. AWS can reclaim the task with a 2-minute SIGTERM. It's supported on ECS (but not on EKS Fargate as of 2026). Use it for fault-tolerant workloads — batch processing, CI runners, non-critical background jobs, or stateless workers that can be restarted without user impact. Mix with On-Demand Fargate through a capacity-provider strategy to maintain a baseline of reliable capacity.

Q: Can I mount persistent storage to Fargate tasks?

A: Yes, with some limits. ECS Fargate tasks can mount Amazon EFS filesystems for shared, persistent, POSIX-compliant storage. EKS Fargate pods can mount EFS, and newer CSI drivers support FSx for Lustre and S3 Mountpoint. Fargate does not support attaching EBS volumes — use EC2 launch type if your workload requires low-latency block storage.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS Fargate documentation before making production decisions.