Amazon ANS-C01: Container en Serverless Networking — Studiegids

By Laurynas Brazys · 3 August 2026 · #amazon #ans-c01 #certification #exam-prep #study-guide

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.

EKS-networking (CNI, pod-networking)

Pod-networking in Amazon EKS wordt gedomineerd door de Amazon VPC CNI-plugin (amazon-vpc-cni-k8s), die elke pod een IP-adres uit de VPC geeft en het pod-verkeer direct op het VPC-netwerk plaatst. Dit ontwerp levert voorspelbare beveiligingscontroles op VPC-niveau (security groups, NACL’s) en low-latency routing, maar vereist zorgvuldige planning van IP-adres- en ENI-capaciteit, omdat het aantal secundaire IPv4-adressen per ENI en het aantal ENI’s per instance-type hardwarematig beperkt zijn. De aws-node daemonset stuurt de IP-toewijzing en attach/detach-operaties aan; de bijbehorende ConfigMap wordt met kubectl bewerkt om het gedrag af te stemmen (bijvoorbeeld door

undefined

in te stellen). Prefix delegation en pod ENI-modi verminderen de uitputting van IP-adressen per node door een node hele /28-prefixen aan een ENI te laten toewijzen (

undefined

) of door een toegewezen ENI per pod toe te wijzen (nuttig voor isolatie met hoge beveiliging).

Alternatieven voor de Amazon VPC CNI, zoals Cilium (eBPF) of Calico, kunnen andere afwegingen bieden. Cilium kan kube-proxy vervangen en high-performance L3/L4-forwarding implementeren met behulp van eBPF, transparante encryptie tussen nodes mogelijk maken (WireGuard of IPsec), en de IP-druk op node-niveau verminderen door overlay- of masquerading-benaderingen te gebruiken. Met Cilium integreer je nog steeds met VPC-routing voor egress en ingress, maar je vermijdt frequente ENI attach/detach-operaties; dit is belangrijk bij een hoge omloopsnelheid van pods. Voor zeer hoge aantallen verbindingen en strikt L7-gedrag, overweeg je ook het afstemmen van de kube-proxy-modus (IPVS) en de kernelinstellingen van de node: pas

undefined

aan, en stel deze beschikbaar via kubelet of daemonset-init-scripts om uitputting van ephemerale poorten te voorkomen bij duizenden gelijktijdige, langlevende gRPC-verbindingen.

ECS-networkingmodi en Lambda VPC-integratie

ECS task-networking heeft drie primaire modi: bridge, host en awsvpc. De awsvpc-modus is het best vergelijkbaar met Kubernetes pod-networking, omdat het een ENI koppelt aan elke taak (of taakgroep) en een privé-IP en security groups direct aan de taak toewijst. Configureer awsvpc door

undefined

met

undefined

te specificeren in

undefined

-API-aanroepen. Fargate dwingt awsvpc af en biedt daardoor netwerkisolatie op taakniveau en integreert met AWS Cloud Map voor service discovery. Gebruik awsvpc wanneer je op security groups gebaseerde verkeersfiltering per taak nodig hebt, of wanneer je standaard VPC-routing en -metrics wilt blootstellen.

Lambda-functies die VPC-toegang nodig hebben, worden aan de VPC gekoppeld via ENI’s in de geconfigureerde subnets en security groups van de functie. Deze ENI’s worden aangemaakt en beheerd door de Lambda control plane, maar het provisionen van ENI’s kan cold-start latency toevoegen en heeft historisch gezien snelle opschaling beperkt, tenzij dit wordt ondervangen met provisioned concurrency of door VPC-eindpunten (AWS PrivateLink) en een zorgvuldig ontworpen subnetarchitectuur te gebruiken. Wanneer je veel Lambda-functies in een VPC plaatst, zorg er dan voor dat subnets beschikbare IP’s hebben, gebruik indien nodig een NAT Gateway of NAT-instances voor egress, en geef de voorkeur aan VPC-eindpunten (

undefined

-eindpunten via

undefined

) om te voorkomen dat egress-verkeer waar mogelijk via het internet wordt gerouteerd. Monitor ENI attach/detach met CloudWatch Logs en VPC Flow Logs om het schaalgedrag te observeren en problemen met concurrency-related throttling op te lossen.

App Mesh en service discovery

AWS App Mesh gebruikt Envoy-sidecars als de data plane en biedt L3–L7 observability, traffic shaping, retries en controles voor TLS-originatie/terminatie. Definieer meshes, virtual nodes en virtual services via de App Mesh API (

undefined

) of de App Mesh-controller voor Kubernetes. App Mesh ondersteunt mTLS door het TLS-blok van een VirtualNode-listener te configureren met een clientPolicy en een certificaatautoriteit, en je kunt integreren met AWS Certificate Manager (ACM) of SDS voor certificaatdistributie. Merk echter op dat App Mesh-sidecars het verkeer per ontwerp beëindigen en opnieuw versleutelen; als een vereiste voorschrijft dat applicatieverkeer end-to-end versleuteld moet blijven tussen de client en de applicatie-pod (geen decryptie in de netwerkproxy), moet je ervoor zorgen dat TLS alleen bij de pod wordt beëindigd en vermijden dat dit gebeurt bij de mesh-ingress of load balancer.

