Amazon Elastic Container Service (ECS)

Amazon Elastic Container Service (Amazon ECS) is one of the  container services provided by Amazon, which is a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker containers on a cluster. Amazon ECS lets clients launch and stop container-based applications with simple API calls. Amazon ECS allows  customers to launch and stop container-based applications with simple API calls, that allows them to get the state of the cluster from a centralized service, and gives access to many familiar Amazon EC2 features. ECS is a great choice to run containers for several reasons. 

ECS used by several big companies such as Duolingo, Samsung, GE, and Cookpad to run their most sensitive and mission critical applications because of its security, reliability, and scalability.

  • AWS customers are able to run their ECS clusters using AWS Fargate, which is serverless compute for containers.
  • it can natively integrate with other services such as Amazon Route 53, Secrets Manager, AWS Identity and Access Management (IAM), and Amazon CloudWatch providing you a familiar experience to deploy and scale your containers.
  • ECS is used extensively within Amazon to power services such as Amazon SageMaker, AWS Batch, Amazon Lex, and Amazon.com’s recommendation engine, ensuring ECS is tested extensively for security, reliability, and availability.
Amazon ECS

Amazon ECS Benefits

Amazon ECS makes it easy to use containers as a building block for AWS clients applications by eliminating the need to install, operate, and scale the cluster management infrastructure. Amazon ECS enables users schedule long-running applications, services, and batch processes using Docker containers.

Amazon ECS is integrated with familiar features such as Elastic Load Balancing, EBS volumes, Amazon VPC, and IAM. Simple APIs allow users  integrate and use their own schedulers or connect Amazon ECS into their existing software delivery process. Using Fargate Spot tasks or EC2 Spot instances customers can get up to 90% discounts.

ECS supports Fargate to provide serverless compute for containers. Fargate removes the need to provision and manage servers. Using the capacity provider the demands of users application determines the compute capacity allocated to it and get the flexibility to use a mix of EC2 and Fargate with Spot and On-Demand pricing options.

Using ECS AWS clients can rapidly launch thousands of containers using ECS with no additional complexity. ECS runs on the best global infrastructure with 69 Availability Zones (AZ) across 22 Regions. AWS provides >2x more regions with multiple availability zones than the next largest cloud provider.

Amazon ECS Features

Amazon ECS is integrated with AWS Cloud Map, that helps customers  discover and connect  their containerized services with each other.  Cloud Map enables customers to define custom names for application resources, and it maintains the updated location of these dynamically changing resources. 

Service mesh makes it easy to build and run complex microservices applications by standardizing how every microservice in the application communicates.  AWS App Mesh is a service that is used for end-to-end visibility and high-availability.

  • App Mesh manages Envoy configuration to provide service mesh capabilities;
  • App Mesh exports metrics, logs, and traces to the endpoints specified in the Envoy bootstrap configuration provided;
  • App Mesh provides an API to configure traffic routes, circuit breaking, retries, and other controls between microservices that are mesh-enabled.

Amazon Elastic Container Service supports Docker networking and integrates with Amazon VPC to provide isolation for containers. Within Amazon ECS, there are four networking modes: 

  • Task Networking: This mode assigns each running ECS task a dedicated elastic networking interface, allowing containers full networking features in a VPC.

  • Bridge: This mode creates a Linux bridge that connects all containers running on the host in a local virtual network, which can be accessed through the host’s default network connection.
  • Host: This mode adds containers directly to the host’s network stack, exposing containers on the host’s network with no isolation.
  • None: This mode disables external networking for containers.

Amazon ECS is integrated with Elastic Load Balancing, that allows to distribute traffic across the containers using Application Load Balancers or Network Load Balancers. 

Amazon ECS enables customers to specify an IAM role for each ECS task. This allows the Amazon ECS container instances to have a minimal role, respecting the ‘least privilege’ access policy and  manage the instance role and the task role separately. 

