ECS and EKS — Containers on AWS

The Foundation of Containerization

To understand orchestration, one must first recognize that a container is a standardized unit of software that packages code and all its dependencies, ensuring the application runs consistently regardless of the environment. Unlike traditional virtual machines, containers share the host operating system kernel, making them lightweight and fast to start. However, managing hundreds of containers manually is impossible. Orchestration engines address this by maintaining the desired state: if a container fails, the orchestrator detects the discrepancy against your defined configuration and automatically launches a replacement. The scheduler is the heart of this process, determining which specific host has enough memory and CPU capacity to support the container, effectively turning a collection of independent servers into a unified pool of compute resources available for your applications to consume dynamically.

# Define a simple task definition for a containerized web server
{
  "family": "web-server",
  "containerDefinitions": [{
    "name": "nginx",
    "image": "public.ecr.aws/nginx/nginx:latest",
    "portMappings": [{"containerPort": 80, "hostPort": 80}]
  }]
}

Amazon ECS: The AWS-Native Choice

Amazon ECS (Elastic Container Service) is AWS's proprietary, highly integrated orchestration platform. Its primary architectural advantage is its deep integration with the rest of the AWS ecosystem, such as IAM for fine-grained security permissions, VPC for networking isolation, and Load Balancers for traffic distribution. ECS treats 'Tasks' as its core primitive; a task definition is a blueprint for your application. Because ECS was built specifically for AWS, the operational overhead is significantly lower compared to generic orchestration tools. You do not manage the control plane, as AWS manages the underlying cluster state for you. This allows teams to iterate faster by avoiding the 'configuration hell' that often plagues complex infrastructure setups, making it the default choice for teams that want to remain firmly within the AWS managed services philosophy.

# Registering a task definition using the AWS CLI
aws ecs register-task-definition --family my-app --container-definitions '[{"name": "app", "image": "nginx"}]'

Amazon EKS: The Industry Standard

Amazon EKS (Elastic Kubernetes Service) provides a managed environment for running the industry-standard Kubernetes platform. Unlike ECS, EKS is designed for maximum portability and compatibility with the wider ecosystem of open-source tooling. Kubernetes is inherently more complex than ECS, utilizing concepts like Pods, Deployments, and Services to manage application lifecycles. EKS is the correct choice when your organization requires a multi-cloud strategy or needs specific advanced scheduling patterns not supported by simpler tools. The management overhead is higher because you must manage Kubernetes-specific manifests, configuration files, and potential plugin compatibility. However, the trade-off is the ability to leverage a massive community of extensions, allowing for highly sophisticated deployment strategies, complex networking topologies, and custom automation that would otherwise require significant development effort to replicate in a proprietary system.

# A Kubernetes deployment manifest to maintain 3 replicas
apiVersion: apps/v1
kind: Deployment
metadata: {name: web-app}
spec:
  replicas: 3
  selector: {matchLabels: {app: web}}
  template:
    metadata: {labels: {app: web}}
    spec:
      containers: [{name: nginx, image: 'nginx'}]

Compute Options: Fargate vs. EC2

Once you have chosen your orchestrator, you must decide where the containers actually run. Fargate is the serverless compute engine for both ECS and EKS. By using Fargate, you relinquish control over the underlying instances; you simply define how much CPU and memory your task needs, and AWS provisions the underlying infrastructure. This removes the need for patching or scaling virtual machines manually. Conversely, the EC2 launch type gives you full control over the underlying cluster instances. You can select specific instance types, manage persistent storage, and optimize for cost by using reserved instances or spot capacity. You choose EC2 mode when your application requires specialized hardware, massive scale optimizations, or deep integration with host-level networking and security configurations that the serverless Fargate abstraction currently cannot provide.

# Fargate launch type configuration snippet for ECS
{ "requiresCompatibilities": ["FARGATE"], "cpu": "256", "memory": "512" }

Service Discovery and Networking

In a distributed system, containers frequently die and are recreated on different physical hosts with different IP addresses. Service discovery solves the problem of how one component finds another. AWS provides integrated tools like Cloud Map and VPC Lattice to keep track of dynamic service locations. When a container starts, it registers its current IP and port; when other services need to communicate, they query these registries rather than hardcoded IPs. This is crucial for microservices, as it decouples internal addressing from service definitions. Furthermore, Load Balancers play a vital role by acting as a stable entry point for external traffic, automatically detecting unhealthy containers via health checks and shifting traffic to healthy ones. Mastering these networking abstractions ensures that your distributed application remains resilient to individual container failures and infrastructure churn.

# ECS service definition connecting to a target group
aws ecs create-service --service-name app-svc --task-definition web-app --load-balancers 'targetGroupArn=arn:aws:tg...,containerName=nginx,containerPort=80'

Interview questions

All AWS interview questions →

Check yourself

Take the full AWS quiz →