Chapter 18: Load Balancing

18.11 One app, multiple regions

By Ravindra Bagale · Last updated: 3 October 2026

Why one region is a single map

lab-alb can use two Availability Zones in Mumbai. Those zones are still one region. A user far from Mumbai pays a delay on every request. A problem that takes the whole region out takes the only front door with it. Flipkart, Amazon, Netflix, and Paytm are used from more than one place. The honest picture is multiple front doors, not a claim about which product they run. One Application Load Balancer cannot register an EC2 instance that lives in another region.

What is in each region

Each region has its own load balancer and its own EC2 instances. Mumbai has lab-alb and the Mumbai target group. A second region, in this lesson Singapore ap-southeast-1, would have its own balancer and its own instances. Nothing in the Mumbai target group is a Singapore instance.

Route 53 decides which region's balancer the user is sent to. Two policies are enough for this chapter.

The query's source is the DNS resolver, not a precise pin on the user's phone. After that answer, the user talks only to the chosen balancer. That balancer then distributes across EC2 instances in its own region, using the rules and the algorithm from section 18.6. It does not distribute across regions.

How to see that one balancer is only Mumbai

1. Open lab-alb in the console.
2. Read the Region selector at the top of the page.
3. You should see Asia Pacific (Mumbai).
4. Open the balancer's subnets or Availability Zones.
5. You should see only Mumbai zones, such as ap-south-1a and ap-south-1b.
6. Try to find a Singapore subnet in that list.
7. You should not find one. The form cannot add it.
8. On paper, draw a second balancer named lab-alb-sg in Singapore, with two EC2 instances of its own.
9. Draw a line from a Mumbai user to lab-alb only.
10. Draw a line from a Singapore user to lab-alb-sg only.
11. You should see two separate drawings. There is no arrow from the Mumbai balancer to a Singapore EC2.

How latency routing divides the users

Do the clicks if example.com is a Route 53 hosted zone you control. If it is not, write the two records on paper. Do not launch a second region of EC2 instances for this lesson. The paper drawing is the second region. Leaving extra instances running is how a lab becomes a surprise.

1. Open Route 53.
2. Open the hosted zone for example.com.
3. Create an A record.
4. Turn on Alias.
5. Set the name to example.com.
6. Set the routing policy to Latency.
7. Set the region to Asia Pacific (Mumbai).
8. Set the alias target to lab-alb.
9. Save.
10. Create a second A record with the same name example.com.
11. Set the routing policy to Latency.
12. Set the region to Asia Pacific (Singapore).
13. Set the alias target to the Singapore balancer's DNS name. On paper, that name is lab-alb-sg.
14. Save.
15. You should see two records, same name, different regions.
16. A resolver that Route 53 measures as closer to Mumbai receives lab-alb.
17. That Mumbai balancer then picks a healthy EC2 in the Mumbai target group only.
18. A resolver closer to Singapore receives the Singapore balancer, and that balancer picks only Singapore EC2 instances.

How geolocation routing divides them instead

1. Create two alias A records for example.com, as above, but do not use Latency.
2. Set the routing policy to Geolocation.
3. On the Mumbai record, set the location to India, or to Asia if India is not the choice you want.
4. On the second record, set the location to Default.
5. Point the default record at the other region's balancer.
6. Save.
7. You should see a location on each record, not a latency region.
8. A query that Route 53 places in India receives the Mumbai balancer.
9. Everyone else receives the default region's balancer.
10. The chosen balancer still load-balances only inside its own region.

Do not turn on both latency and geolocation for the same name and expect a single clear winner. Pick one policy for the lab and delete the extra records before you finish.