Amazon ECS supports Docker and enables coatomers to run and manage Docker containers. Applications package as a container locally will deploy and run on Amazon ECS without the need for any configuration changes. An Amazon ECS-optimized Windows Amazon Machine Image (AMI) provides enhanced instance and container launch time performance and visibility into CPU, memory utilization, and reservation metrics.

An Amazon ECS-optimized Windows Amazon Machine Image (AMI) provides enhanced instance and container launch time performance and visibility into CPU, memory utilization, and reservation metrics.

  • Images are built from a Dockerfile, that is a plain text file that specifies all of the components that are included in the container. These images are then stored in a registry from which they can be downloaded and run on the cluster.
  • The Amazon ECS CLI supports Docker Compose, an open-source tool for defining and running multi-container applications. 
  • A Docker container is a standardized unit of software development, containing everything that the client software application needs to run including code, runtime, system tools, system libraries, etc. Containers are created from a read-only template called an image. 
  • Amazon ECS can be used with any third-party hosted Docker image repository or accessible private Docker registry, such as Docker Hub and Amazon ECR.
Amazon ECS

Amazon ECS uses multiple scheduling strategies that place containers across customers clusters based on the resource they needs, and availability requirements. Using the available scheduling strategies, users can schedule batch jobs, long-running applications and services, and daemon processes.

  • Task Scheduling: Amazon ECS task scheduling allows users to processes that perform work and then stop, such as batch processing jobs. Task scheduling can start tasks manually, automatically from a queue of jobs.
  • Service Scheduling: Amazon ECS service scheduling allows customers to run stateless services and applications. This scheduling strategy ensures that a specified number of tasks are constantly running and restarts tasks if they fail. 
  • Daemon Scheduling: Amazon ECS daemon scheduling automatically runs the same task on each selected instance in the user ECS cluster. This makes it easy to run tasks that provide common management functionality for a service like logging, monitoring, or backups.

Amazon ECS allows to customize how tasks are placed onto a cluster of EC2 instances based on built-in attributes such as instance type, Availability Zone, or custom attributes.

  • AWS customers can use attributes such as environment = production to label resources, use the list API actions to find those resources, and use the RunTask and CreateService API actions to schedule tasks on those resources.
  • Using Amazon ECS, users can also use placement strategies such as bin pack and spread to further define where tasks are placed. 

Amazon ECS allows AWS customers to define tasks through a declarative JSON template called a Task Definition. The task definition is a text file, in JSON format, that describes one or more containers, up to a maximum of ten, that form the application. Within a Task Definition customers can specify one or more containers that are required for the task, including the Docker repository and image, memory and CPU requirements, shared data volumes, and how the containers are linked to each other. Task definitions specify various parameters for this application.

  • Each task that uses the Fargate launch type has its own isolation boundary and does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task.
  • The specific parameters available for the task definition depend on which launch type you are using.
  • In order, the application to run on Amazon ECS, customers need to create a task definition.
  • The API actions, which is provided b ECS allow customers to create and delete clusters, register and deregister tasks, launch and terminate Docker containers, and provide detailed information about the state of your cluster and its instances. 
  • Customers can upload a new version of their application task definition, and the Amazon ECS scheduler automatically starts new containers using the updated image and stop containers running the previous version. 
  • The Amazon ECS will automatically recover unhealthy containers to ensure that you have the desired number of containers supporting your application.

Amazon ECS container instance is an Amazon EC2 instance, which runs the Amazon ECS container agent. Amazon ECS ddownloadsthe clients container images from a registry that they specify, and runs those images within the cluster. When running tasks using Amazon ECS, users place them on a cluster, which is a logical grouping of resources. 

  • Amazon ECS provides customers with a set of simple API actions, which  integrate and extend the service. The API actions enables users to create and delete clusters, register and deregister tasks, launch and terminate Docker containers, and provide detailed information about the state of the cluster and its instances.
  • Using AWS CloudFormation customers can provision Amazon ECS clusters, register task definitions, and schedule containers.
  • Blue/green deployments with AWS CodeDeploy help minimize downtime during application updates. This enables to launch a new version of Amazon ECS service alongside the old version and test the new version before rerouting traffic. 
  • Amazon Elastic File System (Amazon EFS) is a simple, scalable, fully managed elastic file system, enabling to build modern applications, and persist and share data and state, from the Amazon ECS and AWS Fargate deployments.

