Elastic Container Service

Introduction

• Launch container instances on AWS as ECS Tasks
• Launch Types:
  • EC2: You must provision and manage the infrastructure (EC2 instances)
    • Each EC2 instance must run the ECS Agent to register in the ECS cluster

  • Fargate: AWS provisions and manages the infrastructure

IAM Roles for ECS

• EC2 Instance Profile
  • Used by the ECS agent to make API calls to ECS Service, send container logs to CloudWatch, pull docker images from ECR, etc.
• ECS Tasks:
  • Each ECS tasks gets a role. Applies to both EC2 and Fargate launch types
  • Task role is defined in the Task Definition

Load Balancer Integrations

• ALB supports and works for most use cases
• NLB is recommended only for high-throughput use cases

Data Volumes

• Mount EFS file systems onto ECS Tasks
• Works for both EC2 and Fargate Launch Types
• Tasks running in any AZ will share the same data in the EFS file system
• EFS + Fargate = serverless
• S3 cannot be mounted on a file system in your ECS Tasks

ECS Service Auto-scaling

• You can scale on 3 metrics
  • CPU
  • Memory
  • ALB Request Count
• Types of Scaling:
  • 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
• Auto Scaling EC2 instances
  • Use an Auto Scaling Group
    • Scale based on CPU usage
  • ECS Cluster Capacity Provider
    • Used to automatically provision and scale the infrastructure of your ECS Tasks
    • Capacity Provider is paired with an auto-scaling group
    • Add EC2 instances when you are out of usable capacity (CPU, RAM, etc…)

ECS Rolling Updates

• When updating versions of an ECS service, we can control how many tasks can be started and stopped, and in which order
• Rolling Updates

ECS Tasks Definitions

• Tasks definitions are metadata in JSON form to tell ECS how to run a container
• How can we add environment variables to an ECS Task?
  • Hardcoded - URLs for example
  • SSM Parameter Store - sensitive variables such as API keys
  • Secrets Manager - Sensitive variables
• Bind mounts
• Essential Container -If enabled: If one container in the task fails or stops, all the other containers in the task will stop

ECS Task Placement

• When a Task Definition for EC2 is created, ECS must determine where to schedule it

• When a service scales in, ECS must determine which tasks to kill

• To help with this, you can define a task placement strategy and task placement constraint

• Task placement strategies and constraints only work on EC2 launch types

• How does this work?

  • ECS will first determine where it is possible to place the task. Which nodes have enough resources?
  • ECS will then determine which EC2 instances satisfy the task placement constraints
  • ECS will then determine which EC2 instances satisfy the task placement strategy
  • ECS will then schedule the task

• Task Placement Strategies

  • BinPack: Schedule tasks based on the least available amount of CPU or memory
    • i.e. pack as many containers as possible on a node before scheduling containers on other nodes
  • Random: Place the task randomly
  • Spread: Spread instances across nodes based on a specified value (AZ, instanceId, etc.)

• Task Placement Constraints

  • distinctInstance: Each task should be placed on a separate EC2 instance
  • memberOf: Schedule tasks on instances that satisfy an expression written in cluster query language ()