Amazon ANS-C01: Hybride Konnektivität: VPN und Direct Connect — 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.

Grundlegende Konzepte

Hybride Konnektivität in AWS ist die Kombination aus privat bereitgestellten Netzwerkleitungen und verschlüsselten IP-Tunneln, um lokale Netzwerke in die AWS-Cloud zu erweitern. Site-to-Site VPN bietet IPsec-Tunnel (IKEv1/IKEv2), die auf einem Virtual Private Gateway (VGW) oder Transit Gateway enden; AWS stellt zwei unabhängige Tunnel pro VPN-Verbindung für Ausfallsicherheit bereit und unterstützt BGP für dynamisches Routing oder bei Bedarf statische Routen. Client VPN ist ein auf OpenVPN basierender, verwalteter Endpunkt, der gegenseitige Zertifikatsauthentifizierung (ACM Private CA oder hochgeladene Client-Zertifikate) oder SAML-Föderation für die Benutzeridentität, Routenverteilung in eine VPC oder ein Transit Gateway und clientseitiges Split-Tunneling unterstützt, um den in AWS eingehenden Datenverkehr zu begrenzen.

AWS Direct Connect bietet eine dedizierte physische Verbindung zwischen Ihrem Standort und AWS. Verbindungen können dediziert (von AWS bereitgestellt) oder gehostet (von einem Partner bereitgestellt) sein; Sie können mehrere Verbindungen mithilfe einer Link Aggregation Group (LAG) bündeln, um eine einzige logische Schnittstelle darzustellen und die Bandbreite zu erhöhen; Direct Connect unterstützt private virtuelle Schnittstellen (private VIF) zu VPCs, öffentliche VIF für öffentliche AWS-Endpunkte und Transit-VIF zu einem Direct Connect Gateway für Multi-Region- oder Transit-Gateway-Konnektivität. Zum Schutz der Daten auf der physischen Verbindung ist MACsec an unterstützten Standorten verfügbar, um eine Layer-2-Frame-Verschlüsselung zwischen dem Kunden-Edge und dem AWS-Edge bereitzustellen, und die Verschlüsselung während der Übertragung auf Layer 3 bleibt in der Verantwortung von IPsec- oder TLS-Endpunkten.

Zuverlässigkeit und Routing erfordern eine explizite Steuerung von Failover und Pfadauswahl. BGP-Attribute (Local-Preference, AS-Path-Prepending) werden verwendet, um Direct Connect gegenüber VPN für niedrige Latenz und hohen Durchsatz zu bevorzugen, wobei Site-to-Site VPN oder eine sekundäre DX-Verbindung als automatisches Backup fungiert. Wenn eine durchgängige TLS-Verschlüsselung erforderlich ist oder wenn Anwendungen die Beibehaltung der Client-Quell-IP und eine sehr große Anzahl langlebiger TCP-Verbindungen erfordern (z. B. gRPC über TLS auf Port 443), verwenden Sie TCP/TLS-Passthrough-Muster wie einen Network Load Balancer (NLB) oder direkte öffentliche Endpunkte auf EKS-Knoten mit entsprechenden Sicherheitskontrollen; wenn eine Terminierung am Edge akzeptabel ist, unterstützt der Application Load Balancer (ALB) HTTP/2 und gRPC und terminiert TLS, wobei er X-Forwarded-For-Header einfügt, damit Backend-Pods die Client-IPs protokollieren können.

Wichtige Dienste und Konfiguration

Beim Erstellen von Site-to-Site VPN verwenden Sie die EC2 CreateVpnConnection API (aws ec2 create-vpn-connection) und hängen die resultierende vpn-connection typischerweise an ein Virtual Private Gateway (create-vpn-gateway und attach-vpn-gateway) oder durch Angabe der transit-gateway-id an ein Transit Gateway an. Konfigurieren Sie das Customer-Gateway-Gerät mit den generierten Tunnelparametern: IKE-Version, Verschlüsselungsalgorithmen (AES-GCM), Hashing (SHA-2), Diffie-Hellman-Gruppe, Lebensdauer und der Pre-Shared Key. Für dynamisches Routing aktivieren Sie BGP und richten die BGP-Nachbar-ASN und -IP ein; verwenden Sie für eine schnellere Erkennung von Failover auf der Router-Ebene BFD, wo es zwischen lokalen Geräten und dem AWS-Edge unterstützt wird.