Service discovery wordt doorgaans gedaan met Kubernetes Services en CoreDNS voor EKS, met Cloud Map (

undefined

) voor cross-platform, en met Route 53 private hosted zones voor op DNS gebaseerde lookups. AWS Cloud Map integreert rechtstreeks met ECS en App Mesh, waardoor SRV- of A-records en API-gestuurde health checks mogelijk zijn. Voor dynamische omgevingen waar instances snel schalen, combineer je korte DNS TTL’s en Cloud Map health checks om verouderde resolutie te voorkomen; als je onmiddellijke consistentie nodig hebt, gebruik dan een service mesh control-plane API om eindpunten op te halen in plaats van te vertrouwen op DNS-caching.

Ontwerppatronen en afwegingen

Bij het ontwerpen van grootschalige gRPC over TLS met mTLS, moet u beslissen waar TLS wordt beëindigd. Het beëindigen van TLS op de load balancer (ALB) maakt het mogelijk om certificaten te offloaden naar ACM en vereenvoudigt certificaatsrotatie, maar het verbreekt de end-to-end-encryptie en kan geen mutual TLS bieden aan backend-pods, tenzij de backend opnieuw TLS tot stand brengt met de doorgestuurde clientcertificaatinformatie. Voor echte end-to-end mTLS waarbij applicatie-endpoints clients rechtstreeks authenticeren, gebruikt u een L4 passthrough-gateway zoals een Network Load Balancer en laat u de pod/applicatie de TLS/mTLS-afhandeling doen. Combineer NLB target-type ip met de AWS Load Balancer Controller-annotatie service.beta.kubernetes.io/aws-load-balancer-target-type: "ip" om pod-IP’s direct te registreren; dit patroon schaalt goed omdat de NLB is ontworpen voor miljoenen verbindingen en langdurige TCP/gRPC-sessies ondersteunt zonder TLS te beëindigen.

Voor ingress en path-based routing met HTTPS-beëindiging is een Application Load Balancer geschikter omdat deze host/path-regels, redirects en integratie met WAF ondersteunt. Om client-IP’s te behouden wanneer de ALB TLS beëindigt, moet u vertrouwen op de X-Forwarded-For-headers; backend-webservers moeten X-Forwarded-For verwerken en loggen, en u dient de ALB access logs in te schakelen voor verificatie. Als u het daadwerkelijke client-socketadres op de serverlaag nodig heeft (voor legacy software), gebruik dan een NLB met proxy protocol v2 en zorg ervoor dat de backend-services het proxy protocol ondersteunen.

Serviceconnectiviteit over meerdere AWS-accounts en VPC’s schaalt verschillend, afhankelijk van het patroon. VPC peering is eenvoudig maar N^2 in beheer; Transit Gateway centraliseert de routing en schaalt beter voor veel VPC’s met route table-segregatie; AWS PrivateLink (Interface VPC Endpoints) biedt het meest granulaire, per-service en identiteitsbewuste toegangsmodel, omdat u een endpoint-service beschikbaar stelt via een NLB en consumenten interface-endpoints aanmaken in hun VPC’s. Voor multi-account gedeelde services met strikte toegangscontrole en schaalbare onboarding, geef de voorkeur aan PrivateLink omdat het de routing isoleert (geen wijzigingen in de route table van consumenten-VPC’s) en security groups gebruikt voor fijnmazige controles.

Veelvoorkomende valkuilen en beslissingscriteria

Een veelvoorkomende valkuil is de aanname dat hetzelfde netwerkmodel geschikt is voor alle workloads. Stateful workloads of workloads met langdurige verbindingen (gRPC, databases) hebben de voorkeur voor L4 passthrough (NLB) met TLS-terminatie op pod-niveau of hostPort/hostNetwork-patronen om door proxy’s veroorzaakte latency te vermijden; HTTP-microservices die path-based routing, WAF of WebSocket-terminatie vereisen, profiteren van de functies van ALB en App Mesh. Een andere fout is het niet rekening houden met ENI/IP-limieten bij het schalen van EKS-nodes of ECS-taken in awsvpc-modus: raadpleeg altijd de tabel met EC2-instance types, ENI’s en IP’s per ENI, en gebruik prefix delegation of Cilium-overlays wanneer een hoge pod-dichtheid vereist is.

