Amazon ANS-C01: Container- und Serverless-Networking — Lernleitfaden

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

Teil des AWS Advanced Networking Specialty ANS-C01 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

EKS-Networking (CNI, Pod-Networking)

Das Pod-Networking in Amazon EKS wird hauptsächlich über das Amazon VPC CNI-Plugin (amazon-vpc-cni-k8s) realisiert, das jedem Pod eine IP-Adresse aus der VPC zuweist und den Pod-Traffic direkt im VPC-Netzwerk platziert. Dieses Design ermöglicht eine vorhersagbare Sicherheitssteuerung auf VPC-Ebene (Sicherheitsgruppen, NACLs) und Routing mit geringer Latenz, erfordert jedoch eine sorgfältige Planung der IP-Adress- und ENI-Kapazität, da die Anzahl der sekundären IPv4-Adressen pro ENI und die Anzahl der ENIs pro Instanztyp hardwarelimitiert sind. Das aws-node-DaemonSet steuert die IP-Zuweisung und die Attach/Detach-Operationen; seine ConfigMap wird mit kubectl bearbeitet, um das Verhalten anzupassen (zum Beispiel durch Setzen von WARM_IP_TARGET, WARM_ENI_TARGET oder ENABLE_PREFIX_DELEGATION). Prefix-Delegation und Pod-ENI-Modi reduzieren die Erschöpfung von IP-Adressen pro Knoten, indem sie es einem Knoten ermöglichen, ganze /28-Präfixe einem ENI zuzuweisen (ENABLE_PREFIX_DELEGATION=true) oder indem jedem Pod ein dediziertes ENI zugewiesen wird (nützlich für eine hochsichere Isolation).

Alternativen zum Amazon VPC CNI wie Cilium (eBPF) oder Calico können andere Kompromisse bieten. Cilium kann kube-proxy ersetzen und eine hochleistungsfähige L3/L4-Weiterleitung mittels eBPF implementieren, eine transparente Verschlüsselung zwischen den Knoten ermöglichen (WireGuard oder IPsec) und den IP-Adressdruck auf Knotenebene durch Overlay- oder Masquerading-Ansätze reduzieren. Mit Cilium integrieren Sie weiterhin das VPC-Routing für Egress- und Ingress-Traffic, vermeiden aber häufige ENI-Attach/Detach-Operationen, was bei hohen Pod-Churn-Raten wichtig ist. Bei sehr hohen Verbindungszahlen und striktem L7-Verhalten sollten Sie auch das Tuning des kube-proxy-Modus (IPVS) und die Kernel-Einstellungen des Knotens berücksichtigen: Passen Sie conntrack_max, tcp_tw_recycle/tcp_tw_reuse und ip_local_port_range an und stellen Sie diese über kubelet- oder DaemonSet-Init-Skripte bereit, um die Erschöpfung von ephemeren Ports bei Tausenden von gleichzeitigen, langlebigen gRPC-Verbindungen zu vermeiden.

ECS-Netzwerkmodi und Lambda-VPC-Integration

Das Task-Networking von ECS hat drei primäre Modi: bridge, host und awsvpc. Der awsvpc-Modus ist am ehesten mit dem Pod-Networking von Kubernetes vergleichbar, da er an jeden Task (oder jede Task-Gruppe) ein ENI anfügt und dem Task direkt eine private IP und Sicherheitsgruppen zuordnet. Konfigurieren Sie awsvpc, indem Sie awsvpcConfiguration mit subnets und securityGroups in den API-Aufrufen RunTask oder CreateService angeben. Fargate erzwingt den awsvpc-Modus und bietet dadurch eine Netzwerkisolation auf Task-Ebene sowie eine Integration mit AWS Cloud Map für die Service Discovery. Verwenden Sie awsvpc, wenn Sie eine auf Sicherheitsgruppen basierende Filterung des Traffics pro Task benötigen oder wenn Sie standardmäßiges VPC-Routing und Metriken nutzen müssen.

