Amazon ANS-C01: VPC-Design und fortgeschrittenes Networking — Lernleitfaden
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.
Grundlagen der VPC-Architektur und Subnetzaufteilung
Eine VPC ist die grundlegende Netzwerkgrenze in AWS, und die Gestaltung Ihrer CIDR-Zuweisungen definiert alles, was darauf aufbaut. Planen Sie CIDR-Blöcke unter Berücksichtigung von zukünftigem Wachstum und kontoübergreifender Konnektivität: Weisen Sie große, nicht überlappende Adressräume pro Konto/Region zu (z. B. ein /16 pro Umgebung) und unterteilen Sie diese in /20–/24-Subnetze, um Workloads nach Funktion und Verfügbarkeitszone zu isolieren. Denken Sie daran, dass EKS und andere Container-Plattformen IP-Adressen für Pod-ENIs oder sekundäre IPs verbrauchen; das AWS VPC CNI weist Pod-IPs aus dem VPC-Subnetz zu, und die ENI/IP-Limits pro Instanz (DescribeInstanceTypes) schränken die maximale Pod-Dichte ein. Für die Einführung von IPv6 bevorzugen Sie ein Dual-Stack-Design, um öffentlich zugängliche Dienste auf IPv6 auszulagern, während IPv4 für die Integration mit Altsystemen beibehalten wird. Verknüpfen Sie einen von Amazon bereitgestellten IPv6-CIDR-Block mit dem API-Aufruf aws ec2 associate-vpc-cidr-block --vpc-id <vpc> --amazon-provided-ipv6-cidr-block und aktivieren Sie die IPv6-Zuweisung auf Subnetzebene mit create-subnet und der Option --ipv6-cidr-block. Planen Sie NAT-Ressourcen für den IPv4-Egress-Verkehr und verwenden Sie für IPv6 ein Egress-Only Internet Gateway, das mit CreateEgressOnlyInternetGateway erstellt und an die VPC angehängt wird.
Routing-Tabellen und die Platzierung von Subnetzen sind die Mittel, um Topologie und Ausfallsicherheit durchzusetzen. Erstellen Sie separate Routing-Tabellen für jeden Subnetz-Zweck (öffentlich, privat mit NAT, privat mit Direct Connect und isoliert) mithilfe von CreateRouteTable und CreateRoute. Verwenden Sie mehrere NAT Gateways (oder NAT-Instanzen mit Autoscaling) über mehrere AZs hinweg, um den Ausfall des Egress-Verkehrs in einer einzelnen AZ zu vermeiden. Seien Sie explizit bei der Propagierung von Routen, wenn Sie ein Transit Gateway (CreateTransitGateway, CreateTransitGatewayRouteTable) verwenden, damit On-Premises-Präfixe nur dort eingefügt werden, wo sie vorgesehen sind. Für die Service Discovery innerhalb eines Accounts verwenden Sie private Hosted Zones von Route 53 und verknüpfen diese mit den VPCs, die die Einträge benötigen, um DNS-Leakage über Grenzen hinweg zu vermeiden.
Wichtige Dienste und Konfigurationsdetails
Für private Konnektivität gibt es drei dominante Konstrukte, die man verstehen muss: VPC Peering, AWS Transit Gateway und AWS PrivateLink (Interface-VPC-Endpunkte). VPC Peering (CreateVpcPeeringConnection, AcceptVpcPeeringConnection) ist eine einfache, kostengünstige Punkt-zu-Punkt-Verbindung, die Einträge in der Routing-Tabelle erfordert und kein transitives Routing unterstützt. Das Transit Gateway (CreateTransitGateway, CreateTransitGatewayVpcAttachment) ist der skalierbare Hub, der Tausende von VPCs, eine zentrale Routensteuerung und die Integration mit dem Direct Connect Gateway für hybride Konnektivität unterstützt. Verwenden Sie die Propagation von Routen (Route Propagation) und die Zuordnungen von Routing-Tabellen (Route Table Associations) im Transit Gateway, um den Ost-West-Verkehr zu steuern. PrivateLink (CreateVpcEndpointServiceConfiguration zur Registrierung eines NLB-gestützten Dienstes und CreateVpcEndpoint zur Erstellung von Interface-Endpunkten) stellt Dienste kontoübergreifend bereit, ohne eine VPC dem Routing auszusetzen. Dies bietet granulare, dienstspezifische Sicherheit und eine vereinfachte Steuerung der Sicherheitsgruppen. Es skaliert gut, da die Konsumenten Interface-Endpunkte erstellen und der Verkehr auf der Ebene der Netzwerkschnittstelle (NIC) verbleibt.
Load Balancing und die Erhaltung der Client-IP sind übliche Designentscheidungen, die korrekt umgesetzt werden müssen. Der Application Load Balancer (ALB) terminiert TLS, routet auf L7 (CreateLoadBalancer Typ application) und fügt X-Forwarded-For/X-Forwarded-Proto-Header ein, denen die Backends für die Protokollierung der Client-IP vertrauen müssen. Der Network Load Balancer (NLB) erhält die Quell-IPs für Zielgruppen (Target Groups) und unterstützt Millionen von Verbindungen. Für echtes TLS-Pass-Through zu den Backends verwenden Sie einen NLB mit einem TCP-Listener (CreateListener Protokoll TCP) und registrieren die Ziele anhand ihrer IP-Adresse, damit verschlüsselte Sitzungen die Pods oder Instanzen intakt erreichen. Für gRPC und sehr hohe Anzahlen an Verbindungen bevorzugen Sie einen NLB vor EKS mit dem Zieltyp ip und der AWS Load Balancer Controller Annotation service.beta.kubernetes.io/aws-load-balancer-type: "nlb-ip", um Pod-IPs direkt zu registrieren. Diese Kombination erhält die Quell-IP, unterstützt die mTLS-Terminierung am Pod und skaliert mit den Autoscalern.
VPC-Endpunkte eliminieren den Egress-Verkehr ins Internet für AWS-APIs und gängige Dienste. Gateway-Endpunkte für S3 und DynamoDB (CreateVpcEndpoint mit --service-name com.amazonaws.<region>.s3) fügen Routen zu einer Präfixliste des Endpunkts hinzu und sind kostenlos. Interface-Endpunkte (CreateVpcEndpoint mit --vpc-endpoint-type Interface) erstellen Elastic Network Interfaces mit privaten IPs und Sicherheitsgruppen. Sie werden stündlich und pro GB abgerechnet, ermöglichen aber eine Nutzung im Stil von PrivateLink und kontoübergreifenden Zugriff, wenn sie mit einem NLB-gestützten Dienst gekoppelt werden.
Entwurfsmuster und Kompromisse
Für einen zentralen, gemeinsam genutzten Dienst, der von vielen Geschäftsbereichen über verschiedene Konten hinweg genutzt wird, sind PrivateLink und Endpunktdienste das sicherste und skalierbarste Muster, wenn Sie Kontrolle und Isolierung pro Verbindung benötigen. Hosten Sie den Dienst hinter einem Network Load Balancer in der VPC für gemeinsam genutzte Dienste, erstellen Sie einen VPC-Endpunktdienst (CreateVpcEndpointServiceConfiguration) und lassen Sie die Konsumentenkonten Schnittstellenendpunkte erstellen, die Sie genehmigen. Dies vermeidet ein vollständiges Mesh und verhindert transitives Routing. Sicherheitsgruppen an den Schnittstellenendpunkten ermöglichen es Ihnen, einzuschränken, welche Konsumenten sich verbinden dürfen. Der Kompromiss sind die Kosten pro Endpunkt und ein gewisser Verwaltungsaufwand für die Annahme und Überprüfung von Endpunktverbindungen.
Transit Gateway eignet sich besonders, wenn Sie viele VPCs haben, die eine breite Konnektivität, eine zentrale Inspektion und einen einzigen Ort zur Ankündigung von On-Premise-Präfixen über Direct Connect benötigen (CreateTransitGatewayRoute, CreateTransitGatewayRouteTable). Verwenden Sie die Segmentierung von Routing-Tabellen und Propagationskontrollen, um unbeabsichtigte laterale Bewegungen zu vermeiden. Transit Gateway unterstützt die Priorisierung von Routen und die Zuordnung von Routing-Tabellen, sodass Sie den Produktionsverkehr von Netzwerken mit geringerer Vertrauenswürdigkeit isolieren können. Der Kompromiss besteht darin, dass Transit Gateway den Verkehr zentralisiert und Kosten für VPC-übergreifenden Verkehr verursachen kann, der andernfalls lokal wäre. Es verändert auch die Ausfall-Domänen und erfordert eine sorgfältige CIDR-Planung, um Adressüberschneidungen zu vermeiden.
Bei hybriden Architekturen mit begrenzter Wiederverwendung von CIDR-Blöcken sollten Sie die Kombination von Direct Connect mit Transit Gateway und Direct Connect Gateway (CreateDirectConnectGateway) in Betracht ziehen, um die Anzahl der virtuellen Schnittstellen zu reduzieren. Wenn Sie eine Bandbreitenisolierung pro Geschäftsbereich auf der gemeinsam genutzten physischen Verbindung benötigen, richten Sie mehrere private virtuelle Schnittstellen ein und überwachen Sie die CloudWatch-Metriken pro VIF (Metriknamen wie AWS/DX: BytesIn, BytesOut). Verwenden Sie zudem CloudWatch-Alarme auf VIF-Ebene. Um starke Verbraucher zu identifizieren, aktivieren Sie VPC Flow Logs (CreateFlowLogs) nach S3 oder CloudWatch Logs und analysieren Sie die Daten mit Athena oder CloudWatch Logs Insights. Für die Paketerfassung pro VM verwenden Sie Traffic Mirroring (CreateTrafficMirrorSession) für kurze Zeitfenster.
Die Einführung von IPv6 und Dual-Stack-Designs verringern die Abhängigkeit von NAT, senken die Kosten für den Durchsatz von NAT Gateways und vereinfachen die clientseitige Adressierung. Verwenden Sie den API-Aufruf aws ec2 associate-vpc-cidr-block, um ein von Amazon bereitgestelltes IPv6-Präfix zuzuweisen und Subnetze mit IPv6-CIDR-Blöcken zu erstellen. Beachten Sie, dass einige Dienste und Appliances von Drittanbietern möglicherweise nicht IPv6-fähig sind. Verwenden Sie Dual-Stack bei Load Balancern (CreateLoadBalancer mit IpAddressType dualstack), um sowohl IPv4- als auch IPv6-Clients zu unterstützen, während die Backend-Systeme auf IPv4 bleiben.
Häufige Fallstricke und Entscheidungskriterien
Die Vernachlässigung des IP-Adressverbrauchs durch Kubernetes-Pods ist eine häufige Ursache für Dienstunterbrechungen. Berücksichtigen Sie die Limits für ENIs und sekundäre IPs pro Instanztyp und verwenden Sie VPC-CNI-Einstellungen wie WARM_IP_TARGETS oder Prefix Delegation, um die IP-Verfügbarkeit zu verbessern. Die Nichtbeibehaltung von Client-IPs auf L7 ist eine weitere häufige Lücke: Wenn TLS am Load Balancer beendet werden muss, müssen Sie sicherstellen, dass die Anwendung den X-Forwarded-For-Header liest und dass die Sicherheitskontrollen des ALB den direkten Zugriff einschränken, damit den Headern vertraut werden kann. Die Annahme, dass VPC-Peering unbegrenzt skalierbar ist, führt oft zu unüberschaubaren Meshes. Bevorzugen Sie Transit Gateway für Many-to-Many- und PrivateLink für One-to-Many-Dienstbereitstellungen, bei denen Sie granulare Sicherheit und Datenverkehrsisolierung benötigen.
Sicherheitsrichtlinien sollten Sicherheitsgruppen und Netzwerk-ACLs in Kombination mit Kontrollen auf Namespace-Ebene verwenden. Um den Zugriff ausschließlich über Global Accelerator anstelle von direkten ALB-URLs zu erzwingen, verlassen Sie sich auf eine Kombination aus AWS WAF IP-Sets, die mit den IP-Bereichen von Global Accelerator gefüllt werden (automatisiert über die veröffentlichte ip-ranges.json), oder konzipieren Sie den ALB als intern und schalten Sie ihm einen NLB vor, auf den der Global Accelerator zielt. Geben Sie dann nur den Zugang über Global Accelerator frei. Automatisieren Sie immer die Aktualisierungen aller IP-basierten Kontrollen und validieren Sie diese mithilfe von DescribePrefixLists und der regelmäßigen Aufnahme der ip-ranges.json.
Praktisches Problem: Anwendungsfallszenario
Unternehmen: Equinox Payments. Herausforderung: Equinox betreibt einen EKS-gestützten gRPC-Dienst, der End-to-End-mTLS für Tausende von gleichzeitigen Verbindungen, Autoscaling über Cluster Autoscaler und HPA sowie die Beibehaltung der Client-IPs für die Protokollierung erfordert. Ansatz: 1) Bereitstellung des Dienstes hinter einem Network Load Balancer, der mit einem TCP-Listener auf Port 443 über den AWS Load Balancer Controller konfiguriert ist, unter Verwendung der Annotation service.beta.kubernetes.io/aws-load-balancer-type: “nlb-ip”, damit die Pod-IPs als Ziele registriert werden; 2) Beendigung von TLS an den Pods (nicht am NLB) und Implementierung von Mutual TLS in der Anwendung (Server- und Client-Zertifikatsvalidierung), mit Kubernetes Secrets für Zertifikate und Readiness-Probes zur Steuerung der Zielregistrierung; 3) Verwendung des Zieltyps ip, um die Quell-IPs der Clients beizubehalten, Aktivierung des Proxy-Protokolls nur bei Bedarf für zwischengeschaltete Appliances und Verlass auf die pod-seitige Protokollierung, um die Client-IP aus der TCP-Verbindung zu erfassen; 4) Konfiguration von Health Checks als TCP- oder gRPC-fähige Readiness-Probes und Sicherstellung, dass die Richtlinien des Cluster Autoscalers und die Instanztypen der Nodes über ausreichende ENI- und IP-Kapazität verfügen; 5) Implementierung von CloudWatch Container Insights und VPC Flow Logs (CreateFlowLogs) zur Überwachung der Verbindungsanzahlen und der Telemetrie auf VPC-Ebene. Begründung seitens AWS: Ein NLB mit TCP-Listenern erhält verschlüsselte Sitzungen und Quell-IPs bei, während er auf Millionen von Verbindungen skaliert; der Zieltyp ip ermöglicht es den Pods, die Quell-IP direkt ohne NAT zu empfangen; die Beendigung von mTLS an den Pods erfüllt die Anforderungen an End-to-End-Verschlüsselung und Zwei-Wege-Authentifizierung; das Autoscaling funktioniert, da die Bereitschaft der Pods die Zielregistrierung direkt beeinflusst und der NLB transparent mit der Verbindungslast skaliert.
Alle Domänen · Hybride Konnektivität: VPN und Direct Connect →
Diese Fragen üben → · Zeitlich begrenzte Übung auf 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.
Bestehe deine Prüfung →