AWS Builder Center

Builder Center

Amazon ECS: From Basics to Production-Ready Container Deployments

Learn Amazon ECS from the fundamentals to advanced concepts, including task definitions, services, networking, load balancing, Fargate, EC2 launch types, autoscaling, IAM, and real-world deployment scenarios.

Amazon ECS: From Basics to Production-Ready Container Deployments

Amazon Elastic Container Service (Amazon ECS) is a fully managed container orchestration service provided by AWS. It allows us to run, manage, and scale Docker containers without managing the underlying container orchestration infrastructure ourselves.
This article explains Amazon ECS from the fundamentals to production-oriented concepts such as Fargate, EC2, networking, load balancing, ECR, IAM, secrets, monitoring, auto scaling, and CI/CD.

1. What is Amazon ECS?

Amazon ECS is a container orchestration service used to run Docker containers on AWS.
Instead of manually managing individual Docker containers, ECS lets us define:
  • Which container image should run
  • How much CPU and memory the container needs
  • Which ports should be exposed
  • How many copies of the application should run
  • How containers should communicate
  • How the application should scale
A simplified architecture looks like:
1
2
3
4
5
6
7
8
9
10
11
12
13
User
|
v
Application Load Balancer
|
v
ECS Service
|
v
ECS Tasks
|
v
Docker Containers

2. Important ECS Components

ECS Cluster

An ECS cluster is a logical grouping of resources where our containers run.
For example:
1
2
3
4
Production Cluster
├── Backend Service
├── Frontend Service
└── Worker Service

Task Definition

A task definition is a blueprint that describes how a container should run.
It can define:
  • Docker image
  • CPU
  • Memory
  • Port mappings
  • Environment variables
  • IAM roles
  • Logging
  • Storage
  • Health checks
Example:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"family": "backend",
"cpu": "512",
"memory": "1024",
"containerDefinitions": [
{
"name": "backend",
"image": "myrepo/backend:1.0",
"portMappings": [
{
"containerPort": 8080
}
]
}
]
}

Task

A task is a running instance of a task definition.
If we run three tasks, ECS starts three instances of our container:
1
2
3
4
5
Task Definition
|
+---- Task 1
+---- Task 2
+---- Task 3

Service

An ECS service maintains the desired number of running tasks.
For example, if the desired count is three:
1
2
3
4
ECS Service
├── Task 1
├── Task 2
└── Task 3
If Task 1 fails, ECS can start another task to maintain the desired count.
1
2
3
4
5
Task 1 ❌

Task 2 ✅
Task 3 ✅
Task 4 → Started by ECS
This helps maintain application availability.

3. ECS Launch Options

ECS can run containers using different compute options. The two commonly used approaches are ECS on EC2 and ECS with Fargate.

ECS on EC2

With the EC2 launch type, we manage the underlying EC2 instances.
1
2
3
4
5
ECS
|
EC2 Instances
|
Docker Containers
We are responsible for:
  • EC2 instance types
  • Operating system
  • Capacity
  • Instance scaling
  • Patching
  • Instance-level configuration
This provides more control but also introduces more operational work.

ECS Fargate

AWS Fargate provides serverless compute for containers.
1
2
3
4
5
ECS
|
Fargate
|
Containers
We don't need to manage EC2 servers. Instead, we specify resources such as:
  • CPU
  • Memory
  • Container image
  • Networking
  • IAM permissions
AWS manages the underlying infrastructure.
Fargate is a good choice when we want to focus on deploying applications rather than managing servers.

4. ECS Networking

ECS tasks commonly use the awsvpc network mode. Each task receives its own network interface and private IP address.
A typical production architecture is:
1
2
3
4
5
6
7
8
9
10
Internet
|
v
Application Load Balancer
|
v
Private Subnets
|
v
ECS Tasks
The Application Load Balancer can be placed in public subnets while ECS tasks run in private subnets.
This means users do not need direct network access to the containers.

Security Groups

Security groups can control which traffic is allowed.
For example:
1
2
3
4
5
6
7
8
9
10
Internet
|
v
ALB Security Group
|
v
ECS Security Group
|
v
Database Security Group
The ECS security group can allow traffic only from the ALB security group instead of allowing traffic from the entire internet.