Lambda-Funktionen, die VPC-Zugriff benötigen, werden über ENIs in den für die Funktion konfigurierten Subnetzen und Sicherheitsgruppen an die VPC angebunden. Diese ENIs werden von der Lambda-Control-Plane erstellt und verwaltet, aber die Bereitstellung der ENIs kann die Kaltstartlatenz erhöhen und hat in der Vergangenheit eine schnelle Skalierung eingeschränkt, es sei denn, dies wurde durch Provisioned Concurrency oder durch die Verwendung von VPC-Endpunkten (AWS PrivateLink) und eine sorgfältig konzipierte Subnetzarchitektur abgemildert. Wenn Sie viele Lambda-Funktionen in einer VPC platzieren, stellen Sie sicher, dass die Subnetze über verfügbare IPs verfügen, verwenden Sie bei Bedarf ein NAT Gateway oder NAT-Instanzen für den Egress-Traffic und bevorzugen Sie VPC-Endpunkte (com.amazonaws.*-Endpunkte über AWS::EC2::VPCEndpoint), um das Routing des Egress-Traffics über das Internet nach Möglichkeit zu vermeiden. Überwachen Sie das Anfügen und Trennen von ENIs mit CloudWatch Logs und VPC Flow Logs, um das Skalierungsverhalten zu beobachten und Drosselungen im Zusammenhang mit der Gleichzeitigkeit (Concurrency) zu beheben.

App Mesh und Service Discovery

AWS App Mesh verwendet Envoy-Sidecars als Data Plane und bietet Observability auf L3–L7, Traffic Shaping, Wiederholungsversuche (Retries) und Kontrollen für die TLS-Origination/Termination. Definieren Sie Meshes, Virtual Nodes und Virtual Services über die App Mesh API (CreateMesh, CreateVirtualNode, CreateVirtualService) oder den App Mesh Controller für Kubernetes. App Mesh unterstützt mTLS durch die Konfiguration des TLS-Blocks eines VirtualNode-Listeners mit clientPolicy und einer Zertifizierungsstelle (Certificate Authority), und Sie können es für die Zertifikatsverteilung mit AWS Certificate Manager (ACM) oder SDS integrieren. Beachten Sie jedoch, dass App-Mesh-Sidecars den Traffic designbedingt terminieren und neu verschlüsseln; wenn eine Anforderung vorschreibt, dass der Anwendungs-Traffic zwischen dem Client und dem Anwendungs-Pod durchgehend verschlüsselt bleiben muss (keine Entschlüsselung im Netzwerk-Proxy), müssen Sie sicherstellen, dass TLS nur am Pod terminiert wird und eine Terminierung am Mesh-Ingress oder Load Balancer vermeiden.

Service Discovery wird üblicherweise mit Kubernetes Services und CoreDNS für EKS, mit Cloud Map (CreateService, RegisterInstance) für plattformübergreifende Szenarien und mit privaten gehosteten Zonen von Route 53 für DNS-basierte Lookups realisiert. AWS Cloud Map lässt sich direkt in ECS und App Mesh integrieren und ermöglicht SRV- oder A-Records sowie API-gesteuerte Health Checks. Kombinieren Sie in dynamischen Umgebungen, in denen Instanzen schnell skalieren, kurze DNS-TTLs mit Cloud-Map-Health-Checks, um veraltete Auflösungen (stale resolution) zu vermeiden; wenn Sie sofortige Konsistenz benötigen, verwenden Sie eine Service-Mesh-Control-Plane-API, um Endpunkte abzurufen, anstatt sich auf das DNS-Caching zu verlassen.

Design-Muster und Kompromisse

Beim Entwurf für groß angelegtes gRPC über TLS mit mTLS müssen Sie entscheiden, wo die TLS-Terminierung stattfindet. Die Terminierung am Load Balancer (ALB) ermöglicht das Auslagern von Zertifikaten an ACM und vereinfacht die Zertifikatsrotation, unterbricht jedoch die Ende-zu-Ende-Verschlüsselung und kann kein Mutual TLS für Backend-Pods bereitstellen, es sei denn, das Backend stellt TLS mit den weitergeleiteten Client-Zertifikatsinformationen erneut her. Für echtes Ende-zu-Ende-mTLS, bei dem Anwendungs-Endpunkte Clients direkt authentifizieren, verwenden Sie ein L4-Passthrough-Gateway wie einen Network Load Balancer und lassen Sie den Pod/die Anwendung TLS/mTLS handhaben. Kombinieren Sie den NLB-Zieltyp ip mit der AWS Load Balancer Controller-Annotation service.beta.kubernetes.io/aws-load-balancer-target-type: "ip", um Pod-IPs direkt zu registrieren. Dieses Muster skaliert gut, da der NLB für Millionen von Verbindungen ausgelegt ist und langlebige TCP/gRPC-Sitzungen unterstützt, ohne TLS zu terminieren.

