Study guide

Technical reference and lesson notes

Amazon ECS: Docker Images, Task Definitions, Clusters, and Launch Types

Purpose of This Lesson

Amazon Elastic Container Service (Amazon ECS) runs and orchestrates Docker containers in AWS. The key skill is distinguishing the artifacts used to build a container from the ECS resources used to run and maintain it:

A Dockerfile builds a Docker image.
A Docker image packages the application and its dependencies.
An ECS task definition describes how ECS should launch one or more containers.
A task is a running container configuration.
An ECS service maintains a desired number of long-running tasks.
An ECS cluster is a logical grouping of tasks or services.

This distinction is especially important for AWS Certified CloudOps Engineer Associate scenario questions involving container deployment and operational choices.

Key Concepts

Docker containers

A Docker container packages application code, runtime components, libraries, environment variables, and configuration needed to run the application. Containers share the host operating system, making them generally lighter and faster to start than virtual machines. Multiple isolated containers can run on the same host even when they use different application stacks, such as .NET, Java, or Python.

Containers are useful for:

Fast startup and shutdown
Replicating application components for scaling and high availability
Portability across hosts, environments, and clouds where Docker is available
Packaging application dependencies consistently
Microservices architectures, where separate application components run independently

Docker images and Dockerfiles

A Docker image is a read-only, standalone package used to create containers. It can be built from scratch or customized from an existing base image.

A Dockerfile is a text file containing the instructions used to build an image. Common instructions include:

Instruction	Purpose
`FROM`	Selects the base image
`ENV`	Sets environment variables
`RUN`	Executes build-time commands
`COPY`	Copies files or directories into the image
`EXPOSE`	Indicates the network port the container listens on
`CMD` or `ENTRYPOINT`	Defines the command executed when the container starts

A typical build workflow uses docker build, often with -t to assign an image name and tag. The resulting image can then be started with docker run, including the required port mappings.

For example, an application image might use a Python base image, set /app as its working directory, copy application files, install dependencies from requirements.txt, expose port 5000, and start the application with Python.

Image registries: Docker Hub and Amazon ECR

Docker images must be available from a registry before ECS can use them. Images may be pulled directly from Docker Hub or stored in Amazon Elastic Container Registry (Amazon ECR).

Amazon ECR is an AWS-managed Docker registry that provides private repositories within an AWS account. Access to repositories and images is controlled with IAM and resource-based permissions. The Docker CLI can be used to push, pull, and manage ECR images.

A common workflow is:

Pull a base image, such as Ubuntu, from Docker Hub.
Customize the image and build the application image.
Push the resulting image to a private ECR repository.
Reference the ECR image in an ECS task definition.
Run the task or ECS service using that definition.

ECS does not replace the image-building process. The image still needs to be created and made available in a registry.

Amazon ECS Architecture and Operational Context

ECS clusters, tasks, and services

An ECS cluster is a logical grouping of tasks or services. It runs within a VPC and can use resources in the VPC’s Availability Zones.

A task definition is the deployment blueprint for ECS. It is a JSON text file that specifies one or more containers, up to the limit described in the lesson. It identifies the image and defines runtime settings such as CPU, memory, networking, port mappings, commands, environment variables, volumes, and IAM roles.

A task is a running instance created from a task definition. In the terminology used in this lesson, a task is essentially a running Docker container configuration.

An ECS service is used for long-running applications. It maintains a specified desired count of tasks, replacing tasks as necessary to keep that count running. ECS services can also use Application Load Balancers or Network Load Balancers and can participate in scaling arrangements.

Important task-definition settings

A task definition can specify:

Container images
CPU and memory allocations
Container-to-container links where applicable to the task configuration
Docker networking mode
Container-to-host port mappings
Commands executed when a container starts
Environment variables
Data volumes
Behavior when a container finishes or fails
An IAM role used by the task for permissions

The task definition is separate from the Dockerfile. The Dockerfile creates the image; the task definition tells ECS how to run that image.

Fargate launch type

AWS Fargate is the serverless ECS launch type. AWS manages the underlying infrastructure, so the operator does not manage the EC2 container hosts. Fargate provides a fully managed and scalable way to run ECS tasks.

Choose Fargate when the operational goal is to run containers without managing the underlying container instances.

EC2 launch type

With the EC2 launch type, ECS tasks run on EC2 instances called container instances. These instances are visible in the EC2 console and must run the ECS container agent.

The container agent allows the instance to connect to ECS and the cluster. The instances also need an IAM role with the relevant permissions. Because the hosts are customer-managed EC2 instances, this launch type provides more control over the container infrastructure. The number of container instances can also be increased or decreased through scaling arrangements.

Choose the EC2 launch type when control over the underlying hosts is important and the organization is prepared to operate those instances and their ECS agent configuration.

ECS Anywhere and load balancing

Amazon ECS Anywhere extends use of the ECS control plane to on-premises implementations.

