7.4 Container Orchestration — ECS, EKS, and ECR

ECS vs. EKS vs. ECR: The Core Map

Three services dominate container questions. Amazon ECR (Elastic Container Registry) stores images. Amazon ECS (Elastic Container Service) is AWS's own orchestrator with the simplest setup and no control-plane charge. Amazon EKS (Elastic Kubernetes Service) runs upstream Kubernetes for portability and the K8s ecosystem, but its control plane costs $0.10/hour (about $73/month) per cluster.

Both ECS and EKS choose a launch type independent of the orchestrator:

Trap: "least operational overhead" steers you to Fargate, but "need GPUs" or "need a custom kernel module" forces the EC2 launch type because Fargate exposes no host.

Amazon ECR: Registry Features That Get Tested

ECR is a fully managed registry for Docker and OCI images, integrated with ECS, EKS, and Lambda container images.

Worked example: A CI pipeline pushes a new image on every commit, and untagged layers pile up. The correct, no-code fix is an ECR lifecycle policy such as "expire untagged images older than 14 days" and "keep only the 10 most recent tagged images." Writing a Lambda to delete images, or applying S3 lifecycle rules, is wrong because ECR exposes its own native retention rules.

Scanning trap: if a question wants images checked for CVEs automatically on push, that is ECR image scanning, not a third-party tool bolted onto the pipeline.

Scaling, Placement, and Service Discovery

ECS Service Auto Scaling

ECS scales the number of running tasks using Application Auto Scaling. It can target average CPU, average memory, ALB request count per target, or any custom CloudWatch metric. This is distinct from EC2 Auto Scaling, which scales instances; on Fargate there are no instances to scale, only tasks.

Task placement strategies (EC2 launch type)

Capacity providers and cost

Service discovery

AWS Cloud Map registers ECS tasks under friendly names (for example, inventory.internal) and creates Route 53 records automatically, plus an API for lookups. Containers call each other by name, so scaling tasks up or down never breaks references to changing IP addresses. For richer traffic control, App Mesh adds a service mesh.

Decision recap: least ops to manage -> Fargate; cheapest containers for batch -> Fargate Spot or EC2 Spot with binpack; auto vulnerability scanning + retention -> ECR scanning + lifecycle policy; name-based microservice lookup -> Cloud Map.

Task Definitions, Networking, and Hybrid Options

An ECS task definition is the blueprint the exam keeps probing: it declares the container image (from ECR), CPU and memory, the task role (IAM permissions the application code uses) versus the task execution role (permissions ECS needs to pull the image and write logs), port mappings, and the logging driver. Confusing the two IAM roles is a frequent distractor; the task role is for your code's AWS calls, the execution role is for the ECS agent's plumbing.

Networking mode matters for Fargate: Fargate tasks always use awsvpc mode, giving each task its own elastic network interface and security group, so you secure traffic per task rather than per host. This is why "each container needs its own security group and private IP" points to awsvpc / Fargate.

Hybrid and edge container deployments

ECS Anywhere and EKS Anywhere extend the orchestration control plane to on-premises or other-cloud hardware you manage, so a single ECS/EKS interface schedules containers in your data center. Choose these when a question requires running containers on existing on-premises servers while still managing them through AWS APIs. For fully disconnected or low-latency edge sites, AWS Outposts can run ECS/EKS on AWS-managed racks inside your facility.

Worked example: A regulated workload must keep some containers on-premises for data-residency reasons but be operated with the same tooling as cloud workloads. The answer is ECS Anywhere (or EKS Anywhere), not lift-and-shift to EC2, because it preserves a single managed control plane across both environments.