Amazon ANS-C01: Netzwerk-Performance und Monitoring — 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.

Erweitertes Netzwerk und Low-Latency-Fabric

Erweitertes Netzwerk (Enhanced Networking) in AWS ist eine Reihe von Funktionen auf Betriebssystem- und Hypervisor-Ebene, die die Anzahl der Pakete pro Sekunde (Packets-per-Second) erheblich erhöhen, die Latenz und den CPU-Overhead reduzieren und einen höheren Durchsatz pro virtueller Schnittstelle ermöglichen. Die primären Technologien sind der Elastic Network Adapter (ENA), der SR-IOV-basiertes Hochleistungsnetzwerk für die meisten modernen EC2-Instanzfamilien bereitstellt, und der Elastic Fabric Adapter (EFA), ein OS-Bypass-RDMA-ähnliches Gerät, das für HPC und eng gekoppelte MPI/libfabric-Workloads entwickelt wurde. Um ENA zu aktivieren, überprüfen Sie, ob der Instanztyp ENA unterstützt und das Linux-AMI den ENA-Treiber enthält. Programmgesteuert können Sie es bei Bedarf mit EC2-API-Aufrufen wie RunInstances mit InterfaceType=efa aktivieren oder abfragen, oder ModifyInstanceAttribute für die ENA-Unterstützung verwenden. EFA wird angehängt, indem eine Netzwerkschnittstelle mit InterfaceType=efa (aws ec2 create-network-interface --interface-type efa) erstellt wird oder indem Instanzen mit einer EFA-fähigen Netzwerkschnittstelle gestartet werden. Die Instanz muss einen unterstützten Kernel und das libfabric/efa-Kernelmodul ausführen und sollte typischerweise in einer Cluster-Platzierungsgruppe platziert werden, um die niedrigste Intra-Host-Latenz und die höchste Bisection-Bandbreite zu erzielen.

Platzierungsgruppen (Placement Groups) beeinflussen die Leistung, indem sie die Platzierung von Instanzen innerhalb der zugrunde liegenden Netzwerk-Fabric steuern. Eine Cluster-Platzierungsgruppe platziert Instanzen bevorzugt auf einem einzigen Rack oder in einer Netzwerkdomäne mit geringer Latenz, um maximale Ost-West-Bandbreite und konsistente Latenz zu ermöglichen – dies ist für viele EFA-Anwendungsfälle erforderlich. Eine Spread-Platzierungsgruppe erzwingt eine Verteilung auf Host-Ebene, um korrelierte Ausfälle zu vermeiden, verbessert jedoch nicht die Latenz. Bei Szenarien mit hohem, stoßweisem Durchsatz (bursty) definieren die Instanzfamilie und die Anzahl der vCPUs die grundlegenden Netzwerkbandbreiten-Kontingente. Beispielsweise werben bestimmte Instanzgrößen mit bis zu 25 Gbit/s oder 100 Gbit/s, aber die Paketverarbeitung und die TCP-Stacks können ohne ENA/EFA zu Engpässen werden. Wenn Sie für Tausende von gleichzeitigen TCP-Verbindungen (z. B. gRPC über TLS) architekturieren, wählen Sie Instanztypen mit hoher Kapazität für gleichzeitige Verbindungen, aktivieren Sie ENA und bevorzugen Sie NLB / target-type=ip für die direkte Pod-Adressierung beim Betrieb in EKS, um Engpässe am Node-Port zu vermeiden.

Schlüsseldienste und Konfiguration für Beobachtbarkeit und Durchsetzung

Die Überwachung des Netzwerkzustands und die Diagnose von Engpässen stützen sich auf eine Kombination aus VPC Flow Logs, CloudWatch-Metriken, Traffic Mirroring und den Reachability/Access Analyzern. VPC Flow Logs liefern Metadaten pro Flow (Quell-/Ziel-IP, Ports, Pakete, Bytes, Aktion), die Sie an CloudWatch Logs oder S3 senden und mit CloudWatch Logs Insights abfragen können, um Präfixe mit hohem Volumen oder „Top-Talker“ zu finden. Für die Live-Inspektion auf Paketebene können Sie mit Traffic Mirroring ein Spiegelungsziel (Mirror Target) und einen Filter erstellen und dann Sitzungen (aws ec2 create-traffic-mirror-target, aws ec2 create-traffic-mirror-session) einrichten, um den Datenverkehr von ENIs zu einer Inspektions-Appliance, die in EC2 läuft, oder zu AWS Network Packet Broker-Partnern zu kopieren.