Client VPN-Endpunkte werden über die EC2 CreateClientVpnEndpoint API (aws ec2 create-client-vpn-endpoint) erstellt. Sie stellen ein Serverzertifikat aus ACM, eine Authentifizierungsoption (Zertifikat oder SAML) bereit und verknüpfen den Endpunkt mit einem oder mehreren VPC-Subnetzen, um Elastic Network Interfaces zu erstellen. Verwenden Sie authorize-client-vpn-ingress, um erlaubte Netzwerke pro Autorisierungsregel zu öffnen, und create-client-vpn-route, um Routen in die VPC zu pushen. Für große Benutzerpopulationen und bedingten Zugriff integrieren Sie Client VPN mit dem AWS Directory Service oder SAML-Identitätsanbietern und skalieren Sie die gleichzeitigen Verbindungen, indem Sie dem Client VPN-Endpunkt ausreichende CIDR-Adressbereiche zuweisen.

Die Bereitstellung von Direct Connect verwendet die Direct Connect APIs wie create-connection oder, bei Partnerverbindungen, stellt der Partner eine gehostete Verbindung bereit und Sie verwenden die APIs allocate-hosted-connection oder accept-virtual-interface. Um physische Verbindungen zu bündeln, rufen Sie create-lag und dann create-private-virtual-interface oder create-transit-virtual-interface auf, um eine virtuelle Schnittstelle an eine VPC oder ein Direct Connect Gateway anzuhängen. Für MACsec arbeiten Sie mit dem Partner oder dem AWS-Bestellportal zusammen, um MACsec für die Verbindung anzufordern; die Konfiguration umfasst den Schlüsselaustausch und eine passende Cipher Suite auf dem Customer-Edge-Switch, und operative Befehle werden in der Regel zum Zeitpunkt der Bereitstellung koordiniert. Für Architekturen mit mehreren VPCs bevorzugen Sie ein Direct Connect Gateway mit einem Transit-VIF, um eine Verbindung zu einem Transit Gateway herzustellen – dies skaliert besser als die Erstellung vieler privater VIFs und ermöglicht zentralisiertes Routing über TGW-Routentabellen.

Entwurfsmuster und Kompromisse

Wählen Sie eine Aktiv-Aktiv-Architektur für hohen Durchsatz und kurze Failover-Zeiten, indem Sie zwei Direct Connect-Verbindungen an unterschiedlichen Standorten platzieren, identische Präfixe mit BGP ankündigen und LAG für die Link-Bündelung innerhalb eines Standorts verwenden. Aktiv-Aktiv mit BGP-Multipath bietet überlegene Leistung und echte Lastverteilung; dies erfordert jedoch symmetrisches Routing, kompatibles On-Premises-BGP und eine sorgfältige Abstimmung von AS-Path und Local Preference. Nutzen Sie Site-to-Site VPN als automatisches Aktiv-Passiv-Backup, da IPsec-Tunnel resilient und global erreichbar sind. Rechnen Sie jedoch mit höherem Jitter, geringerem Durchsatz und längeren Failover-Zeiten im Vergleich zu Direct Connect. Wo eine deterministische Konnektivität mit niedriger Latenz zwingend erforderlich ist, ist eine zweite DX-Verbindung trotz höherer Kosten vorzuziehen.