Für Ingress und pfadbasiertes Routing mit HTTPS-Terminierung ist der Application Load Balancer besser geeignet, da er Host-/Pfadregeln, Weiterleitungen und die Integration mit WAF unterstützt. Um Client-IPs zu erhalten, wenn der ALB TLS terminiert, verlassen Sie sich auf X-Forwarded-For-Header. Backend-Webserver müssen X-Forwarded-For verarbeiten und protokollieren, und Sie sollten die ALB-Zugriffsprotokolle zur Überprüfung aktivieren. Wenn Sie die tatsächliche Client-Socket-Adresse auf der Server-Ebene benötigen (für Legacy-Software), verwenden Sie einen NLB mit proxy protocol v2 und stellen Sie sicher, dass die Backend-Services das Proxy-Protokoll unterstützen.

Die Service-Konnektivität über mehrere AWS-Konten und VPCs hinweg skaliert je nach Muster unterschiedlich. VPC Peering ist einfach, hat aber einen Management-Aufwand von N^2. Transit Gateway zentralisiert das Routing und skaliert besser für viele VPCs mit der Trennung von Routing-Tabellen. AWS PrivateLink (Interface VPC Endpoints) bietet das granularste, pro-Service und identitätsbasierte Zugriffsmodell, da Sie einen Endpunkt-Service über einen NLB bereitstellen und die Konsumenten Interface Endpoints in ihren VPCs erstellen. Für kontoübergreifende Shared Services mit strenger Zugriffskontrolle und skalierbarem Onboarding ist PrivateLink zu bevorzugen, da es das Routing isoliert (keine Änderungen an den Routing-Tabellen in den Konsumenten-VPCs) und Security Groups für feingranulare Kontrollen verwendet.

Häufige Fallstricke und Entscheidungskriterien

Ein wiederkehrender Fallstrick ist die Annahme, dass dasselbe Netzwerkmodell für alle Workloads geeignet ist. Zustandsbehaftete oder langlebige Verbindungsworkloads (gRPC, Datenbanken) bevorzugen L4-Passthrough (NLB) mit TLS-Terminierung auf Pod-Ebene oder hostPort/hostNetwork-Muster, um durch Proxys verursachte Latenz zu vermeiden; HTTP-Microservices, die pfadbasiertes Routing, WAF oder WebSocket-Terminierung benötigen, profitieren von den Funktionen von ALB und App Mesh. Ein weiterer Fehler ist die Nichtberücksichtigung von ENI/IP-Limits bei der Skalierung von EKS-Knoten oder ECS-Tasks im awsvpc-Modus: Konsultieren Sie immer die Tabelle für ENIs und IPs pro ENI des EC2-Instanztyps und verwenden Sie Prefix Delegation oder Cilium-Overlays, wenn Sie eine hohe Pod-Dichte benötigen.

Überwachung und Debugging erfordern mehrere Quellen: VPC Flow Logs und ENI-Metriken, um ausgehenden/eingehenden Datenverkehr zu sehen, CloudWatch-Metriken für AWS Load Balancers (ActiveFlowCount, ProcessedBytes) und Telemetrie auf Anwendungsebene von Envoy/App Mesh oder dem AWS X-Ray-Agenten. Denken Sie bei Lambda und Fargate daran, dass Kaltstarts, die mit ENI-Operationen verbunden sind, durch Provisioned Concurrency oder durch eine Neugestaltung der Zugriffsmuster zur Nutzung von VPC-Endpunkten und PrivateLink gemindert werden können, sodass Funktionen keinen breiten ausgehenden Zugriff benötigen.

Praktisches Problem: Anwendungsfallszenario

Name des Unternehmens: Acme Payments Inc. Herausforderung: Acme Payments betreibt einen gRPC-Service auf Amazon EKS, der Tausende von gleichzeitigen TLS-Verbindungen auf TCP-Port 443 unterstützen, Mutual TLS (mTLS) verwenden muss, damit das Client-Zertifikat vom Backend-Service validiert wird, und dem EKS-Cluster ermöglichen muss, über Cluster Autoscaler und HPA automatisch zu skalieren, ohne die Konnektivität zu unterbrechen oder eine TLS-Terminierung im Load Balancer zu erfordern.

Nummerierter Ansatz:

