1.6 Containers: ECS, ECR, Fargate

Containers on AWS

Amazon Elastic Container Service (ECS) is AWS's native orchestrator for Docker containers; Amazon Elastic Kubernetes Service (EKS) runs managed Kubernetes for teams standardized on it. For DVA-C02 you mainly need ECS building blocks, the two compute launch types, the IAM role split, the ECR push/pull flow, and the containers-versus-Lambda decision. Expect troubleshooting items — image pull fails before the app runs, no server management wanted, or work exceeds 15 minutes.

Task Definitions and Services

A task definition is the JSON blueprint for one or more containers in a task: the container image URI, CPU and memory (at the task and container level), port mappings, environment variables, secrets, logging configuration, and the two IAM roles. A running instantiation is a task. A service maintains a desired count of tasks, replaces unhealthy ones, performs rolling deployments (minimumHealthyPercent / maximumPercent), and registers tasks behind an Application or Network Load Balancer for steady, long-running workloads.

Task definitions are versioned by revision; updating one creates a new revision you point the service at.

Launch Types: EC2 vs Fargate

Fargate removes capacity planning entirely: you declare CPU and memory per task and AWS runs it. The EC2 launch type still requires you to keep the underlying instances patched and scaled, typically via an Auto Scaling group registered as a capacity provider.

The Two ECS IAM Roles

This distinction is heavily tested:

• Task role — permissions for your application code inside the container (for example, read from S3, write to DynamoDB, publish to SNS). This follows least privilege for what the app actually does.
• Task execution role — permissions for the ECS agent / Fargate infrastructure to pull the image from ECR, fetch secrets, and send container logs to CloudWatch Logs. It runs before and around your code, not inside it.

Keep them separate so application permissions stay independent of platform plumbing. The diagnostic rule: if a task fails to start with an image-pull or logging error before your code runs, suspect the task execution role; if your running app gets AccessDenied calling another AWS service, suspect the task role.

Amazon ECR

Amazon Elastic Container Registry (ECR) is a managed, private OCI/Docker registry integrated with IAM and encryption. The push workflow is: aws ecr get-login-password | docker login to authenticate the Docker client with a temporary token, docker tag the image to the repository URI, then docker push. Add lifecycle policies to expire old/untagged images automatically and enable image scanning (basic or enhanced via Amazon Inspector) to find CVEs. ECR also supports immutable tags to prevent overwrites.

App Runner

AWS App Runner runs containerized web apps and APIs directly from a container image or from source code, automatically handling load balancing, autoscaling, TLS, and deployments — the simplest fully managed path to a public web service when you do not want to configure ECS, clusters, or load balancers yourself.

Containers vs Lambda

Use Lambda for short (15-minute cap), event-driven, bursty work with a supported runtime. Use containers (ECS/Fargate) for long-running processes, large artifacts beyond Lambda's package model, custom OS-level dependencies, or steady high-utilization services where always-on compute is cheaper than per-invocation billing.

Networking, Scaling, and Secrets

Each Fargate task gets its own elastic network interface and private IP; choose awsvpc network mode so tasks attach directly to your VPC subnets and security groups. Service Auto Scaling adjusts the desired task count using target-tracking (for example, keep average CPU at 60%) or step scaling on CloudWatch alarms. Inject configuration through the task definition's secrets block, which pulls values from SSM Parameter Store or Secrets Manager at task start so secrets never live in the image. ECS integrates with CloudWatch Container Insights for per-task CPU, memory, and network metrics.

Deployment Strategies and Common Traps

ECS supports rolling update deployments natively and blue/green deployments through AWS CodeDeploy (which shifts traffic between two target groups and can auto-roll-back on alarms).

On the exam, the most-missed points are the two-role split (image-pull failures point to the task execution role, runtime AccessDenied to the task role), the fact that Fargate bills per task vCPU and memory while EC2 bills per instance regardless of task density, and that App Runner — not raw ECS — is the answer when the scenario emphasizes "simplest managed web service with built-in load balancing, scaling, and TLS." Finally, remember the ECR push flow always begins with get-login-password to obtain a temporary auth token before docker push.

Two more details surface in scenarios: a task can run in awsvpc mode behind an Application Load Balancer that performs path- or host-based routing and health checks, replacing unhealthy tasks automatically; and task placement strategies (binpack, spread, random) plus constraints control how tasks distribute across EC2 instances for cost or availability, though they are irrelevant on Fargate since AWS manages placement. When a scenario needs Kubernetes-native tooling or existing Helm charts, the answer is EKS, not ECS, even though both can run on Fargate.