ALB vs NLB vs GLB: Hvornår skal De bruge hvad

Elastic Load Balancing (ELB) distribuerer automatisk indgående applikationstrafik på tværs af flere mål—EC2-instanser, containere, Lambda-funktioner eller IP-adresser. ELB er en administreret tjeneste, hvilket betyder, at AWS håndterer klargøring, skalering og tilgængelighed for selve load balanceren på tværs af flere AZ'er.

AWS tilbyder tre typer load balancere under ELB-paraplyen: Application Load Balancer (ALB), Network Load Balancer (NLB) og Gateway Load Balancer (GWLB). Hver af dem fungerer på et forskelligt lag i OSI-modellen og er optimeret til forskellige anvendelsesområder.

ALB fungerer på lag 7 (HTTP/HTTPS) i OSI-modellen. Den kan inspicere HTTP-headere, stier, forespørgselsstrenge, værtsnavne og cookies for at træffe intelligente routingsbeslutninger. ALB er det oplagte valg til webapplikationer, mikrotjenester og API-endepunkter, der har brug for indholdsbaseret routing.

Vigtige ALB-funktioner: sti-baseret routing (/api/* til én målgruppe, /static/* til en anden), værtsbaseret routing (forskellige virtuelle værter til forskellige backends), routing baseret på HTTP-header og forespørgselsstreng, understøttelse af WebSocket samt understøttelse af HTTP/2. ALB kan route til EC2-instanser, containere (ECS/EKS), Lambda-funktioner og IP-adresser.

NLB fungerer på lag 4 (TCP/UDP/TLS). Den router pakker baseret på IP-protokoldata uden at inspicere applikationsindholdet. NLB er designet til ekstrem ydeevne: den håndterer millioner af forespørgsler pr. sekund med ultralav latenstid (typisk under 100 mikrosekunder).

Vigtige NLB-funktioner: statiske IP-adresser pr. AZ (én Elastic IP pr. subnet), TLS-gennemgang (videresend krypteret trafik uden dekryptering), bevarelse af klientens IP-adresse samt understøttelse af UDP-protokoller (f.eks. DNS, RADIUS og spilservere). NLB kan ikke udføre indholdsbaseret routing eller inspicere HTTP-headere.

GWLB fungerer på lag 3 (netværkslaget) og er udelukkende designet til implementering, skalering og administration af virtuelle netværksapparater fra tredjeparter—firewalls, systemer til registrering og forebyggelse af indtrængen (IDS/IPS) samt systemer til dyb pakkeinspektion.

GWLB bruger GENEVE-protokollen (port 6081) til at indkapsle trafik og sende den til din samling af apparater. Apparatet inspicerer pakken og sender den tilbage gennem det samme GWLB-endepunkt. Trafikken flyder transparent uden behov for routingændringer i kilde-VPC'en. Dette er standardmønstret til at indsætte centraliseret sikkerhedsinspektion i AWS VPC-trafikflows.

Vælg ALB når:

• Du har brug for HTTP/HTTPS-baseret routing efter indhold (sti, vært, header, forespørgselsstreng)
• Din backend omfatter Lambda-funktioner eller ECS-containere
• Du har brug for forbindelser via WebSocket eller HTTP/2
• Du vil integrere med AWS WAF for at sikre webapplikationen på load balancer-laget
• Du bygger en mikrotjenestearkitektur med mange tjenester på forskellige URL-stier
• Du har brug for SSL/TLS-terminering ved load balanceren

ALB er det korrekte svar på de fleste spørgsmål om load balancing af webapplikationer og REST-API'er ved SAA-C03-eksamen.

Vælg NLB når:

• Du har brug for ekstrem ydeevne (millioner af forespørgsler pr. sekund, latenstid under et millisekund)
• Du kræver statiske IP-adresser, som partnere eller firewalls kan føje til en tilladelsesliste
• Du skal håndtere UDP-trafik (spil, DNS, RADIUS, IoT)
• Du ønsker TLS-gennemgang uden dekryptering ved load balanceren (ende-til-ende-kryptering til målet)
• Du har brug for naturligt at bevare klientens kilde-IP på TCP-niveau
• Du bruger AWS PrivateLink til at eksponere tjenester for andre VPC'er eller konti (NLB er påkrævet til PrivateLink)

Vælg GWLB når du har brug for at:

• Indsætte firewall-apparater fra tredjeparter (Palo Alto, Fortinet, Check Point) i dit netværkstrafikflow
• Udføre dyb pakkeinspektion på VPC-niveau for al indgående eller udgående trafik
• Skalere en samling af IDS/IPS-apparater horisontalt med automatisk load balancing

Arkitektur: Trafikken flyder fra kilde-VPC → GWLB-endepunkt → apparat-VPC (hvor GWLB fordeler trafikken på tværs af apparatinstanser) → apparatet sender trafikken tilbage til GWLB → GWLB videresender den til den oprindelige destination. Kilden og destinationen er ikke klar over den mellemliggende inspektion.

Load balancing på tværs af zoner fordeler trafikken jævnt på alle registrerede mål i alle aktiverede AZ'er, uanset i hvilken AZ load balancer-noden modtog forespørgslen. Uden load balancing på tværs af zoner fordeler hver AZ's node kun trafik til mål i sin egen AZ.

ALB har load balancing på tværs af zoner aktiveret som standard uden ekstra omkostninger. NLB har load balancing på tværs af zoner deaktiveret som standard—aktivering medfører gebyrer for dataoverførsel mellem AZ'er. GWLB har load balancing på tværs af zoner deaktiveret som standard. Aktivér load balancing på tværs af zoner, når antallet af mål er ujævnt fordelt mellem AZ'er, for at undgå overbelastede områder.

Hurtig sammenligningstabel til 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 = Nej (brug mønstret NLB + ALB); NLB = Ja (1 pr. AZ); GWLB = Ikke relevant
• WAF-integration: ALB = Ja; NLB = Nej; GWLB = Nej
• Lambda-mål: ALB = Ja; NLB = Nej; GWLB = Nej
• Forbindelsesdræning: alle tre understøtter forsinkelse ved afregistrering

ALB integreres naturligt med AWS WAF for regional beskyttelse (i modsætning til WAF på CloudFront til global beskyttelse ved kanten). Ved at knytte en WAF Web ACL til en ALB kan du filtrere HTTP-forespørgsler, før de når din applikation—blokere SQL-injektion, XSS, kendte ondsindede IP-adresser og klienter, der misbruger hastigheden.

Brug ALB + WAF når du ønsker sikkerhedsinspektion på load balancer-laget (f.eks. for at beskytte API'er, der ikke leveres via CloudFront). WAF Web ACL'er, der er knyttet til ALB'er, skal være i samme region som ALB'en og have REGIONAL-scope (i modsætning til CloudFront WAF, som kræver CLOUDFRONT-scope i us-east-1).

AWS PrivateLink bruger NLB til at eksponere tjenester i én VPC for forbrugere i andre VPC'er eller AWS-konti uden behov for VPC-peering, en internetgateway eller NAT. Tjenesteudbyderen opretter en NLB foran sin tjeneste og opretter en VPC Endpoint Service. Forbrugerne opretter et Interface VPC Endpoint i deres VPC, som peger på tjenesten.

Trafikken flyder over AWS's private netværk og passerer aldrig internettet. PrivateLink er standardmønstret for SaaS-udbydere på AWS og til eksponering af delte tjenester (f.eks. en centraliseret sikkerhedstjeneste) for flere interne AWS-konti.

I denne lektion lærte du, at ALB router på lag 7 (HTTP) med indholdsbaserede regler, WAF-integration og Lambda-mål, at NLB router på lag 4 (TCP/UDP) med statiske IP'er og ekstrem gennemstrømning, og at GWLB implementerer virtuelle netværksapparater på lag 3 ved hjælp af GENEVE. Vælg den load balancer, der passer til kravene til protokol og funktioner. Næste gang undersøger vi målgrupper og tilstandstjek.