Bei TLS-Anforderungen auf Anwendungsebene hängen die Designentscheidungen davon ab, ob der Load Balancer den entschlüsselten Datenverkehr einsehen darf. Wenn End-to-End Mutual TLS erforderlich ist, terminieren Sie TLS am Backend, indem Sie einen NLB im TCP/TLS-Passthrough-Modus verwenden und die Kubernetes-Ingress-Pods das mTLS-Handling übernehmen lassen. Verwenden Sie für EKS den Zieltyp ip, damit Pods skalieren und der Cluster Autoscaler Knoten hinzufügen kann, ohne die NLB-Konfiguration zu ändern. Aktivieren Sie außerdem Proxy Protocol v2, wenn Sie die ursprüngliche Quell-IP des Clients am Pod benötigen. Wenn die TLS-Terminierung am ALB akzeptabel ist, verwenden Sie einen ALB mit einem HTTPS-Listener, konfigurieren Sie Zertifikate in ACM, aktivieren Sie HTTP/2 für gRPC-Unterstützung und verlassen Sie sich für Client-IPs auf X-Forwarded-For. Ein ALB ermöglicht pfadbasiertes Routing zu mehreren Zielgruppen für die URL-basierte Weiterleitung.

Für die Konnektivität über mehrere Konten und VPCs hinweg, bei der granulare Sicherheit und Skalierbarkeit erforderlich sind, bietet ein Hub-and-Spoke-Muster mit einem Transit Gateway und einem zentralisierten Direct Connect Gateway die beste Skalierbarkeit. Verbinden Sie jede VPC einer Geschäftseinheit mit einem Transit Gateway (TGW) und assoziieren Sie das TGW über ein Transit-VIF mit einem Direct Connect Gateway. Verwenden Sie TGW-Routentabellen, um die Segmentierung durchzusetzen, und nutzen Sie Richtlinien auf Ressourcenebene, Security Groups und Network ACLs für granulare Kontrollen. Der Kompromiss besteht in der betrieblichen Komplexität bei der Verwaltung der TGW-Routentabellen und der Notwendigkeit, IAM- und Kontengrenzen sorgfältig zu gestalten.

Häufige Fallstricke und Entscheidungskriterien

Ein häufiger Fehler ist es, sich auf ein einziges VIF pro VPC zu verlassen, ohne die VIF-Limits und die betriebliche Komplexität bei steigender Anzahl von VPCs zu berücksichtigen. Verwenden Sie ein Direct Connect Gateway und Transit-VIFs, wenn Sie viele VPCs oder mehrere Regionen erwarten. Ein weiterer häufiger Fallstrick ist die Annahme, dass sich VPN und Direct Connect identisch verhalten: IPsec-Rekeys, MTU-Auswirkungen und Unterschiede im Durchsatz pro Tunnel bedeuten, dass VPN ein zuverlässiges Backup, aber kein leistungsäquivalenter Ersatz ist. Eine weitere Fehlerquelle ist die Fehlkonfiguration der TLS-Terminierung und der Erwartungen an die nachgelagerte Client-IP. Wählen Sie NLB-Passthrough für echtes End-to-End-TLS mit mTLS oder ALB-Terminierung und Verarbeitung von X-Forwarded-For, wenn der Edge-Knoten TLS terminieren kann.

Schließlich sind Überwachung und Transparenz unerlässlich. Aktivieren Sie CloudWatch-Metriken für Direct Connect (ConnectionBpsEgress/Ingress), Flow-Logs für die VPC-Transparenz und verwenden Sie CloudWatch-Alarme, um Automatisierungen zur Verkehrsverlagerung auszulösen oder Netzwerkingenieure zu benachrichtigen. Für die forensische Zuordnung des Datenverkehrs, wenn mehrere Geschäftsbereiche die Bandbreite auf einem LAG gemeinsam nutzen, korrelieren Sie VIF-Statistiken und VPC-Flow-Logs und ziehen Sie Bandbreitenkontrollen pro VPC am Edge in Betracht, um „Noisy Neighbor“-Probleme zu vermeiden.

Praktisches Problem: Anwendungsfallszenario

Unternehmen: Meridian Medical Analytics. Herausforderung: Meridian betreibt eine globale Flotte von medizinischen Bildgebungsgeräten, die gRPC über TCP-Port 443 verwenden, um hochvolumige, verschlüsselte Streams auf ein Backend hochzuladen, das in einem Amazon EKS-Cluster in us-east-1 gehostet wird. Die Geräte erfordern Mutual TLS (mTLS) für die gegenseitige Client-Authentifizierung und Tausende von gleichzeitigen, langlebigen Verbindungen. Der EKS-Cluster skaliert automatisch mit dem Cluster Autoscaler und HPA. Meridian benötigt eine deterministische, niedrige Latenz von ihrem primären Rechenzentrum und ein automatisches Failover auf das Cloud-VPN.

