Amazon ANS-C01: Load Balancing en Verkeersbeheer — Studiegids
Onderdeel van de AWS Advanced Networking Specialty ANS-C01 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.
Kernconcept
Load balancing in AWS werkt op twee fundamentele lagen: L4 (transport) en L7 (applicatie). Network Load Balancer (NLB) verzorgt L4 (TCP/UDP/TLS) distributie en is geoptimaliseerd voor extreme prestaties, waarbij het bron-IP-adres van de client behouden blijft en miljoenen gelijktijdige verbindingen met zeer lage latency en ‘connection churn’ worden ondersteund. Application Load Balancer (ALB) werkt op L7 (HTTP/HTTPS/WebSocket en HTTP/2/gRPC), biedt host- en path-gebaseerde routing, inspectie van headers, HTTP-gebaseerde health checks en ‘cookie stickiness’, en voert TLS-terminatie uit wanneer geconfigureerd met certificaten in ACM. Gateway Load Balancer (GWLB) is een speciaal gebouwde load balancer voor het schalen van virtuele appliances van derden (firewalls, IDS/IPS) met behulp van GENEVE-encapsulatie en Gateway Load Balancer endpoints (GWLBe), wat inline verkeersinspectie mogelijk maakt zonder handmatige schaling van appliances.
Listeners en listener rules zijn de L4/L7-toegangspunten die protocollen/poorten koppelen aan target groups. Een listener op een ALB kan complexe regels hebben die host, pad, headers en bron-IP CIDR inspecteren en verkeer doorsturen naar verschillende target groups; een ALB kan ook TLS offloaden (termineren) en de headers X-Forwarded-For, X-Forwarded-Proto en X-Forwarded-Port aan de targets presenteren. Een NLB-listener is doorgaans een TCP/UDP/TLS-listener die verkeer doorstuurt naar target groups zonder de payload te parsen (tenzij je TLS-terminatie op de NLB inschakelt): bij gebruik van TCP-passthrough behoud je end-to-end TLS, dus de backend moet certificaten presenteren en valideren voor mutual TLS. Target groups vormen de koppeling tussen een load balancer-listener en de set endpoints (instance, IP of Lambda), en ze stellen attributen beschikbaar zoals het protocol/de poort/het pad voor health checks, ‘deregistration delay’ (connection draining) en ‘stickiness’-eigenschappen.
Belangrijkste services en configuratie
Kies de juiste balancer voor de verkeerskenmerken en beveiligingseisen. Gebruik een ALB wanneer je host/path-gebaseerde routing, HTTP/HTTPS-functies zoals WebSockets of HTTP/2/gRPC met applicatiebewuste routing, en op cookies gebaseerde ‘stickiness’ nodig hebt. Configureer ALB-listeners met CreateListener of via AWS::ElasticLoadBalancingV2::Listener, koppel certificaten uit ACM, en stel listener rules in met CreateRule en condities (Field=path-pattern, host-header, http-header). Schakel ‘stickiness’ in op ALB target groups met ModifyTargetGroupAttributes door Key=stickiness.enabled,Value=true en Key=stickiness.lb_cookie.duration_seconds,Value=<seconds> in te stellen om door de load balancer gegenereerde cookies te gebruiken.
Gebruik een NLB voor TCP-verbindingen met hoge doorvoer en een lange levensduur, en wanneer het behoud van het bron-IP-adres van de client op de backend vereist is. Maak een NLB aan met aws elbv2 create-load-balancer –name my-nlb –type network –subnets <subnet-ids> en voeg een TCP-listener toe met aws elbv2 create-listener –load-balancer-arn <arn> –protocol TCP –port 443 –default-actions Type=forward,TargetGroupArn=<tg-arn>. Voor passthrough TLS en mTLS, configureer de NLB-listener als TCP zodat TLS door de backend wordt getermineerd; stel de target group in op target-type ip bij het registreren van pod-IP’s voor Kubernetes. Gebruik ModifyTargetGroupAttributes om Key=deregistration_delay.timeout_seconds,Value=<seconds> in te stellen om ‘connection draining’ mogelijk te maken; voor een NLB kun je waar nodig ook ‘source IP affinity’ (stickiness op de target group) inschakelen.
Gateway Load Balancer wordt geconfigureerd met CreateLoadBalancer Type=gateway en ondersteund door target groups van je appliance-instances (of een scale set in een autoscaling group), en gebruikt een Gateway Load Balancer endpoint in consumer-VPC’s om verkeer naar de appliances in de service-VPC te sturen. Gebruik dit patroon wanneer je transparante inspectie nodig hebt en wilt dat appliances automatisch meeschalen met het verkeer; maak listeners aan op poort 6081 (GENEVE-encapsulatie) en registreer de ENI’s van de appliance in de GWLB target group.
Operationele instellingen die je programmatisch moet beheren, zijn onder meer ‘cross-zone load balancing’, ‘deregistration delay’ (connection draining) en het afstemmen van health checks. Voor ‘cross-zone balancing’ stel je attributen in op de load balancer (aws elbv2 modify-load-balancer-attributes –load-balancer-arn <arn> –attributes Key=load_balancing.cross_zone.enabled,Value=true) om een gelijkmatige verdeling van het verkeer over de AZ’s te garanderen in plaats van een scheve verdeling per AZ-capaciteit. Stel het interval, de time-out en de drempels voor ‘healthy’/‘unhealthy’ in op de target groups om ‘flapping’ tijdens autoscaling-events te voorkomen.
Ontwerppatronen en afwegingen
Voor end-to-end TLS en mutual TLS (mTLS), waarbij verkeer versleuteld moet blijven en clientcertificaten aan de backend moeten worden aangeboden, geef je de voorkeur aan L4 passthrough met een NLB en TCP-listeners. Dit houdt de TLS-sessie intact zodat backends de X.509-certificaten van de client kunnen valideren; configureer target groups om IP-targets te gebruiken zodat Kubernetes pod-IP’s direct kunnen worden geregistreerd en de AWS Load Balancer Controller de levenscyclus van de targets kan beheren. De afweging is het verlies van ALB L7-functies zoals host/path-routing, integraties met Web Application Firewall en native HTTP cookie stickiness op de load balancer-laag.
Wanneer je content-based routing, TLS-terminatie en geavanceerde HTTP-functies nodig hebt, gebruik je een ALB en beëindig je de TLS op de ALB (met door ACM beheerde certificaten). Om het IP-adres van de client te behouden voor logging en WAF-regels, lees je de X-Forwarded-For-header die de ALB invult, of gebruik je een laag die het oorspronkelijke IP-adres van de client in de headers injecteert. Als de backend OS/netwerkstack het IP-adres van de client op socket-niveau moet kunnen zien, gebruik dan een NLB (of schakel Proxy Protocol in om het oorspronkelijke IP door te geven), maar let op dat Proxy Protocol moet zijn ingeschakeld op de target group en dat je applicatie of proxy (bijvoorbeeld Envoy) dit moet kunnen parsen.
Het afhandelen van sticky sessions in een autoscaling-omgeving vereist zorgvuldige overweging. ALB cookie stickiness kan een client voor een bepaalde duur aan een target binden, wat een gebalanceerde schaling over pods kan belemmeren als het sessieverkeer zwaar is; alternatieve patronen zijn onder meer het gebruik van stickiness met een korte duur in combinatie met het externaliseren van de sessiestatus naar ElastiCache (Redis) of DynamoDB, of het gebruik van een sidecar proxy (Envoy) om sessie-affiniteit met consistent hashing af te handelen. Connection draining (deregistration delay) is cruciaal voor een graceful shutdown: stel deregistration_delay.timeout_seconds in op een duur die langer is dan de langste RPC/HTTP-request om abrupte beëindiging en client-errors tijdens pod-terminatie te voorkomen; configureer Kubernetes preStop hooks om de levenscyclus van de pod te coördineren met de deregistratie.
GWLB is het geschikte patroon wanneer je schaalbare inline inspectie over veel VPC’s nodig hebt en gecentraliseerde beveiligingscontroles wilt. Combineer GWLB waar nodig met Transit Gateway- of VPC-peering-architecturen; de kosten en operationele complexiteit van het beheren van appliances zijn de afwegingen ten opzichte van het gebruik van managed services zoals AWS Network Firewall.
Veelvoorkomende valkuilen en beslissingscriteria
Een veelgemaakte fout is het beëindigen van TLS op de ALB zonder rekening te houden met de downstream-behoeften voor clientauthenticatie of het oorspronkelijke bron-IP. Als backends het clientcertificaat of het werkelijke bron-IP op de TCP-laag nodig hebben (voor logging of autorisatie), beëindig TLS dan op de backend via NLB passthrough of gebruik Proxy Protocol en zorg ervoor dat de applicatie dit parseert. Een andere veelvoorkomende valkuil is het inschakelen van sticky sessions zonder externe sessieopslag bij gebruik van de Horizontal Pod Autoscaler: wanneer pods uit- of inschalen, kan sticky affinity hotspots en verspilde capaciteit creëren; geef de voorkeur aan stateless backends of externaliseer de sessiestatus.
Operationele fouten ontstaan ook door verkeerd geconfigureerde health checks en deregistratievertragingen die leiden tot het wegvallen van verzoeken tijdens het schalen. Stel altijd de paden en drempelwaarden voor health checks in om de opwarmtijd van de applicatie te weerspiegelen en gebruik deregistration_delay.timeout_seconds om langlopende verbindingen de tijd te geven om af te ronden (draining). Cross-zone load balancing moet bewust worden ingesteld: het inschakelen ervan vermindert de tail latency en verdeelt de belasting gelijkmatiger, maar kan de kosten voor dataverkeer tussen AZ’s verhogen; evalueer dit tegen de AZ-capaciteit en verkeerspatronen. Ten slotte introduceert GWLB encapsulatie (GENEVE) en overhead voor het beheer van appliances — automatiseer de registratie van appliances met de AWS API’s (CreateTargetGroup/RegisterTargets) en instrumenteer met CloudWatch-metrics om autoscaling-beleid aan te sturen.
Praktijkprobleem: Gebruiksscenario
Bedrijf: Acme Telemetry. Uitdaging: Zorg voor end-to-end-encryptie voor een gRPC-service (gRPC over TLS op TCP-poort 443) die is geïmplementeerd in een Amazon EKS-cluster, ondersteun duizenden gelijktijdige, langlopende verbindingen, gebruik Kubernetes Cluster Autoscaler en HPA, en vereis mutual TLS (mTLS) zodat het clientcertificaat wordt gevalideerd door de backend (d.w.z. verkeer mag niet worden gedecrypteerd door een tussenliggende load balancer).
- Implementatieaanpak van de use-case: Provisioneer een Network Load Balancer met een TCP-listener op poort 443 en een target group van het type “ip” die verwijst naar pod-IP’s. Maak de NLB aan met
undefined
, maak de target group aan met
undefined
, registreer targets via de annotaties van de AWS Load Balancer Controller voor Kubernetes (
undefined
) zodat de controller de pod-IP’s automatisch registreert, en maak de listener aan met
undefined
. Stel het target group-attribuut deregistration_delay.timeout_seconds in op een geschikte waarde (bijvoorbeeld 300) met
undefined
om graceful draining mogelijk te maken.
Configuratie van backend TLS en mTLS: Beëindig TLS en voer mutual TLS uit op de pod-laag. Implementeer Envoy sidecars of laat de gRPC-servers TLS rechtstreeks accepteren, waarbij servercertificaten en CA-bundels worden opgeslagen in Kubernetes Secrets en in de pod worden gemount. Configureer backends om clientcertificaten te valideren tegen uw CA en configureer health checks om TCP te gebruiken om te voorkomen dat TLS op de load balancer wordt beëindigd. Zorg ervoor dat de lifecycle hooks van HPA en Cluster Autoscaler coördineren met de deregistratie van de target group door preStop hooks te implementeren die pods de tijd geven om het afronden (draining) van verbindingen te voltooien voordat ze worden beëindigd.
Schaalbaarheid en operationele controles: Schakel indien nodig cross-zone load balancing in op de NLB met
undefined
om verbindingen gelijkmatig over de AZ’s te verdelen. Monitor gelijktijdige verbindingen en flow rates met CloudWatch-metrics (NetworkPackets, ActiveFlowCount voor NLB) en stel autoscaling-beleid in voor de appliance (indien een sidecar wordt gebruikt) en voor de worker nodes. Gebruik ModifyTargetGroupAttributes voor het afronden van verbindingen en stem de intervallen van health checks af voor snellere detectie van storingen zonder ‘flapping’ (snel wisselende statussen). Automatiseer ten slotte de certificaatrotatie met behulp van AWS Secrets Manager en de integratie met Kubernetes cert-manager.
AWS-redenering: NLB in TCP-modus behoudt de TLS-sessie end-to-end, zodat de backend mTLS-validatie kan uitvoeren; de L4-architectuur is gebouwd voor miljoenen gelijktijdige flows en langlopende verbindingen, en door target-type ip te gebruiken kan de AWS Load Balancer Controller pod-IP’s rechtstreeks registreren, waardoor HPA/Cluster Autoscaler transparant kan schalen. Het afronden van verbindingen (deregistration_delay) en health checks voorkomen verlies van verzoeken tijdens het beëindigen van pods, en cross-zone balancing zorgt voor een gelijkmatige verdeling over de AZ’s, waarbij de kosten voor dataverkeer tussen AZ’s worden afgewogen tegen de prestaties.
← DNS en Route 53 · Alle domeinen · Netwerkbeveiliging en Compliance →
Oefen deze vragen → · Getimede oefening op ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Slaag voor je examen →