AWS Fargate
AWS Fargate is the serverless compute engine that runs containers without any servers for you to manage. It is not a separate place to launch containers — it is a launch type you use under ECS or EKS. You declare what each container needs (CPU, memory, networking, IAM role); AWS finds a place to run it, and you never see, patch, or pay for an idle host.
Launched in 2017, Fargate changed how most teams run containers on AWS. The standing advice is to start with Fargate and move to managed EC2 nodes only when there is a concrete reason.
How Fargate Fits with ECS and EKS
Fargate is the compute engine; ECS and EKS are the orchestrators. ECS + Fargate is the simpler, most common combination — ECS schedules tasks, Fargate runs them. EKS + Fargate places Kubernetes pods on Fargate through a Fargate profile. You can mix Fargate and EC2 in one cluster: steady services on EC2, short-lived jobs on Fargate.
EC2 launch typeyou manage the hostsFargateno serversSizing and Limits
Each task picks CPU and memory from a fixed matrix, from 0.25 vCPU with 0.5–2 GB up to 16 vCPU with 32–120 GB. Every task uses awsvpc mode, so it gets its own elastic network interface and private IP. Tasks include 20 GB of ephemeral storage (configurable to 200 GB); for persistent data, mount an EFS file system.
Fargate runs on both x86 and Arm (Graviton). Switching a task to Graviton is usually a one-line change and runs about 20% cheaper for the same work.
Pricing
You pay per vCPU-second and GB-second, from the moment the image starts pulling until the task stops — roughly USD 0.0405 per vCPU-hour and USD 0.0044 per GB-hour for Linux/x86 in US East as of this writing. A 0.5 vCPU, 1 GB task running continuously costs about USD 18 per month.
Fargate Spot offers up to 70% off in exchange for a possible two-minute interruption — well suited to stateless or batch tasks. Billing includes image-pull time, so smaller images start faster and cost slightly less per run.
Fargate — zero server management, fast automatic scaling, and a small team. The default for most container workloads.
EC2 launch type — steady high traffic where reserved capacity is cheaper, GPUs or special hardware, privileged containers, or fast local NVMe.
- Writing important data only to the task's ephemeral disk — it is wiped when the task stops. Mount EFS for anything that must persist.
- Staying on x86 when Graviton would run the same task ~20% cheaper for a one-line change.
- Shipping bloated container images — Fargate bills image-pull time and large images slow scale-out exactly when load is rising.
- Running interruption-tolerant batch on on-demand Fargate instead of Fargate Spot, leaving ~70% savings on the table.
- Reaching for Fargate when the workload needs GPUs, privileged mode, or custom kernel features it does not support.
- Over-provisioning task CPU and memory 'to be safe' — Fargate bills the requested size for the full runtime.
- Right-size to the smallest CPU/memory that meets the need; you can raise it later.
- Use Arm/Graviton tasks for the ~20% discount where your image supports it.
- Keep images small so tasks start fast under scale-out and cost less per run.
- Run the baseline on on-demand Fargate and bursty, fault-tolerant work on Fargate Spot.
- Mount EFS for any shared or persistent state instead of the ephemeral disk.
- Use CloudWatch Logs as the task log driver for straightforward debugging.
Knowledge Check
How does Fargate relate to ECS and EKS?
- Fargate is a serverless compute engine (launch type) that runs containers under ECS or EKS, which do the orchestration
- Fargate is a separate orchestrator that competes directly with ECS and EKS by scheduling and placing containers on its own
- Fargate replaces both ECS and EKS for all container workloads, so no orchestrator sits on top of it
- Fargate is the registry where ECS and EKS store and version their container images
Where should a Fargate task store data that must survive the task stopping?
- On a mounted EFS file system — the task's 20 GB ephemeral storage is wiped when it stops
- On the task's 20 GB ephemeral storage, which is retained and reattached across task restarts
- In the container image itself, writing the data into a layer that ships with each deployment
- On the underlying Fargate host's local disk, which keeps the files after the task exits
A stateless batch job can tolerate interruption. How do you cut its Fargate cost the most?
- Run it on Fargate Spot for up to ~70% off, accepting a possible two-minute interruption
- Increase its vCPU and memory allocation so the job finishes in fewer total billed seconds overall
- Run it on on-demand Fargate with Provisioned Concurrency to keep the cost low
- Switch it from awsvpc to bridge networking mode to lower the per-task cost
Which requirement pushes a workload off Fargate toward the EC2 launch type?
- Needing GPUs, privileged containers, or custom kernel features Fargate does not support
- Wanting zero server management, with no underlying hosts to patch, scale, or right-size yourself
- Wanting fast automatic scaling that adds and removes tasks as load changes
- Having a small team with little spare time for operations work
You got correct