A container packages your application code together with all its dependencies — runtime, libraries, system tools — into a single, portable unit. Unlike a virtual machine, a container shares the host operating system's kernel. This makes containers lightweight (megabytes, not gigabytes), fast to start (seconds, not minutes), and identical across environments (your laptop = staging = production).

Docker is the standard container runtime. You define a Dockerfile, build an image, and run it as a container. The image is immutable — the same image produces the same behavior everywhere.

Running one container on your laptop is easy. Running 200 containers across 50 servers in production — keeping them healthy, distributing traffic, replacing failures, scaling up at peak, and rolling out updates without downtime — is not something Docker alone can do. That is the orchestration problem.

An orchestrator solves: where to place containers, how many to run, when to replace them, and how to update them without downtime. ECS is AWS's answer to this problem.

Amazon ECS (Elastic Container Service) is a fully managed container orchestration service. You define your containers, ECS handles the rest:

The critical point: ECS is the control plane only. It does not run your containers itself. It tells EC2 instances or Fargate to run them. Think of ECS as the "brain" that decides what runs where — the compute comes from your chosen launch type.

When should you pick ECS over other container orchestrators? This comparison covers the three most common choices on AWS:

Think of ECS as a restaurant kitchen:

This is the most common ECS production pattern: an ALB distributes traffic to Fargate tasks running in private subnets across two Availability Zones. If an entire AZ goes down, the remaining tasks continue serving traffic. The ECS Service automatically replaces failed tasks and maintains the desired count of 4.

ECS has five core entities that form a clear hierarchy: Cluster → Service → Task → Container, plus a Task Definition that serves as the blueprint. Understanding how these relate is the single most important concept in ECS.

A cluster is the logical grouping that holds all your ECS resources. It is the top-level boundary — services, tasks, and capacity all live inside a cluster. A cluster does not contain compute by itself — you register EC2 instances to it, or use Fargate which provisions compute on demand.

Common pattern: one cluster per environment — dev, staging, production. Each cluster has its own services and capacity, providing isolation between environments.

A task definition is a JSON document that describes how to run your container(s). Think of it as a blueprint or recipe — it specifies the Docker image, CPU and memory requirements, networking mode, IAM roles, environment variables, log configuration, and more. You never run a task definition directly — you use it to launch tasks.

Here is a minimal task definition in JSON — the key fields every ECS user must understand:

A task is a running instance of a task definition. When ECS launches a task, it pulls the Docker image, allocates CPU/memory, assigns an ENI (in awsvpc mode), and starts the container(s). A task can contain one container (most common) or multiple (sidecar pattern).

An ECS service maintains a desired count of running tasks. If a task crashes, the service replaces it. If you want 4 copies running at all times, the service ensures exactly 4 are always healthy. Services also integrate with load balancers — automatically registering and deregistering tasks as targets.

ECS services are self-healing by default. You don't configure recovery — it is built into the service abstraction. If anything goes wrong with a running task, ECS replaces it automatically. Combined with ALB health checks, this creates a resilient system that recovers from failures without human intervention.

A container is a single Docker container inside a task. Most tasks run one container (your application). But ECS supports multi-container tasks — a common pattern for sidecars like log routers, tracing agents (X-Ray daemon), or envoy proxies. Containers in the same task share the network namespace (they can communicate over localhost) and can share volumes.

This is the most exam-tested ECS concept, and the most commonly confused. ECS uses two separate IAM roles with completely different purposes:

ECS gives you exactly two choices for where your containers physically run: EC2 launch type (you manage the servers) or Fargate launch type (AWS manages the servers). This is the single most impactful architectural decision in ECS — it determines your pricing model, operational burden, scaling behavior, and what features are available.

With the EC2 launch type, you provision and manage a fleet of EC2 instances. You register these instances with your ECS cluster by installing the ECS container agent (pre-installed on the Amazon ECS-optimized AMI). ECS places your containers on these instances based on available CPU and memory. You are responsible for patching, scaling, and monitoring the instances themselves.

With Fargate, you do not provision or manage any servers. You specify CPU and memory requirements in the task definition, and AWS provisions a compute environment for each task. You never see the underlying instance. Each task runs in its own isolated micro-VM (using Firecracker), providing strong security isolation — one customer's task cannot affect another's.

The Fargate pricing model is straightforward: you pay per vCPU-second and per GB-second your task runs. There is no cost when no tasks are running (unlike EC2 where the instance bill continues). This makes Fargate ideal for variable workloads — the cost matches the actual usage precisely.

Fargate does not let you specify arbitrary CPU and memory — there are fixed valid combinations. If you specify an invalid pairing, the task definition fails to register.

A single ECS cluster can use both launch types simultaneously. This is the production-standard pattern for cost optimization: run steady-state workloads on EC2 Reserved Instances (cheapest baseline), and burst overflow to Fargate (no pre-provisioning needed). Capacity Provider strategies let you define the mix — for example, "80% on EC2, 20% overflow on Fargate" or "batch jobs on Fargate Spot, web tier on Fargate."

