ALB vs NLB vs GLB: Når bør De bruke hva

NLB opererer på lag 4 (TCP/UDP/TLS). Den ruter pakker basert på data fra IP-protokollen uten å undersøke applikasjonsinnholdet. NLB er utviklet for ekstrem ytelse: den håndterer millioner av forespørsler per sekund med svært lav latenstid (vanligvis under 100 mikrosekunder).

Viktige NLB-funksjoner: statiske IP-adresser per AZ (én Elastic IP per subnett), TLS-gjennomkobling (videresend kryptert trafikk uten dekryptering), bevaring av klientens IP-adresse og støtte for UDP-protokoller (for eksempel DNS, RADIUS og spillservere). NLB kan ikke utføre innholdsbasert ruting eller undersøke HTTP-headere.

GWLB opererer på lag 3 (nettverkslaget) og er utelukkende utviklet for distribusjon, skalering og administrasjon av virtuelle nettverksapparater fra tredjeparter—brannmurer, systemer for inntrengingsdeteksjon og -forebygging (IDS/IPS) samt systemer for dyp pakkeinspeksjon.

GWLB bruker GENEVE-protokollen (port 6081) til å kapsle inn trafikk og sende den til apparatparken Deres. Apparatet undersøker pakken og returnerer den gjennom samme GWLB-endepunkt. Trafikken flyter transparent uten at det kreves rutingsendringer i kilde-VPC-en. Dette er standardmønsteret for å sette inn sentralisert sikkerhetsinspeksjon i AWS VPC-trafikkflyter.

Velg ALB når:

• De trenger HTTP/HTTPS-innholdsbasert ruting (sti, vert, header eller spørrestreng)
• Backend-løsningen Deres inkluderer Lambda-funksjoner eller ECS-containere
• De trenger WebSocket- eller HTTP/2-tilkoblinger
• De ønsker å integrere med AWS WAF for sikkerhet i webapplikasjonen på lastbalanseringslaget
• De bygger en mikrotjenestearkitektur med mange tjenester på ulike URL-stier
• De trenger SSL/TLS-terminering på lastbalansereren

ALB er det riktige svaret på de fleste spørsmål om lastbalansering for webapplikasjoner og REST-API-er på SAA-C03-eksamen.

Velg NLB når:

• De trenger ekstrem ytelse (millioner av forespørsler per sekund, latenstid på under ett millisekund)
• De krever statiske IP-adresser som partnere eller brannmurer kan tillate i allowlister
• De trenger å håndtere UDP-trafikk (spill, DNS, RADIUS eller IoT)
• De ønsker TLS-gjennomkobling uten dekryptering på lastbalansereren (ende-til-ende-kryptering til målet)
• De trenger å bevare klientens kilde-IP direkte på TCP-nivå
• De bruker AWS PrivateLink til å eksponere tjenester for andre VPC-er eller kontoer (NLB kreves for PrivateLink)

Velg GWLB når De trenger å:

• Sette inn tredjeparts brannmurapparater (Palo Alto, Fortinet eller Check Point) i nettverkstrafikkflyten
• Utføre dyp pakkeinspeksjon på VPC-nivå for all innkommende eller utgående trafikk
• Skalere en flåte av IDS/IPS-apparater horisontalt med automatisk lastbalansering

Arkitektur: Trafikken flyter fra kilde-VPC → GWLB-endepunkt → apparat-VPC (der GWLB fordeler trafikken på apparatinstanser) → apparatet returnerer trafikken til GWLB → GWLB videresender den til den opprinnelige destinasjonen. Kilden og destinasjonen er ikke klar over inspeksjonen imellom.

Lastbalansering på tvers av soner fordeler trafikken jevnt på alle registrerte mål i alle aktiverte AZ-er, uavhengig av hvilken AZ-noden til lastbalansereren mottok forespørselen i. Uten lastbalansering på tvers av soner fordeler noden i hver AZ bare trafikk til mål i sin egen AZ.

ALB har lastbalansering på tvers av soner aktivert som standard uten ekstra kostnad. NLB har dette deaktivert som standard—aktivering medfører kostnader for dataoverføring mellom AZ-er. GWLB har lastbalansering på tvers av soner deaktivert som standard. Aktiver funksjonen når antallet mål er ujevnt fordelt mellom AZ-er, for å unngå overbelastede punkter.

Rask sammenligningstabell for eksamen:

• OSI-lag: ALB = 7 (HTTP), NLB = 4 (TCP/UDP), GWLB = 3 (IP)
• Protokoller: ALB = HTTP, HTTPS, WebSocket; NLB = TCP, UDP, TLS; GWLB = alle IP-protokoller via GENEVE
• Statisk IP: ALB = Nei (bruk mønsteret NLB + ALB); NLB = Ja (1 per AZ); GWLB = Ikke relevant
• WAF-integrasjon: ALB = Ja; NLB = Nei; GWLB = Nei
• Lambda-mål: ALB = Ja; NLB = Nei; GWLB = Nei
• Tilkoblingstømming: alle tre støtter forsinkelse ved avregistrering

ALB integreres direkte med AWS WAF for regional beskyttelse (i motsetning til WAF på CloudFront for global beskyttelse ved kanten). Ved å knytte en WAF Web ACL til en ALB kan De filtrere HTTP-forespørsler før de når applikasjonen, og blokkere SQL-injection, XSS, kjente ondsinnede IP-adresser og klienter som overskrider grenseverdier.

Bruk ALB + WAF når De ønsker sikkerhetsinspeksjon på lastbalanseringslaget (for eksempel for å beskytte API-er som ikke leveres gjennom CloudFront). WAF Web ACL-er som er knyttet til ALB-er, må være i samme region som ALB-en og ha omfanget REGIONAL (i motsetning til CloudFront WAF, som krever omfanget CLOUDFRONT i us-east-1).

AWS PrivateLink bruker NLB til å eksponere tjenester i én VPC for forbrukere i andre VPC-er eller AWS-kontoer uten krav om VPC-peering, en internett-gateway eller NAT. Tjenesteleverandøren oppretter en NLB foran tjenesten og oppretter en VPC Endpoint Service. Forbrukerne oppretter et Interface VPC Endpoint i sin VPC som peker til tjenesten.

Trafikken går over AWS sitt private nettverk og passerer aldri internett. PrivateLink er standardmønsteret for SaaS-leverandører på AWS og for å eksponere delte tjenester (for eksempel en sentralisert sikkerhetstjeneste) for flere interne AWS-kontoer.

I denne leksjonen lærte De at ALB ruter på lag 7 (HTTP) med innholdsbaserte regler, WAF-integrasjon og Lambda-mål, at NLB ruter på lag 4 (TCP/UDP) med statiske IP-adresser og ekstrem gjennomstrømming, og at GWLB distribuerer virtuelle nettverksapparater på lag 3 ved hjelp av GENEVE. Knytt lastbalansereren til kravene til protokoller og funksjoner. Neste tema er målgrupper og helsekontroller.