Chapter 18: Load Balancing

18.16 Internet-facing and internal load balancers

By Ravindra Bagale · Last updated: 3 October 2026

Why there are two schemes

Users on the internet must reach the web tier. They type a public name. The app tier must not be reachable from the internet. If it is, anyone can call the API and skip the checks the web tier was supposed to do. Two balancers, two schemes, is how you keep those doors apart.

What the scheme changes

You choose the scheme when you create the balancer. You do not flip it later. Changing scheme means creating a new balancer and moving the listeners. The console will not turn an internal balancer into an internet-facing one in place.

A public subnet in this lesson has a route to an internet gateway. A private subnet does not.

How the two balancers are placed

Worked example in one VPC. The ranges are private ranges we chose for the drawing. They are not a claim about your default VPC.

Internet-facing Application Load Balancer:

1. Scheme is Internet-facing.
2. Subnet one is 172.16.0.0/24, a public subnet.
3. Subnet two is 172.16.1.0/24, a public subnet in a second Availability Zone.
4. Its security group allows TCP 80 and TCP 443 from 0.0.0.0/0.
5. It forwards to the web target group.

Internal Application Load Balancer:

1. Scheme is Internal.
2. Subnet one is 172.16.10.0/24, a private subnet.
3. Subnet two is 172.16.11.0/24, a private subnet in a second Availability Zone.
4. Its security group allows TCP 8080 only from the web tier security group.
5. It does not allow 8080 from 0.0.0.0/0.
6. It forwards to the app target group on port 8080.

The path of one user:

1. A user in Pune opens https://www.example.com.
2. DNS sends them to the internet-facing balancer.
3. That balancer sends the request to a web EC2.
4. The web EC2 calls http://internal-api-lb.example.internal:8080.
5. That name is a private record we point at the internal balancer. The AWS DNS name of an internal balancer also resolves to private addresses inside the VPC. It does not have a route from the internet.
6. The internal balancer sends the call to an app EC2.
7. The app EC2 is not on the internet. Its subnet is private. Its security group does not allow the world.

How to set the scheme in the console

Button names may vary.

1. Choose Create load balancer, then Application Load Balancer.
2. On the scheme control, choose Internet-facing for the public balancer.
3. Pick the two public subnets.
4. Finish that balancer.
5. Start a second Application Load Balancer.
6. On the scheme control, choose Internal.
7. Pick the two private subnets.
8. You should see the scheme listed on each balancer's description. One says internet-facing. One says internal.
9. If you picked the wrong scheme, do not hunt for an edit that flips it. Create a new balancer with the right scheme and delete the wrong one when nothing still points at it.

What goes wrong if the app balancer is internet-facing

Second example, the failure.

1. The app balancer is created as internet-facing by mistake.
2. It receives public addresses.
3. Its security group is left open, or a later edit allows 8080 from 0.0.0.0/0.
4. Anyone who learns the DNS name can call the API directly.
5. The web tier's checks are skipped.
6. The fix is a new internal balancer in the private subnets, a security group that allows 8080 only from the web tier, and a private DNS name. You do not "switch" the old one.