USD ($)
$
United States Dollar
Euro Member Countries
India Rupee
د.إ
United Arab Emirates dirham
ر.س
Saudi Arabia Riyal

Deploying Containers with Amazon ECS

Lesson 23/50 | Study Time: 40 Min

You have built a Docker image and stored it in ECR. Now you need to run it at scale, reliably, automatically, and with the ability to handle traffic spikes without manual intervention.

Amazon Elastic Container Service (ECS) is AWS's fully managed container orchestration service that does exactly this. It runs your containers, manages their health, scales them up and down, and restarts them if they fail.

What is Amazon ECS?

ECS is a service that runs and manages Docker containers on AWS. You tell ECS what container to run, how much CPU and memory it needs, how many copies to keep running, and ECS handles the rest — scheduling, placement, health monitoring, and scaling.

ECS removes the operational burden of managing container infrastructure yourself. You focus on your application. ECS keeps it running.

Core ECS Concepts


1. Cluster: A cluster is the logical boundary for your ECS resources — a group of infrastructure where your containers run. Every ECS deployment belongs to a cluster. You can have separate clusters for dev, staging, and production.


2. Task Definition

A task definition is a blueprint for your container. It defines:


1. Which Docker image to use — pulled from ECR.

2. How much CPU and memory the container gets.

3. Environment variables and secrets.

4. Port mappings — which container port maps to which host port.

5. Logging configuration — typically CloudWatch Logs.


Think of a task definition as the specification for how your container should run.


3. Task: A task is a running instance of a task definition — the actual container in execution. A task can contain one or more tightly coupled containers that run together.


4. Service: A service ensures that a specified number of tasks are always running. If a task fails or crashes, the service automatically starts a replacement. Services also integrate with load balancers to distribute traffic across multiple running tasks.

The Two Launch Types

This is the most important choice you make when setting up ECS — where do your containers actually run?


1. Fargate — Serverless Containers

With Fargate, you do not manage any servers at all. You define the task — the container, CPU, memory — and AWS provisions the underlying infrastructure automatically.

There are no EC2 instances to launch, patch, or scale. AWS handles everything below the container level.


You pay per task — based on the CPU and memory your task uses, for the time it runs. When the task stops, you stop paying.


Best for:


1. Teams that want to focus purely on applications, not infrastructure.

2. Variable or unpredictable workloads where you do not want to manage server capacity.

3. Microservices and API workloads.

2. EC2 Launch Type — Self-Managed Infrastructure

With the EC2 launch type, you provision and manage a pool of EC2 instances that form the cluster. ECS schedules containers onto these instances. You have full control over the instance types, the operating system, and the underlying infrastructure.


You pay for the EC2 instances — whether they are fully utilised or not.


Best for:


1. Workloads that require specific instance types — GPU workloads, memory-optimised workloads.

2. Teams that need maximum control over the underlying infrastructure.

3. Cost-sensitive workloads with predictable, sustained traffic where Reserved Instances offer significant savings.


Note: For most teams starting with ECS, Fargate is the recommended choice. It removes operational complexity and lets you focus on the application.

ECS Auto Scaling

ECS services can scale automatically based on demand. There are two dimensions of scaling:


With Fargate, cluster scaling is not a concern — AWS handles infrastructure capacity automatically.

ECS and Load Balancing

In production, you rarely expose a single container directly to the internet. ECS integrates with the Application Load Balancer (ALB) to distribute incoming traffic across all running tasks in a service.

When a new task starts, ECS automatically registers it with the load balancer. When a task stops, ECS deregisters it. Users always hit a healthy task — they never see individual containers starting or stopping.

ECS Logging

Every container running on ECS can send its logs to Amazon CloudWatch Logs automatically. You configure the log driver in the task definition — typically awslogs — and specify the CloudWatch log group.

From there, you can search logs, set up alarms, and diagnose issues without ever SSH-ing into a server.



Drew Collins

Drew Collins

Product Designer
Profile

Class Sessions

1- What is DevOps? Principles, Culture, and Practices 2- The DevOps Lifecycle 3- Introduction to Cloud Computing 4- AWS Global Infrastructure 5- Core AWS Services Overview 6- Git Fundamentals 7- Branching Strategies 8- Pull Requests and Code Review Best Practices 9- Integrating Git with AWS CodeCommit and GitHub 10- Managing Secrets and Sensitive Files in Repositories 11- What is CI/CD? 12- Building Pipelines with AWS CodePipeline and CodeBuild 13- Automated Testing in CI 14- Deployment Strategies 15- Using GitHub Actions and Jenkins on AWS 16- Why Infrastructure as Code (IaC)? 17- AWS CloudFormation 18- Terraform on AWS 19- AWS Cloud Development Kit (CDK) 20- IaC Best Practices 21- Docker Fundamentals 22- Amazon ECR 23- Deploying Containers with Amazon ECS 24- Kubernetes Basics and Amazon EKS 25- Integrating Containers into CI/CD Pipelines 26- Serverless Computing Concepts and Use Cases 27- Building and Deploying AWS Lambda Functions 28- Event-Driven Automation with Amazon EventBridge 29- Orchestrating Workflows with AWS Step Functions 30- API Gateway Integration for Serverless APIs 31- Introduction to MLOps 32- Training and Deploying Models with Amazon SageMaker 33- Automating ML Pipelines with SageMaker Pipelines 34- Using Amazon CodeWhisperer and AI Tools for Code Automation 35- AI-Powered Testing, Anomaly Detection, and Incident Prediction 36- Observability Fundamentals 37- Amazon CloudWatch 38- Distributed Tracing with AWS X-Ray 39- Centralised Logging with Amazon OpenSearch Service 40- Setting Up Automated Alerts and Incident Response Workflows 41- Shift-Left Security 42- IAM Roles, Policies, and Least-Privilege Access 43- Static Code Analysis and Vulnerability Scanning in CI/CD 44- AWS Security Hub, GuardDuty, and Config for Compliance 45- Secrets Management with AWS Secrets Manager and Parameter Store 46- AWS Well-Architected Framework 47- Auto Scaling and Elastic Load Balancing for Resilience 48- Cost Monitoring with AWS Cost Explorer and Budgets 49- Disaster Recovery Strategies 50- Preparing Your Project for Production