AWS Fargate
Serverless compute engine for containers
Imagine you have a shipping container full of your application, and you need someone to run it. Normally, you'd rent a truck (EC2 instance), load the container on it, and drive it yourself. Fargate is like calling a delivery service where you hand them the container, tell them how much CPU and memory it needs, and they handle everything else. You don't manage trucks, don't worry about maintenance, don't even see the trucks. You just pay for the time your container is running. It's serverless containers: all the benefits of containerization without managing the underlying servers.
Fargate is a serverless compute engine for containers that works with both ECS (Elastic Container Service) and EKS (Elastic Kubernetes Service). Instead of provisioning EC2 instances to run containers, you define task definitions (ECS) or pod specs (EKS) specifying CPU, memory, and container images. Fargate provisions the exact compute resources needed and runs your containers in isolated microVMs.
Key Capabilities
- Runs ECS tasks and EKS pods on fully managed infrastructure with no EC2 instances to provision, patch, or scale
- Each task or pod gets its own isolated kernel and a dedicated VPC network interface with its own IP address
- CPU and memory are configured at the task or pod level, with billing based on the resources requested
- Fargate Spot provides significantly discounted pricing for fault-tolerant, interruptible workloads
- IAM task roles grant individual containers scoped AWS permissions without sharing credentials across a host
- Supports ephemeral storage up to 200GB per ECS task for temporary data within a container's lifecycle
Gotchas & Constraints
Gotcha #1: Fargate tasks take 30-60 seconds to start (slower than EC2-backed containers), so it's not ideal for bursty workloads requiring instant scale. Gotcha #2: Fargate costs more per vCPU-hour than EC2, so for steady-state workloads running 24/7, EC2 might be cheaper. Constraints: Limited to specific CPU/memory combinations, GPU support is available for AI inference workloads (announced late 2024), and tasks are ephemeral; there is no persistent storage except EFS mounts.
A microservices architecture runs 20 different services, each containerized. Previously, they ran ECS on EC2 instances, but managing cluster capacity was a nightmare: over-provisioning wasted money, under-provisioning caused outages. They migrate to Fargate, defining each service as an ECS task with specific CPU/memory requirements. Fargate automatically provisions compute for each task. When a service needs to scale (e.g., the payment service during checkout spikes), ECS launches more Fargate tasks without worrying about cluster capacity. They use Application Load Balancer for traffic distribution and Service Discovery for inter-service communication.
The Result
40% reduction in operational overhead, no more cluster management, and precise cost allocation per service.