Introduction to Amazon Elastic Container Service (ECS)

container management service
highly scalable and fast
makes it easy to run, stop and manage containers on a cluster
integrated with the AWS Fargate serverless compute engine which automatically provisions and manages Amazon EC2 instances

AWS ECS is organised in the following groups:

Clusters
Namespaces
Task definitions

Clusters

A cluster is a logical grouping of services or standalone tasks.

The cluster list view provides a snapshot of the status of each of your clusters. This view displays the number of active services and the deployment status of all tasks within the cluster.

Namespaces

A namespace groups together Amazon ECS services to configure common connectivity. Amazon ECS can manage namespaces in AWS Cloud Map on your behalf.

The namespace list view provides a snapshot of each of your namespaces. This view displays the namespace ID in AWS Cloud Map, the short name of the namespace, and the date that it was created.

Use namespaces to correlate Amazon ECS services that connect to each other. Each service can be in a single namespace. A service can be in the default namespace configured in the cluster, or specify a different namespace. The namespace must be in the same AWS Region as the Amazon ECS service and cluster. The type of namespace in AWS Cloud Map doesn't affect Service Connect.

Amazon ECS can create a namespace as you create a cluster, or you can assign a default namespace to an existing cluster at any time. Services that you create in these clusters can connect to the other services in the namespace without additional configuration. Additional configuration of a domain name and port is required when you want to make a service available for your other services to connect to.

Task definitions

The Task definitions view lists each task definition family you've created.
You can perform the following actions:
- Deploy the task definition as a service or a task.
- Create a new revision

Creating a new Task definition

Family (Info):

A task definition family is used to group multiple versions, also referred to as revisions, of the same task definition. The first task definition that is registered into a particular family is given a revision of 1, and any task definitions registered after that are given a sequential revision number.

Launch type (Info):

The Launch type specified for a task definition determines where Amazon ECS launches the task or service. The task definition parameters are validated against the allowed values for the launch type.

By default, the AWS Fargate option is selected. You can also select Amazon EC2 instances.

Amazon ECS returns an error if the task definition is not valid for use on the infrastructure type specified when creating a service or running a task.

This field corresponds to the requiresCompatibilities task definition parameter.

Operating system/Architecture (Info):

The Operating system/Architecture configuration for the task definition defines the operating system and the CPU architecture that your tasks run on. When you have multiple tasks that are part of a service, the tasks must all have the same configuration for this option. To use the 64-bit ARM CPU architecture, select Linux/ARM64.

Network mode (Info):

The network mode specifies what type of networking the containers in the task use. The following are available:
The awsvpc network mode, which provides the task with an elastic network interface (ENI). When creating a service or running a task with this network mode you must specify a network configuration consisting of one or more subnets, security groups, and whether to assign the task a public IP address.
The awsvpc network mode is required for tasks hosted on Fargate.
The bridge network mode uses Docker's built-in virtual network, which runs inside each Amazon EC2 instance hosting the task. The bridge is an internal network namespace that allows each container connected to the same bridge network to communicate with each other. It provides an isolation boundary from containers that aren't connected to the same bridge network. You use static or dynamic port mappings to map ports in the container with ports on the Amazon EC2 host.
If you choose bridge for the network mode, under Port mappings, for Host port, specify the port number on the container instance to reserve for your container.
The default mode uses Docker's built-in virtual network mode on Windows, which runs inside each Amazon EC2 instance that hosts the task. This is the default network mode on Windows if a network mode isn't specified in the task definition.
The host network mode has the task bypass Docker's built-in virtual network and maps container ports directly to the ENI of the Amazon EC2 instance hosting the task. As a result, you can't run multiple instantiations of the same task on a single Amazon EC2 instance when port mappings are used.
The none network mode provides a task with no external network connectivity.
For tasks hosted on Amazon EC2 instances, the available network modes are awsvpc, bridge, host, and none. If no network mode is specified, the bridge network mode is used by default.

Task size

For task size, specify the amount of CPU and memory to reserve for the task. The CPU value is specified as a number of vCPUs. The memory value is specified in GB.

For Amazon ECS tasks hosted on AWS Fargate, the task CPU and memory values are required and there are specific values for both CPU and memory that are supported.

For .25 vCPU CPU, the valid memory values are .5 GB, 1 GB, or 2 GB.
For .5 vCPU, the valid memory values are 1 GB, 2 GB, 3 GB, or 4 GB.
For 1 vCPU, the valid memory values are 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, or 8 GB.
For 2 vCPU, the valid memory values are between 4 GB and 16 GB in 1 GB increments.
For 4 vCPU, the valid memory values are between 8 GB and 30 GB in 1 GB increments.
For 8 vCPU, the valid memory values are between 16 GB and 60 GB in 4 GB increments. This option requires Linux platform 1.4.0 or later.
For 16 vCPU, the valid memory values are between 32GB and 120 GB in 8 GB increments.
This option requires Linux platform 1.4.0 or later.

