AWS Containers
Fargate
Serverless compute engine for containers - no EC2 instances to manage
AWS Fargate is a serverless compute engine for containers that works with both ECS and EKS, eliminating the need to provision, configure, or scale EC2 instances. You define CPU and memory requirements per task or pod, and Fargate allocates compute resources automatically. Fargate is ideal for variable workloads, batch jobs, and teams who want to focus on application code rather than infrastructure management.
How Fargate Executes Containers
Fargate uses a micro-VM architecture. Each task (ECS) or pod (EKS) runs in an isolated Firecracker micro-VM with dedicated vCPU and memory. This provides stronger isolation than shared EC2 nodes where containers share the kernel.
| Aspect | Traditional EC2 Containers | Fargate |
|---|---|---|
| Isolation | Shared EC2 kernel - container-level isolation | Dedicated micro-VM per task/pod - VM-level isolation |
| Provisioning | Provision EC2 instances before deploying | No instances to provision - define CPU/memory in task |
| Visibility | Full access to host OS, logs, disk | No host access - all through CloudWatch Logs and ECS APIs |
| Scaling | Scale instances + tasks separately | Scale tasks only - no node scaling needed |
| Startup time | Near-instant if instance is running | 10-30 seconds for new task - micro-VM boot time |
| Multi-tenancy | Multiple customers may share a host | Single tenant per micro-VM - stricter compliance |
Fargate's Firecracker micro-VM isolation is the reason it qualifies for compliance frameworks (PCI-DSS, HIPAA) that require strong tenant isolation. Each task is completely isolated at the hypervisor level.
CPU and Memory Sizing Combinations
Fargate does not let you pick arbitrary CPU and memory values. You must use one of the supported combinations. Choosing the wrong size is a common cost and performance issue.
| vCPU | Allowed Memory Range | Granularity |
|---|---|---|
| 0.25 | 512MB - 2GB | 512MB increments |
| 0.5 | 1GB - 4GB | 1GB increments |
| 1 | 2GB - 8GB | 1GB increments |
| 2 | 4GB - 16GB | 1GB increments |
| 4 | 8GB - 30GB | 1GB increments |
| 8 | 16GB - 60GB | 4GB increments |
| 16 | 32GB - 120GB | 8GB increments |
Ephemeral storage is 20GB by default, expandable to 200GB for an additional cost. Fargate also supports EFS for shared persistent storage.
Fargate charges for the vCPU and memory you configure, not what you actually use. A task configured as 4 vCPU/8GB that only uses 0.5 vCPU/1GB still pays for 4 vCPU/8GB. Right-size your tasks using CloudWatch Container Insights metrics.
Fargate Pricing vs EC2 - When Each Wins
Fargate pricing is per-second for vCPU and memory. The break-even point with EC2 depends on utilization. Below ~20-30% average CPU utilization, Fargate is often cheaper; above that, EC2 reserved instances win.
| Pricing Component | Rate (us-east-1) | Notes |
|---|---|---|
| vCPU | $0.04048/vCPU/hour | Charged per second, 1-minute minimum |
| Memory | $0.004445/GB/hour | Charged per second, 1-minute minimum |
| Fargate Spot vCPU | ~$0.01220/vCPU/hour (~70% discount) | Can be interrupted - use for fault-tolerant workloads |
| Fargate Spot memory | ~$0.00133/GB/hour | Same discount as vCPU |
| Ephemeral storage (>20GB) | $0.000111/GB/hour | First 20GB free |
Cost comparison example: 1 vCPU, 2GB Fargate task running 24/7 for 30 days = (~$0.04048 + 2 x $0.004445) x 720 hours = ~$35.63/month. Equivalent t3.small (2 vCPU, 2GB) On-Demand = $15.18/month, 1-year Reserved = $9.49/month.
| Scenario | Winner | Reason |
|---|---|---|
| Spiky web API (20% avg utilization) | Fargate | No idle capacity cost |
| Always-on microservice at 80% CPU | EC2 Reserved | Fargate 3x more expensive at high utilization |
| Nightly batch job (2 hours/day) | Fargate | Pay only for 2 hours, no idle instance cost |
| High throughput data processing | EC2 (c5.xlarge) | Better price-per-vCPU and network throughput |
| Dev/test environments | Fargate | Scale to zero, no overnight costs |
| Compliance-sensitive multi-tenant | Fargate | VM-level isolation without managing hosts |
Networking, Security Groups, and VPC Design
Every Fargate task runs in awsvpc networking mode and gets its own ENI injected into your VPC. This means every task has a unique private IP and can have its own security group.
Fargate tasks in private subnets need either a NAT Gateway or VPC endpoints to reach AWS services and ECR.
| Connectivity Need | Solution | Cost |
|---|---|---|
| Pull from ECR | ECR VPC endpoint (PrivateLink) | VPC endpoint + data processing charges |
| Write CloudWatch Logs | CloudWatch Logs VPC endpoint | VPC endpoint charges |
| Access internet | NAT Gateway in public subnet | $0.045/hr + data charges |
| Access S3 | S3 Gateway endpoint | Free |
| Access Secrets Manager | Secrets Manager VPC endpoint | VPC endpoint charges |
For production Fargate in private subnets, the minimum VPC endpoints needed are: ecr.api, ecr.dkr, s3 (gateway), and logs. Without these, tasks fail to pull images or write logs. S3 is needed because ECR stores image layers in S3 internally.
# Minimal ECS Fargate task in private subnet (via CDK-like CloudFormation)
# Security group - inbound from ALB only, outbound to VPC endpoints
TaskSecurityGroup:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Fargate task SG
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 8080
ToPort: 8080
SourceSecurityGroupId: !Ref ALBSecurityGroup
SecurityGroupEgress:
- IpProtocol: "-1"
CidrIp: 10.0.0.0/16 # VPC CIDR - reaches VPC endpoints and RDSObservability: Logs, Metrics, and Debugging Without SSH
With Fargate, you cannot SSH into the host. All observability must be configured in advance through logging, metrics, and the ECS Exec feature.
| Observability Tool | What It Provides | How to Configure |
|---|---|---|
| CloudWatch Logs | Container stdout/stderr | awslogs log driver in task definition |
| Container Insights | CPU, memory, network, disk per task | Enable on ECS cluster |
| ECS Exec | Interactive shell into running container | enableExecuteCommand=true on service |
| AWS X-Ray | Distributed tracing | Add X-Ray sidecar container to task definition |
| FireLens | Route logs to external destinations (Splunk, Datadog) | Add Fluent Bit sidecar as log router |
# ECS Exec - interactive access to running Fargate task (no SSH needed)
# 1. Enable on service
aws ecs update-service \
--cluster my-cluster \
--service my-service \
--enable-execute-command
# 2. Start interactive session
aws ecs execute-command \
--cluster my-cluster \
--task arn:aws:ecs:us-east-1:123:task/abc123 \
--container my-app \
--interactive \
--command "/bin/bash"
# Requires: SSM agent in container, correct IAM permissions on task roleECS Exec requires the SSM Agent to be running inside the container. Official AWS images (Amazon Linux 2, ECS-optimized) include it. Custom minimal images (Alpine-based) do not. Add the SSM agent installation to your Dockerfile if using ECS Exec on custom images.
Interview Focus Points
- 1When would you choose Fargate over EC2 launch type for ECS - what is the cost break-even point?
- 2How does Fargate networking work - why does each task need its own ENI and what are the implications?
- 3What VPC endpoints are required for Fargate tasks in private subnets and why?
- 4How does Fargate Spot work and what types of workloads are suitable for it?
- 5How do you debug a Fargate container when you cannot SSH into the host?
- 6Explain the Firecracker micro-VM used by Fargate - what security benefits does it provide?
- 7How would you right-size a Fargate task - what metrics would you look at?
- 8What are the limitations of Fargate compared to EC2 launch type (DaemonSets, GPU, storage, etc.)?
- 9How does Fargate handle persistent storage - what are the options and trade-offs?