# Elastic Container Service (ECS)

## Icon

![ECS Icon](https://icon.icepanel.io/AWS/svg/Containers/Elastic-Container-Service.svg)

## Basics

* Its a fully managed container orchestration service that helps you easily deploy, manage, and scale **containerized** applications.

### Capacity Management

* There are 3 ways to do capacity management for this orchestration service.

#### EC2 instance Launch Type

* Docker containers are placed on Amazon EC2 instances in this type of launch configuration.
* Provisioning and managing the EC2 instance infrastructure needs to be done.
* Each EC2 instances would be running ECS Agent who would be registering EC2 instances to ECS cluster.
* ECS `Task Placement strategy` and `Task placement constraints` assists us to decide which ECS task to terminate when adding new adding new ECS Task due to scaling or new deployment to cluster.
  * `Task Placement Strategy`
    * This strategy is done based on best effort basis.
    * Following is the strategy algorithm
      * Identify instances that satisfy ECS task requirement of CPU, Memory and port as per Task definition.
      * Identify instances that satisfy the Task Placement Constraints.
      * Select instance for task placement.
    * Following are the strategies.
      * `Binpack`
        * Place Task based on least available CPU or memory.
        * Reduces the number of instances in use, resulting in cost savings.
      * `Random`
        * Places Task randomly.
      * `Spread`
        * Places based on specified value.
        * This value can be ECS availability zones, Instance Id and so on...
    * These strategies can be mixed and matched.
  * `Task Placement Constraints`
    * `distinctInstance`
      * Two task of same type are never placed on same EC2 instance.
    * `memberOf`
      * Places instances based on the result of an expression written in cluster query language.

![EC2 Instance](https://574639531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJDnjsv52I3fJ56WbLgHu%2Fuploads%2Fgit-blob-f1abcfa44c1f87ed138bd3d45637156ab9ec3753%2FEC2_Instances_LaunchType.png?alt=media)

#### Fargate

* In this type of configuration, the infrastructure _(no EC2 instances to manage)_ is serverless.
* Based on configuration for RAM and CPU provided, ECS will run the ECS tasks behind the scene.
* Scaling is simply increasing the number of tasks.
* Fargate launch type does not require host port to be configured as each ECS task gets its own private IP address throug an Elastic Network Interface (ENI) i.e., infrastructure is not to be managed by the user.

![ECS Fargate](https://574639531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJDnjsv52I3fJ56WbLgHu%2Fuploads%2Fgit-blob-73c430de5b80fcdec9b20d02b12e94ad244ed905%2FECS_Fargate.png?alt=media)

#### External

* [External Instances using ECS Anywhere](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-anywhere.html)

### Terminology

#### Task Definition

* **Task Definition** is a blueprint of an application to be created.
* It is a JSON document which has details regarding how to run a task definitions.
* Following are the crucial information,
  * Image Name
  * Port bindings
  * Environment Variables
  * CPU and Memory usage
  * Networking information
  * IAM roles
  * Logging configuration
* Can define upto 10 containers per task definition.
* Environment variables can be loaded from,
  * Hardcoded i.e from URL etc..
  * Secret Manager
  * SSM parameter store
  * Amazon S3 _(Bulk )_
* Data can be shared between containers created from same task defintion by mounting data volumes _(Bind Mounts)_.
  * This concept is called SideCar container pattern, where sidecar container is used to read or write data _(e.g., metrics/logs)_ to other destinations.
  * For EC2 instance launch type, EC2 instance store is the Bind Mount with
  * For Fargate launch type, Ephemeral Storage is the Bind Mount.
* **ECS tasks** are runtime instance of **Task Definition**.
* Containers are **ECS tasks** that run on ECS clusters.

## IAM roles

* IAM roles are assigned per task definition
* Following roles are used based on launch type to create and manage ECS Task

### EC2 Instance Profile

* Used by EC2 agent when launch type is EC2 instance.
* This role helps to make API calls to ECS service.
* Send logs to CloudWatch Logs.
* Pull docker image from ECR.
* Reference sensitive data in Secret Manager or SSM parameter store.

### ECS Task Role

* Applicable to both launch types.
* Allows each tasks to have specific role based on the requirement.
* These roles are defined in the task definition of ECS service.

## Load Balancer Integration

* ALB and NLB is supported to be integrated with ECS cluster.
* Classic Load balancer is not recommended for integration and does not support Fargate Launch Type.
* Application Load Balancer can connect to correct EC2 port for EC2 Launch Type when Dynamic Host Port Mapping is configured _(i.e only container port is mapped)_, provided that Inbound Rules allow mapping to any port from ALB's security group.

## Auto Scaling

### ECS Service Auto Scaling

* AutoScaling allows to increase or decrease the desired number of ECS task.
* Scaling can be one of the following
  * Target Tracking _(based on configured CloudWatch Metrics)_.
    * Scaling can be based on following metrics,
    * ECS Service Average CPU Utilization
    * ECS Service Average Memory Utilization
    * ALB Request Count Per Target
  * Step Scaling
  * Scheduled Scaling
* This scaling is not same as EC2 Auto Scaling.

### Auto Scaling EC2 instances

* Auto Scaling Group Scaling
  * Scale your ASG based on CPU Utilization i.e Add EC2 instance when CPU utilization reaches the target threshold.
* ECS Cluster Capacity Provider
  * Capacity provider paired with Auto Scaling Group.
  * Add EC2 instances when resource utilization reaches the target threshold configured.
  * This is a better scaling option that the Auto Scaling Group Scaling.

## Rolling Updates

* Rolling updates ensure high availability of your application when it getting updated or new changes are being deployed.
* This is done by making sure a **min** number of tasks are running at the time of updates, but doesnt cross the **max** number of tasks running.
* When min is `50%` and max is `100%` the following diagram shows how an application does rolling update. ![Rolling Update](https://574639531-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FJDnjsv52I3fJ56WbLgHu%2Fuploads%2Fgit-blob-d8b112fed4322894b7090fc170aa280169a88330%2FRolling_Update.png?alt=media)

## Data Volumes

### EFS integration

* Can be mounted to ECS tasks of both EC2 and Fargate launch types.
* Tasks running in any AZ can connect with EFS and share data. Hence help us achieve multi-AZ shared storage for your containers.
* EFS + Fargate => Serverless.

### S3 integration

* Cannot be mounted as file system.

## References

* [Docker-vs-VM](https://aws.amazon.com/compare/the-difference-between-docker-vm/)
* [Launch Types](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/launch_types.html)
* [Load Balancer Integrations](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-load-balancing.html)
* [Cluster and Scaling](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/clusters.html)
