Amazon Elastic Container Service (ECS)
- Container management service for Docker containers (ECS Task)
- Highly scalable / high performance, lets you run applications on an EC2 cluster
- Amazon Elastic Container Registry (ECR) is private repository for Docker images, the public version is Amazon ECR Public Gallery; backed by Amazon S3, access controlled through IAM
- ECS Launch Types
- Fargate Launch Type is serverless, managed by AWS
- EC2 Launch Type gives you direct access to the instances, but you have to manage them, with ECS Agent
- Launch Docker containers on AWS = Launch ECS Tasks on ECS Clusters
- ECS Agent would use EC2 Instance Profile
- ESC Tasks use each individual ESC Task Role, which is defined in the task definition
- ECS Task definition is metadata in JSON, up to 10 containers in one file
- Image name
- Port Binding for Container and Host
- on EC2 Launch type, if only define container port, then the ALB would use Dynamic Host Port Mapping, then on EC2 instance’s Security Group should set allow on any port from ALB security group
- each task has its unique private IP on Fargate Launch, so only define the container port
- Memory and CPU required
- Environment variables (Hardcoded ,SSM Parameter Store, Secrets Manager, or files stored in S3)
- Networking
- IAM Role (One IAM Role per Task Definition)
- Logging configuration (CloudWatch)
- Data Volume to share data among multiple containers (Applications and Metrics/Logs, aka sidecar)
- EC2 Launch Type – using EC2 instance storage
- Fargate Launch Type – using ephemeral storage (20-200 GB), data deleted when containers demolished
- ECS Task Placement strategy & Task Placement constraints – Only for EC2 Launch Type
- find instances meet CPU/Memory/Port requirements
- find those satisfy task placement constraints
- distinctInstance – place each task on different container instance
- memberOf – using Cluster Query Language, placing on certain instances (like t2.*)
- find those satisfy task placement strategies
- Binpack – cost-saving by using least available amount of CPU or Memory as minimum instances
- Random
- Spread (can be AZ or instance ID)
- Mount EFS for ECS tasks; in comparison, S3 cannot be mounted as File System
- Works for both EC2 and Fargate launch types
- tasks in any AZ will share the same data
- Use cases: persistent multi-AZ shared storage for your containers
- ECS does not use EC2 Auto Scaling, instead, uses the AWS Application Auto Scaling based on
- Average CPU Utilization
- Average Memory Utilization – Scale on RAM
- ALB Request Count Per Target
- AWS Application Auto Scaling policy can be
- Target Tracking – scale based on the target specific CloudWatch metric
- Step Scaling – based on a specified CloudWatch Alarm
- Scheduled Scaling – scale based on a specified date/time (predictable changes)
- Under EC2 Launch Type, the way to auto-scaling EC2 instances by
- Auto Scaling Group Scaling – use EC2 ASG to check instance loadings (CPU, Memory, etc.)
- ECS Cluster Capacity Provider, paired with ASG
- Used to automatically provision and scale the infrastructure for your ECS Tasks
- Imagine you have an e-commerce application running on ECS. You can define a capacity provider strategy that uses an Auto Scaling group for EC2 instances to handle the bulk of your traffic, and then also use Fargate for handling sudden traffic spikes. ECS will then automatically manage the scaling of both your EC2 instances and Fargate resources, ensuring optimal performance and cost efficiency.Â
- AWS Coplit is the CLI tool, running apps on AppRunner, ECS and Fargate; with CodePipeline for deployment <— Deprecated in Feb 2025.
- Load Balancer Integrations
- 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)
- IAM roles for ECS
- EC2 Instance Profile (EC2 Launch Type only):
- Used by the ECS agent
- Makes 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
- ECS Task Role:
- Allows each task to have a specific role
- Use different roles for the different ECS Services you run
- Task Role is defined in the task definition
- EC2 Instance Profile (EC2 Launch Type only):
- Logging with “awslogs” driver
- Containers can send application logs directly to CloudWatch Logs
- You need to turn on awslogs log driver (for CW Logs)
- Configure logConfiguration parameters in your Task Definition
- Fargate Launch Type
- Task Execution Role must have the required permissions
- Supports awslogs, splunk, awsfirelens log drivers
- EC2 Launch Type
- Prevents logs from taking up disk space on your container EC2 instances
- Uses CloudWatch Unified Agent & ECS Container Agent
- Enable logging using ECS_AVAILABLE_LOGGING_DRIVERS in /etc/ecs/ecs.config
- Container EC2 instances must have permissions
- Logging with Sidecar Container
- Using a sidecar container which is responsible for collecting logs from all other containers and files on the file system and send the logs to a log storage (e.g., CloudWatch Logs)
| awslog | splunk | awsfirelens | |
|---|---|---|---|
| Purpose | This is the default and simplest driver, designed to send container logs directly to Amazon CloudWatch Logs. | This driver is specifically designed to send container logs to a Splunk instance. | This driver acts as a log router, leveraging Fluentd or Fluent Bit as a sidecar container to provide highly customizable log routing and processing. |
| Configuration | Requires minimal configuration, primarily specifying the CloudWatch log group. | Requires specifying the Splunk endpoint and potentially other Splunk-specific configurations. | More complex setup involving a sidecar container and detailed Fluentd/Fluent Bit configurations to define log destinations (e.g., CloudWatch, Splunk, S3, Elasticsearch, Kinesis), filtering, and enrichment. |
| Use Case | Ideal for basic logging needs where CloudWatch Logs is the sole or primary log destination. | Suitable for organizations already utilizing Splunk as their central log management and analysis platform. | Best for advanced logging scenarios requiring routing to multiple destinations, complex log transformations, or integration with diverse logging tools beyond CloudWatch or Splunk directly. It offers flexibility to send logs to Splunk, CloudWatch, or other custom destinations based on the Fluent Bit/Fluentd configuration. |
Amazon Elastic Container Registry (ECR)
- Store and manage Docker images on AWS
- Private and Public repository (Amazon ECR Public Gallery https://gallery.ecr.aws)
- Fully integrated with ECS, backed by Amazon S3
- Access is controlled through IAM (permission errors => policy)
- Supports image vulnerability scanning, versioning, image tags, image lifecycle…
- Lifecycle Policies
- Automatically remove old or unused images based on age or count
- Each Lifecycle Policy contains one or more rules
- All rules are evaluated at the same time, then applied based on priority
- Images are expired within 24 hours after they meet the criteria
- Helps you reduce unnecessary storage costs
Amazon Elastic Kubernetes Service (EKS)
- EC2 Launch for deploy worker node; Fargate for serverless
- Kubernetes is cloud-agnostic (can be used in any cloud – Azure, GCP…)
- Kubernetes is an open-source system for automatic deployment, scaling and management of containerized (usually Docker) application
- For multiple regions, deploy one EKS cluster per region
- Collect logs and metrics using CloudWatch Container Insights
- Node Types
- Managed Node Groups
- AWS handles EC2 instances with ASG managed by EKS
- On-Demand or Spot instances
- Self-Managed Nodes
- Self create and manage EC2 instance with self-define ASG
- On-Demand or Spot instances
- can use prebuilt AMI – Amazon EKS Optimized AMI
- AWS Fargate
- Managed Node Groups
- Data Volumes
- Can specify StorageClass manifest on EKS cluster, leverage a Container Storage Interface (CSI) compliant driver
- Amazon EBS (EC2)
- Amazon EFS (EC2, Fargate)
- Amazon FSx for Lustre (EC2)
- Amazon FSx for NetApp ONTAP (EC2)
- Can specify StorageClass manifest on EKS cluster, leverage a Container Storage Interface (CSI) compliant driver
- Control Plane Logging
- Send EKS Control Plane audit and diagnostic logs to CloudWatch Logs
- EKS Control Plane Log Types
- API Server (api)
- Audit (audit)
- Authenticator (authenticator)
- Controller Manager (controllerManager)
- Scheduler (scheduler)
- Ability to select the exact log types to send to CloudWatch Logs
- Nodes & Containers Logging
- You can capture node, pod, and containers logs and send them to CloudWatch Logs
- Use CloudWatch Agent to send metrics to CloudWatch
- Use the Fluent Bit, or Fluentd log drivers to send logs to CloudWatch Logs
- Container logs are stored on a Node directory /var/log/containers
- Use CloudWatch Container Insights to get a dashboarding monitoring solution for nodes, pods, tasks, and services