A Beginner’s Guide to Running a Web App on ECS: How ECR, Task Definitions, and ALB Work Together

When you start learning Amazon ECS, you encounter many AWS services and settings:

• ECS clusters
• ECR
• Task definitions
• ECS services
• VPCs
• Security groups
• ALB

You may understand each one separately but still wonder:

“What do I actually need to run a new web app on ECS?”

If someone asks you to run an app on ECS, you can start by thinking through this setup:

Prepare a Docker image in ECR
        ↓
Create a task definition
        ↓
Create an ECS service
        ↓
Configure the VPC, subnets, and security groups
        ↓
Make the app accessible through an ALB
        ↓
Set up logs and monitoring

This article explains the basic setup for running a web application on ECS.

Understand the Overall ECS Architecture

A typical setup for a web application accessible from the internet looks like this:

                    Internet
                       ↓
                      ALB
                       ↓
              ┌────── VPC ──────┐
              │                  │
              │   ECS Service    │
              │       ↓          │
              │     Task         │
              │       ↓          │
              │   Container      │
              │                  │
              └──────────────────┘
                       ↑
                      ECR

Container
   ↓
CloudWatch Logs

Here is what each part does:

Component	Role
ECR	Stores Docker images
Task definition	Defines how containers run
ECS task	Runs the containers
ECS service	Maintains the desired number of tasks
VPC / subnet	Provides the network where tasks run
Security group	Controls network traffic
ALB	Routes user requests to ECS tasks
CloudWatch Logs	Stores application logs for viewing and troubleshooting

Understanding these relationships makes the overall ECS setup easier to follow.

Prepare a Docker Image in ECR

To run an application on ECS, you first need a container image.

For example, if your application is written in:

Node.js
Python
PHP
Java

you can create a Dockerfile and build a Docker image.

Application
     ↓
Dockerfile
     ↓
Docker image

Amazon ECR (Elastic Container Registry) is an AWS service for storing that image.

Source code
     ↓
docker build
     ↓
Docker image
     ↓
    ECR

In simple terms, ECR is:

A place to store the Docker images used by ECS

When a task starts, it pulls its image from ECR or another container registry.

Create a Task Definition

After preparing the Docker image, create a task definition.

A task definition is a blueprint that tells ECS how to run your containers.

For example, it specifies:

• Which Docker image should ECS use?
• How much CPU does the task need?
• How much memory does it need?
• Which port does the container use?
• Which environment variables does it need?
• Where should its logs go?

A simplified example looks like this:

Task Definition

Image
→ Docker image in ECR

CPU
→ 1024

Memory
→ 2048

Port
→ 8080

Logs
→ CloudWatch Logs

An ECS task is a running instance created from a task definition.

Task definition
       ↓
“Start with these settings”
       ↓
ECS task
       ↓
Container

You can think of the task definition as the blueprint and the task as something running from that blueprint.

Create an ECS Service

An ECS service is useful when you want tasks to keep running.

Suppose you always want two tasks running:

Keep two tasks running

Set the service’s desired count to 2:

ECS Service

Desired Count = 2

      ↓

┌────────┐
│ Task 1 │
└────────┘

┌────────┐
│ Task 2 │
└────────┘

If Task 1 stops unexpectedly, the service starts a replacement to maintain the desired count.

Task 1
  ↓
Stops

ECS Service
  ↓
Starts a new task

That is why ECS services are commonly used for web applications that need to keep running.

What Is an ECS Cluster?

You will also come across the term cluster.

An ECS cluster is a logical group for ECS services and tasks.

ECS Cluster
     │
     ├── ECS Service A
     │       ├── Task
     │       └── Task
     │
     └── ECS Service B
             ├── Task
             └── Task

You can manage multiple services and tasks within the same cluster.

Fargate Lets You Run Tasks Without Managing EC2 Instances

Two common ways to run ECS tasks are:

• ECS on EC2
• AWS Fargate

With ECS on EC2, your tasks run on EC2 instances that you manage.

ECS + EC2

ECS
 ↓
EC2
 ↓
Task
 ↓
Container

With Fargate, AWS manages the underlying compute infrastructure, so you do not need to manage the EC2 instances yourself.

ECS + Fargate

ECS
 ↓
Fargate
 ↓
Task
 ↓
Container

For a new web application, ECS with Fargate is often a reasonable option to consider unless you have specific requirements for running on EC2.

Configure the VPC, Subnets, and Security Groups

You also need to plan the network where your ECS tasks will run.

For example, Fargate tasks run in subnets within a VPC.

VPC
 ↓
Subnet
 ↓
ECS task

A common web application setup places an internet-facing ALB in public subnets and ECS tasks in private subnets.

Internet
   ↓
ALB in public subnets
   ↓
ECS tasks in private subnets

Users access the application through the ALB, while the tasks remain in private subnets.

Configure Security Groups

Security groups control which network traffic is allowed.

For example, suppose users connect to the ALB over port 443, and the ALB sends requests to tasks over port 8080.

Internet
   ↓
Port 443
   ↓
ALB
   ↓
Port 8080
   ↓
ECS task

