Chapter 18: Load Balancing

18.1 How a load balancer actually works

By Ravindra Bagale · Last updated: 3 October 2026

Why one name is not one computer

In Chapter 17, two t3.micro instances shared the work. A visitor cannot be expected to know both public IP addresses, or to guess which one is up. If you publish only instance A's address, instance B sits idle. If you publish both and A dies, half the people still try A. The missing piece is a single front door that knows which computers are healthy.

What it does with one request

A load balancer is an AWS service in front of your instances. It has a DNS name. The user does not connect to EC2 first. The path of one request is always the same shape.

1. The user asks DNS for example.com.
2. DNS returns the load balancer's address.
3. The user sends the HTTP request to the load balancer.
4. The load balancer looks at its healthy targets.
5. It picks one healthy EC2 instance.
6. It sends that request to the instance.
7. The instance answers, often through Nginx or Apache.
8. The load balancer returns that response to the user.

The user still sees example.com. The user does not see which instance was picked.

How to watch that path on paper, then in the lab

Do this on paper before you create anything. You will repeat it with real instances in the later sections.

1. Draw a box named example.com.
2. Draw a box under it named load balancer.
3. Draw two boxes under that, named EC2 A and EC2 B.
4. Write "healthy" next to both EC2 boxes.
5. Draw an arrow from the user to example.com.
6. Draw an arrow from example.com to the load balancer.
7. Draw an arrow from the load balancer to EC2 A only.
8. Write "response" on an arrow back from EC2 A to the user.
9. Cross out EC2 A and write "stopped".
10. Draw the next arrow from the load balancer to EC2 B only.
11. You should see that the user never chooses the EC2. The balancer chooses, and it skips the stopped one.