CloudWatch stellt die relevanten Metriken für verschiedene Ebenen bereit: EC2-Instanzmetriken wie NetworkIn/NetworkOut und NetworkPacketsIn/NetworkPacketsOut, Application Load Balancer-Metriken unter AWS/ApplicationELB wie RequestCount, ActiveConnectionCount und ClientTLSNegotiationErrorCount, Network Load Balancer-Metriken unter AWS/NetworkELB wie ProcessedBytes und NewFlowCount sowie AWS/DirectConnect-Metriken für die virtuelle Schnittstelle BytesIn/BytesOut. Verwenden Sie CloudWatch Alarms und Contributor Insights für Flow-Logs, um sättigende Datenflüsse (saturating flows) zu erkennen. Zur Pfad- und Konfigurationsvalidierung ermöglicht der Reachability Analyzer (über die EC2-API StartNetworkInsightsAnalysis / CreateNetworkInsightsPath), End-to-End-Paketpfade durch Routing-Tabellen, NACLs, Sicherheitsgruppen und VPN/Direct Connect-Anhänge zu modellieren und zu testen, während der Network Access Analyzer hilft, unbeabsichtigte Netzwerkzugriffspfade über Ihre VPCs und AWS Organizations hinweg zu erkennen.

Entwurfsmuster und Kompromisse bei Load Balancing und sicherem Zugriff

Wenn Sie echtes End-to-End-TLS mit gegenseitigem TLS (mTLS) am Backend benötigen und gleichzeitig Tausende von gRPC-Verbindungen unterstützen müssen, ist ein Network Load Balancer im TCP-Modus das bevorzugte Muster. Ein NLB behält standardmäßig die Quell-IP des Clients bei und kann vom AWS Load Balancer Controller für EKS-Services mithilfe von Annotationen wie service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip” und target-type=ip erstellt werden, um den Datenverkehr direkt an die Pod-IPs zu senden. Die Verwendung von TCP-Passthrough auf Port 443 bedeutet, dass der Backend-Pod das gegenseitige TLS (Client- und Server-Zertifikatsüberprüfung) terminiert. Der Datenverkehr wird also niemals im Load Balancer entschlüsselt, wodurch die beidseitige Authentifizierung erhalten bleibt. Dieses Muster skaliert gut mit der Anzahl der Verbindungen, da der NLB für Millionen gleichzeitiger Verbindungen und einen geringen Overhead pro Verbindung ausgelegt ist.

Für Architekturen, die eine TLS-Terminierung am Load Balancer und pfadbasiertes Routing zu mehreren Zielgruppen (Target Groups) erfordern, ist der Application Load Balancer die richtige Wahl, da er HTTP/2 und gRPC, pfadbasiertes Routing und hostbasierte Regeln unterstützt. Um eine genaue Protokollierung der Client-IP zu gewährleisten, wenn der ALB die TLS-Verbindung terminiert, stellen Sie sicher, dass die Backend-Anwendung die X-Forwarded-For-Header (der ALB fügt sie automatisch ein) parst, oder verwenden Sie das PROXY-Protokoll mit einem NLB, wenn Sie die Quell-IP auf der TCP-Ebene beibehalten müssen. Wenn Sie Global Accelerator verwenden, um statische Anycast-Frontend-IPs bereitzustellen, und verhindern möchten, dass Clients den Accelerator umgehen und direkt auf die ALB-URL zugreifen, schränken Sie die Security Group des ALB so ein, dass sie eingehenden Datenverkehr nur von den statischen IPs des Accelerators (den beiden dem Accelerator zugewiesenen statischen Adressen) akzeptiert, sodass ein direkter Zugriff aus dem Internet verweigert wird.

Für kontoübergreifende Shared Services mit strengen Kontrollen pro Geschäftsbereich und hoher Skalierbarkeit ist AWS PrivateLink (VPC Endpoint Services, die auf internen NLBs basieren) oft das sicherste und skalierbarste Muster. Die Shared-Services-VPC veröffentlicht Dienste über Network Load Balancer-Endpunkte (aws ec2 create-network-interface mit Zielgruppen) und stellt sie als VPC Endpoint Service bereit. Consumer-Konten erstellen Interface-Endpunkte in ihren VPCs, die sich mit dem NLB des Providers verbinden. Der Provider steuert den Zugriff über Endpunkt-Richtlinien (Endpoint Policies) und Security Groups, und der Datenverkehr durchläuft niemals eine zentrale Routing-Ebene. Ein Transit Gateway eignet sich, wenn Sie vollständige Routing-Transparenz und transitive Konnektivität benötigen, aber es zentralisiert das Routing und ist für die Zugriffskontrolle pro Dienst weniger granular als PrivateLink.

Häufige Fallstricke und Entscheidungskriterien

Ein häufiger Fehler ist die Annahme, dass die angegebene Bandbreite einer Instanz unbegrenzt ist; Instanzfamilien und -größen setzen harte Netzwerkgrenzen, und bei der Skalierung sollte die Aufteilung auf mehrere ENIs und die Platzierung in Cluster Placement Groups für eine konsistente Leistung berücksichtigt werden. Ein weiterer Fallstrick ist, sich ausschließlich auf CloudWatch NetworkIn/NetworkOut zu verlassen, ohne VPC Flow Logs zu korrelieren, um den Datenverkehr einer bestimmten VPC, einem Subnetz oder einer Geschäftseinheit zuzuordnen; Flow Logs und Traffic Mirroring sind notwendig, um zu isolieren, welche virtuelle Schnittstelle oder Anwendung die Sättigung von Direct Connect verursacht. Vermeiden Sie auch die TLS-Terminierung am ALB, wenn gegenseitiges TLS (mTLS) Ende-zu-Ende erforderlich ist – wenn die Richtlinie vorschreibt, dass das Backend das Client-Zertifikat sehen muss, wählen Sie TLS-Passthrough mit einem NLB oder führen Sie TLS-Bridging mit ordnungsgemäßer Zertifikatsvalidierung durch, aber seien Sie explizit darin, wo das Vertrauen hergestellt wird.