ECS integrates with Elastic Load Balancing. An Application Load Balancer (ALB) or Network Load Balancer (NLB) can distribute traffic across containers associated with an ECS service.

Exam- or Assessment-Relevant Takeaways

Do not confuse a Dockerfile with an ECS task definition. The Dockerfile builds an image; the task definition controls how ECS launches containers.
A task is running workload, while a task definition is the blueprint used to create it.
An ECS service maintains a desired number of long-running tasks.
Fargate removes the need to manage EC2 container instances and their underlying infrastructure.
The EC2 launch type requires container instances running the ECS agent and having appropriate permissions.
Images can be stored in Docker Hub or Amazon ECR. ECR is the AWS-managed private registry option described in this lesson.
A cluster is a logical grouping of tasks or services, not an image repository and not a single container.
Task definitions can specify container images, CPU, memory, ports, commands, environment variables, volumes, networking, and IAM roles.
For traffic distribution across ECS tasks, consider an ALB or NLB integrated with an ECS service.
ECS runs Docker containers; it does not eliminate the need to build and store Docker images.

Tool / Feature Decision Guide

Requirement or scenario	Appropriate choice	Reason
Run containers without managing host EC2 instances	Fargate launch type	AWS manages the underlying infrastructure
Control the EC2 hosts that run containers	EC2 launch type	Tasks run on customer-managed container instances
Store private Docker images in AWS	Amazon ECR	Provides private repositories with IAM and resource-based access control
Build a repeatable application image	Dockerfile with `docker build`	Encodes image-building instructions and dependencies
Tell ECS which image and runtime settings to use	ECS task definition	Defines ECS-specific deployment and container settings
Keep a specified number of application containers running	ECS service	Maintains the desired task count
Group related ECS workloads logically	ECS cluster	Provides the logical grouping for tasks and services
Distribute application traffic across ECS tasks	ALB or NLB integrated with an ECS service	Provides load balancing for containerized workloads
Extend ECS control-plane management to on-premises resources	ECS Anywhere	Supports on-premises ECS implementations

Common Traps / Misconceptions

A task definition is not a Dockerfile. A Dockerfile builds the image; a task definition configures its execution in ECS.
A task is not the stored image. The image is a read-only package in a registry; a task is a running workload created from a task definition.
ECR is not the same as ECS. ECR stores container images, while ECS runs and orchestrates containers.
Fargate does not mean there is no infrastructure. It means the underlying infrastructure is managed for you rather than operated as customer-managed EC2 container instances.
An EC2 instance is not automatically an ECS container instance. It must run the ECS container agent and have the permissions needed to connect to ECS.
An ECS service is not just a one-time task launch. Its role is to maintain the desired count of long-running tasks.
EXPOSE does not by itself publish traffic externally. It indicates the container port in the image; ECS task configuration and load-balancing or host-port settings determine how the workload is run and reached.
Containers are isolated but share the host operating system. This is a major reason they are generally more resource-efficient than virtual machines, but it is also different from running a separate guest operating system per workload.

Real-World Engineer / Analyst Notes

Keep image creation and runtime configuration as separate troubleshooting domains. If the image cannot build, inspect the Dockerfile and build context. If the image builds but the task does not start correctly, inspect the task definition, image access, CPU and memory settings, ports, commands, environment variables, and IAM configuration.
Use versioned image tags and task-definition revisions in operational workflows so that the image selected by a task can be identified later. The lecture establishes that task definitions select images, but it does not prescribe a particular tagging strategy.
For EC2 launch type incidents, verify both core host prerequisites: the ECS agent is running and the instance has the permissions required to connect to ECS.
For a service that is below its desired count, distinguish between an application or container failure and an infrastructure or placement problem. The service’s purpose is to maintain the desired count, but the cause of failure must be investigated separately.
Confirm port relationships carefully. The task definition can specify container and host ports, while the application itself must listen on the expected container port.
Use ECR when image ownership, private repository access, and AWS-integrated permissions are operational requirements. Docker Hub remains a possible image source when a public or externally hosted image is appropriate.

Quick Reference Summary

Dockerfile: Instructions for building a Docker image.
Docker image: Read-only package containing application code, runtime, libraries, configuration, and dependencies.
Registry: Stores images; examples are Docker Hub and Amazon ECR.
ECS task definition: JSON blueprint describing one or more containers and their ECS runtime settings.
Task: Running workload created from a task definition.
ECS service: Maintains the desired count of long-running tasks.
ECS cluster: Logical grouping of ECS tasks or services.
Fargate: Serverless ECS launch type with AWS-managed underlying infrastructure.
EC2 launch type: Runs tasks on EC2 container instances that require the ECS agent and appropriate IAM permissions.
Load balancing: ECS services can integrate with an ALB or NLB.
ECS Anywhere: Uses the ECS control plane to manage on-premises implementations.

Flashcards