For Amazon ECS tasks hosted on Amazon EC2 instances, the task size fields are optional. If your cluster doesn't have any registered container instances with the requested CPU units available, the task fails. Supported values are between 128 CPU units (0.125 vCPUs) and 10240 CPU units (10 vCPUs). To specify the memory value in GB, enter GB after the value. For example, to set the Memory value to 3GB, enter 3GB.

Task role

The task role is an IAM role that is used by containers in a task to make AWS API calls on your behalf. Applications must sign their AWS API requests with AWS credentials, and a task role provides a strategy for managing credentials for your applications to use, similar to the way that Amazon EC2 instance profiles provide credentials to Amazon EC2 instances.

A task IAM role is required when using the AWS Distro for OpenTelemetry integration to collect trace data or metrics.

Task execution role

The task execution role is an IAM role that grants the Amazon ECS container and Fargate agents permission to make AWS API calls on your behalf.

To use the task execution role, you must run container agent 1.16.0 or later.

The following are common use cases for a task execution AWS Identity and Access Management (IAM) role:
Your task is hosted on AWS Fargate or on an external instance and it does the following:
Pulls a container image from an Amazon ECR private repository.
Sends container logs to Amazon CloudWatch Logs by using the awslogs log driver.
Your tasks are hosted on either AWS Fargate or Amazon EC2 instances and they do the following:
Use private registry authentication.
Reference sensitive data in the task definition by using AWS Secrets Manager secrets or AWS Systems Manager Parameter Store parameters.

Container

A container definition provides details and resource requirements for a container that is passed to the Docker daemon. A task definition may contain one or more container definitions.

For applications that require multiple containers, you should group the containers in the same task definition under the following conditions.
If the containers share a common lifecycle. For example, if they must launch or be terminated together.
If the containers must share the same resources or data volumes.
If the containers must run on the same underlying host. For example, if one container references the other on a localhost port.

Image URI e.g.

Command can be used for executing an entrypoint, for example: /usr/local/my-app/entrypoint.sh

Deregister

When a task definition revision is deregistered, the revision transitions to an INACTIVE state. Existing tasks and services that use the inactive task definition revision continue to run without disruption.

Inactive revisions can't be used to run new tasks or create new services, and you can't update an existing service to use an inactive revision.

Are you sure you want to deregister the following task definition:revision?

Creating a cluster

Infrastructure (Info):

From the Infrastructure workflow, you can configure the infrastructure where your containers run.

The valid options are:

AWS Fargate
Fargate is a serverless, pay-as-you-go compute engine. With Fargate you don't need to manage servers, handle capacity planning, or isolate container workloads for security.
Amazon EC2 instances
You choose the instance type, the number of instances, and manage the capacity.
External instances using ECS Anywhere
Amazon ECS Anywhere provides support for registering an external instance such as an on-premises server or virtual machine (VM), to your Amazon ECS cluster.

By default, when you create a cluster, the cluster is configured for AWS Fargate.

To use EC2 instances, clear AWS Fargate and select Amazon EC2 instances. When you add EC2 instances, you can use an existing group, or create a new Auto Scaling group to act as the capacity provider.

To use your on-premises servers, clear AWS Fargate and select External instances using ECS Anywhere. When the cluster creation is complete, go to Cluster details page to generate the registration command for your external instances, and then run the command on all your external instances.

Monitoring (Info):

From the Monitoring workflow, you can turn on CloudWatch Container Insights.

CloudWatch Container Insights comes at an additional cost and is a fully managed service. It automatically collects, aggregates, and summarizes Amazon ECS metrics and logs. It provides the following information for clusters and services with tasks in the RUNNING state:
CPU and memory utilization
The number of task and services
Read and write storage
Network transmit and receive rates (for tasks that use the bridge or awsvpc network mode)
Container instance counts for clusters, services, and tasks
You can view the metrics in the CloudWatch Container Insights dashboard and perform the following operations:
Query and analyze container application logs by integrating with CloudWatch Container Insights logs.
Create CloudWatch alarms so that you can track issues.

Inside the cluster, we create a service which runs a task defined via selected task definition (in Deployment configuration >> Task definition >> Family):

This is a list of all AWS resources involved in running a (Docker) container in one ECS cluster:

Task definition

Revisions
Task role

policies: ...

resources: ...

Task execution role
Containers

Container

Image. This is a Amazon Elastic Container Registry (Amazon ECR) image URI e.g. 03623477220.dkr.ecr.us-east-1.amazonaws.com/my-app:36 (36 is its tag which is usually a docker image version)

In Amazon ECR >> Private registry >> Repositories: my-app

Log configuration

awslogs-group (In CloudWatch >> Log groups)

Cluster - contains services

Service

Task definition: revision <-- this is the link between a Cluster and Task definition
Network (VPC)
Subnets
Security groups
Service role e.g. AWSServiceRoleForECS (AWS-defined role. Amazon ECS uses the service-linked role named AWSServiceRoleForECS to enable Amazon ECS Service to call AWS APIs on your behalf.)
Load balancers