AWS Container Services: Comprehensive Study Guide

This guide covers the core container orchestration and compute services provided by AWS, specifically focusing on the architectural decisions required for the AWS Certified Solutions Architect - Professional exam.

Learning Objectives

• Differentiate between Amazon ECS and Amazon EKS orchestration models.
• Evaluate the trade-offs between EC2 and AWS Fargate launch types.
• Design scalable container architectures using Tasks, Services, and Clusters.
• Identify use cases for Amazon ECR in the CI/CD pipeline.
• Recommend modernization strategies (Re-platform vs. Re-architect) using containers.

Key Terms & Glossary

• Orchestration: The automated arrangement, coordination, and management of complex computer systems and services.
• Control Plane: The "brains" of the container service responsible for scheduling and managing the state of the cluster.
• Data Plane: The actual compute resources (EC2 or Fargate) where your containers run.
• Sidecar Pattern: A design pattern where a secondary container (the sidecar) is attached to the main application container to provide peripheral features like logging or security.
• Ephemeral Storage: Temporary storage that is deleted when the container instance or task is terminated.

The "Big Idea"

The transition from monolithic architectures to microservices is powered by containers. AWS removes the "undifferentiated heavy lifting" of managing the container orchestration software (ECS/EKS) and the underlying servers (Fargate), allowing architects to focus on application logic and scaling rather than infrastructure maintenance.

Formula / Concept Box

Hierarchical Outline

1. Amazon Elastic Container Service (ECS)
   • Architecture: Clusters (logical grouping) → Services (lifecycle management) → Tasks (running containers).
   • Task Definitions: JSON blueprints defining CPU, memory, and Docker images.
   • Launch Types: EC2 (full control) vs. Fargate (serverless).
2. Amazon Elastic Kubernetes Service (EKS)
   • Nature: Vanilla Kubernetes experience.
   • Integration: Compatible with open-source K8s tools (kubectl, Helm).
   • Management: Managed control plane; customer manages or uses Fargate for the data plane.
3. AWS Fargate
   • Serverless: No EC2 instances to patch or manage.
   • Security: Task-level isolation; each task runs in its own kernel.
   • Storage: Ephemeral by default; requires EFS for persistence.
4. Amazon Elastic Container Registry (ECR)
   • Role: Fully managed Docker container registry.
   • Security: Integrated with IAM for resource-based access control.

Visual Anchors

ECS Resource Hierarchy

Compute Responsibility Model

\begin{tikzpicture}[node distance=2cm] \draw[thick, fill=orange!20] (0,0) rectangle (4,1) node[pos=.5] {Customer Code}; \draw[thick, fill=blue!20] (0,-1.2) rectangle (4,-0.2) node[pos=.5] {Container Runtime}; \draw[thick, fill=gray!20] (0,-2.4) rectangle (4,-1.4) node[pos=.5] {OS / Patching}; \draw[thick, fill=green!20] (0,-3.6) rectangle (4,-2.6) node[pos=.5] {Hardware};

\end{tikzpicture}

Definition-Example Pairs

• Launch Type: The infrastructure strategy used to host containers.
  • Example: Using Fargate for a bursty web API where you don't want to manage scaling policies for underlying EC2 instances.
• Service Scheduler: The logic that ensures a specific number of tasks are running.
  • Example: If a task fails due to an application error, the ECS Service automatically detects the failure and starts a new task to replace it.
• Container Registry: A place to store and version Docker images.
  • Example: A CI/CD pipeline builds a new image, pushes it to Amazon ECR, and then triggers an ECS service update to deploy the new version.

Worked Examples

Scenario 1: The Modernization Dilemma

Problem: A company has a legacy Java monolith. They want to move to containers with minimal Kubernetes expertise and want to integrate deeply with AWS IAM. Solution: Use Amazon ECS. Since the team lacks K8s knowledge, ECS provides an "opinionated" and simpler management experience. By using the Fargate launch type, they also eliminate the need to patch servers.

Scenario 2: Persistent Data in Fargate

Problem: A developer is running a CMS on Fargate and notices that uploaded images disappear when the task restarts. Step-by-Step Fix:

1. Identify: Fargate storage is ephemeral.
2. Provision: Create an Amazon EFS file system.
3. Configure: Update the ECS Task Definition to include a volume pointing to the EFS ID.
4. Mount: Map the volume to a container mount point (e.g., /var/www/html/uploads).
5. Result: Data now persists across task restarts.

Checkpoint Questions

1. Which container service is best for a team that already uses standard Kubernetes tools and manifests?
2. What is the main difference between an ECS "Task" and an ECS "Service"?
3. True/False: AWS Fargate allows you to SSH into the underlying host to troubleshoot performance.
4. Which service acts as a private repository for your Docker images?

Muddy Points & Cross-Refs

• ECS vs. EKS: The choice often comes down to ecosystem. If you are "All-in" on AWS, ECS is usually easier. If you need portability across clouds, EKS is the winner.
• Storage Limitations: Fargate does not support EBS volumes. You must use EFS or S3 for persistent data.
• Windows Support: ECS supports Windows containers on EC2, but Windows support on Fargate has specific version and region constraints.

Comparison Tables

ECS vs. EKS

EC2 vs. Fargate Launch Types