AWS Container Deployment: ECS and EKS Deep Dive

This guide covers the deployment, management, and scaling of containerized applications using Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS), as required for the AWS Certified DevOps Engineer Professional exam.

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between Amazon ECS and Amazon EKS use cases and architectures.
• Configure ECS Task Definitions, Services, and Clusters using Infrastructure as Code (CloudFormation).
• Evaluate various EKS deployment options including EKS Anywhere, Outposts, and Distro.
• Implement modernization workflows using AWS App2Container and AWS App Runner.
• Select the appropriate launch type (Fargate vs. EC2) based on cost, management overhead, and isolation requirements.

Key Terms & Glossary

• Container Image: A read-only template with instructions for creating a Docker container.
• Task Definition (ECS): A JSON-formatted text file that describes one or more containers (up to 10) that form your application.
• Pod (EKS): The smallest deployable units of computing that you can create and manage in Kubernetes.
• Fargate: A serverless compute engine for containers that works with both ECS and EKS.
• Control Plane: The orchestration layer that manages the lifecycle of containers (nodes, scheduling, and API).
• Data Plane: The actual compute resources (EC2 or Fargate) where the containerized workloads run.

The "Big Idea"

[!IMPORTANT] Containers are the cornerstone of Immutable Infrastructure. Instead of patching running servers, DevOps engineers replace the entire container with a new version. AWS provides two primary orchestrators: ECS (AWS-native, simpler) and EKS (Kubernetes-compatible, highly flexible). The goal is to abstract the underlying infrastructure so that scaling and recovery become automated processes.

Formula / Concept Box

Hierarchical Outline

1. Amazon Elastic Container Service (ECS)
   • Architecture Components
     • Task Definition: JSON file defining IAM roles, network mode, and container definitions.
     • Tasks: Instantiations of task definitions.
     • Services: Manages task scheduling and scaling.
   • Launch Types
     • EC2 Launch Type: Full control over the underlying EC2 instances.
     • Fargate Launch Type: Serverless; each task has its own isolation boundary (no shared kernel).
2. Amazon Elastic Kubernetes Service (EKS)
   • Deployment Options
     • Standard EKS: Managed Kubernetes control plane in the AWS cloud.
     • EKS on Outposts: Running Kubernetes on-premises on AWS-provided hardware.
     • EKS Anywhere: Running Kubernetes on your own infrastructure.
     • EKS Distro: The same open-source Kubernetes distribution used by Amazon EKS.
3. Modernization & Automation Tools
   • AWS App Runner: Fully managed service for quick deployment of web apps from source code or images.
   • AWS App2Container (A2C): CLI tool to transform .NET/Java apps into containerized images.
   • AWS Copilot: Command-line interface for deploying and managing production-ready containerized apps.

Visual Anchors

ECS Resource Hierarchy

EKS Deployment Ecosystem

Definition-Example Pairs

• Service Discovery: The mechanism where containers find each other's IP/DNS within a cluster.
  • Example: A "Frontend" container querying backend.local to reach a "Product API" container without knowing its specific EC2 host IP.
• Sidecar Pattern: Deploying a secondary container alongside the main application container within the same task/pod.
  • Example: A Log-Collector container that sits in the same ECS Task as a Web-App container to ship logs to CloudWatch.
• App2Container (A2C): A tool that automates the containerization of legacy applications.
  • Example: Running inventory and containerize commands on an old Windows Server 2012 VM to turn a .NET 4.5 app into a Docker image for EKS.

Worked Examples

Configuring an ECS Task for Fargate

Scenario: You need to deploy a web application that must be isolated from other workloads for security compliance.

1. Select Launch Type: Choose Fargate. Why? Fargate provides a dedicated kernel for each task, ensuring no shared resources with other tenants.
2. Define Networking: Set networkMode to awsvpc. This gives each task its own Elastic Network Interface (ENI) and private IP.
3. Assign Roles:
   • Task Execution Role: Used by the ECS agent to pull images from ECR and send logs to CloudWatch.
   • Task Role: Used by the application code inside the container to access S3 or DynamoDB.
4. CloudFormation Snippet:

Checkpoint Questions

1. Which ECS component is responsible for maintaining the desired number of running tasks and integrating with a Load Balancer?
2. What is the main difference between EKS Anywhere and EKS on Outposts?
3. How many containers can be defined in a single ECS Task Definition?
4. Which AWS service automates the entire CI/CD pipeline, networking, and scaling for a container image with zero infrastructure management?

▶Click to see answers

1. ECS Service.
2. EKS on Outposts uses AWS-managed hardware installed on-premises, while EKS Anywhere allows you to use your own existing hardware.
3. Up to 10 containers.
4. AWS App Runner.

Muddy Points & Cross-Refs

• ECS Anywhere vs. EKS Anywhere: Both allow on-premises container orchestration. Choose ECS Anywhere if you want the simplicity of the ECS control plane; choose EKS Anywhere if your organization is standardized on Kubernetes (K8s) tooling and APIs.
• Task Execution Role vs. Task Role: This is a common exam trap.
  • Execution Role = AWS Service Permissions (Pulling the image, Logging).
  • Task Role = Application Permissions (Accessing S3, DynamoDB).

Comparison Tables

ECS vs. EKS

Fargate vs. EC2 Launch Types