Monitoring en debugging vereisen meerdere bronnen: VPC Flow Logs en ENI-metrics om uitgaand/inkomend verkeer te zien, CloudWatch-metrics voor AWS Load Balancers (ActiveFlowCount, ProcessedBytes), en telemetrie op applicatieniveau van Envoy/App Mesh of de AWS X-Ray-agent. Voor Lambda en Fargate is het belangrijk te onthouden dat cold starts die verband houden met ENI-operaties kunnen worden beperkt door provisioned concurrency of door de toegangspatronen te herstructureren om VPC-endpoints en PrivateLink te gebruiken, zodat functies geen brede egress-toegang nodig hebben.

Praktijkprobleem: Gebruikersscenario

Bedrijfsnaam: Acme Payments Inc. Uitdaging: Acme Payments draait een gRPC-service op Amazon EKS die duizenden gelijktijdige TLS-verbindingen op TCP-poort 443 moet ondersteunen, mutual TLS (mTLS) moet gebruiken zodat het clientcertificaat wordt gevalideerd door de backend-service, en het EKS-cluster moet kunnen autoscalen via Cluster Autoscaler en HPA zonder de connectiviteit te verbreken of TLS-terminatie in de load balancer te vereisen.

Stapsgewijze aanpak:

Implementeer de service met TLS op pod-niveau en wederzijdse authenticatie in de applicatie of in een sidecar die de end-to-end TLS voor externe clients niet termineert. Sla server-/clientcertificaten op in AWS Secrets Manager en mount deze via de Kubernetes CSI secrets store, of gebruik een mechanisme voor certificaatdistributie dat werkt met de pod-levenscyclus.
Gebruik de AWS Load Balancer Controller om een Network Load Balancer te creëren door de Service te annoteren (service.beta.kubernetes.io/aws-load-balancer-type: "nlb") en het target type in te stellen op IP (service.beta.kubernetes.io/aws-load-balancer-target-type: "ip"). Maak vervolgens een TCP-listener op poort 443. Dit zorgt ervoor dat de NLB L4 passthrough uitvoert en TLS niet termineert.
Configureer de NLB-target group met protocol TCP en registreer pod-IP’s dynamisch (de Load Balancer Controller roept CreateTargetGroup en RegisterTargets aan). Zorg ervoor dat health checks zijn ingesteld op TCP of een aangepaste, op TCP gebaseerde health probe met een kort interval, zodat targets snel als ‘healthy’ worden gemarkeerd tijdens autoscaling (aws elbv2 create-target-group --protocol TCP --port 443 --target-type ip; aws elbv2 create-listener --protocol TCP --port 443 ...).
Optimaliseer de Amazon VPC CNI om een hoge pod-dichtheid te ondersteunen en ENI-churn te verminderen: schakel prefix delegation in indien ondersteund (stel ENABLE_PREFIX_DELEGATION=true in de aws-node ConfigMap), configureer WARM_IP_TARGET om reserve-adressen te behouden, en monitor aws-node-metrics (logs van de kube-system daemonset en aangepaste CloudWatch-metrics). Als IP-limieten op node-niveau een probleem vormen, overweeg dan Cilium met eBPF voor een hogere pod-dichtheid en minder ENI-operaties.
Schaal het cluster veilig: zorg ervoor dat Cluster Autoscaler de juiste node group-tags en IAM-permissies heeft, stel PodDisruptionBudgets in, en verifieer dat de health checks van de target group en NLB connection draining zijn geconfigureerd om te voorkomen dat langdurige gRPC-verbindingen worden verbroken tijdens het terugschalen.
Beveilig certificaatsrotatie en -vertrouwen: automatiseer certificaatsrotatie met ACM Private CA of Secrets Manager en zorg ervoor dat pods bijgewerkte trust bundles ophalen zonder dat herconfiguratie van de NLB nodig is. Gebruik Kubernetes readiness/liveness probes die de gereedheid van de mTLS-handshake weerspiegelen.

AWS-redenering: Een Network Load Balancer in IP target-modus behoudt TLS tot aan de pod (echte end-to-end encryptie) en ondersteunt miljoenen persistente TCP-verbindingen, wat het geschikt maakt voor duizenden gelijktijdige gRPC-sessies. Het direct registreren van pod-IP’s vermijdt de complexiteit van hostPort- of instance target-registratie per node en werkt naadloos samen met Cluster Autoscaler/HPA, omdat de AWS Load Balancer Controller pod-IP’s registreert en deregistreert naarmate pods schalen. Het optimaliseren van de VPC CNI of het adopteren van een op eBPF gebaseerde data plane voorkomt IP-uitputting en vermindert de latency van het koppelen/ontkoppelen van ENI’s, wat essentieel is voor snelle autoscaling en workloads met veel verbindingen. Het opslaan en leveren van mTLS-artefacten via Secrets Manager of een CSI-provider maakt de levenscyclus van certificaten beheersbaar zonder de load balancer aan te hoeven passen.

← Automatisering · Alle domeinen

Oefen deze vragen → · Getimede oefening op ExamRoll.io →