18.7 Application Load Balancer

By Ravindra Bagale Last updated: 3 October 2026

Why HTTP needs to be understood

example.com and api.example.com can share one balancer and still reach different instances. The balancer reads the Host header and the path. That is what "application" means here: it understands HTTP. A Network Load Balancer forwarding raw TCP cannot do that split.

What you already built

lab-alb is the Application Load Balancer. It terminates HTTP on port 80. The certificate for HTTPS, if you add a 443 listener later, sits on the balancer, and the instances can keep speaking HTTP behind it. That is the opposite of the Network Load Balancer example in the next section. This lab's proof is the two host names, not a new certificate.

The picture for a real shop and a real API is the same shape, and only the shape. Flipkart's website and Flipkart's app calls do not have to be the same process. Amazon's pages and Amazon's service calls do not have to be the same process. You do not know their host rules. You do know that an Application Load Balancer can send example.com to group A and api.example.com to group B.

How to prove the two host names

Confirm lab-alb is Active.
Confirm the rule for host api.example.com forwards to site-b-tg.
Confirm the default action forwards to site-a-tg.
Run curl -s -H 'Host: example.com' http://ALB-DNS/.
You should see This is server A, the shop.
Run curl -s -H 'Host: api.example.com' http://ALB-DNS/.
You should see This is server B, the api.
Stop instance A.
Run curl -s -H 'Host: example.com' http://ALB-DNS/.
You should see 502, or a connection error from the balancer, because site-a-tg has no healthy target.
Run curl -s -H 'Host: api.example.com' http://ALB-DNS/.
You should still see server B. The other host did not die with A.
Start instance A.
Wait until site-a-tg says healthy.
Run the example.com curl again.
You should see server A again.

That last wait is the health check. Manual DNS in section 18.3 never did it.