Chapter 18: Load Balancing

18.17 Load balancer in a three-tier architecture

By Ravindra Bagale · Last updated: 3 October 2026

Why the tiers are separate

Presentation, application, and data are separated so a sale spike can add web instances without putting the database on the internet. Amazon, Flipkart, and IRCTC on a busy day are the traffic picture only. This is not their internal design. The database stays in a private subnet. Users never open it. The web tier can grow from 2 instances to 6 without a new database.

What the picture contains

Users on the internet
        |
        v
Internet-facing ALB
  public subnets, two AZs
        |
        v
Web tier
  EC2 Auto Scaling group
  min 2, desired 2, max 6
  target group TG-web, port 80
        |
        v
Internal ALB
  private subnets, two AZs
        |
        v
App tier
  EC2 Auto Scaling group
  min 2, desired 2, max 4
  target group TG-api, port 8080
        |
        v
Data tier
  Amazon RDS MySQL, Multi-AZ
  private subnets, port 3306
  no load balancer in front

There is no load balancer in front of the primary database. You do not round-robin writes to two primaries. A read replica is optional and is not fronted by either of these Application Load Balancers. This lesson does not build a reader endpoint.

The tiers, with the numbers we set:

1. Users on the internet.
2. Internet-facing Application Load Balancer in two public subnets and two Availability Zones.
3. Web tier: Auto Scaling group, minimum 2, desired 2, maximum 6, target group TG-web, port 80, behind the public balancer.
4. Internal Application Load Balancer in two private subnets and two Availability Zones.
5. App tier: Auto Scaling group, minimum 2, desired 2, maximum 4, target group TG-api, port 8080, behind the internal balancer.
6. Data tier: Amazon RDS MySQL, Multi-AZ, private subnets, port 3306 allowed only from the app tier security group.

Both of those balancers are Application Load Balancers, so cross-zone load balancing is already on. Section 18.18 does not ask you to toggle it here.

How the security groups chain

One line each. The source is the previous tier's security group, not the whole internet.

1. Public balancer security group: inbound 443 from 0.0.0.0/0.
2. Web security group: inbound 80 from the public balancer security group only.
3. Internal balancer security group: inbound 8080 from the web security group only.
4. App security group: inbound 8080 from the internal balancer security group only.
5. RDS security group: inbound 3306 from the app security group only.

If you kept the HTTP port 80 redirect from section 18.14, the public balancer security group also allows 80 from 0.0.0.0/0. That extra line is only for the redirect. It does not open the web instances to the world.

How one product page and one checkout call move

Flipkart-style traffic, our numbers, not a real shop's design.

Product page:

1. The browser asks for https://www.example.com/product/42.
2. The internet-facing balancer accepts it on 443.
3. The rule sends it to TG-web.
4. One of the 2 web instances, desired capacity 2, builds the page.
5. That web instance calls the internal balancer on port 8080.
6. The internal balancer sends the call to one of the 2 app instances in TG-api.
7. The app instance reads the product row from RDS on port 3306.
8. The row comes back app, internal balancer, web, public balancer, browser.
9. RDS was never the next hop of the public balancer.

Checkout:

1. The browser posts https://www.example.com/checkout.
2. The internet-facing balancer accepts it on 443.
3. The rule sends it to the checkout target group from section 18.13, desired 2, not to the browsing group.
4. That checkout instance calls the same internal balancer on port 8080.
5. The internal balancer sends it to TG-api.
6. The app instance writes the order to the RDS primary on port 3306.
7. The write is one primary, not a round robin across two databases.
8. You should see two balancers in the path, and no balancer between the app instance and RDS.

What is not in this picture

Do not register the RDS instance in TG-web or TG-api. Do not put the database behind the same Application Load Balancer as the web servers. The balancer speaks HTTP to web and app instances. The database speaks MySQL on 3306 to the app tier only.