Amazon ECS provides monitoring capabilities for containers and clusters through Amazon CloudWatch. Users can monitor average and aggregate CPU and memory utilization of running tasks as grouped by task definition, service, or cluster.

  • By setting CloudWatch alarms to users can get alert when the containers or clusters need to scale up or down.

Amazon ECS allows to record all the Amazon ECS API calls and have the log files delivered to users through AWS CloudTrail.

  • The recorded information includes the identity of the API caller, the time of the API call, the source IP address of the API caller, the request parameters, and the response elements returned by Amazon ECS.

Amazon ECS can be used on AWS Outposts to run containerized applications that require particularly low latencies to on-premises systems. AWS Outposts is a fully managed service that extends AWS infrastructure, AWS services, APIs, and tools to virtually any connected site. 

Amazon Fargate

AWS Fargate is a technology that is used with Amazon ECS to run containers without having to manage servers or clusters of Amazon EC2 instances. AWS Fargate is a serverless compute engine for containers that works with both Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS)

The core task of Fragate is to provision and scale clusters, patch and update each server, task placement strategies including, manages the availability of containers All the user need to do is define the application’s requirements, select Fargate as the launch type in the console or CLI, and Fargate takes care of the rest.

  • Each Fargate task has its own isolation boundary, and it does not share the underlying kernel, CPU resources, memory resources, or elastic network interface with another task.
  • Amazon ECS EC2 launch type enables customers to manage a cluster of servers and schedule placement of containers on the servers. 
  • In order to take full advantage of Fargate, customers required to do the following:
    • Amazon ECS task definitions for Fargate network mode need to be set to awsvpc. The awsvpc network mode provides each task with its own elastic network interface.
    • Customers need to specify CPU and memory at the task level. They can also specify CPU and memory at the container level for Fargate tasks, if they desire to do so. Most use cases are satisfied by only specifying these resources at the task level.
  • Individual ECS tasks or EKS pods each run in their own dedicated kernel runtime environment and do not share CPU, memory, storage, or network resources with other tasks and pods. This ensures workload isolation and improved security for each task or pod.
  • Fargate,is built-in integrations with other AWS services including Amazon CloudWatch Container Insights. With this customers gather metrics and logs for monitoring their applications through an extensive selection of third party tools with open interfaces.

AWS Fargate platform versions are used to refer to a specific runtime environment for Fargate task infrastructure. It is a combination of the kernel and container runtime versions.

  • FireLens for Amazon ECS enables customers to use task definition parameters to route logs to an AWS service or AWS Partner Network (APN) destination for log storage and analytics.
  • Recycling for Fargate tasks, which is the process of refreshing tasks that are a part of an Amazon ECS service.
  • It has a definition parameters that enable customers to define a proxy configuration, dependencies for container startup and shutdown as well as a per-container start and stop timeout value
  • It supports injecting sensitive data into the containers that store in either AWS Secrets Manager secrets or AWS Systems Manager Parameter Store parameters and then referencing them in the container definition.
  • It enables CloudWatch Container Insights, and supports spot capacity provider.

Fargate Platform Version‐1.2.0 enables private registry authentication using AWS Secrets Manager.

Fargate Platform Version‐1.1.0

It has the Amazon ECS task metadata endpoint, supports Docker health checks in container definitions, and it also supports Amazon ECS service discovery. 

  • Clusters are Region-specific
  • A cluster may contain a mix of tasks using either the Fargate or EC2 launch types.
  • A cluster may contain a mix of both Auto Scaling group capacity providers and Fargate capacity providers, however when specifying a capacity provider strategy they may only contain one or the other but not both.
  • It allows customers to create custom IAM policies to allow or restrict user access to specific clusters.