5. ECS with Application Load Balancer

For a web application, clients normally should not connect directly to individual ECS tasks.
Instead, an Application Load Balancer distributes traffic:
1
2
3
4
5
6
7
8
9
10
Client
|
v
Application Load Balancer
|
+---- ECS Task 1
|
+---- ECS Task 2
|
+---- ECS Task 3
The ALB performs health checks and routes traffic to healthy targets.
If a task becomes unhealthy, the load balancer can stop sending traffic to that task.

6. Amazon ECR

Amazon Elastic Container Registry (ECR) is used to store Docker container images.
A typical deployment pipeline looks like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Developer
|
v
GitHub
|
v
GitHub Actions
|
v
Docker Build
|
v
Amazon ECR
|
v
Amazon ECS
Example commands:
1
2
3
4
5
6
7
docker build -t my-backend .

docker tag my-backend:latest \
123456789012.dkr.ecr.ap-south-1.amazonaws.com/my-backend:latest

docker push \
123456789012.dkr.ecr.ap-south-1.amazonaws.com/my-backend:latest
ECS can then pull the image from ECR when starting a task.

7. IAM and ECS

IAM controls which AWS resources ECS tasks and users can access.
For example, suppose a Spring Boot application running inside ECS needs to read objects from Amazon S3.
Instead of storing AWS access keys inside the container, we can assign an IAM task role.
1
2
3
4
5
6
7
8
ECS Task
|
v
IAM Task Role
|
+---- S3
+---- DynamoDB
+---- Secrets Manager
This is safer than hardcoding long-term credentials.
The principle of least privilege should be followed so that a task receives only the permissions it actually needs.

8. Environment Variables and Secrets

Applications commonly require configuration such as:
1
2
3
4
DATABASE_URL
DATABASE_USERNAME
DATABASE_PASSWORD
JWT_SECRET
Sensitive information should not be hardcoded into Docker images or source code.
AWS Secrets Manager and Systems Manager Parameter Store can be used to manage configuration and secrets.
A simplified architecture is:
1
2
3
4
5
ECS Task
|
+---- Secrets Manager
|
+---- Database
This allows applications to retrieve sensitive configuration without placing secrets directly inside the application image.

9. ECS Auto Scaling

ECS services can automatically adjust the number of running tasks according to application demand.
For example, an application may normally run two tasks:
1
2
Task 1
Task 2
During high traffic, the service can scale out:
1
2
3
4
5
6
7
2 tasks
|
v
4 tasks
|
v
8 tasks
When demand decreases, it can scale back down.
Common scaling metrics include:
  • CPU utilization
  • Memory utilization
  • Application Load Balancer request count
  • Custom CloudWatch metrics
Auto Scaling helps maintain performance while avoiding unnecessary compute costs.

10. CloudWatch Monitoring and Logging

Amazon CloudWatch can be used to monitor ECS workloads.
Applications can send container logs to CloudWatch Logs.
A simplified flow is:
1
2
3
4
5
6
7
ECS Container
|
v
CloudWatch Logs
|
v
Monitoring / Troubleshooting
CloudWatch can also provide metrics and alarms for things such as:
  • CPU utilization
  • Memory utilization
  • Request counts
  • Error rates
  • Task counts
  • Application health
Logs are especially useful when diagnosing application crashes, failed deployments, or unexpected behavior.

11. Production Architecture

A typical production architecture might look like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Internet
|
v
Route 53
|
v
Application Load Balancer
|
+----------+----------+
| |
Private Subnet Private Subnet
| |
ECS Task 1 ECS Task 2
| |
+----------+----------+
|
Database
Additional AWS services can support the architecture:
  • Amazon ECR for container images
  • Amazon CloudWatch for monitoring and logs
  • AWS Secrets Manager for secrets
  • AWS IAM for permissions
  • Amazon Route 53 for DNS
  • Amazon VPC for networking
  • Application Load Balancer for traffic distribution

12. Real-World CI/CD Scenario

