ECS, Fargate, and EKS: The Container Story

Sven's team had built their app as a set of Docker containers. The question they hit on AWS: where do containers run? AWS gives you three answers — Amazon ECS, AWS Fargate, and Amazon EKS — and the choice between them depends on what you value more: control, simplicity, or portability.

This chapter is the comparison and the decision rule.

A Quick Container Refresher

A container packages an application with everything it needs to run — code, runtime, libraries, OS dependencies — into a single image. Containers run on a host that has Docker (or another container runtime) installed.

In production, you do not run one container — you run dozens or hundreds, across many hosts, with auto-scaling, health checks, service discovery, and rolling updates. The system that manages all this is called a container orchestrator.

AWS offers two orchestrators and one launch type:

• Amazon Elastic Container Service (ECS) — AWS's own orchestrator. Deeply integrated, AWS-native;
• Amazon Elastic Kubernetes Service (EKS) — managed Kubernetes, the open-source orchestrator that runs everywhere;
• AWS Fargate — a launch type that runs ECS or EKS tasks without you managing the underlying EC2 hosts.

Amazon ECS

ECS is AWS's container orchestrator. The mental model:

• A task definition is a JSON document describing one or more containers, their CPU, memory, ports, environment variables, IAM role, and networking;
• A task is one running instance of a task definition;
• A service keeps a desired number of tasks running, replaces failed ones, integrates with a load balancer;
• A cluster is a logical grouping — your tasks run in a cluster. ECS supports two launch types: EC2 (you manage the underlying instances) and Fargate (AWS manages them).

AWS Fargate

Fargate is a serverless container runtime. You define a task; AWS finds capacity, starts the container, runs it, charges you for the vCPU-seconds and memory-seconds used.

Key facts:

• No EC2 instances to manage, patch, or pay for separately;
• Per-second billing after the first minute;
• Each task gets its own kernel — strong isolation between tasks;
• Slightly more expensive than equivalent EC2 capacity, but no operational overhead. Fargate works with both ECS and EKS. "Running Fargate" usually means "ECS on Fargate" unless specified otherwise.

Amazon EKS

EKS is managed Kubernetes. AWS runs the Kubernetes control plane for you; you run the workers (or use Fargate for them).

Why pick EKS over ECS:

• You already use Kubernetes elsewhere and want portability;

• Your team has Kubernetes expertise;

• You need the Kubernetes ecosystem — Helm charts, operators, service meshes like Istio;

• You're building a multi-cloud strategy. Why pick ECS over EKS:

• You're all-in on AWS;

• You want lower operational complexity;

• You want tighter integration with AWS services (IAM roles per task, secrets from Secrets Manager, CloudWatch logs by default);

• You prefer ECS's simpler mental model over Kubernetes's deeper one. EKS has a flat hourly fee for the control plane (~$0.10/hour per cluster, or about $73/month) on top of compute costs. ECS control plane is free.

The Decision Matrix

When Sven asked "which one," the answer came from three questions:

• Do you already use Kubernetes? → If yes, EKS;
• Do you want to manage EC2 hosts? → If no, use Fargate as the launch type (with ECS or EKS);
• Do you want the simplest AWS-native option? → ECS on Fargate. For Sven's team, the answer was ECS on Fargate. They didn't have Kubernetes experience, they didn't want to maintain EC2 instances, and ECS integrated cleanly with their existing AWS services.

Networking Modes

ECS task networking has three modes:

• awsvpc — each task gets its own ENI and IP address. The default for Fargate, and recommended for EC2 too;
• bridge — Docker's default networking, tasks share the host's network;
• host — task uses the host's network directly. For modern workloads, use awsvpc. It gives each task its own security group and avoids port conflicts.

Container Image Storage

Container images live in Amazon Elastic Container Registry (ECR):

• Private registry per account, per region;
• IAM-based access control;
• Image scanning for vulnerabilities (basic free, enhanced paid via Amazon Inspector);
• Lifecycle policies to clean up old images. ECS and EKS pull images from ECR (or Docker Hub, or any registry) when starting tasks. Authentication to ECR is automatic when the task role has the right permissions.

App Runner: The Simpler Cousin

For very small containerized apps, AWS also offers App Runner — a fully managed service that takes a container image (or source code) and runs it as a service with a public URL, auto-scaling, and HTTPS. No orchestration to configure.

App Runner fits when you have one or two containers and want a hosted URL with no setup. Beyond that, ECS Fargate gives more control.

For the Exam

DVA-C02 tests:

• ECS task definitions and the difference between tasks and services;
• ECS launch types — EC2 vs Fargate;
• IAM roles — task role (what the container can do) vs task execution role (what ECS can do on the task's behalf);
• ECS network modes — bridge, host, awsvpc;
• ECR authentication and lifecycle policies;
• When to pick ECS vs EKS — the AWS-native vs portable question.