Amazon ECS cluster 

An Amazon ECS cluster is a logical grouping of tasks or services. A cluster is a grouping of container instances that is used when running tasks or services that use the EC2 launch type. When using capacity providers, a cluster is a logical grouping of capacity providers. By default cluster is created when customers first use Amazon ECS, but multiple clusters can be created in an account that keep users resources separate. These are general concepts of Amazon ECS clusters.

  • Clusters are Region-specific.

  • The following are the possible states that a cluster can be in.

    ACTIVE: The cluster is ready to accept tasks and, if applicable, you can register container instances with the cluster.
    PROVISIONING: The cluster has capacity providers associated with it and the resources needed for the capacity provider are being created.
    DEPROVISIONING: The cluster has capacity providers associated with it and the resources needed for the capacity provider are being deleted.
    FAILED: The cluster has capacity providers associated with it and the resources needed for the capacity provider have failed to create.
    INACTIVE: The cluster has been deleted. Clusters with an INACTIVE status may remain discoverable in your account for a period of time. However, this behavior is subject to change in the future, so you should not rely on INACTIVE clusters persisting.
  • A cluster may contain a mix of tasks using either the Fargate or EC2 launch types

  • A cluster may contain a mix of both Auto Scaling group capacity providers and Fargate capacity providers, however when specifying a capacity provider strategy they may only contain one or the other but not both

  • For tasks using the EC2 launch type, clusters can contain multiple different container instance types, but each container instance may only be registered to one cluster at a time.

  • Custom IAM policies may be created to allow or restrict user access to specific clusters

Capacity Providers manage compute capacity for containers, that allow the application to define its requirements for how it uses the capacity. It can be used to define flexible rules for how containerized workloads run on different types of compute capacity, and manage the scaling of the capacity. Using Capacity Providers improve the availability, scalability, and cost of running tasks and services on ECS.

  • A capacity provider is used in association with a cluster to determine the infrastructure that a task runs on. For Amazon ECS on Amazon EC2 users, a capacity provider consists of a name, an Auto Scaling group, and the settings for managed scaling and managed termination protection.
  • A default capacity provider strategy is associated with each Amazon ECS cluster. Which determines the capacity provider strategy the cluster will use if no other capacity provider strategy or launch type is specified when running a task or creating a service. 
  • A capacity provider strategy gives customers control over how their tasks use one or more capacity providers. The capacity provider strategy consists of one or more capacity providers with an optional base and weight specified for each provider.
  • Capacity Providers work with both EC2 and Fargate, do that customers can create a Capacity Provider associated with an EC2 Auto Scaling Group (ASG)
  • Splitting running tasks and services across multiple Capacity Providers enables new capabilities such as running a service in a predefined split percentage across Fargate and Fargate Spot, or ensuring that a service runs an equal number of tasks in multiple availability zones without requiring the service to rebalance.

#01

CAPACITY PROVIDERS

 

#02

AWS Fargate capacity providers

 

 

Amazon ECS on AWS Fargate capacity providers enables to use both Fargate and Fargate Spot capacity with your Amazon ECS tasks. Using Fargate Spot users can run interruption tolerant Amazon ECS tasks at a discounted rate compared to the Fargate price. Fargate Spot runs tasks on spare compute capacity. Considered the following when using Fargate capacity providers:

  • The Fargate and Fargate Spot capacity providers do not need to be created. They are available to all accounts and only need to be associated with a cluster to be available for use.

  • To associate Fargate and Fargate Spot capacity providers to an existing cluster, you must use the Amazon ECS API or AWS CLI

  • The Fargate and Fargate Spot capacity providers are reserved and cannot be deleted. If necessary disassociate them from a cluster using the PutClusterCapacityProviders API.

  • When a new cluster is created using the Amazon ECS console along with the Networking only cluster template, the FARGATE and FARGATE_SPOT capacity providers are associated with the new cluster automatically.

  • To add the FARGATE and FARGATE_SPOT capacity providers to an existing cluster, is necessery to use the AWS CLI or API

  • Using Fargate Spot requires that your task use platform version 1.3.0 or later. 

  • When tasks using the Fargate and Fargate Spot capacity providers are stopped, a task state change event is sent to Amazon EventBridge

  • A cluster may contain a mix of Fargate and Auto Scaling group capacity providers, however a capacity provider strategy may only contain either Fargate or Auto Scaling group capacity providers, but not both.