Consider a Spring Boot backend running on port 8080.
A CI/CD pipeline could look like:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Developer
|
v
GitHub
|
v
GitHub Actions
|
+---- Build Application
|
+---- Run Tests
|
+---- Build Docker Image
|
v
Amazon ECR
|
v
Amazon ECS
|
v
Application Load Balancer
|
v
Users
When a developer pushes new code:
  1. GitHub Actions starts.
  2. The application is built.
  3. Automated tests are executed.
  4. A Docker image is created.
  5. The image is pushed to ECR.
  6. ECS is updated with the new image.
  7. New tasks are started.
  8. Health checks are performed.
  9. Healthy tasks begin receiving traffic.
This creates a repeatable deployment process.

13. ECS Deployment Strategies

ECS deployments can be designed to reduce application downtime.
A common approach is a rolling deployment.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
Old Version
Task 1
Task 2
Task 3

|
v

New Version
Task 1
Task 2
Task 3
ECS gradually replaces old tasks with new ones while maintaining the desired service capacity.
For more advanced deployment workflows, blue/green deployments can be used.
1
2
3
4
5
Load Balancer
|
+---- Blue Environment
|
+---- Green Environment
Traffic can be shifted to the new version after validation.

14. ECS vs EC2 vs Fargate

FeatureEC2ECS on EC2ECS Fargate
Server managementRequiredRequiredNo
Container orchestrationManualECSECS
Infrastructure controlHighHighLower
Operational overheadHighMediumLow
Container scalingManual/Auto ScalingEC2 + ECS scalingECS Service Auto Scaling
Fargate is often a convenient choice when the goal is to run containers without managing servers.
ECS on EC2 can be useful when we need more control over the underlying infrastructure or want to optimize workloads for specific instance types.

15. ECS vs Kubernetes

ECS and Kubernetes are both container orchestration solutions, but they have different operational models.

Amazon ECS

  • AWS-native
  • Simple integration with AWS services
  • Less infrastructure management
  • Good choice for AWS-focused applications

Kubernetes

  • Open-source
  • Highly extensible
  • Large ecosystem
  • Can run across different cloud providers and on-premises environments
  • Requires more Kubernetes-specific knowledge and management
For an AWS-focused project, ECS can be a simpler starting point for learning container orchestration.

16. Important ECS Concepts to Remember

A simple way to remember the core ECS hierarchy is:
1
2
3
4
5
6
7
Cluster
|
Service
|
Task
|
Container
The supporting services can be remembered as:
1
2
3
4
5
6
7
8
9
ECR → Stores container images
ECS → Runs and manages containers
Fargate → Serverless compute for containers
ALB → Distributes application traffic
IAM → Controls permissions
CloudWatch → Monitoring and logs
Secrets Manager → Stores sensitive configuration
Route 53 → DNS
VPC → Networking

17. Practical Learning Path

If you are learning ECS as a DevOps engineer, a practical sequence is:
  1. Learn Docker fundamentals.
  2. Build and run a Docker container locally.
  3. Create an ECR repository.
  4. Push a Docker image to ECR.
  5. Create an ECS cluster.
  6. Create a task definition.
  7. Run a task using Fargate.
  8. Create an ECS service.
  9. Configure VPC and security groups.
  10. Add an Application Load Balancer.
  11. Configure CloudWatch logging.
  12. Add IAM task roles.
  13. Store secrets using Secrets Manager.
  14. Configure ECS Service Auto Scaling.
  15. Create a CI/CD pipeline using GitHub Actions.
  16. Implement rolling or blue/green deployments.

Conclusion

Amazon ECS provides a practical way to run Docker containers on AWS, from simple development workloads to production applications.
The key concepts to understand are:
  • ECS clusters
  • Task definitions
  • Tasks
  • Services
  • EC2 launch type
  • Fargate
  • VPC networking
  • Security groups
  • Application Load Balancers
  • Amazon ECR
  • IAM roles
  • Secrets Manager
  • CloudWatch
  • Auto Scaling
  • CI/CD
Once these concepts are understood and practiced together, ECS becomes a powerful tool for deploying containerized applications in real-world DevOps environments.
# amazon-ecs
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article