AWS Fargate — Serverless Containers

AWS Fargate is a serverless compute engine for containers that works with both Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). Before Fargate, running containers on AWS required you to provision and manage a cluster of Amazon EC2 instances. You had to choose instance types, configure auto scaling groups, patch the operating system, and handle node failures. This is called the "control plane" and "data plane" model: you control the cluster (control plane) and you manage the worker nodes (data plane). Fargate removes the data plane management entirely. You define your task or pod – the container image, CPU, memory, networking, and IAM role – and AWS runs it on a shared, managed infrastructure. You never see the underlying servers; you only pay for the resources your containers consume while they are running.

Fargate uses a lightweight hypervisor technology called Firecracker, which AWS open-sourced in 2018. Firecracker creates micro Virtual Machines (microVMs) that provide strong isolation between containers, similar to how a traditional hypervisor isolates VMs, but with a much smaller footprint. Each Fargate task or pod runs inside its own microVM, which is dedicated to that task. This ensures security and performance isolation even though multiple customers share the same physical host.

When you submit a task definition to ECS (or a pod spec to EKS), the Fargate scheduler determines the optimal placement. It selects a host that has enough spare capacity to meet the task’s resource requirements. The scheduler uses a bin-packing algorithm to maximise utilisation across the fleet of managed hosts. Once a host is selected, Firecracker boots a microVM with the exact CPU and memory you specified, loads the container image from Amazon ECR (Elastic Container Registry), and starts the container. The entire process takes seconds.

Networking is handled via an elastic network interface (ENI) that is attached to each task. This means each Fargate task gets its own primary private IP address from your VPC subnet. You can assign security groups to the task’s ENI, giving you fine-grained network control. Tasks can also be placed behind an Application Load Balancer (ALB) or Network Load Balancer (NLB) for traffic distribution. Fargate integrates with AWS CloudMap for service discovery.

Running containers on-premises requires you to manage the entire stack: physical servers, hypervisor, container runtime, orchestration (like Kubernetes), networking, storage, and security. With Fargate, you skip all of that. Compared to ECS with EC2 (the EC2 launch type), Fargate eliminates the need to manage a cluster of EC2 instances. With EC2 launch type, you must create an Auto Scaling group, choose instance types, handle patching, and optimise bin-packing yourself. Fargate handles bin-packing across AWS’s fleet, which can lead to better utilisation and lower cost for spiky workloads. However, for very predictable, high-utilisation workloads, EC2 launch type can be cheaper because you can reserve instances for a discount. For Kubernetes users, Fargate for EKS is similar: you define a Fargate profile that selects which pods run on Fargate versus on EC2 worker nodes. The pods run in microVMs, but you still manage the Kubernetes control plane (EKS managed, but not serverless).

Use Fargate when:

Avoid Fargate when:

Below is a minimal AWS CLI command to run a simple NGINX container on Fargate. You must have an ECS cluster and a task definition.

aws ecs run-task \
    --cluster my-cluster \
    --task-definition my-task-def \
    --launch-type FARGATE \
    --network-configuration "awsvpcConfiguration={subnets=[subnet-12345],securityGroups=[sg-67890],assignPublicIp=ENABLED}"

The --launch-type FARGATE is crucial. Without it, the default is EC2 launch type. The --network-configuration is required because Fargate tasks use the awsvpc network mode, which gives each task its own ENI.

Here is a snippet of an AWS CloudFormation resource that defines a Fargate service:

MyFargateService:
  Type: AWS::ECS::Service
  Properties:
    Cluster: !Ref MyCluster
    TaskDefinition: !Ref MyTaskDefinition
    LaunchType: FARGATE
    NetworkConfiguration:
      AwsvpcConfiguration:
        Subnets:
          - subnet-12345678
        SecurityGroups:
          - sg-12345678
        AssignPublicIp: ENABLED
    DesiredCount: 2

Note the LaunchType: FARGATE property. Without it, the service would default to EC2 launch type and fail because no EC2 instances are in the cluster.

A media company receives thousands of user-uploaded images every day. They need to resize and compress each image into multiple formats. Using AWS Fargate, they create a task definition that runs a Python script using the Pillow library. The script reads the original image from an S3 bucket, processes it, and writes the output back to S3. They trigger tasks via an SQS queue: a Lambda function consumes messages from SQS and calls run-task for each image. Fargate launches a task per image, processes it in seconds, and terminates. They pay only for the compute time per image. Cost is minimal because tasks are short-lived. If they used EC2, they would need a cluster of instances running 24/7, which would be wasteful. The challenge they face is cold start latency (a few seconds) and the 1-minute minimum billing, but for batch processing of thousands of images, the per-second billing after the first minute still saves money. They also use EFS to share a cache of common assets across tasks, reducing image pull time.

A SaaS startup runs a set of microservices (user service, payment service, notification service) on ECS with Fargate. Each service is a small container with 0.25 vCPU and 512 MB memory. They use an Application Load Balancer to route traffic. Traffic patterns are variable: spikes during business hours, low at night. With Fargate, they use Application Auto Scaling to scale each service based on CPU utilisation. During a spike, Fargate launches new tasks in seconds, handling the load. They never manage servers. The cost is higher per vCPU-hour compared to using EC2 with Reserved Instances, but because they avoid the overhead of managing EC2 and can scale to zero during off-hours, total cost is lower. A common mistake: they initially set the memory too low, causing out-of-memory errors. They learned to monitor memory utilisation and adjust task definitions. Another issue: they used public IPs for tasks, which exposed them to the internet. They switched to private subnets with a NAT gateway and ALB, improving security.

A financial analytics company runs a nightly ETL job that processes terabytes of data from a data warehouse. They use a Fargate task that runs a Spark-like container (using Apache Spark on EMR is separate, but they use a custom container). The job runs for about 2 hours. They schedule it with Amazon EventBridge (CloudWatch Events) to run once per day. With Fargate, they pay for 2 hours of compute per day. If they used EC2, they would need an instance running 24/7 for a 2-hour job, which is wasteful. However, Fargate’s CPU and memory limits (up to 16 vCPU, 120 GB) may not be enough for very large Spark jobs. They found that Fargate works well for medium-sized ETL but for massive jobs, they use EMR on EC2. A misconfiguration: they did not set the task execution role correctly, so the container could not pull the image from ECR, and the task failed with an AccessDenied error. They fixed it by attaching the AmazonECSTaskExecutionRolePolicy.