ECS Cluster Auto Scaling (CAS) is a service provided by AWS, and it has capability to manage the scaling ECS for EC2 Auto Scaling Groups (ASG). With CAS, customers can configure ECS to scale the ASG automatically. Each cluster has one or more capacity providers and an optional default capacity provider strategy. The capacity providers determine the infrastructure to use for the tasks, and the capacity provider strategy determines how the tasks are spread across the capacity providers. 

  • ECS will ensure the ASG scales in and out as needed with no further intervention required. CAS relies on ECS capacity providers, which provide the link between ECS cluster and the ASGs. Each ASG is associated with a capacity provider, and each such capacity provider has only one ASG, but many capacity providers can be associated with one ECS cluster.
  • When managed scaling is enabled, Amazon ECS manages the scale-in and scale-out actions of the Auto Scaling group. Amazon ECS creates an AWS Auto Scaling scaling plan with a target tracking scaling policy based on the target capacity value the customer specified.
  • When Amazon ECS capacity providers – Amazon Elastic Container Service, use either the cluster’s default capacity provider strategy or specify a capacity provider strategy that overrides the cluster’s default strategy. 
Cluster auto scaling considerations
  • Amazon ECS uses the AWSServiceRoleForECS service-linked IAM role for the permissions it requires to call AWS Auto Scaling, on your behalf. For more information on using and creating Amazon ECS service-linked IAM roles, see Service-Linked Role for Amazon ECS.

  • When using capacity providers with Auto Scaling groups, the IAM user creating the capacity providers, needs the autoscaling:CreateOrUpdateTags permission. This is because Amazon ECS adds a tag to the Auto Scaling group when it associates it with the capacity provider.

#03

ECS CLUSTER AUTO SCALING

 

#04

Task Definitions

 

The task definition is a text file, in JSON format, that describes one or more containers, up to a maximum of ten, that form the application. Within a Task Definition customers can specify one or more containers that are required for the task, including the Docker repository and image, memory and CPU requirements, shared data volumes, and how the containers are linked to each other. In order to run Docker containers in Amazon ECS, a task definition is required. 

Application architecture: The following launch type are recommended by AWS for the AWS Application architecture:

  • Using the Fargate launch type: When architecting AWS application using the Fargate launch type tasks, the main question need to be asked is when to put multiple containers into the same task definition versus deploying containers separately in multiple task definitions.
  • Using the EC2 launch type: when considering how to model task definitions and services using the EC2 launch type, it helps to think about what processes need to run together and how to scale each component.

Task definition parameters: Task definitions are split into separate parts: the task family, the IAM task role, the network mode, container definitions, volumes, task placement constraints, and launch types. The family and container definitions are required in a task definition, while task role, network mode, volumes, task placement constraints, and launch type are optional. Using a per-container swap configuration, each container within a task definition can have swap enabled or disabled, and for those that have it enabled, The swap configuration for a container is managed by the following container definition parameters:

  • maxSwap: If a maxSwap value of 0 is specified, the container will not use swap. Accepted values are 0 or any positive integer. If the maxSwap parameter is omitted, the container will use the swap configuration for the container instance it is running on. A maxSwap value must be set for the swappiness parameter to be used.
  • swappiness:This allows users to tune a container’s memory swappiness behavior. A swappiness value of 0 will cause swapping to not happen unless absolutely necessary. A swappiness value of 100 will cause pages to be swapped very aggressively. Accepted values are whole numbers between 0 and 100.