Bei der Diagnose von intermittierender Sättigung auf gemeinsam genutzten physischen Verbindungen wie Direct Connect sollten Metriken über verschiedene Schichten hinweg korreliert werden: AWS/DirectConnect-Metriken für virtuelle Schnittstellen, VPC Flow Logs für Byte-Zählungen pro Subnetz/ENI und EC2 Network*-Metriken für das Verhalten auf Instanzebene. Verwenden Sie den Reachability Analyzer, um zu überprüfen, ob asymmetrisches Routing oder eine fehlerhafte Routenverteilung Probleme mit dem Rückweg verursacht, und verwenden Sie Traffic Mirroring, um Paket-Dumps für eine tiefgehende Protokollinspektion zu erfassen.

Praktisches Problem: Anwendungsfallszenario

AcmeIoT steht vor dem Problem, dass Verkaufsautomaten weltweit über gRPC mit gegenseitigem TLS eine Verbindung zu einem auf EKS gehosteten Backend herstellen müssen. Die Anzahl der Verbindungen muss in die Tausende gehen, der Dienst muss Ende-zu-Ende verschlüsselt bleiben und die Backend-Pods skalieren dynamisch mit dem Cluster Autoscaler und HPA.

Erstellen Sie einen AWS LoadBalancer vom Typ Network Load Balancer für den Kubernetes Service. Verwenden Sie dazu den AWS Load Balancer Controller und Annotationen, um den NLB und target-type=ip anzugeben (

undefined

und

undefined

). Konfigurieren Sie einen TCP-Listener auf Port 443, sodass der NLB reines TCP-Passthrough durchführt; konfigurieren Sie keine TLS-Zertifikate auf dem NLB.

Implementieren Sie die Terminierung und Validierung von gegenseitigem TLS in den Anwendungs-Pods. Jeder Pod sollte ein Serverzertifikat präsentieren und Client-Zertifikate validieren, wobei ein Prozess zur Rotation von kurzlebigen Zertifikaten verwendet wird, der mit AWS Secrets Manager oder SSM Parameter Store integriert ist. Stellen Sie sicher, dass die Pod-IPs erreichbar sind, indem Sie target-type ip verwenden und dass die Health Checks als TCP- oder gRPC-Health-Checks auf der Zielgruppe konfiguriert sind.
Stellen Sie eine hohe Verbindungsskalierung sicher, indem Sie Instanzen mit ENA-Unterstützung und ausreichender Netzwerkbandbreite auswählen, ENA aktivieren (bestätigen Sie dies mit dem ENA-Treiber im AMI und verwenden Sie

undefined

, um ena-support bei Bedarf zu aktivieren) und Pods über mehrere Nodes verteilen, wobei der Cluster Autoscaler die Nodes basierend auf den Pod-Anforderungen skaliert. Verwenden Sie Placement Groups für eng gekoppelte Cluster, die eine konsistente Latenz benötigen, und stellen Sie eine ausreichende Anzahl von Nodes über mehrere AZs hinweg bereit.

Überwachen und validieren Sie mithilfe von CloudWatch und VPC Flow Logs. Erstellen Sie CloudWatch-Metriken und Alarme für ActiveFlowCount/NewFlowCount des NLB und NetworkIn/Out der EKS-Worker-EC2-Instanzen. Verwenden Sie VPC Flow Logs, um Top-Talker zu identifizieren, und den Reachability Analyzer (

undefined

), um Routing-Pfade während Autoscaling-Ereignissen zu validieren. Wenn Sie ein Debugging auf Paketebene benötigen, erstellen Sie Traffic-Mirroring-Sitzungen zu einer Inspektionsinstanz.

Begründung seitens AWS: Ein Network Load Balancer im TCP-Modus erhält die Quell-IP-Adresse, unterstützt eine massive Anzahl gleichzeitiger Verbindungen und ermöglicht Ende-zu-Ende-TLS, da er TLS nicht terminiert. Der target-type ip mit dem AWS Load Balancer Controller integriert sich in die Autoscaling-Semantik von EKS, sodass neue Pod-IPs dynamisch als Ziele registriert werden. ENA und die richtige Instanzgröße bieten die erforderliche Netzwerkkapazität, um Tausende von gleichzeitigen TLS-Verbindungen ohne CPU-Überlastung des Hosts zu bewältigen. Die Kombination aus CloudWatch, VPC Flow Logs, Reachability Analyzer und Traffic Mirroring bietet die notwendige Observability, um Sättigungs- oder Routing-Probleme zu erkennen und zu beheben.

← Content Delivery und Edge-Networking · Alle Domänen · Automatisierung →

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