7.4 Container Orchestration — ECS, EKS, and ECR

AWS Solutions Architect Associate SAA-C03

Track your progress as you read

Finished sections get a check mark.

1 Introduction

About the AWS Solutions Architect Associate (SAA-C03) Exam Study Strategies and Exam Tips for SAA-C03 The AWS Well-Architected Framework

2 Domain 1: Design Secure Architectures (30%)

1.1 IAM Fundamentals — Users, Groups, Roles, and Policies 1.2 AWS Organizations, SCPs, and Multi-Account Strategy 1.3 VPC Security — Security Groups, NACLs, and VPC Endpoints 1.4 Encryption, KMS, and Secrets Management 1.5 AWS WAF, Shield, and Network Firewall 1.6 GuardDuty, Inspector, Macie, and Security Hub 1.7 The Shared Responsibility Model for Solutions Architects 1.8 Data Protection, Compliance, and Audit Services

3 Domain 2: Design Resilient Architectures (26%)

2.1 Elastic Load Balancing (ELB) — ALB, NLB, and GWLB 2.2 EC2 Auto Scaling — Dynamic, Predictive, and Scheduled 2.3 Multi-AZ and Multi-Region Architectures 2.4 Disaster Recovery Strategies — RTO and RPO 2.5 Decoupling with SQS, SNS, and EventBridge 2.6 AWS Step Functions and Workflow Orchestration

4 Domain 3: Design High-Performing Architectures (24%)

3.1 EC2 Instance Types, Purchasing Options, and Placement Groups 3.2 Lambda, Serverless Compute, and Container Services 3.3 Amazon S3 - Storage Classes, Lifecycle, and Performance 3.4 Block and File Storage - EBS, EFS, and FSx 3.5 Database Services - RDS, Aurora, DynamoDB, and More 3.6 CloudFront, Route 53, and Global Accelerator 3.7 Data Ingestion and Transformation - Kinesis, Glue, and EMR

5 Domain 4: Design Cost-Optimized Architectures (20%)

4.1 Compute Cost Optimization — Right-Sizing, RIs, Savings Plans, and Spot 4.2 Storage Cost Optimization — S3 Tiers, EBS, and Data Transfer 4.3 Database Cost Optimization 4.4 AWS Cost Management and Monitoring Tools

6 VPC and Networking Deep Dive

5.1 VPC Architecture — Subnets, Route Tables, and Gateways 5.2 VPC Connectivity — Peering, Transit Gateway, and Direct Connect 5.3 Amazon API Gateway 5.4 CloudFormation and Infrastructure as Code 5.5 AWS PrivateLink and Endpoint Services

7 Migration, Transfer, and Hybrid Services

6.1 The 7 Rs of Cloud Migration 6.2 AWS Snow Family — Snowball Edge Devices 6.3 CloudWatch, CloudTrail, and AWS Config 6.4 Amazon Cognito and Identity Federation 6.5 AWS DataSync and Transfer Family

8 Serverless Architecture and Application Services

7.1 Serverless Architecture Patterns 7.2 Advanced SQS Patterns — DLQ, Backpressure, and FIFO 7.3 Analytics Services — Athena, OpenSearch, and QuickSight 7.4 Container Orchestration — ECS, EKS, and ECR

9 Advanced Topics and Exam Scenarios

8.1 Advanced IAM — Permission Boundaries, Federation, and Cross-Account 8.2 Caching Strategies and ElastiCache Patterns 8.3 Hybrid Architecture — DNS, Storage, and Compute 8.4 SAA-C03 Scenario Practice — Putting It All Together

7.4 Container Orchestration — ECS, EKS, and ECR

Key Takeaways Explain This Topic AI

Amazon ECR is the managed Docker/OCI registry: KMS encryption at rest, automatic vulnerability scanning, lifecycle policies to expire old images, and cross-Region replication.

Amazon ECS is AWS-native orchestration with no control-plane fee; Amazon EKS runs standard Kubernetes and charges $0.10 per hour (about $73/month) per cluster control plane.

Both ECS and EKS run on the Fargate launch type (serverless, zero node management) or the EC2 launch type (you manage instances for GPU, custom kernels, or per-instance cost control).

Fargate Spot delivers up to 70 percent savings for interruption-tolerant tasks; the binpack placement strategy packs tasks onto the fewest instances to cut EC2 cost, while spread maximizes availability.

AWS Cloud Map provides DNS- and API-based service discovery so containers find each other by name instead of hardcoded IPs, and ECS Service Auto Scaling reacts to CPU, memory, ALB request count, or custom metrics.

Last updated: October 2026

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:

• Launch type You manage Pick when
• Fargate Nothing (serverless) "least operational overhead", spiky/short tasks
• EC2 The instances GPU, custom AMIs/kernels, Spot fleets, per-host tuning

• Requirement Best choice
• Simplest orchestration ECS on Fargate
• Kubernetes compatibility / multi-cloud portability EKS
• Maximum container cost optimization ECS on EC2 Spot + Fargate Spot
• Hybrid (on-prem + cloud) ECS Anywhere or EKS Anywhere
• GPU machine-learning workloads ECS/EKS on EC2 GPU instances

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.

• Feature What the exam asks
• Encryption at rest Images encrypted with AWS KMS by default
• Image scanning Automatic vulnerability scanning (basic, or enhanced via Amazon Inspector)
• Lifecycle policies Auto-expire untagged or old images to control storage cost
• Cross-Region replication Pull images locally in multi-Region deployments
• Cross-account access Share images via repository policies
• ECR Public Gallery Host public base 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)

• Strategy Behavior Use for
• binpack Fills each instance before using the next Minimizing instance count and cost
• spread Distributes evenly across AZs/instances Maximizing availability
• random Places arbitrarily Simple, no preference
• Capacity providers and cost

• Provider Cost note
• Fargate Per-second vCPU + memory, no host to manage
• Fargate Spot Up to 70% cheaper for interruption-tolerant tasks
• EC2 Auto Scaling group Pair with Spot Instances for deepest savings
• 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 service-to-service traffic control, AWS points users to Amazon ECS Service Connect ; AWS App Mesh support ended on September 30, 2026.

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.

• Concept Key fact
• Task role IAM permissions for the application's AWS API calls
• Task execution role Lets ECS pull the ECR image and push logs to CloudWatch
• awsvpc mode One ENI + security group per task (required on Fargate)
• Load balancing ALB target group registers tasks dynamically
• 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.