Specifying sensitive data: Amazon ECS enables to inject sensitive data into the containers by storing users sensitive data in either AWS Secrets Manager secrets or AWS Systems Manager Parameter Store. Secrets can be exposed to a container in the following ways:

  • To inject sensitive data into your containers as environment variables, use the secrets container definition parameter.

  • To reference sensitive information in the log configuration of a container, use the secretOptions container definition parameter.

 

Amazon ECS task definitions

Amazon ECS

A task definition is required to run Docker containers in Amazon ECS. The following are some of the parameters users can specify in a task definition:

  • The Docker image to use with each container in the task
  • How much CPU and memory to use with each task or each container within a task
  • The launch type to use, which determines the infrastructure on which users tasks are hosted
  • The Docker networking mode to use for the containers in the task
  • The logging configuration to use for the tasks
  • Whether the task should continue to run if the container finishes or fails
  • The command the container should run when it is started
  • Any data volumes that should be used with the containers in the task
  • The IAM role that your tasks should use
 

Users can define multiple containers in a task definition. The parameters that is used depend on the launch type users choose for the task. Not all parameters are valid. 

Users entire application stack does not need to be on a single task definition, and in most cases it should not. The application can span multiple task definitions. Users can do this by combining related containers into their own task definitions, each representing a single component

Amazon ECS task networking

The networking behavior of Amazon ECS tasks hosted on Amazon EC2 instances is dependent on the network mode defined in the task definition. The following are the available network modes. Amazon ECS recommends using the awsvpc network mode unless you have a specific need to use a different network mode.

  • awsvpc — The task is allocated its own elastic network interface (ENI) and a primary private IPv4 address. This gives the task the same networking properties as Amazon EC2 instances.
  • bridge — The task utilizes Docker’s built-in virtual network which runs inside each Amazon EC2 instance hosting the task.
  • host — The task bypasses 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.
  • none — The task has no external network connectivity.
 
Using data volumes in tasks

There are several use cases for using data volumes in Amazon ECS task definitions. The following are the types of data volumes that can be used:

Docker volumes — A Docker-managed volume that is created under /var/lib/docker/volumes on the host Amazon EC2 instance. Docker volume drivers (also referred to as plugins) are used to integrate the volumes with external storage systems, such as Amazon EBS. The built-in local volume driver or a third-party volume driver can be used. Docker volumes are only supported when running tasks on Amazon EC2 instances.

  • Windows containers only support the use of the local driver. To use Docker volumes, specify a dockerVolumeConfiguration in your task definition. 

Bind mounts — A file or directory on the host machine is mounted into a container. Bind mount host volumes are supported when running tasks on either AWS Fargate or Amazon EC2 instances.

  • To use bind mount host volumes, specify a host and optional sourcePath value in the task definition. 

Container instances

An Amazon ECS container instance is an Amazon EC2 instance that is running the Amazon ECS container agent and has been registered into an Amazon ECS cluster. When you run tasks with Amazon ECS using the EC2 launch type or an Auto Scaling group capacity provider, your tasks are placed on your active container instances.

Amazon ECS
Amazon ECS-optimized AMIs

Amazon ECS-optimized AMIs are preconfigured and tested on Amazon ECS by AWS engineers. It is the simplest way to get started and to get the containers running on AWS quickly. The Amazon ECS-optimized AMI metadata, including the AMI name, Amazon ECS container agent version, and ECS runtime version which includes the Docker version, for each variant can be retrieved programmatically. 

An Amazon ECS container instance specification consists of the following components. A modern Linux distribution running at least version 3.10 of the Linux kernel; The Amazon ECS container agent;a Docker daemon running at least version 1.9.0, and any Docker runtime dependencies; and an initialization and nanny process to run and monitor the Amazon ECS container agent.

  • The Amazon ECS-optimized AMIs receive regular updates for Amazon ECS container agent changes, Docker version updates, and Windows or Linux kernel security updates.
