ALB versus NLB versus GLB: wanneer gebruikt u welke

De NLB werkt op laag 4 (TCP/UDP/TLS). Deze routeert pakketten op basis van gegevens uit het IP-protocol, zonder de inhoud van de applicatie te inspecteren. NLB is ontworpen voor extreme prestaties: deze verwerkt miljoenen aanvragen per seconde met ultralage latentie (doorgaans minder dan 100 microseconden).

Belangrijke functies van NLB: statische IP-adressen per AZ (één Elastic IP per subnet), TLS-doorgifte (versleuteld verkeer doorsturen zonder het te ontsleutelen), behoud van het IP-adres van de client en ondersteuning voor UDP-protocollen (bijvoorbeeld DNS, RADIUS en gameservers). NLB kan geen routering op basis van inhoud uitvoeren en geen HTTP-headers inspecteren.

De GWLB werkt op laag 3 (netwerklaag) en is uitsluitend ontworpen voor het implementeren, schalen en beheren van virtuele netwerkapparaten van derden—firewalls, systemen voor inbraakdetectie en -preventie (IDS/IPS) en systemen voor diepe pakketinspectie.

GWLB gebruikt het GENEVE-protocol (poort 6081) om verkeer in te kapselen en naar je verzameling apparaten te sturen. Het apparaat inspecteert het pakket en stuurt het via hetzelfde GWLB-eindpunt terug. Het verkeer stroomt transparant door zonder dat routeringswijzigingen in de bron-VPC nodig zijn. Dit is het standaardpatroon voor het invoegen van centrale beveiligingsinspectie in AWS VPC-verkeersstromen.

Kies ALB wanneer:

• Je routering op basis van HTTP/HTTPS-inhoud nodig hebt (pad, host, header, querytekenreeks)
• Je backend Lambda-functies of ECS-containers bevat
• Je WebSocket- of HTTP/2-verbindingen nodig hebt
• Je AWS WAF wilt integreren voor beveiliging van webapplicaties op de laag van de load balancer
• Je een microservicesarchitectuur bouwt met veel services op verschillende URL-paden
• Je SSL/TLS-beëindiging op de load balancer nodig hebt

ALB is het juiste antwoord voor de meeste examenvragen over load balancing van webapplicaties en REST-API's op het SAA-C03-examen.

Kies NLB wanneer:

• Je extreme prestaties nodig hebt (miljoenen aanvragen per seconde, latentie van minder dan een milliseconde)
• Je statische IP-adressen nodig hebt die partners of firewalls op een allowlist kunnen zetten
• Je UDP-verkeer moet verwerken (games, DNS, RADIUS, IoT)
• Je TLS-doorgifte wilt zonder ontsleuteling op de load balancer (end-to-endversleuteling naar het doel)
• Je het bron-IP-adres van de client standaard op TCP-niveau moet behouden
• Je AWS PrivateLink gebruikt om services beschikbaar te maken voor andere VPC's of accounts (voor PrivateLink is NLB vereist)

Kies GWLB wanneer je het volgende moet doen:

• Virtuele firewallapparaten van derden (Palo Alto, Fortinet, Check Point) in je netwerkverkeersstroom invoegen
• Diepe pakketinspectie uitvoeren op VPC-niveau voor al het inkomende of uitgaande verkeer
• Een verzameling IDS/IPS-apparaten horizontaal schalen met automatische load balancing

Architectuur: verkeer stroomt van de bron-VPC → GWLB-eindpunt → apparaat-VPC (waar GWLB het verkeer over apparaatinstanties verdeelt) → het apparaat stuurt het verkeer terug naar GWLB → GWLB stuurt het door naar de oorspronkelijke bestemming. De bron en bestemming merken niets van de inspectie ertussen.

Load balancing over zones heen verdeelt verkeer gelijkmatig over alle geregistreerde doelen in alle ingeschakelde AZ's, ongeacht in welke AZ het knooppunt van de load balancer de aanvraag heeft ontvangen. Zonder load balancing over zones heen verdeelt het knooppunt van elke AZ het verkeer alleen over doelen in de eigen AZ.

Bij ALB is load balancing over zones heen standaard ingeschakeld zonder extra kosten. Bij NLB is dit standaard uitgeschakeld—inschakelen brengt kosten voor gegevensoverdracht tussen AZ's met zich mee. Bij GWLB is load balancing over zones heen standaard uitgeschakeld. Schakel dit in wanneer het aantal doelen per AZ verschilt, om overbelasting van afzonderlijke zones te voorkomen.

Snelle vergelijkingstabel voor het examen:

• OSI-laag: ALB = 7 (HTTP), NLB = 4 (TCP/UDP), GWLB = 3 (IP)
• Protocollen: ALB = HTTP, HTTPS, WebSocket; NLB = TCP, UDP, TLS; GWLB = alle IP-protocollen via GENEVE
• Statisch IP-adres: ALB = Nee (gebruik het patroon NLB + ALB); NLB = Ja (1 per AZ); GWLB = n.v.t.
• WAF-integratie: ALB = Ja; NLB = Nee; GWLB = Nee
• Lambda-doel: ALB = Ja; NLB = Nee; GWLB = Nee
• Verbindingen beëindigen: alle drie ondersteunen een vertraging bij deregistratie

ALB integreert standaard met AWS WAF voor regionale bescherming (in tegenstelling tot WAF op CloudFront voor wereldwijde bescherming aan de edge). Door een WAF Web ACL aan een ALB te koppelen, kun je HTTP-aanvragen filteren voordat ze je applicatie bereiken—en zo SQL-injecties, XSS, bekende kwaadwillende IP-adressen en clients die de snelheidslimieten overschrijden blokkeren.

Gebruik ALB + WAF wanneer je beveiligingsinspectie op de laag van de load balancer wilt uitvoeren (bijvoorbeeld om API's te beschermen die niet via CloudFront worden aangeboden). WAF Web ACL's die aan ALB's zijn gekoppeld, moeten zich in dezelfde regio als de ALB bevinden en moeten het REGIONAL-bereik hebben (in tegenstelling tot CloudFront WAF, waarvoor het CLOUDFRONT-bereik in us-east-1 vereist is).

AWS PrivateLink gebruikt NLB om services in één VPC beschikbaar te maken voor gebruikers in andere VPC's of AWS-accounts, zonder VPC-peering, een internetgateway of NAT. De serviceprovider maakt een NLB vóór de service en maakt een VPC Endpoint Service. Gebruikers maken een Interface VPC Endpoint in hun VPC die naar de service verwijst.

Het verkeer loopt over het privénetwerk van AWS en gaat nooit via internet. PrivateLink is het standaardpatroon voor SaaS-providers op AWS en voor het beschikbaar maken van gedeelde services (bijvoorbeeld een gecentraliseerde beveiligingsservice) voor meerdere interne AWS-accounts.

In deze les heb je geleerd dat ALB op laag 7 (HTTP) routeert met regels op basis van inhoud, WAF-integratie en Lambda-doelen, dat NLB op laag 4 (TCP/UDP) routeert met statische IP-adressen en een extreem hoge verwerkingscapaciteit en dat GWLB virtuele netwerkapparaten implementeert op laag 3 met GENEVE. Koppel de load balancer aan de vereisten voor protocollen en functies. Hierna behandelen we doelgroepen en statuscontroles.