Containers
Registries, orchestrators, and runtimes for building, storing, and running containerized workloads.
Amazon ECR
Fully managed container image registry for storing, sharing, and deploying Docker/OCI images.
- Private registry by default; ECR Public is a separate gallery for open distribution
- Auth via IAM — no separate registry credentials to manage; ECS, EKS, Fargate, Lambda, and App Runner pull natively
- Image scanning: basic (free, on-push) or enhanced via Amazon Inspector (continuous, OS + language packages)
- Lifecycle policies auto-expire old images; cross-Region and cross-account replication built in; tags can be made immutable
Exam triggers
Phrases and scenarios that point here.
- "Store container images", "private Docker registry", "managed registry" → ECR
- Container deployment on ECS/EKS/Fargate → images come from ECR
- "Scan images for vulnerabilities" → ECR image scanning (enhanced = Inspector)
- Multi-Region container deployments or DR → ECR cross-Region replication
Not this service
- Running the containers themselves → ECS, EKS, or Fargate
- Storing arbitrary files or build artifacts → S3 or CodeArtifact
Use cases
- The image warehouse behind CI/CD: pipeline builds an image, pushes to ECR, ECS/EKS pulls the exact tagged version — the registry is the handoff point between build and deploy
- Sharing one set of blessed base images across an organization via cross-account access, so every team builds on the same patched foundation
- Replicating images to a second Region so DR clusters can pull locally instead of reaching across Regions at deploy time
- Pull-through cache for Docker Hub or other upstream registries — dodges rate limits and keeps builds working when the upstream is down
- Enforcing immutable tags so 'v1.4.2' in production can never silently point at a different image than what was tested
Commonly confused with
Verified against AWS documentation · 2026-08-28
Amazon ECS
AWS-native container orchestration service that runs and scales Docker containers without you managing a control plane.
- Hierarchy: cluster → service → task → container; the task definition is the blueprint (image, CPU/memory, ports, IAM role)
- Two launch types the exam cares about: EC2 (you manage the instances) and Fargate (serverless — AWS manages compute)
- Task role ≠ instance role: the task IAM role grants permissions to the containers, not to the host
- The service scheduler keeps the desired task count running and replaces failed tasks automatically; pair with ALB for web traffic
Exam triggers
Phrases and scenarios that point here.
- "Run Docker containers" + "AWS-native" / "least operational overhead" → ECS, usually on Fargate
- "No infrastructure to manage" or "serverless containers" → Fargate launch type
- "Full control over the underlying instances" (GPU, custom AMI, daemon agents) → EC2 launch type
- Containers need AWS API access → task IAM role, never hardcoded credentials
Not this service
- Kubernetes required (existing manifests, Helm, multi-cloud portability) → EKS
- Just storing container images → ECR
- Simple web app from code without touching orchestration → App Runner
Use cases
- Lifting a Docker Compose side project into production: same containers, but ECS restarts them when they crash at 3 a.m. instead of you
- Microservices behind an ALB, where each service scales its task count independently — checkout scales up on payday, search doesn't
- Scheduled batch jobs (nightly ETL, report generation) as Fargate tasks fired by EventBridge — compute exists only for the minutes the job runs
- Bursty workloads on Fargate: think of EC2 launch type as owning a car and Fargate as taking taxis — taxis win when trips are short and unpredictable
- Hybrid teams using EC2 launch type to bin-pack many small containers onto reserved instances they already pay for
Commonly confused with
Verified against AWS documentation · 2026-08-28
Amazon EKS
Managed Kubernetes control plane — AWS runs the masters, you run the workloads.
- AWS operates the Kubernetes control plane across multiple AZs; you bring worker compute — managed node groups (EC2), self-managed EC2, or Fargate
- Runs upstream, certified Kubernetes — existing manifests, kubectl, and Helm charts work unchanged, and workloads stay portable off AWS
- Fargate runs pods serverless — no nodes to patch, scale, or right-size; each pod gets its own isolated compute
- Hybrid flavors: EKS Anywhere (run clusters on your own hardware), EKS Distro (the same Kubernetes distribution, self-run anywhere)
Exam triggers
Phrases and scenarios that point here.
- "Kubernetes", "K8s", "open-source orchestration", "avoid vendor lock-in" → EKS, not ECS
- "Migrate existing on-prem Kubernetes workloads to AWS with minimal changes" → EKS
- Kubernetes + "no server management" → EKS on Fargate
- Kubernetes on your own on-prem hardware → EKS Anywhere
Not this service
- Containers with no Kubernetes requirement, simplest AWS-native option → ECS
- Just deploy a container from a repo, zero orchestration knowledge → App Runner
Use cases
- Lift-and-shift an on-prem Kubernetes estate to AWS — the team keeps its manifests, Helm charts, and muscle memory instead of relearning a proprietary orchestrator
- Multi-cloud or exit-strategy mandates, where the same workload definitions must run on AWS today and somewhere else tomorrow
- Teams already invested in the Kubernetes ecosystem (Istio, ArgoCD, Prometheus operators) that ECS can't host
- Batch/ML jobs on spare cluster capacity — Kubernetes scheduling packs bursty jobs alongside steady services on the same nodes
- Platform teams offering an internal 'paved road': one shared cluster, many product teams deploying via namespaces and RBAC
Commonly confused with
Verified against AWS documentation · 2026-08-28
AWS App Runner
Fully managed service that runs containerized web apps and APIs directly from source code or a container image — no infrastructure to manage.
- Point it at a GitHub repo or ECR image — App Runner builds, deploys, load balances, and serves over HTTPS automatically
- Auto scales on concurrent requests per instance; scales down to provisioned (idle) instances, not to zero
- VPC connector lets the app reach private resources like RDS; the app itself is internet-facing by default
- Built-in TLS and load balancing — no ALB to configure or pay for
- Reality check: closed to new customers since April 2026, no new features planned — AWS now points new workloads to ECS Express Mode. Exams still test it as the 'easiest container deployment' answer
Exam triggers
Phrases and scenarios that point here.
- "Containerized web app with no infrastructure or orchestration experience" → App Runner
- "Deploy straight from source code repository" with automatic build pipeline → App Runner
- "Simplest / fastest way to get a container serving HTTPS traffic" → App Runner
- Team has no ECS, EKS, or networking knowledge and just needs a web service running → App Runner
Not this service
- Full control over orchestration, networking, or task placement → ECS or EKS
- Event-driven, short-lived functions → Lambda
- Background workers or non-HTTP workloads → ECS on Fargate (App Runner only serves web traffic)
- Static site or frontend hosting → Amplify or S3 + CloudFront
Use cases
- A two-person startup ships a Node.js API from GitHub to a live HTTPS endpoint in minutes — no Dockerfile-to-production pipeline to build, no cluster to babysit
- Internal tools and admin dashboards where paying an engineer to manage ECS would cost more than the app earns
- Prototypes and MVPs that need a real production URL today and can migrate to ECS later if they grow
- Microservice APIs behind a VPC connector talking to a private RDS instance, without anyone touching subnets or security groups directly
Commonly confused with
Verified against AWS documentation · 2026-08-28