[AWS] ECS

AWS ECS (Elastic Container Service) runs highly secure, reliable, and scalable containers. This post is mainly focuses on the general ECS features and the EC2 launch type. Please refer to this post for the Fargate launch type.

Features

• ECS is a management system of Containers at scale.
• ELB(Elastic Load Balancer) integration
• Easy Security Management with IAM roles
• Launch Types
  • EC2: You are provisioning underlying EC2 instances for your containers.
  • Fargate: Underlying instances are managed by the service.

Task Definition

Task definitions specify the container information for your application

• type compatibility
  • Fargate, EC2, or External (ECS Anyware)
• Task Execution Role
• Task size
  • Memory and vCPU
• Container image
• Host port mapping

Cluster

Once you have a task definition, you need to setup a cluster to run a task. An Amazon ECS cluster is a regional grouping of one or more container instances on which you can run task requests.

• Each EC2 instance must run the ECS Agent to register in the ECS Cluster.

In the cluster Tasks tab, you can run a new task inside the cluster.

• Pricing Model
  • On-demand instances or Spot instances
• Instance Type and AMI ID
• The number of instances
• Network settings
  • VPC, Subenets, and Security Groups

IAM Roles

EC2 Instance Profile

• attached to an EC2 instance
• used by an ECS agent
• what to do
  • pull docker images from ECR
  • make API calls to ECS services
  • send container logs to CloudWatch Logs
  • read values from Secrets Manager or SSM Parameter Store

ECS Task Role

• allows each task to its job – a specific role per task
• defined in the task definition

Invoking ECS Tasks

• by the events trough Amazon EventBridge
  • ex.) an object is uploaded to S3 -> EventBridge event -> Launch the ECS task
• by the EventBridge schedules
  • ex.) every hour or in a specified date and time.
• by the SQS message (polling)

Integration with Load Balancer

• works with Application Load Balancer in most use cases
• Use Network Load Balancer only for high throughput / high performance use cases or to pair with AWS Private Links

Common Storage

To share data among ECS tasks in multi-AZ, you can mount EFS onto ECS or Fargate tasks.

• works for both EC2 and Fargate 
• Fargate + EFS = Serverless
• S3 cannot be mounted as a file system.

Auto Scaling

ECS Service Auto Scaling scales the tasks, not the EC2 instances.

ECS Service Scaling

• ECS Auto Scaling is based on:
  • ECS Service Average CPU Utilization
  • ECS Service Average Memory Utilization
  • ALB Request Count per Target (ALB Metric)

• ECS Service Auto Scaling Types
  • Target Tracking: based on the target value of a specific CloudWatch metric
  • Step Scaling: scale based on the specific CloudWatch alarm
  • Scheduled Scaling: scale based on the schedule (predictable)

Scaling EC2 Instances

• Auto Scaling Group
  • scale your ASG based on CPU utilization
• ECS Cluster Capacity Provider
  • scale the infrastructure of the ECS tasks
  • paired with ASG

Monitoring and Logging

CloudWatch Integration

CloudWatch Container Insights

• Amazon CloudWatch Container Insights collects, aggregates, and summarizes additional metrics and logs from your containerized applications.
• Metrics
  • CPU and Memory utilization
  • Task and Service counts
  • Read/write storage
  • Network throughput
  • Container instance counts

Events via EventBrige

• Any change in tasks can be sent to EventBrige.

{
  "source": "aws.ecs",
  "detail-type": "ECS Task State Change",
  "detail": {
    "lastStatus": "STOPPED",
    "stoppedReason": "..."
  }
}

Logging Drivers

• Containers can send application logs directly to CloudWatch Logs
• You need to turn on “awslogs” log driver.
• You need to configure “logConfiguration” section in the Task definition.

"logConfiguration": {
  "logDriver": "awslogs",
  "options": {
    "awslogs-group": "/ecs/fagate-task",
    "awslogs-region": "us-east-1",
    "awslogs-stream-prefix": "ecs"
  }
}

Logging with Sidecar Container

• You can launch a separate container to collect log from all other containers.

Best Practices

• Container Image
  • Make images complete and static
    • Store all application dependencies as static files inside the container image
  • Keep container images as small as possible
    • Maintain fast container launch time
  • Run only a single application process with a container image
  • Write logs to stdout and stderr streams
  • Use tags for versioning