Containers on AWS – ECS, EKS, Fargate, ECR

1. What is Docker?

Docker is a software development platform for deploying apps. An app is packaged into a container, and that container can run on any operating system. The idea is simple and its consequences are large: the app runs the same regardless of where it runs.

What that buys you, in the deck’s words:

• It runs on any machine.
• There are no compatibility issues.
• Behavior is predictable.
• There is less work involved.
• It is easier to maintain and deploy.

Docker works with any language, any OS, any technology. Its classic use cases are microservices architectures and lift-and-shift of applications from on-premises into the AWS cloud.

On a server — for example an EC2 instance — Docker runs on top of the host operating system, and the containers sit on top of Docker.

Where are Docker images stored?

Docker images live in Docker repositories:

• Docker Hub (https://hub.docker.com) is the public repository where you find base images for many technologies and operating systems, such as Ubuntu or MySQL.
• Amazon ECR (Amazon Elastic Container Registry) offers a private repository, and also a public repository through the Amazon ECR Public Gallery (https://gallery.ecr.aws).

Docker versus virtual machines

Docker is “sort of” a virtualization technology, but not exactly. The difference is in what each container carries.

With virtual machines, the infrastructure runs a host OS, then a hypervisor, and each VM carries its own guest OS plus the app. With Docker, the infrastructure runs a host OS — an EC2 instance — then the Docker daemon, and the apps run directly on top of it.

Because resources are shared with the host, you can pack many containers onto one server — far more than you could fit virtual machines.

The basic lifecycle

The workflow has four moves: you write a Dockerfile, you build it into an image, you run the image as a container, and you push the image to a Docker repository such as Amazon ECR so other machines can pull it.

2. Container management services on AWS

AWS offers four pieces, and the exam expects you to know which is which:

• Amazon Elastic Container Service (Amazon ECS) — Amazon’s own container platform.
• Amazon Elastic Kubernetes Service (Amazon EKS) — Amazon’s managed Kubernetes, based on the open source project.
• AWS Fargate — Amazon’s own serverless container platform, which works with both ECS and EKS.
• Amazon ECR — where you store container images.

Exam tip

Fargate is the serverless launch type you pick when running ECS tasks, and EKS can use it too. A question about “running containers without managing servers” is pointing at Fargate, regardless of whether the orchestrator is ECS or EKS.

3. Amazon ECS – EC2 launch type

ECS is the Elastic Container Service. Launching Docker containers on AWS with ECS means launching ECS Tasks on ECS Clusters.

With the EC2 launch type, you provision and maintain the infrastructure — the EC2 instances that make up the cluster. Each EC2 instance must run the ECS Agent, which is what registers it into the ECS cluster. Once the instances are registered, AWS takes care of starting and stopping containers on them; your responsibility stops at keeping the fleet healthy and appropriately sized.

4. Amazon ECS – Fargate launch type

With the Fargate launch type you still launch Docker containers on AWS, but you do not provision the infrastructure — there are no EC2 instances to manage. It is all serverless.

The model becomes:

• You create task definitions that state the CPU and RAM each task needs.
• AWS runs the ECS tasks for you on capacity it manages.
• To scale, you simply increase the number of tasks. There is no instance fleet to grow first.

Exam tip

The dividing line between the two launch types is who owns the EC2 instances. “We must patch and size the container hosts” is EC2 launch type; “we want no servers to manage” is Fargate. Note also that the ECS Agent only exists in the EC2 launch type.

5. IAM roles for ECS

There are two distinct roles here, and confusing them is a classic mistake.

EC2 Instance Profile — used with the EC2 launch type only. It is the role assumed by the ECS Agent on the instance, and it is what lets the instance:

• Make API calls to the ECS service.
• Send container logs to CloudWatch Logs.
• Pull Docker images from ECR.
• Reference sensitive data in Secrets Manager or SSM Parameter Store.

ECS Task Role — a role granted to each task individually, so that different ECS services running on the same instance can hold different permissions. One task’s role might allow access to S3 while another’s allows DynamoDB. The task role is defined in the task definition.

Exam tip

When a question asks how to give one containerized microservice access to a specific S3 bucket without granting it to every container on the host, the answer is the ECS Task Role, not the instance profile.

6. Load balancer integrations

ECS tasks sit behind a load balancer that takes user traffic on ports 80 and 443 and distributes it across tasks running on the cluster’s instances.

• The Application Load Balancer is supported and works for most use cases.
• The Network Load Balancer is recommended only for high throughput / high performance use cases, or when you need to pair it with AWS PrivateLink.
• The Classic Load Balancer is supported but not recommended: it has no advanced features and does not work with Fargate.

7. Data volumes with EFS

You can mount EFS file systems onto ECS tasks, and this works for both the EC2 and Fargate launch types.

The consequence is that tasks running in any Availability Zone share the same data in the EFS file system. Fargate plus EFS gives you a fully serverless setup with persistent storage, and the use case is exactly that: persistent, multi-AZ, shared storage for your containers.

Exam tip

The deck’s explicit warning: Amazon S3 cannot be mounted as a file system. If a question asks for a shared POSIX file system across containers, the answer is EFS.

8. ECS Service Auto Scaling

ECS Service Auto Scaling automatically increases or decreases the desired number of ECS tasks. It is built on AWS Application Auto Scaling.

The metrics it can scale on:

• ECS Service Average CPU Utilization.
• ECS Service Average Memory Utilization — scaling on RAM.
• ALB Request Count Per Target, a metric that comes from the ALB.

The scaling strategies available:

• Target Tracking — scale towards a target value for a specific CloudWatch metric.
• Step Scaling — scale based on a specified CloudWatch Alarm.
• Scheduled Scaling — scale based on a date and time, for predictable changes.

A concrete flow: the CloudWatch metric for ECS Service CPU usage rises as tasks 1 and 2 get busy, a CloudWatch alarm triggers, and Application Auto Scaling starts task 3. Optionally, an ECS Capacity Provider scales the underlying Auto Scaling Group at the same time.

Exam tip

ECS Service Auto Scaling operates at the task level and is not the same thing as EC2 Auto Scaling, which operates at the instance level. With the EC2 launch type you often need both. Fargate Auto Scaling is much easier to set up, precisely because there is no instance layer to scale.

Auto scaling the underlying EC2 instances

With the EC2 launch type, scaling the service is useless if there is nowhere to place the new tasks, so you accommodate ECS service scaling by adding EC2 instances. There are two approaches:

• Auto Scaling Group scaling — scale the ASG on CPU utilization, adding EC2 instances over time.
• ECS Cluster Capacity Provider — the infrastructure your ECS tasks need gets provisioned and scaled for you. You pair the capacity provider with an Auto Scaling Group, and it brings up more EC2 instances whenever the cluster falls short on capacity (CPU, RAM and the like). This is the smarter of the two, because it reacts to what the tasks actually need rather than to a proxy metric.

9. Common ECS integration patterns

ECS tasks invoked by EventBridge

A client uploads an object to an S3 bucket. The bucket emits an event to Amazon EventBridge, whose rule says “run an ECS task”. EventBridge starts a new AWS Fargate task in the ECS cluster; the task’s ECS Task Role grants it access to S3 and DynamoDB, so it gets the object, processes it and saves the result to Amazon DynamoDB.

ECS tasks invoked on an EventBridge schedule

The same shape, driven by time instead of an event: an EventBridge rule fires every hour and runs a Fargate task that performs batch processing against Amazon S3, using an ECS Task Role that grants S3 access.

ECS with an SQS queue

Messages accumulate in an SQS queue, and the tasks of an ECS service poll it for work. ECS Service Auto Scaling adds tasks as the workload grows, which is the container version of the SQS worker pattern.

Intercepting stopped tasks with EventBridge

When an ECS task’s containers exit, an EventBridge event is emitted. An event pattern matching those events triggers SNS, which emails an administrator. It is the standard way to be told that containers are dying rather than discovering it from a dashboard.

Real-world example

A nightly report job used to run on a permanently-on EC2 instance. Replacing it with an EventBridge schedule that launches a Fargate task means the compute exists for the fifteen minutes the job runs, and a second EventBridge rule on stopped tasks emails the on-call engineer if the container exits unexpectedly.

10. Amazon ECR

ECR is the Elastic Container Registry: it stores and manages Docker images on AWS.

• It offers both a private repository and a public repository (the Amazon ECR Public Gallery at https://gallery.ecr.aws).
• It is fully integrated with ECS and is backed by Amazon S3.
• Access is controlled through IAM — so a permission error pulling an image is a policy problem, not a networking one.
• It supports image vulnerability scanning, versioning, image tags and image lifecycle policies.

In an ECS cluster, the EC2 instances pull images A and B from the ECR repository using an IAM role.

11. Amazon EKS

Amazon EKS — Amazon Elastic Kubernetes Service — lets you stand up managed Kubernetes clusters on AWS. Kubernetes itself is open source, and its job is to deploy, scale and manage containerized applications automatically — Docker ones, as a rule.

EKS is an alternative to ECS: same goal, different API. It supports EC2 if you want to deploy worker nodes, or Fargate if you want serverless containers.

The use case the deck names is specific: your company already uses Kubernetes on-premises or in another cloud and wants to migrate to AWS while keeping Kubernetes, which is possible because Kubernetes is cloud-agnostic and runs on Azure, GCP and elsewhere.

Two operational notes: for multiple regions, deploy one EKS cluster per region, and collect logs and metrics using CloudWatch Container Insights.

A typical EKS deployment spreads across three Availability Zones in a VPC. Public subnets hold NAT gateways and the public-facing ELB; private subnets hold the EKS worker nodes in an Auto Scaling Group, each node running EKS pods. Services are exposed through an EKS public service load balancer or an EKS private service load balancer, both implemented as ELBs.

EKS node types

• Managed Node Groups — EKS creates and manages the nodes (EC2 instances) for you. The nodes are part of an ASG managed by EKS, and both On-Demand and Spot Instances are supported.
• Self-Managed Nodes — you create the nodes and register them to the EKS cluster, managing them with your own ASG. You can use the prebuilt Amazon EKS Optimized AMI, and again both On-Demand and Spot are supported.
• AWS Fargate — no maintenance required and no nodes to manage.

Data volumes for EKS

To attach storage you must specify a StorageClass manifest on the EKS cluster, which leverages a Container Storage Interface (CSI) compliant driver. The supported storage types are:

• Amazon EBS
• Amazon EFS — the one that works with Fargate
• Amazon FSx for Lustre
• Amazon FSx for NetApp ONTAP

Exam tip

If a question mentions an existing Kubernetes investment, or the wish to stay portable across clouds, choose EKS. If it mentions Fargate plus persistent shared storage on EKS, the volume type has to be Amazon EFS, the one the deck marks as working with Fargate.

12. AWS App Runner

AWS App Runner is fully managed: it takes web applications and APIs to production at scale without asking you to know anything about infrastructure.

The flow: you start from source code or a container image (Docker), configure settings such as vCPU, RAM, auto scaling and health checks, and App Runner creates and deploys the application, giving you a URL to access it. It automatically builds and deploys the web app.

What comes with it: automatic scaling, high availability, a load balancer and encryption, plus VPC access support so the app can connect to database, cache and message queue services.

Use cases: web apps, APIs, microservices and rapid production deployments.

Real-world example

A small team wants an internal API online this afternoon. Pointing App Runner at the repository gives them an automatically scaled, load-balanced, encrypted endpoint they reach by URL, without anyone writing a task definition, a cluster or a load balancer listener.

13. AWS App2Container (A2C)

AWS App2Container is a command-line tool: point it at a Java or .NET web app and it migrates and modernizes that app into a Docker container.

It targets lift-and-shift of apps running on-premises on bare metal, in virtual machines, or in any cloud into AWS, with the promise of accelerating modernization without code changes, including for legacy apps.

What it produces:

• CloudFormation templates for compute, network and so on.
• Docker containers registered into ECR.
• Deployments to ECS, EKS or App Runner.
• Support for pre-built CI/CD pipelines.

The tool works in four stages:

Stage	What happens
Discover & Analyze	Create an app inventory and analyze runtime dependencies
Extract & Containerize	Extract the app with its dependencies and create a Docker image
Create Deployment Artifacts	Generate ECS task and EKS pod definitions, CI/CD pipelines and other infrastructure, via a CloudFormation template
Deploy to AWS	Store the Docker image in Amazon ECR and deploy to ECS, EKS or App Runner

Quick recap

Item	What to remember for the exam
Docker	Apps packaged in containers run identically anywhere; containers share host resources, so many fit on one server, unlike VMs which each carry a guest OS
Image storage	Docker Hub (public) and Amazon ECR (private, plus the ECR Public Gallery)
The four AWS pieces	ECS (AWS’s own orchestrator), EKS (managed Kubernetes), Fargate (serverless launch type for both), ECR (image registry)
ECS EC2 launch type	You provision and maintain the EC2 instances; each must run the ECS Agent to register with the cluster
ECS Fargate launch type	No infrastructure to provision; create task definitions with CPU/RAM and scale by increasing the number of tasks
EC2 Instance Profile	EC2 launch type only; used by the ECS Agent for ECS API calls, CloudWatch Logs, ECR pulls, Secrets Manager / SSM Parameter Store
ECS Task Role	Per-task role defined in the task definition, so different services get different permissions
Load balancers	ALB for most cases, NLB for high throughput or AWS PrivateLink, CLB supported but not recommended and not compatible with Fargate
Data volumes	EFS mounts on both launch types, shared across AZs; Fargate + EFS = serverless; S3 cannot be mounted as a file system
ECS Service Auto Scaling	Uses Application Auto Scaling on CPU, memory or ALB Request Count Per Target; strategies are Target Tracking, Step Scaling, Scheduled Scaling; task level, not instance level
Scaling EC2 capacity	ASG scaling on CPU, or an ECS Cluster Capacity Provider paired with an ASG to add instances when CPU/RAM capacity is missing
ECS patterns	EventBridge rules (event-driven or scheduled) running Fargate tasks, SQS-driven worker services, and EventBridge + SNS to alert on stopped tasks
Amazon ECR	Private and public repositories, backed by S3, access via IAM, with vulnerability scanning, versioning, tags and lifecycle policies
Amazon EKS	Managed Kubernetes, alternative to ECS with a different API; one cluster per region; monitor with CloudWatch Container Insights; use it when Kubernetes is already in play
EKS node types	Managed Node Groups, Self-Managed Nodes (EKS Optimized AMI), or AWS Fargate; the first two support On-Demand and Spot
EKS volumes	Declare a StorageClass using a CSI driver; EBS, EFS (works with Fargate), FSx for Lustre, FSx for NetApp ONTAP
AWS App Runner	Fully managed deploy of web apps and APIs from source code or a container image; automatic scaling, HA, load balancer, encryption, VPC access
AWS App2Container	CLI to containerize Java and .NET web apps from on-premises or any cloud; generates CloudFormation, pushes to ECR, deploys to ECS / EKS / App Runner