AMI storage configuration
  • The Amazon Linux 2-based Amazon ECS-optimized AMIs (Amazon ECS-optimized Amazon Linux 2 AMI, Amazon ECS-optimized Amazon Linux 2 (arm64) AMI, and Amazon ECS GPU-optimized AMI) ship with a single 30-GiB root volume.
  • The Amazon ECS-optimized Amazon Linux AMI ships with 30 GiB of total storage. Users can modify this value at launch time to increase the available storage on your container instance. This storage is used for the operating system and for Docker images and metadata. 

 

 

Spot Instances

A Spot Instance is an unused Amazon EC2 instance that is available for less than the On-Demand price. Because Spot Instances enable to request unused EC2 instances at steep discounts. The hourly price for a Spot Instance is called a Spot price. The Spot price of each instance type in each Availability Zone is set by Amazon EC2, and adjusted gradually based on the long-term supply of and demand for Spot Instances.

Spot Instance Draining: Amazon EC2 terminates, stops, or hibernates Spot Instance when the Spot price exceeds the maximum price for users request or capacity is no longer available.

  • Amazon EC2 provides a Spot Instance interruption notice, which gives the instance a two-minute warning before it is interrupted.
  • If Amazon ECS Spot Instance draining is enabled on the instance, ECS receives the Spot Instance interruption notice and places the instance in DRAINING status.
  • Service tasks on the draining container instance that are in the PENDING state are stopped immediately.
  • If there are container instances in the cluster that are available, replacement service tasks are started on them.

Spot Instance draining is disabled by default and must be manually enabled. To enable Spot Instance draining for a new container instance, when launching the container instance add the following script into the User data field, replacing MyCluster with the name of the cluster to register the container instance to.

Bootstrapping Container Instances

The data can be used to perform common automated configuration tasks and even run scripts when the instance boots. For Amazon ECS, the most common use cases for user data are to pass configuration information to the Docker daemon and the Amazon ECS container agent. Users can pass multiple types of user data to Amazon EC2, including cloud boothooks, shell scripts, and cloud-init directives. 

Amazon ECS Container Agent: The Linux variants of the Amazon ECS-optimized AMI look for agent configuration data in the /etc/ecs/ecs.config file when the container agent starts. You can specify this configuration data at launch with Amazon EC2 user data. 

Docker Daemon: You can specify Docker daemon configuration information with Amazon EC2 user data, but this configuration data must be written before the Docker daemon starts. The cloud-boothook user data format executes earlier in the boot process than a user data shell script.

Docker Daemon: You can specify Docker daemon configuration information with Amazon EC2 user data, but this configuration data must be written before the Docker daemon starts. The cloud-boothook user data format executes earlier in the boot process than a user data shell script.

Cloud-init-per Utility: The cloud-init-per utility is provided by the cloud-init package to help you create boothook commands for instances that run at a specified frequency.

 

Amazon Elastic Container Service (Amazon ECS) is one of the  container services provided by Amazon, which is a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker containers on a cluster. Amazon ECS lets clients launch and stop container-based applications with simple API calls. Amazon ECS allows  customers to launch and stop container-based applications with simple API calls, that allows them to get the state of the cluster from a centralized service, and gives access to many familiar Amazon EC2 features. ECS is a great choice to run containers for several reasons. 

ECS used by several big companies such as Duolingo, Samsung, GE, and Cookpad to run their most sensitive and mission critical applications because of its security, reliability, and scalability.

  • AWS customers are able to run their ECS clusters using AWS Fargate, which is serverless compute for containers.
  • it can natively integrate with other services such as Amazon Route 53, Secrets Manager, AWS Identity and Access Management (IAM), and Amazon CloudWatch providing you a familiar experience to deploy and scale your containers.
  • ECS is used extensively within Amazon to power services such as Amazon SageMaker, AWS Batch, Amazon Lex, and Amazon.com’s recommendation engine, ensuring ECS is tested extensively for security, reliability, and availability.