Q: A team has a working Docker image but needs ECS to know which image to pull, which ports to map, and how much CPU and memory to allocate. What should the team create?

A: An ECS task definition. It controls ECS runtime settings; the Dockerfile was used earlier to build the image.

Q: When should Fargate be selected instead of the EC2 launch type?

A: Select Fargate when the team wants to run ECS tasks without managing the underlying EC2 container instances and infrastructure.

Q: What two prerequisites are especially important for an EC2 instance serving as an ECS container instance?

A: It must run the ECS container agent and have an IAM role with the permissions needed to connect to ECS and the cluster.

Q: An application must keep six copies of a long-running container available. Which ECS feature should enforce this desired count?

A: An ECS service. A service maintains the specified number of running tasks and can be integrated with load balancing.

Q: What is the decisive difference between an ECS task and an ECS task definition?

A: The task definition is the blueprint, while the task is the running workload created from that blueprint.

Q: When would Amazon ECR be preferred over Docker Hub in the workflow described here?

A: Use ECR when the image should be stored in a private AWS repository under account control, with IAM and resource-based access permissions.

Q: What does a Dockerfile contribute to an ECS deployment?

A: It provides repeatable instructions for building the Docker image, including the base image, copied files, installed dependencies, exposed port, and startup command.

Q: An operator needs to distribute requests across containers running as part of an ECS service. Which AWS capability is relevant?

A: Elastic Load Balancing integrated with the ECS service, using an Application Load Balancer or Network Load Balancer.

Q: Why are containers generally more resource-efficient and faster to start than virtual machines?

A: Containers share the host operating system instead of requiring a separate guest operating system, so they typically use fewer resources and start in seconds.

Q: What is the role of an ECS cluster?

A: It is a logical grouping of ECS tasks or services within the ECS environment. It is not the image registry and does not replace the task definition.

Q: A Docker image is built locally and must be used by ECS. What operational step is needed before ECS can pull it from a private AWS repository?

A: Push the image to an Amazon ECR private repository, then reference that image from the ECS task definition.

Q: Which task-definition settings help connect a containerized application to its runtime environment?

A: Relevant settings include networking mode, container and host port mappings, environment variables, volumes, startup commands, CPU, memory, and IAM role configuration.

Practice Questions

Question 1

A company wants to run a web application on ECS but does not want to provision, patch, or manage EC2 instances hosting the containers. Which option best fits this requirement?

A. EC2 launch type with a custom AMI
B. Fargate launch type
C. Docker Hub without ECS
D. An ECS task definition without a launch type

Correct answer: B. Fargate launch type

Explanation: Fargate is the serverless ECS launch type described in the lesson. It removes the need to manage the underlying container instances.

Question 2

An engineer changes the base image, copies new application files, and installs an additional library. Which artifact should be modified first?

A. ECS service
B. ECS cluster
C. Dockerfile
D. Load balancer target configuration

Correct answer: C. Dockerfile

Explanation: The Dockerfile contains the instructions used to build the image. The updated image can then be stored in a registry and referenced by an ECS task definition.

Question 3

A service is configured with a desired count of four tasks, but only two are currently running. Which ECS resource is responsible for attempting to maintain the desired count?

A. Amazon ECR repository
B. ECS service
C. Dockerfile
D. ECS container agent

Correct answer: B. ECS service

Explanation: An ECS service maintains the desired number of long-running tasks. The container agent is required for EC2 container instances to connect to ECS, but it is not the resource that defines the desired service count.

Question 4

An ECS deployment using the EC2 launch type cannot connect its container instances to the cluster. The instances are otherwise running normally. Which pair should be checked first?

A. Docker Hub image tags and ALB listener rules
B. ECS agent status and the instance IAM role
C. ECR storage capacity and task desired count
D. Dockerfile COPY instructions and container volume size

Correct answer: B. ECS agent status and the instance IAM role

Explanation: EC2 container instances must run the ECS container agent and have the relevant permissions to connect to ECS and the cluster.

Question 5

An image builds successfully, but ECS launches it with the wrong port and insufficient memory. Where should the operator correct these settings?

A. The Docker registry’s repository policy only
B. The ECS cluster name
C. The ECS task definition
D. The ECS Anywhere control plane

Correct answer: C. The ECS task definition

Explanation: Task definitions specify container and host port mappings, memory, CPU, and other ECS runtime settings. The Dockerfile builds the image but is not the primary ECS deployment configuration for these settings.

WordPress Metadata

Suggested Slug:
amazon-ecs-docker-task-definitions-launch-types

Meta Description:
Study Amazon ECS architecture, Docker images, ECR, task definitions, services, clusters, and the differences between Fargate and EC2 launch types.

Tags:
Amazon ECS, AWS Fargate, ECS task definitions, Amazon ECR, Docker containers, ECS clusters, ECS services, EC2 launch type, container orchestration, AWS Certified CloudOps Engineer