Right, so you’ve got your container image. You’ve defined your task. Now you have to decide where to run the thing. Do you rent a virtual server (an EC2 instance), install Docker on it, and manage the whole circus yourself? Or do you say, “You know what, I have better things to do than patch operating systems and manage a cluster of servers,” and hand that mess off to AWS?

That’s Fargate. It’s the “just run my container, I don’t want to manage a server” option. You’re not paying for a whole EC2 instance 24/7; you’re paying for the vCPUs and memory your actual task uses, down to the second. It’s serverless for containers, and it’s glorious for about 90% of the workloads I’ve ever built.

The mental shift is crucial: you’re not thinking in servers, you’re thinking in tasks. You tell Fargate, “I need one instance of my api task running with 1 vCPU and 2GB of RAM,” and it finds a slice of a physical machine somewhere in its massive fleet to run it. You never SSH into it. You never see the underlying OS. It’s just… running.

The Fargate Tax (and Why It’s Worth It)

First, the bad news: Fargate is more expensive per second of compute than equivalent EC2 capacity. There, I said it. AWS is charging you a premium for the privilege of not having to manage the underlying EC2 instances. But before you rage-close this book, do the real math. Factor in the time your team isn’t spending on:

  • Patching the underlying OS for CVEs every other week.
  • Right-sizing, provisioning, and scaling instance groups.
  • Monitoring disk space on the underlying hosts.
  • Dealing with failed instance health checks.

For most teams, the “Fargate Tax” is the cheapest part of their infrastructure. It’s an operations team in a box.

The Nitty-Gritty: CPU and Memory Allocations

Fargate isn’t a free-for-all. It has strict, and frankly kinda weird, combinations of vCPU and memory you’re allowed to use. You can’t just say “I want 1.5 vCPUs and 3.5 GB of RAM.” You have to pick from their menu.

There are two modes: v1.4 (the older one) and the newer, more flexible v1.3+ (which you should always use unless you have a very good reason not to). For Linux tasks on platform version 1.4, the combinations are rigid. But for the newer LATEST platform version (which uses the Fargate v1.3+ infra), you have much more flexibility, but you’re still bound by a ratio. You can’t, for example, have a huge amount of memory with a tiny CPU.

Here’s a task definition snippet that shows a Fargate-specific configuration. Notice the requiresCompatibilities and cpu/memory settings at the task level, not the container level.

{
  "family": "my-fargate-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "1024",
  "memory": "2048",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "my-app",
      "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest",
      "portMappings": [
        {
          "containerPort": 8080,
          "hostPort": 8080,
          "protocol": "tcp"
        }
      ],
      "essential": true,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-fargate-app",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

Networking: You’re in awsvpc Now, Baby

This is non-optional and critically important. For Fargate, your networkMode must be awsvpc. This isn’t your grandma’s Docker bridge networking. This means each task gets its own elastic network interface (ENI) directly attached to your VPC. It gets its own private IP address.

Why is this awesome?

  1. Security Groups: You can apply a security group directly to the task itself. This is a way cleaner security model than managing rules on a shared EC2 host.
  2. Service Discovery: It plays nicely with AWS Cloud Map because each task has a stable, unique IP.
  3. Simplicity: It behaves like any other EC2 instance in your VPC. No weird port mapping nonsense to figure out.

The pitfall? You absolutely must create a VPC and subnets that can assign enough private IP addresses to all your running tasks. And for the love of all that is holy, make sure those subnets have routes to a NAT Gateway if your task needs to pull a container image from the internet (like Docker Hub) or talk to other AWS services.

The Cold, Hard Truth About Storage

Fargate tasks are ephemeral. The file system is temporary. The moment your task stops, everything written to it vanishes into the ether. This is the number one “oh crap” moment for people migrating from EC2-backed ECS.

You have two escapes from this prison:

  1. Mount EFS Volumes: This is the preferred method. You can mount an Elastic File System (EFS) volume into your Fargate task. It’s a fully-managed NFS share that persists independently of your task. Perfect for shared configuration, temporary processing space, or anything that needs to live longer than the task.
  2. Mount EBS via AWS Lambda: Just kidding. You can’t. Don’t even think about it. This is the biggest limitation and a clear line in the sand from AWS: Fargate is for stateless, ephemeral compute. If you need a stateful, persistent block store, you’re back in EC2-land. Plan your architecture accordingly.

So, when do you choose Fargate? Almost always. Start with it. Default to it. Only retreat to EC2 if you have a hard requirement it can’t meet (like a specific kernel module, GPU access, or that persistent EBS volume) or if your cost modeling shows the premium is genuinely unsustainable for your specific, constant workload. For everyone else, welcome to the future. It’s serverless, and your SSH keys are no longer required.