ECS Fargate Deep Dive Part 1: How Fargate Really Works

Introduction

This is Part 1 of our ECS Fargate Deep Dive series. In these posts, we’ll strip away the abstraction and look at what’s really happening under the hood when you launch a Fargate task.

We’ll cover internals like Firecracker microVMs, ENI networking, IAM roles, storage and scheduling - the things AWS doesn’t show you in the console.

ECS Fargate: Behind the Scenes of Serverless Containers

When you launch a task on ECS Fargate, it feels like magic — no EC2 instances, no cluster autoscaling, just containers running. But what’s actually happening under the hood?

Let’s peel back the layers.

Why Should You Care?

Fargate feels “serverless for containers” — but knowing how it works helps you:

• Debug networking issues (e.g. ENI/IP exhaustion).
• Understand cold starts and scaling behaviour.
• Make cost vs flexibility trade-offs between ECS on EC2 and Fargate.
• See why Fargate is safer in multi-tenant workloads.

What Fargate Really Is

Fargate isn’t a special kind of ECS cluster. It’s an AWS-managed capacity layer that runs your containers in lightweight microVMs. You pick CPU, memory, networking, and IAM roles — AWS handles the hosts, patching, and kernel security.

Deep Dive: What Actually Happens

Firecracker MicroVMs

• Each Fargate task = one Firecracker microVM.
• Built on KVM, stripped down for speed.
• Isolation is stronger than plain Docker namespaces.
• Each has its own kernel, cgroups, and seccomp profile.

This is why tasks don’t share kernels, unlike ECS on EC2.

Networking

When you start a Fargate task:

• AWS provisions an Elastic Network Interface (ENI) in your VPC.
• Every task gets its own Elastic Network Interface (ENI).
• The ENI is placed directly in your VPC subnet and directly to the microVM.
• Security groups/NACLs apply directly to the task.
• From a network perspective, tasks behave like first-class EC2 instances. This is why Fargate tasks look and feel like EC2 instances on the network.

Storage & Security

• Ephemeral storage: 20 GiB by default (up to 200 GiB). Dies with the task.
• Persistent storage: use EFS mounts if needed.
• IAM Roles for Tasks: AWS injects temporary credentials directly into the microVM.
• No SSH/SSM access — AWS fully manages the hosts.

Scheduling & Scaling

1. ECS control plane tells Fargate: “Run this task with X CPU, Y memory.”
2. Fargate provisions a microVM, attaches an ENI, pulls the image and starts the task.
3. Scaling = AWS spinning up/destroying microVMs behind the scenes.

Performance & Limits

• Cold starts: ~30–60s (microVM boot + ENI attach + image pull).
• Resource limits: 0.25–16 vCPUs, 0.5–120 GiB RAM.
• Restrictions: no privileged mode, no GPUs, no custom kernels. Can't run DinD (docker in docker) in a task.
• Cost model: billed per vCPU-second + GiB-second.

ECS on EC2 vs ECS Fargate

Architecture Diagram

Takeaways

• Each Fargate task runs in its own microVM, not a shared host kernel.

• Networking is first-class: ENI per task, direct VPC integration.

• You give up host control in exchange for security + simplicity.

• Cold starts, ENI limits, and no privileged mode are the main gotchas.

How to Think of It

Fargate is basically AWS Lambda for containers:

• Instead of functions, you run containers.

• Instead of ephemeral processes, you get microVMs.

• You trade host control for simplicity, security, and auto-scaling.