Stellen Sie den Service mit TLS auf Pod-Ebene und gegenseitiger Authentifizierung bereit, die in der Anwendung oder in einem Sidecar implementiert ist, das End-to-End-TLS für externe Clients nicht terminiert. Speichern Sie Server-/Client-Zertifikate im AWS Secrets Manager und binden Sie sie über den Kubernetes CSI Secrets Store ein oder verwenden Sie einen Zertifikatsverteilungsmechanismus, der mit dem Pod-Lebenszyklus funktioniert.
Verwenden Sie den AWS Load Balancer Controller, um einen Network Load Balancer zu erstellen, indem Sie den Service annotieren (service.beta.kubernetes.io/aws-load-balancer-type: “nlb”) und den Zieltyp auf IP setzen (service.beta.kubernetes.io/aws-load-balancer-target-type: “ip”). Erstellen Sie dann einen TCP-Listener auf Port 443. Dies stellt sicher, dass der NLB ein L4-Passthrough durchführt und TLS nicht terminiert.
Konfigurieren Sie die NLB-Zielgruppe mit dem Protokoll TCP und registrieren Sie Pod-IPs dynamisch (der Load Balancer Controller ruft CreateTargetGroup und RegisterTargets auf). Stellen Sie sicher, dass die Zustandsprüfungen (Health Checks) auf TCP oder eine benutzerdefinierte TCP-basierte Zustandsprüfung in einem kurzen Intervall eingestellt sind, damit Ziele während der automatischen Skalierung schnell als fehlerfrei markiert werden (aws elbv2 create-target-group –protocol TCP –port 443 –target-type ip; aws elbv2 create-listener –protocol TCP –port 443 …).
Optimieren Sie das Amazon VPC CNI, um eine hohe Pod-Dichte zu unterstützen und den ENI-Churn zu reduzieren: Aktivieren Sie Prefix Delegation, falls unterstützt (setzen Sie ENABLE_PREFIX_DELEGATION=true in der aws-node ConfigMap), konfigurieren Sie WARM_IP_TARGET, um Ersatzadressen vorzuhalten, und überwachen Sie die aws-node-Metriken (kube-system DaemonSet-Logs und benutzerdefinierte CloudWatch-Metriken). Wenn IP-Limits auf Knotenebene ein Problem darstellen, ziehen Sie Cilium mit eBPF für eine höhere Pod-Dichte und reduzierte ENI-Operationen in Betracht.
Skalieren Sie den Cluster sicher: Stellen Sie sicher, dass der Cluster Autoscaler über die richtigen Knotengruppen-Tags und IAM-Berechtigungen verfügt, setzen Sie PodDisruptionBudgets und überprüfen Sie, ob die Zustandsprüfungen der Zielgruppe und das Connection Draining des NLB so konfiguriert sind, dass langlebige gRPC-Verbindungen während des Herunterskalierens nicht unterbrochen werden.
Sichern Sie die Zertifikatsrotation und das Vertrauen: Automatisieren Sie die Zertifikatsrotation mit ACM Private CA oder Secrets Manager und stellen Sie sicher, dass Pods aktualisierte Trust Bundles abrufen, ohne dass eine Neukonfiguration des NLB erforderlich ist. Verwenden Sie Kubernetes Readiness/Liveness Probes, die die Bereitschaft des mTLS-Handshakes widerspiegeln.

AWS-Begründung: Ein Network Load Balancer im IP-Zielmodus erhält TLS bis zum Pod bei (echte Ende-zu-Ende-Verschlüsselung) und unterstützt Millionen von persistenten TCP-Verbindungen, was ihn für Tausende von gleichzeitigen gRPC-Sitzungen geeignet macht. Die direkte Registrierung von Pod-IPs vermeidet die Komplexität der Registrierung von hostPort- oder Instanz-Zielen pro Knoten und funktioniert reibungslos mit Cluster Autoscaler/HPA, da der AWS Load Balancer Controller die Pod-IPs registriert und deregistriert, wenn die Pods skalieren. Die Optimierung des VPC CNI oder die Einführung einer eBPF-basierten Datenebene verhindert die Erschöpfung von IP-Adressen und reduziert die Latenz beim Anhängen/Ablösen von ENIs, was für eine schnelle automatische Skalierung und Workloads mit vielen Verbindungen unerlässlich ist. Die Speicherung und Bereitstellung von mTLS-Artefakten über Secrets Manager oder einen CSI-Provider macht den Lebenszyklus von Zertifikaten handhabbar, ohne den Load Balancer anfassen zu müssen.

← Automatisierung · Alle Domänen

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →