Amazon SAP-C02: Vernetzung & Hybride Konnektivität — Lernleitfaden

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Teil des AWS Solutions Architect Professional SAP-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

VPC-Architektur und Segmentierungsmuster

Das Design einer VPC-Topologie beginnt mit dem Sprengradius-Management und vorhersagbarem Routing. Für kleine Deployments kann eine einzelne VPC mit mehreren Subnetzen und strengen Security Groups effizient sein, aber wenn Teams und Anwendungen wachsen, wird das Single-VPC-Muster anfällig: Ressourcenkontingente, teamübergreifende Governance und „störende Nachbarn“ erhöhen das Betriebsrisiko. Das Modell mit mehreren VPCs pro Team oder einem Account pro Team verbessert die Isolation und die IAM-Grenzen; verwenden Sie AWS Organizations mit separaten Konten für Teams und einem Shared-Services-Konto für DNS, Logging und Identität. Für die Konnektivität zwischen VPCs ist VPC Peering einfach und latenzarm, aber nicht-transitiv und bei Skalierung betrieblich aufwendig. Transit Gateway (TGW) ersetzt das „Transit-VPC“-Muster: Es unterstützt Tausende von Attachments, zentralisiert Routing-Tabellen und vereinfacht Multicast- oder Hub-and-Spoke-Muster. PrivateLink (Interface VPC Endpoints) ermöglicht eine Isolation auf Service-Ebene, ohne Dienste dem Internet auszusetzen, was für kontoübergreifende Microservices entscheidend ist. Häufige Fallstricke sind das alleinige Verlassen auf Security Groups zur Segmentierung (diese sind zustandsbehaftet und zu grob für die Ost-West-Filterung), das Vergessen des zustandslosen Verhaltens von NACLs und die fehlende Planung der CIDR-Zuweisung (Überlappungen behindern Peering und DX). Entscheidungen hängen von den Kosten im Vergleich zur Verwaltbarkeit ab: TGW hat Attachment-Kosten, reduziert aber die Komplexität pro Peering; die Multi-Account-Isolation erhöht den Overhead der Landing Zone, verringert aber den Sprengradius. Dokumentieren Sie immer den CIDR-Plan, die Regeln zur Routen-Weitergabe (Route Propagation) und die Zuständigkeiten für gemeinsam genutzte Dienste, um Abweichungen (Drift) zu vermeiden.

Hybride Konnektivität, Routing und Resilienz

Die Wahl der hybriden Konnektivität hängt von Durchsatz, Jitter, Latenz und einer konsistenten öffentlichen Egress-Adressierung ab. Private VIFs von AWS Direct Connect (DX) bieten deterministische Bandbreite und niedrigere Egress-Kosten im Vergleich zu Internet-VPN für große, stetige Datenströme; verwenden Sie ein Direct Connect Gateway, um mehrere Regionen zu verbinden, oder ein Attachment an ein Transit Gateway für zentralisiertes Routing. Site-to-Site VPN (verwaltetes IPsec mit BGP) wird für eine schnelle Einrichtung oder als resilientes Backup für DX verwendet; konfigurieren Sie BGP mit passenden ASNs und Routenprioritäten, um asymmetrisches Routing zu vermeiden. Wichtige Routing-Fallstricke sind überlappende On-Premises- und Cloud-CIDRs, eine fehlerhafte Routen-Weitergabe (Route Propagation) im TGW und die Annahme von transitivem Routing über gepeerte VPCs hinweg. MTU und Fragmentierung können den VPN-Verkehr stören – testen Sie die Pfad-MTU und passen Sie die MSS auf den Geräten an. Für Multi-Region-Setups ziehen Sie eine Aktiv/Aktiv-DX-Konfiguration an mehreren Standorten oder eine Kombination aus DX mit VPN-Failover in Betracht. Abwägungen: Dedizierte DX-Verbindungen kosten mehr, reduzieren aber Jitter und Egress-Gebühren; VPN ist günstiger und einfacher, aber bei hohem Durchsatz weniger stabil. Architektieren Sie für ein vorhersagbares Failover mit zwei unabhängigen Tunneln, redundanten DX-Verbindungen an getrennten Standorten und expliziten TGW-Routing-Tabellen zur Steuerung der Pfadauswahl und von Grenzwerten.

DNS, PrivateLink und Service-Konnektivitätsmuster

DNS ist ein zentraler Bestandteil von hybriden und Multi-Account-Netzwerken. Verwenden Sie Route 53 Private Hosted Zones für die VPC-interne Auflösung und Route 53 Resolver Inbound/Outbound Endpoints, um eine bedingte Weiterleitung (Conditional Forwarding) zwischen On-Premises- und AWS-DNS zu ermöglichen. Dies unterstützt Split-Horizon-DNS, bei dem interne Namen zu privaten IPs aufgelöst werden, während die öffentlichen Einträge global bleiben. PrivateLink (Interface Endpoints) bietet private, ENI-gestützte Konnektivität zu AWS-Services oder SaaS-Partnern, ohne den Datenverkehr über das öffentliche Internet zu leiten; dies steht im Gegensatz zu Gateway Endpoints für S3 und DynamoDB, die günstiger sind und Routing-Tabellen anstelle von ENIs verwenden. PrivateLink vermeidet, dass Dienste VPC-CIDR-Konflikten ausgesetzt werden, und unterstützt kontoübergreifende Consumer mit Service-Akzeptanzrichtlinien. Häufige Fallstricke sind das Vergessen, Private Hosted Zones mit allen Consumer-VPCs zu verknüpfen, das Nicht-Erstellen von Route 53 Resolver-Regeln für On-Premises-Domänen und die Unterschätzung des IP-Verbrauchs pro ENI des Endpunkts. Entscheidungskriterien: Bevorzugen Sie Gateway Endpoints für den Zugriff auf S3/DynamoDB mit hohem Durchsatz, um NAT-Kosten zu vermeiden; verwenden Sie Interface Endpoints, wenn Sie privaten Zugriff auf API-Endpunkte oder Dienste von Drittanbietern mit strengeren Sicherheitsanforderungen benötigen. Überwachen Sie die DNS-Latenz und legen Sie TTLs mit Change Control fest, um das Failover-Verhalten zu steuern.

Egress, NAT-Design, Sicherheitskontrollen und Betriebspraktiken

Die Egress-Architektur beeinflusst Kosten, Auditierbarkeit und Integrationen mit Drittanbietern. Ein NAT Gateway bietet verwalteten, hochverfügbaren IPv4-Egress für private Subnetze mit automatischer Skalierung pro AZ; NAT Instances sind für Anwendungsfälle mit geringem Durchsatz kostengünstiger, erfordern aber betriebliche Wartung und Failover-Skripting. Die Zentralisierung des Egress über eine dedizierte Egress-VPC, die an ein Transit Gateway angebunden ist, erzwingt konsistente ausgehende IPs, Inspektionspunkte und vereinfachte Richtlinien, führt aber zu Hairpin-Routing und potenziellen Bandbreitenengpässen. Für IPv6 verwenden Sie ein Egress-Only Internet Gateway. Ersetzen Sie SSH-Bastions durch den AWS Systems Manager Session Manager, um die Auditierung zu ermöglichen und öffentliche eingehende Anmeldeinformationen zu eliminieren; der Session Manager arbeitet über den SSM-Agenten, ohne SSH-Ports zu öffnen. Für erweiterte Filterung und DPI setzen Sie AWS Network Firewall oder Appliances von Drittanbietern hinter dem TGW ein. Abwägungen zwischen Kosten und Leistung: NAT Gateways sind einfach, verursachen aber Gebühren pro GB – nutzen Sie VPC-Endpunkte, um die Kosten für S3-Egress und NAT zu reduzieren. Zu den betrieblichen Fallstricken gehören das Nichtaktivieren von VPC Flow Logs für die Fehlersuche im Datenverkehr, das Belassen von zu weiten Egress-Regeln, die Datenexfiltration ermöglichen, und die Verwendung von SCPs oder IAM-Richtlinien, die unbeabsichtigt Lifecycle-Operationen blockieren; setzen Sie das Prinzip der geringsten Rechte (Least Privilege) durch und protokollieren Sie alles in einem zentralen Konto zur Analyse.

Praktisches Problem: Acme Financial Services – Zentralisierter, vorhersagbarer Egress für das Whitelisting durch Drittanbieter

Szenario: Acme Financial Services betreibt mehrere Anwendungs-VPCs in zwei AWS-Regionen, die mit einem Transit Gateway und über Direct Connect und VPN mit lokalen Rechenzentren verbunden sind. Mehrere Anwendungen in separaten Konten müssen eine Partner-API aufrufen, die Anfragen nur von einem einzigen öffentlichen CIDR-Block akzeptiert.

Herausforderung: Bereitstellung eines hochverfügbaren, auditierbaren Egress-Pfads mit einem vorhersagbaren, einzigen öffentlichen CIDR-Block für alle Anwendungs-VPCs über Regionen hinweg, bei gleichzeitiger Minimierung von Latenz und Betriebsaufwand.

Empfohlener Ansatz:

Bringen Sie einen öffentlichen IPv4-CIDR mittels BYOIP (Bring Your Own IP) zu AWS und weisen Sie Elastic IPs aus diesem CIDR als Egress-Adressen zu.
Erstellen Sie in jeder Region eine zentralisierte Egress-VPC mit NAT Gateways in mehreren AZs; verknüpfen Sie die BYOIP Elastic IPs mit diesen NAT Gateways und binden Sie die Egress-VPCs an das Transit Gateway an.
Aktualisieren Sie die TGW-Routing-Tabellen, sodass alle Anwendungs-VPCs 0.0.0.0/0 an das Egress-VPC-Attachment weiterleiten, aktivieren Sie die Routen-Propagation und ein durch Health-Checks überwachtes Failover über die AZs hinweg; konfigurieren Sie das On-Prem-Routing so, dass bei Bedarf der lokale Egress bevorzugt wird.
Implementieren Sie AWS Network Firewall oder ein verwaltetes IDS in der Egress-VPC für die Filterung des ausgehenden Datenverkehrs, aktivieren Sie VPC Flow Logs und CloudWatch-Alarme und verwenden Sie den Route 53 Resolver für eventuell erforderliche DNS-Weiterleitungen.

Begründung: Die Zentralisierung des Egress über TGW und NAT Gateways mit einem durch BYOIP bereitgestellten IP-Adressraum liefert einen vorhersagbaren CIDR für das Whitelisting, während gleichzeitig Hochverfügbarkeit und zentralisierte Überwachung gewährleistet bleiben. Dieser Ansatz schafft eine Balance zwischen betrieblicher Einfachheit, Sicherheitskontrollen und der Anforderung des Partners nach einem einzigen öffentlichen CIDR.

← Organisatorische Komplexität · Alle Domänen · Sicherheit →

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