Elastic Container Service(ECS)

Launch Types

Not Serverless
Containers run on underlying EC2 instances
ECS takes care of launching & stopping containers (ECS tasks)
You must provision & maintain EC2 instances (use ASG)
EC2 instances have ECS agent running on them as a docker container
Inside a VPC spanning multiple AZ, there is an ECS cluster spanning multiple AZ. Inside the ECS cluster, there will be an ASG responsible for launching container instances (EC2). On every EC2 instance, ECS agent will be running (happens automatically if you choose the AMI for ECS when launching the instance) which registers these instances to the ECS cluster. This will allow the ECS cluster to run Docker containers (ECS tasks) on these instances.

Serverless
No need to provision infrastructure
No need to worry about infrastructure scaling
ECS launches the required containers based on the CPU / RAM needed (we won't know where these containers are running)
VPC and ECS cluster are setup the same way as in EC2 launch type, but instead of using ASG with EC2 instances, we have a Fargate cluster spanning multiple AZ. The Fargate cluster will run ECS tasks anywhere within the cluster and attach an ENI (private IP) to each task. So, if we have a lot of ECS tasks, we need sufficient free private IPs.

EC2 Instance Profile (IAM role for the EC2 instance)
- Used by the ECS agent to:
  - Make API calls to ECS service
  - Send container logs to Cloud Watch
  - Pull Docker image from ECR
Task Execution Role
- Allows ECS tasks to access AWS resources
- Each task can have a separate role
- Use different roles for the different ECS Services
- Task Role is defined in the task definition
- Use taskRoleArn parameter to assign IAM policies to ECS Task Execution Role
- Ex. Reference sensitive data in Secrets Manager or SSM Parameter Store

An ECS Service is a collection of long-running ECS tasks (eg. web application) that perform the same function
We can use ALB to send requests to these tasks
Service CPU Usage or the SQS queue length for a service are used for scaling
Diagram

EC2 Launch Type
- For every container, the container port is mapped to a random free port on the hots (instance). So the application running inside that container will be reached by the ALB on that random port.
- Dynamic Host Port Mapping - Once the ALB is registered to a service in the ECS cluster, it will automatically find the right port on the EC2 Instances. This only works with ALB, not CLB.
- You must allow on the EC2 instance’s security group any port from the ALB security group because it may attach on any port
- Diagram
Fargate Launch Type
- Each task has a unique IP but the same container port
- The ALB connects to each task directly on its IP and container port since these containers are not run on a defined host (instance).
- You must allow on the ENI’s security group the task port from the ALB security group
- Diagram

Minimum healthy percentage - determines how many tasks, running the current version, we can terminate while staying above the threshold
Maximum percentage - determines how many new tasks, running the new version, we can launch while staying below the threshold
Min: 50% and Max: 100% and starting number of tasks 4
Min: 100% and Max: 150% and starting number of tasks 4

Store the secrets in Parameter Store and encrypt them using KMS
Reference the secrets in container definition with the name of the environment variable
Create an ECS task execution role and reference it with your task definition, which allows access to both KMS and the Parameter Store/Secrets Manager.
Supported for both EC2 and Fargate launch types

You can use EventBridge (CloudWatch Events) to run Amazon ECS tasks when certain AWS events occur.
Ex: set up a CloudWatch Events rule that runs an Amazon ECS task whenever a file is uploaded to an S3 bucket. You can also declare a reduced number of ECS tasks whenever a file is deleted from the S3 bucket.