When using the EC2 launch type, ECS decides which instance gets each new task. Task placement strategies control this decision. They apply only to EC2 — Fargate handles placement internally (one micro-VM per task, AWS chooses the host).

This architecture uses each launch type where it shines: Fargate for the web tier (simple, no servers, auto-scales), EC2 Spot for batch processing (cheapest compute, interruption-tolerant), and EC2 GPU for ML inference (needs hardware that Fargate can't provide). All managed through a single ECS cluster with capacity provider strategies.

Fargate is a serverless compute engine for containers. It removes the server layer entirely — you define what you want to run and how much CPU/memory it needs. AWS handles everything else: provisioning compute, patching the OS, managing the container runtime, and isolating your workload.

Every Fargate task gets its own Elastic Network Interface (ENI) with a private IP address in your VPC. This has major implications:

Fargate does NOT allow arbitrary resource values. You must choose from predefined CPU/memory combinations. If you specify an invalid pair, the task definition will fail to register.

Fargate task startup is not instant — understanding the timeline helps you set realistic expectations for scaling and health check grace periods:

Storage in Fargate is fundamentally different from EC2 — there is no EBS available. Understanding what you get (and don't get) prevents painful surprises:

Fargate is excellent — but it's NOT always the right choice. These limitations are critical for architecture decisions and exam answers:

How your ECS tasks connect to the network determines their security posture, IP behavior, and load balancer integration. ECS supports three networking modes — but for all practical purposes, awsvpc is the only one you should use (and the only one that works with Fargate).

In awsvpc mode, each ECS task gets its own Elastic Network Interface (ENI) — a real VPC network interface with a private IP address. This means each task has its own security group, appears as a distinct network entity in your VPC, and can be targeted directly by load balancers. There is no port conflict — every task listens on the same container port (e.g., 8080) because each has its own IP.

In awsvpc mode, security groups are assigned at the task level (via the service's network configuration), not at the instance level. This gives you fine-grained control:

The key insight: reference security groups by their group ID, not by IP ranges. Since task IPs change on every restart, IP-based rules would constantly break. SG-to-SG references are stable regardless of task IP churn.

ECS integrates with ALB (Application Load Balancer) and NLB (Network Load Balancer) through target groups. When you create a service with a load balancer, ECS automatically registers each task's IP:port as a target. When a task is replaced, the old target is deregistered and the new one registered — seamlessly.

For service-to-service communication without a load balancer, ECS integrates with AWS Cloud Map to provide DNS-based service discovery. When a task starts, it registers a DNS record (e.g., web-api.production.local). Other services resolve this name to get the task's current IP address. When the task stops, the record is removed.

Service Connect is the newer recommended approach. It injects an Envoy sidecar proxy into your tasks automatically. Your code calls http://web-api:8080, and the proxy handles discovery, load balancing, retries, and telemetry. Think of it as a lightweight service mesh managed by ECS — no Kubernetes or App Mesh complexity.

ECS containers need storage for application data, temp files, shared state, and logs. The options depend heavily on your launch type:

Amazon EFS is the most important storage integration for ECS because it works with both EC2 and Fargate and supports concurrent access from multiple tasks across multiple AZs. Mount an EFS file system in your task definition, and every task gets read/write access to the same files — no matter which AZ it runs in.

This pattern is common for file processing: API tasks accept uploads and write to EFS, processor tasks read from EFS and generate thumbnails or transcodes. EFS is shared across all tasks and all AZs — no need to copy files between tasks or use S3 as an intermediary for simple file sharing.

A capacity provider is the bridge between your ECS tasks and the infrastructure they run on. It answers a simple question: "When ECS needs to launch a new task, where does the compute come from?" Without capacity providers you must manually ensure enough EC2 instances exist. With them, ECS automatically provisions capacity — either by scaling an Auto Scaling Group (EC2) or by simply requesting Fargate resources from AWS.

The FARGATE and FARGATE_SPOT capacity providers are built into ECS — you don't create them. They are available on every cluster. Fargate is the default: every task you launch on Fargate uses this provider unless you configure otherwise.

import signal, sys

def graceful_shutdown(signum, frame):
    print("SIGTERM received — finishing work...")
    # flush queues, save checkpoint, close DB
    sys.exit(0)

signal.signal(signal.SIGTERM, graceful_shutdown)

process.on('SIGTERM', async () => {
  console.log('SIGTERM received — draining...');
  server.close(); // stop accepting new requests
  await flushQueues();
  await db.close();
  process.exit(0);
});

For the EC2 launch type, capacity providers link your ECS cluster to an Auto Scaling Group. This enables Cluster Auto Scaling (CAS) — when ECS needs to place tasks but no instance has enough room, CAS triggers the ASG to launch new instances. When instances are underutilized, CAS scales them in. This eliminates manual capacity planning.

The target capacity % is the most important CAS parameter. Set it to 100% for maximum cost efficiency (every instance fully packed, but new tasks wait for scale-out). Set it to 70-80% for responsiveness (headroom means tasks place instantly, but you pay for idle capacity).

A capacity provider strategy defines how tasks are distributed across multiple capacity providers. You assign weights and an optional base count per provider. This is how you build hybrid workloads — for example, "run 2 tasks on on-demand Fargate as baseline, then spread additional tasks 80% to Fargate Spot and 20% to on-demand."

The base count guarantees a minimum number of tasks on that provider (placed first, before weights apply). After base is filled, additional tasks distribute according to the weight ratio. This gives you predictable baseline capacity with elastic overflow.

This pattern maximizes cost savings for batch workloads: EC2 Spot gives the deepest discount (up to 90%), Fargate Spot adds overflow without managing instances, and 2 on-demand Fargate tasks guarantee a minimum processing rate even during Spot capacity shortages.

ECS Service Auto Scaling adjusts the desired task count automatically based on CloudWatch metrics. It uses Application Auto Scaling — the same system that scales DynamoDB tables and Aurora replicas. You define a target value (e.g., "keep average CPU at 70%"), and the system adds or removes tasks to maintain it.

When you update a service (new image version, config change), ECS must replace old tasks with new ones. How it does this determines whether your users experience downtime, mixed versions, or seamless updates.

The deployment circuit breaker automatically detects when a deployment is failing (new tasks keep crashing) and rolls back to the previous stable version. Without it, a bad deployment loops endlessly: ECS launches new task → task crashes → ECS launches another → crashes → repeat forever, burning compute.

Amazon ECR (Elastic Container Registry) is a fully managed Docker container image registry. It stores, manages, and deploys your container images. ECS pulls images from ECR during task launch — this is the standard production pattern. ECR integrates with IAM for access control, encrypts images at rest, and scans for known vulnerabilities.

When ECS launches a task, the image pull follows a precise sequence. Understanding this flow helps debug "CannotPullContainerError" — the most common task startup failure:

ECS services integrate with ALB and NLB via target groups. When a task starts, ECS automatically registers it with the target group. When a task stops, ECS deregisters it after the ALB drains active connections. For Fargate (awsvpc mode), the target type must be ip (not instance).

ECS tasks use two different IAM roles. Confusing them is one of the most common ECS mistakes and a frequent exam question.

Never hardcode secrets (database passwords, API keys) in your Docker image or task definition environment variables. Instead, reference them from AWS Secrets Manager or SSM Parameter Store. ECS injects the secret value at task launch time — your container sees the value as a regular environment variable, but the actual secret never appears in the task definition.

ECS containers send logs to CloudWatch via the awslogs log driver. Each container gets its own log stream within a log group. Container Insights provides CPU, memory, network, and disk metrics at the task and container level — critical for troubleshooting and capacity planning.

X-Ray traces requests across your microservices — showing where time is spent, which service is slow, and where errors occur. For ECS, you run the X-Ray daemon as a sidecar container in the same task. Your application sends trace data to the daemon (localhost:2000/udp), and the daemon forwards it to the X-Ray service.

ECS is flexible enough to support many application styles — from long-running web services to one-shot batch jobs. The key is matching the right ECS features (service vs standalone task, Fargate vs EC2, Spot vs On-Demand) to each workload's requirements.

The most common ECS architecture: multiple independent services, each in its own ECS service with its own task definition, scaling policy, and deployment lifecycle. An ALB routes requests by path to the correct target group. Services discover each other via AWS Cloud Map (Service Discovery) for internal communication.

A service polls SQS for messages and processes them. When the queue grows, Auto Scaling adds tasks. When the queue empties, it scales back down. This pattern decouples producers from consumers and handles traffic spikes gracefully — the queue absorbs the burst while consumers process at their own pace.

One-shot tasks triggered by a schedule (EventBridge cron) or an event. Unlike services, batch tasks run to completion and exit — they are not restarted. Perfect for nightly reports, database migrations, ETL jobs, and data exports.

A modern web application with a static frontend (React/Vue SPA) served from S3 + CloudFront, and an API backend running on ECS behind ALB. CloudFront routes /api/* to ALB origin and everything else to S3. This separates the static delivery (CDN-optimized) from the dynamic API (container-optimized).

When an ECS task stops unexpectedly, ECS records a stopped reason that tells you what went wrong. This is the first place to look when debugging — run aws ecs describe-tasks and check the stoppedReason and containers[].reason fields.

ECS Exec lets you exec into a running container — like docker exec -it but for containers running on Fargate or EC2. It uses AWS Systems Manager Session Manager under the hood. This is essential for debugging running containers that aren't behaving as expected.