Adrian Cantrill’s SAA-C02 study course, 40 minutes: HA and Scaling section: Applicaton Load Balancing (ALB) vs Network Load Balancing (NLB)
Application and Network Load Balancer
One important consideration is to know when to pick Application Load Balancers and when to pick Network Load Balancers.
When using classic load balancers, you connected instances directly to the load balancer, or you integrated an auto-scaling group directly with that load balancer. It was something like a single domain name using a single classic load balancer, and this has attached a single SSL certificate for that domain, and then an auto scaling group is attached to that, and the Classic Load Balancer distributes connections over those instances.
The problem is that this doesn’t scale because classic load balancers don’t support SNI and you can’t have multiple SSL certificates per load balancer, so every single unique HTTPS application that you have requires its own classic load balancer. This is one of the many reasons that classic load balancers should be avoided.
Compare this to the same application architecture using a single application load balancer, so it is handling multiple applications. This time we can use listener based rules, each of which can have an SSL certificate handling HTTPS for both domains. Then we can have host based rules which direct incoming connections at multiple target groups, which forward these on to multiple auto-scaling groups. This is a two-to-one consolidation: we’ve halved the number of load balancers required to deliver these two different applications.
Imagine if there were a hundred legacy applications and each of the used a classic load balancer. Moving from version 1 to version 2 offers significant advantages, and one of those is consolidation.
Application load balancer key points:
– Layer 7 load balancer…. Listens on HTTP and/or HTTPS
– No other layer 7 protocols (SMTP, SSH, Gaming….)
– And no TCP/UDP/TLS listeners
– L7 content type, cookies, custom headers, user location and app behavior
– HTTPS HTTPS (SSL/TLS) always terminated on the ALB – no unbroken SSL (security teams!)
– a new connection is made to the application
– ALB”s must have SSL certs if HTTPS is used
– ALB”s are slower than NLB …. more levels of the network stack to process
– Health checks evaluate application health … layer 7
– Rules direct connection which arrive at a listener
– rules are processed in priority order
– default order = catchall
– Rule conditions: host-header, http-header, http-request-method, path-pattern, query-string & source-ip
– Actions: forward, redirect, fixed-response, authenticate-oidc & authenticate-cognito
Network Load Balancer key points:
– Layer 4 load balancer ….. TCP, TLS, UDP, TCP, TCP_UDP
– no visibility or understanding of HTTP or HTTPS
– no headers, no cookies, no session stickiness
– really really really fast (millions of rps, 25% of ALB latency)
– SMTP, SSH, Game Servers, financial apps (not http/s)
– health checks just check ICMP/TCP Handshake… not app aware
– NLB’s can have static IP’s – useful for whitelisting
– Forward TCP to instances: unbroken encryption (NLB’s and TCP listeners is how you can do unbroken end to end encryption)
– Used with private link to provide services to other VPC’s
Reasons to NLB or ALB
– Unbroken encryption: NLB
– Static IP for whitelisting: NLB
– The fastest performance: NLB (millions rps)
– Protocols not HTTP or HTTPS: NLB
– Privatelink: NLB
– Otherwise: ALB
CloudMastermind 