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 EC2 instances to manage)
No need to worry about infrastructure scaling
Just create task definitions
AWS just runs ECS Tasks for you based on the CPU / RAM you need (we won’t know where these containers are running)
To scale, just increase the number of tasks - no more EC2 instances
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.

Accommodate ECS Service Scaling by adding underlying EC2 Instances •
Auto Scaling Group Scaling
- Scale your ASG based on CPU Utilization
- Add EC2 instances over time
ECS Cluster Capacity Provider
- Used to automatically provision and scale the infrastructure for your ECS Tasks
- Capacity Provider paired with an Auto Scaling Group
- Add EC2 Instances when you’re missing capacity (CPU, RAM…)

Used by the ECS agent to:
- Make API calls to ECS service
- Send container logs to CloudWatch Logs
- Pull Docker image from ECR
- Reference sensitive data in Secrets Manager or SSM Parameter Store

Application Load Balancer supported and works for most use cases
Network Load Balancer recommended only for high throughput / high performance use cases, or to pair it with AWS Private Link
Classic Load Balancer supported but not recommended (no advanced features – no Fargate)

Automatically increase/decrease the desired number of ECS tasks
Amazon ECS Auto Scaling uses AWS Application Auto Scaling
- ECS Service Average CPU Utilization
- ECS Service Average Memory Utilization - Scale on RAM
- ALB Request Count Per Target – metric coming from the ALB
Target Tracking – scale based on target value for a specific CloudWatch metric
Step Scaling – scale based on a specified CloudWatch Alarm
Scheduled Scaling – scale based on a specified date/time (predictable changes)
ECS Service Auto Scaling (task level) ≠ EC2 Auto Scaling (EC2 instance level)
Fargate Auto Scaling is much easier to setup (because Serverless)

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.