Ansatz:

1. Stellen Sie einen Network Load Balancer (NLB) vor dem EKS-Service bereit, mit TCP-Listenern auf Port 443 und dem Zieltyp „IP“, damit Pod-Endpunkte direkt als Ziele dienen können. Konfigurieren Sie den NLB für TLS-Passthrough (terminieren Sie TLS nicht am NLB), sodass Mutual TLS mit den Backend-Pods ausgehandelt wird. Verwenden Sie aws elbv2 create-load-balancer und create-listener, um den NLB und die Zielgruppen zu konfigurieren.
2. Konfigurieren Sie EKS-Pod-Container (Ingress oder Sidecar) so, dass sie Mutual TLS unter Verwendung von Server- und Client-Zertifikaten von einer privaten CA (ACM Private CA für die Ausstellung von Server-Zertifikaten; Client-Zertifikate werden auf den Geräten bereitgestellt) terminieren. Stellen Sie sicher, dass die Pods HTTP/2 gRPC unterstützen und über HPA und den Cluster Autoscaler skalieren. Verwenden Sie eine auf langlebige Verbindungen abgestimmte Verzögerung bei der Aufhebung der Registrierung der Zielgruppe.
3. Für die On-Premise-Konnektivität stellen Sie eine dedizierte Direct Connect-Verbindung (create-connection) bereit, die mit einem LAG aggregiert wird, falls mehrere physische Leitungen verfügbar sind. Erstellen Sie ein privates virtuelles Interface (create-private-virtual-interface) zu einem Direct Connect Gateway, das mit Ihrem Transit Gateway für das Routing zur EKS-VPC verbunden ist. Aktivieren Sie MACsec bei der Bereitstellung, wenn der Carrier und der Standort dies unterstützen, um den Layer-2-Transport zu sichern.
4. Implementieren Sie eine Site-to-Site VPN-Verbindung (aws ec2 create-vpn-connection zu einem Transit Gateway) als automatischen Failover-Pfad. Steuern Sie das Failover mit BGP-Attributen, indem Sie Direct Connect bevorzugen (höhere Local-Preference) und die VPN-Verbindung eine niedrigere Präferenz erben lassen. Verwenden Sie BFD, wo unterstützt, für eine schnellere Erkennung von Pfadausfällen. Überwachen Sie die Metriken von Direct Connect und VPN in CloudWatch und richten Sie Alarme ein, um Änderungen am Traffic Engineering oder Benachrichtigungen auszulösen.

AWS-Begründung: Das TCP-Passthrough des NLB erhält das End-to-End Mutual TLS aufrecht, sodass die Client-Zertifikate der Geräte von den Backend-Pods validiert werden. Dies erfüllt die Anforderung, dass der Verkehr nicht am Edge entschlüsselt wird. Der Zieltyp „IP“ und der NLB unterstützen die Skalierung für Tausende von gleichzeitigen, langlebigen Verbindungen und erhalten dabei die Client-IP mittels Proxy-Protokoll oder durch Auslesen der Client-IP aus der TLS-Sitzung, falls erforderlich. Direct Connect bietet eine deterministische, hochbandbreitige Konnektivität zu us-east-1 mit LAG für Kapazität und MACsec für die Verschlüsselung der physischen Verbindung. Site-to-Site VPN stellt einen global erreichbaren, verschlüsselten Backup-Pfad mit BGP-vermitteltem Failover bereit. Dieses Design schafft eine Balance zwischen Sicherheit, Leistung und Skalierbarkeit und entspricht gleichzeitig den Best Practices für die Konfiguration von AWS Direct Connect und VPN.

← VPC-Design und fortgeschrittenes Networking · Alle Domänen · Transit Gateway und Netzwerktopologie →

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

Amazon durchsuchen →