The ALB’s security group can allow inbound traffic on port 443 from the internet.

Internet
   ↓
Allow port 443
   ↓
ALB

The tasks’ security group can allow inbound traffic on port 8080 from the ALB’s security group.

ALB security group
        ↓
Allow port 8080
        ↓
ECS task

This lets the ALB reach the tasks without allowing the entire internet to connect directly to the tasks’ application port.

Configure an ALB

An Application Load Balancer (ALB) is commonly used to make a web application accessible from outside the VPC.

User
 ↓
ALB
 ↓
ECS task

The ALB receives user requests and forwards them to the ECS tasks.

If multiple tasks are running, the ALB can distribute requests among them.

             ALB
              ↓
        ┌─────┴─────┐
        ↓           ↓
      Task 1      Task 2

How Target Groups Fit In

A target group connects ALB routing to the tasks that receive requests.

Internet
   ↓
ALB
   ↓
Target group
   ↓
ECS task

An ALB listener rule forwards requests to a target group. The ECS tasks are registered as targets in that group.

When you connect an ECS service to an ALB, ECS registers and deregisters tasks as they start and stop.

Health Checks Matter Too

A target group can check whether an ECS task is responding properly.

For example, it might request:

/health

and expect:

HTTP 200

The check looks like this:

ALB target group
       ↓
GET /health
       ↓
ECS task
       ↓
200 OK
       ↓
Healthy

Health checks help the ALB avoid routing user requests to tasks that are not responding as expected.

Set Up Logs and Monitoring

Even if the application starts successfully, troubleshooting is difficult if you cannot see its logs.

ECS can send container logs to Amazon CloudWatch Logs.

ECS task
   ↓
Container
   ↓
Application logs
   ↓
CloudWatch Logs

Those logs can help you inspect:

• Application errors
• HTTP requests
• Startup errors
• Exceptions

A common setup uses the awslogs log driver in the task definition.

Monitor with CloudWatch

Logs are only one part of monitoring. You should also consider metrics and alarms, such as:

• CPU utilization
• Memory utilization
• Running task count
• ALB 5xx errors
• Healthy and unhealthy target counts

ECS / ALB
    ↓
CloudWatch
    ↓
Metrics / Logs
    ↓
Alarms

The goal is to notice when the application has a problem, not just confirm that it started once.

You Can Also Configure Auto Scaling

If traffic varies, ECS Service Auto Scaling can adjust the number of running tasks.

For example:

Normal load

2 tasks

When load increases:

More traffic
     ↓
Higher CPU utilization
     ↓
Auto Scaling
     ↓
4 tasks

You can also configure scaling to reduce the task count when load falls.

What Should You Check When Asked to “Run This on ECS”?

When setting up a new web application on ECS, these questions help you understand what is needed:

Item	What to check
Docker	Can the application run in a container?
ECR	Where will the image be stored?
Task definition	What CPU, memory, port, and environment variables are needed?
ECS service	How many tasks should run, and how will deployments work?
Launch option	Will the tasks run on Fargate or EC2?
VPC	Which VPC will contain the tasks?
Subnets	Will the tasks use public or private subnets?
Security groups	Which traffic should be allowed between the ALB and tasks?
ALB	Does the application need external access?
Target group	Where should requests go, and how will health checks work?
CloudWatch Logs	Where will container logs be stored?
Monitoring	Which metrics and errors should trigger alerts?
Auto Scaling	Should the number of tasks change with load?

The Flow from Application to Running Tasks

Here is the overall setup flow:

Application
     ↓
Build a Docker image
     ↓
Push the image to ECR
     ↓
Task definition
・Image
・CPU
・Memory
・Port
・Environment
・Logs
     ↓
ECS service
・Desired count
・Fargate / EC2
     ↓
VPC / Subnets / Security groups
     ↓
ALB / Target group
     ↓
CloudWatch Logs / Monitoring
     ↓
Auto Scaling

From a user’s point of view, requests follow this route:

User
 ↓
Internet
 ↓
ALB
 ↓
Target group
 ↓
ECS task
 ↓
Container
 ↓
Application

The deployment flow is different:

Source code
     ↓
Docker build
     ↓
ECR
     ↓
Task definition
     ↓
ECS service
     ↓
ECS task

Keeping the request path and the deployment flow separate makes the architecture easier to understand.

Summary

Running a web application on ECS involves more than configuring ECS alone. You also need an image registry, networking, a way to route requests, and a way to observe the application.

A useful overview is:

ECR
 ↓
Task definition
 ↓
ECS service
 ↓
VPC / Security groups
 ↓
ALB
 ↓
Logs / Monitoring

Each component has a different job:

ECR
→ Stores Docker images

Task definition
→ Defines how containers run

ECS task
→ Runs the containers

ECS service
→ Maintains the desired number of tasks

VPC / Security groups
→ Provide networking and control traffic

ALB / Target group
→ Route user requests to ECS tasks

CloudWatch
→ Provides logs, metrics, and alarms

When someone asks you to run a new app on ECS, start by checking what you need for the image, task definition, service, network, ALB, and monitoring.