AWS Fargate Explained: Serverless Containers Without Managing Servers

If you're running containers on AWS, you've likely encountered the question: should I use Fargate or EC2? AWS Fargate eliminates the need to manage underlying servers for your containerized applications, but that convenience comes with tradeoffs.

This guide explains what Fargate is, how it works, and when it makes sense for your workloads.

What Is AWS Fargate?

AWS Fargate is a serverless compute engine for containers that works with both Amazon ECS (Elastic Container Service) and Amazon EKS (Elastic Kubernetes Service). With Fargate, you don't provision, configure, or scale virtual machines—AWS handles all infrastructure management.

You define your container requirements (CPU, memory, networking), and Fargate:

• Provisions the right amount of compute
• Runs your containers in isolation
• Scales automatically based on demand
• Patches and maintains the underlying infrastructure

Think of Fargate as "Lambda for containers"—you focus on your application, AWS handles everything else.

Fargate vs EC2: Key Differences

When running containers on AWS, you have two main options:

How Fargate Pricing Works

Fargate pricing is based on the vCPU and memory resources your containerized application requests. You pay for what you use, billed per second with a one-minute minimum.

Current Pricing (US East - N. Virginia)

Example Cost Calculation

For a container running with 0.5 vCPU and 1 GB memory for 24 hours:

vCPU cost: 0.5 × $0.04048 × 24 = $0.49
Memory cost: 1 × $0.004445 × 24 = $0.11
Total daily cost: $0.60
Monthly estimate: ~$18

Cost Comparison: Fargate vs EC2

For a workload requiring 2 vCPU and 4 GB memory running 24/7:

Key insight: Fargate costs more per unit but can save money for:

• Variable workloads that scale up/down
• Workloads that don't run 24/7
• Teams without capacity to manage infrastructure

When to Use Fargate

Fargate Is Ideal For:

1. Microservices architectures - Each service scales independently
2. Batch processing jobs - Pay only during processing
3. Development and staging environments - No wasted capacity
4. Teams without infrastructure expertise - Reduces operational burden
5. Unpredictable traffic patterns - Automatic scaling without over-provisioning
6. Quick deployments - No cluster capacity planning needed

Stick with EC2 When You Need:

1. GPU workloads - Machine learning, video processing
2. Persistent high utilization - 24/7 workloads benefit from Reserved Instances
3. Custom AMIs or kernel configurations - Specialized OS requirements
4. Maximum cost efficiency at scale - Large, predictable workloads
5. Spot Instance savings - EC2 Spot can be 70-90% cheaper

Fargate Architecture

Here's how Fargate fits into the AWS container ecosystem:

┌─────────────────────────────────────────────────────────┐
│                    Your Application                      │
├─────────────────────────────────────────────────────────┤
│              ECS Task Definition / EKS Pod               │
│   (Container image, CPU, memory, networking, IAM role)   │
├─────────────────────────────────────────────────────────┤
│                     AWS Fargate                          │
│        (Serverless compute - you don't see this)         │
├─────────────────────────────────────────────────────────┤
│              AWS Infrastructure (EC2, etc.)              │
│           (Managed entirely by AWS)                      │
└─────────────────────────────────────────────────────────┘

Each Fargate task runs in its own isolated environment with:

• Dedicated kernel
• No shared resources with other customers
• Encrypted ephemeral storage

Getting Started with Fargate

Basic ECS Task Definition for Fargate

{
  "family": "my-fargate-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "nginx:latest",
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ],
      "essential": true
    }
  ]
}

Key Configuration Points

1. Network mode must be awsvpc - Each task gets its own ENI
2. CPU and memory are at task level - Not individual containers
3. Valid CPU/memory combinations exist - Not all combinations work

Supported CPU and Memory Combinations

Fargate Spot: Reduce Costs by 70%

Fargate Spot runs tasks on spare AWS capacity at up to 70% discount. Like EC2 Spot Instances, tasks can be interrupted with a 2-minute warning.

Good for Fargate Spot:

• Batch processing
• CI/CD builds
• Data transformation jobs
• Any interruptible workload

Not for Fargate Spot:

• User-facing web applications
• Real-time APIs
• Anything requiring high availability

Enable Fargate Spot in ECS

{
  "capacityProviderStrategy": [
    {
      "capacityProvider": "FARGATE_SPOT",
      "weight": 1,
      "base": 0
    },
    {
      "capacityProvider": "FARGATE",
      "weight": 1,
      "base": 1
    }
  ]
}

This configuration runs at least one task on regular Fargate and additional tasks on Spot.

Fargate with EKS vs ECS

Fargate works with both ECS and EKS. Here's how to choose:

Recommendation: Use ECS + Fargate unless you specifically need Kubernetes features or are already invested in the Kubernetes ecosystem.

Common Fargate Gotchas

1. Cold Starts

Fargate tasks can take 30-60 seconds to start. For latency-sensitive applications:

• Keep minimum task count > 0
• Use Application Auto Scaling with target tracking
• Consider ECS Service Connect for service discovery

2. Storage Limitations

Fargate provides 20 GB ephemeral storage by default (configurable up to 200 GB). For persistent storage:

• Use EFS (Elastic File System) mounts
• Store data in S3
• Use external databases (RDS, DynamoDB)

3. Networking Complexity

Each Fargate task needs:

• A VPC with subnets
• Security groups
• NAT Gateway for private subnet internet access

This adds cost and complexity compared to Lambda.

4. No SSH Access

You cannot SSH into Fargate tasks. For debugging:

• Use ECS Exec for interactive sessions
• Implement robust logging (CloudWatch Logs)
• Add health check endpoints

Monitoring Fargate Workloads

Essential CloudWatch Metrics

Enable Container Insights

Container Insights provides deeper visibility:

aws ecs update-cluster-settings \
  --cluster my-cluster \
  --settings name=containerInsights,value=enabled

Migration Path: EC2 to Fargate

If you're currently on ECS with EC2, migration to Fargate is straightforward:

1. Update task definition - Add "requiresCompatibilities": ["FARGATE"]
2. Set network mode - Change to "networkMode": "awsvpc"
3. Configure CPU/memory - Move from instance-level to task-level
4. Update service - Change launch type to FARGATE
5. Test in staging - Verify performance and costs

Final Thoughts

AWS Fargate removes infrastructure management from container deployments, letting teams focus on applications rather than servers. It's not always the cheapest option, but for teams without dedicated infrastructure expertise or workloads with variable demand, the operational simplicity often justifies the premium.

Start with Fargate for new projects, then optimize to EC2 if cost analysis shows significant savings potential. The migration path in either direction is manageable.