What Really Happens When You Open a Website Behind an AWS Load Balancer?
Follow a web request through an AWS Application Load Balancer, from the browser to EC2. Learn how listeners, target groups, health checks, and security groups work together—and how to troubleshoot when something breaks.
What Really Happens When You Open a Website Behind an AWS Load Balancer?
When you open a website, it feels simple.
You enter a URL, press Enter, and a few moments later you see a webpage.
But when that website is running on AWS behind a load balancer, several components work together before the first HTML response reaches your browser.
A simple architecture might look like this:
User → Application Load Balancer → Target Group → EC2 → Web Server
Understanding this flow helped me see AWS infrastructure differently. Instead of thinking about EC2, Security Groups, Load Balancers, and Target Groups as separate AWS services, I started understanding how they work together to deliver a request.
This article walks through that journey from the user's request to the response.
The Architecture
For this example, imagine a simple website running on two Amazon EC2 instances.
Each instance runs a web server and serves the same application.
An Application Load Balancer sits in front of them:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
┌─────────────┐
│ User │
└──────┬──────┘
│
▼
┌──────────────────┐
│ Application Load │
│ Balancer │
└────────┬─────────┘
│
┌──────┴──────┐
│ Target Group│
└──────┬──────┘
│
┌────────┴────────┐
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ EC2 1 │ │ EC2 2 │
│ Web Server│ │ Web Server│
└──────────┘ └──────────┘The important part is that the user does not need to know which EC2 instance will process the request.
The load balancer provides the entry point and routes traffic to registered targets.
1. The User Sends a Request
Everything starts when the user opens the website.
For example:
1
http://my-application.example.comThe browser needs to reach the application's endpoint.
At a high level, the request eventually reaches the public endpoint of the Application Load Balancer.
The important idea is that the user is communicating with the load balancer, not directly with the individual EC2 instances.
This creates an abstraction between the client and the application servers.
2. The Load Balancer Receives the Request
The Application Load Balancer operates at the application layer.
When it receives a request, it evaluates its listener configuration and determines what action should be performed.
A listener defines how the load balancer receives traffic.
For example:
1
2
HTTP : 80
HTTPS : 443A listener can then forward requests to a target group.
Conceptually:
1
2
3
4
5
6
7
Request
↓
Listener
↓
Listener Rule
↓
Target GroupThis separation is important.
The load balancer does not simply "send traffic to an EC2 instance."
It uses listeners and rules to determine where that traffic should go.
3. What Is a Target Group?
This was one of the concepts that helped me understand load balancing more clearly.
A target group is essentially the collection of targets that can receive traffic for a particular routing configuration.
For an EC2-based application, the targets can be EC2 instances.
For example:
1
2
3
4
5
Target Group
│
├── EC2 Instance 1
│
└── EC2 Instance 2The load balancer uses the target group to determine which registered targets are available to receive requests.
AWS also allows different target types, including instances, IP addresses, and Lambda functions, depending on the architecture.
4. But How Does AWS Know If an EC2 Instance Is Working?
This is where health checks become important.
Imagine that EC2 Instance 1 is running, but the web server has stopped.
From the perspective of EC2, the instance might still be "running."
But that does not necessarily mean that the application is healthy.
The Application Load Balancer can perform health checks against registered targets.
For example:
1
2
3
4
5
ALB
│
├── Health Check → EC2 #1 → Healthy
│
└── Health Check → EC2 #2 → UnhealthyIf a target fails its health checks, the load balancer can stop routing normal requests to that unhealthy target.
This is an important distinction:
EC2 running ≠ application healthy
The instance can be operational while the application running on it is not responding correctly.
5. Security Groups Are Part of the Path
Another important lesson is that the load balancer and EC2 instances need to be able to communicate.
A common architecture uses separate security groups:
1
2
3
4
5
Internet
↓
ALB Security Group
↓
EC2 Security GroupThe load balancer's security group can allow inbound traffic from the internet on the required listener port.
The EC2 security group can then allow traffic from the load balancer's security group on the application's listening port.
For example:
1
2
3
4
5
ALB Security Group
Inbound:
HTTP 80
Source: 0.0.0.0/0Then:
1
2
3
4
5
EC2 Security Group
Inbound:
HTTP 80
Source: ALB Security GroupThe important idea is that the EC2 instance does not necessarily need to accept application traffic directly from the entire internet.
Instead, it can restrict application traffic to the load balancer.
This creates a much clearer security boundary.
6. The Request Reaches the EC2 Instance
Once the load balancer selects a healthy target, the request is forwarded to the EC2 instance.
Now we are inside the server.
For example:
1
2
3
4
5
6
7
ALB
↓
EC2
↓
Web Server
↓
ApplicationThe web server could be Apache, Nginx, or another application server.
At this point, the request is no longer primarily an AWS load-balancing problem.
It becomes a Linux and application problem.
The server needs to have:
- the web server installed
- the application running
- the expected port open
- the correct files deployed
- the correct permissions
- the expected response available
This is where cloud infrastructure and Linux administration start to overlap.
7. Where Does User Data Fit?
When launching an EC2 instance, user data can be used to perform startup configuration.
For example, a simple script could install a web server and create an initial webpage.
Conceptually:
1
2
3
4
5
# Install web server
# Start web server
# Create website filesThis is useful because the server can configure itself when it launches instead of requiring every step to be performed manually.
For a learning environment, this is a useful first step toward automation.
Instead of:
1
2
3
4
5
6
7
8
9
Launch EC2
↓
SSH
↓
Install software
↓
Configure server
↓
Create websiteyou can move toward:
1
2
3
4
5
Launch EC2
↓
User Data
↓
Configured Web ServerThat small change introduces an important cloud engineering idea:
Infrastructure should become increasingly reproducible.
8. The Response Travels Back
After the web server processes the request, it returns a response.
The simplified flow becomes:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Browser
↓
Application Load Balancer
↓
Target Group
↓
Healthy EC2
↓
Web Server
↓
Application
↑
Response
↑
Application Load Balancer
↑
BrowserThe user only sees the final webpage.
But several AWS and Linux components were involved in producing it.
9. What Happens When One EC2 Instance Fails?
This is where the architecture becomes more interesting.
Imagine:
1
2
3
4
Target Group
EC2 #1 → Healthy
EC2 #2 → HealthyTraffic can be distributed between them according to the load balancer's routing behavior.
Now suppose EC2 #2 stops responding correctly.
The health check can detect the problem:
1
2
EC2 #1 → Healthy
EC2 #2 → UnhealthyThe load balancer can then route requests to the healthy target instead.
The important point is that the load balancer is not simply distributing requests blindly.
Health checks influence which targets are considered available for traffic.
This is one of the reasons why health checks are such an important part of load-balanced architectures.
10. When the Website Does Not Work
This architecture also gives us a useful troubleshooting method.
If the website is unavailable, don't immediately assume that the load balancer is broken.
Break the request path into layers.
Layer 1 — DNS / Endpoint
Can the client resolve and reach the load balancer endpoint?
Layer 2 — Load Balancer
Is the listener configured correctly?
Layer 3 — Target Group
Are the EC2 instances registered?
Layer 4 — Health Checks
Are the targets healthy?
Layer 5 — Security Groups
Can the load balancer communicate with the EC2 instances?
Layer 6 — EC2
Is the instance running?
Layer 7 — Web Server
Is Apache, Nginx, or the application actually running?
Layer 8 — Application
Is the application returning the expected response?
This way of thinking is more useful than simply memorizing AWS console settings.
You are following the request through the system.
11. A Small but Important Security Lesson
One of the easiest mistakes when learning AWS is to make everything accessible just to make the application work.
For example:
1
2
3
EC2
Inbound HTTP
Source: 0.0.0.0/0This may make troubleshooting easier, but it does not necessarily represent the desired architecture.
A more controlled design is:
1
2
3
4
5
Internet
↓
ALB
↓
EC2with the EC2 security group allowing application traffic from the load balancer rather than from arbitrary internet clients.
The goal is not simply:
"Make it work."
The goal is:
"Make it work while keeping the communication paths intentional."
12. What This Taught Me About AWS
When I first started learning AWS, it was easy to think about services individually:
- EC2 = virtual server
- ALB = load balancer
- Security Group = firewall
- Target Group = collection of servers
Those definitions are useful, but they don't explain how an application actually works.
The more useful mental model is:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
USER
│
▼
Application Load Balancer
│
Listener
│
▼
Target Group
/ \
/ \
▼ ▼
EC2 #1 EC2 #2
│ │
Web Server Web Server
│ │
└──────┬──────┘
│
ApplicationEach component has a responsibility.
The load balancer receives and routes traffic.
The target group identifies possible destinations.
Health checks determine which targets are healthy.
Security groups control which network traffic is allowed.
EC2 provides the compute environment.
The web server and application process the request.
Understanding those relationships is much more valuable than memorizing what each AWS service does in isolation.
Final Thoughts
A load-balanced website may look simple from the outside:
Open URL → See webpage
But behind that action is a chain of infrastructure decisions:
Request → Load Balancer → Listener → Target Group → Health Check → EC2 → Web Server → Response
For me, this is one of the most useful ways to learn cloud infrastructure.
Instead of asking only:
"What does this AWS service do?"
start asking:
"Where does it fit in the request, and what happens if it fails?"
That question changes the way you approach AWS architecture.
It also provides a natural path from learning individual services to understanding how real cloud systems work.
Keep building. Keep breaking things. Then follow the request until you find out why.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article