Amazon SAA-C03: Netzwerk & Konnektivität — Lernleitfaden

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Teil des AWS SAA-C03 — Vollständiger Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

VPC-Design und CIDR-Planung

Jede VPC beginnt mit einem CIDR-Block, und die bei der Erstellung getroffene Wahl hat nachgelagerte Konsequenzen für Peering, Transit-Gateway-Attachments und hybride Konnektivität. Der primäre CIDR-Block muss zwischen /16 und /28 liegen, aus dem RFC 1918-Adressbereich stammen und darf sich nicht mit Netzwerken überschneiden, mit denen Sie Peering durchführen, über ein Transit Gateway routen oder die Sie über Direct Connect oder VPN erreichen möchten. Überlappende CIDRs sind die häufigste Ursache für fehlerhafte hybride Designs, da AWS nicht zwischen zwei Netzwerken mit demselben Adressraum routen kann – das Transit Gateway akzeptiert zwar das Attachment, aber die Propagierung schlägt fehl oder verwirft den Datenverkehr stillschweigend.

Wenn einer VPC der Adressraum ausgeht, müssen Sie sie nicht neu erstellen. Es können bis zu vier sekundäre IPv4-CIDR-Blöcke angehängt werden (und zusätzliche Bereiche aus einem größeren Pool für eine Standard-Gesamtzahl von fünf, die per Quota-Erhöhung erweitert werden kann). Sekundäre Blöcke können aus demselben RFC 1918-Bereich oder aus dem Shared-Address-Space 100.64.0.0/10 stammen, was nützlich ist, wenn 10.0.0.0/8 erschöpft ist oder wenn Carrier-Grade-NAT-Adressraum benötigt wird. Sekundäre CIDRs ermöglichen es Ihnen, neue Subnetze für Erweiterungen – EKS-Pod-Networking, eine neue Schicht (Tier) – zu erstellen, ohne bestehende Workloads neu nummerieren zu müssen.

aws ec2 associate-vpc-cidr-block \
  --vpc-id vpc-0abc123 \
  --cidr-block 100.64.0.0/16

Ein robustes Design reserviert ein /17 oder /18 für zukünftiges Wachstum, richtet Subnetz-Grenzen an Availability Zones aus (ein /20 pro AZ pro Tier ist ein gängiges Muster) und lässt Spielraum für die ENIs, die von Interface-Endpunkten, NAT-Gateways und Load Balancern verbraucht werden.

Eine VPC ist ein regionales Konstrukt, das in Subnetze unterteilt ist, von denen jedes an eine einzelne AZ gebunden ist. Die Unterscheidung zwischen „öffentlich“ (public) und „privat“ (private) ist eine reine Routing-Entscheidung: Ein öffentliches Subnetz hat eine Route 0.0.0.0/0 → igw-xxxx, die auf ein Internet Gateway zeigt, während ein privates Subnetz entweder keine Standardroute hat oder 0.0.0.0/0 auf ein NAT-Gerät verweist. Instanzen in einem öffentlichen Subnetz benötigen zusätzlich eine öffentliche oder Elastic IP, um eingehend erreichbar zu sein; das IGW führt ein 1:1-NAT zwischen der privaten und der öffentlichen IP durch.

NAT-Gateways, NAT-Instances und IPv6-Egress

Für reinen ausgehenden IPv4-Internetzugriff aus privaten Subnetzen sind NAT-Gateways die richtige Primitive. Ein verwaltetes NAT-Gateway skaliert automatisch auf 45–100 Gbit/s, unterstützt 55.000 gleichzeitige Verbindungen pro eindeutigem Ziel, wird von AWS gepatcht und ist innerhalb seiner AZ hochverfügbar. NAT-Gateways werden pro Stunde und pro verarbeitetem GB abgerechnet.

NAT-Instances – selbstverwaltete EC2 mit deaktivierter Source/Destination-Prüfung – sind Legacy. Sie sind durch den Durchsatz einer einzelnen Instanz begrenzt, müssen für Failover geskriptet werden und werden unter Dauerlast zu einem Engpass. Sie eignen sich nur für atypische Anforderungen wie benutzerdefiniertes Filtern, und selbst dann ist eine Gateway Load Balancer Appliance in der Regel vorzuziehen.

Das kanonische hochverfügbare Muster ist ein NAT-Gateway pro AZ, jedes im öffentlichen Subnetz dieser AZ, mit einer separaten privaten Routing-Tabelle pro AZ, deren Standardroute auf das lokale NAT-Gateway zeigt:

Private subnet AZ-a  → Route table A → 0.0.0.0/0 → NAT-GW-a (public subnet AZ-a)
Private subnet AZ-b  → Route table B → 0.0.0.0/0 → NAT-GW-b (public subnet AZ-b)
Private subnet AZ-c  → Route table C → 0.0.0.0/0 → NAT-GW-c (public subnet AZ-c)

Die Bereitstellung eines einzigen, über mehrere AZs gemeinsam genutzten NAT-Gateways ist aus zwei Gründen eine Falle. Erstens ist es ein Single Point of Failure: Ein AZ-Ausfall legt den Egress-Verkehr für jedes private Subnetz lahm. Zweitens durchquert jedes Paket von Instanzen in anderen AZs eine AZ-Grenze, was zusätzlich zur NAT-Gateway-Verarbeitung Kosten für die Datenübertragung zwischen AZs (derzeit 0,01 $/GB pro Richtung) verursacht. Bei Workloads mit Hunderten von TB an Egress-Verkehr stellt dies die Kosten für die zusätzlichen NAT-Gateways bei weitem in den Schatten. Eine zweite häufige Fehlkonfiguration ist die Platzierung des NAT-Gateways selbst in einem privaten Subnetz – es hat dann keinen Pfad zum IGW und funktioniert nicht.

Für IPv6 ist NAT weder notwendig noch verfügbar, da jede IPv6-Adresse global routbar ist. Um reinen ausgehenden IPv6-Verkehr zu erlauben, während unaufgeforderter eingehender Verkehr blockiert wird, hängen Sie ein Egress-Only Internet Gateway an und routen Sie ::/0 von privaten Subnetzen dorthin. Ein reguläres IGW ist bidirektional und würde Instanzen exponieren.

VPC-Endpunkte: Gateway vs. Interface

VPC-Endpunkte halten den Datenverkehr zwischen Ihrer VPC und AWS-Services im AWS-Backbone und umgehen dabei das Internet, NAT-Gateways und Internet-Gateways vollständig. Es gibt zwei grundlegend unterschiedliche Implementierungen, und deren Verwechslung ist einer der häufigsten Architekturfehler.

Gateway-Endpunkte existieren nur für Amazon S3 und DynamoDB. Sie sind ein Eintrag in einer Routing-Tabelle – eine Präfixliste (z. B. pl-63a5400a für S3 in us-east-1), die auf den Endpunkt selbst abzielt. Es gibt kein ENI, keine DNS-Änderung, keine stündlichen Kosten und keine Sicherheitsgruppe (der Zugriff wird durch die Routing-Tabelle plus die Endpunkt-Richtlinie gesteuert). Da sie routenbasiert sind, funktionieren sie nur für Ressourcen innerhalb der VPC – On-Premises-Netzwerke, die über Direct Connect auf S3 zugreifen, können sie nicht nutzen.

Interface-Endpunkte (AWS PrivateLink) sind ENIs mit privaten IPs, die in Ihren Subnetzen platziert und stündlich pro AZ plus pro GB abgerechnet werden. Sie funktionieren für fast jeden anderen Service – SQS, KMS, Secrets Manager, ECR, STS, SSM, SNS und Hunderte weitere – sowie für Dienste von Drittanbietern, die als Endpunkt-Services veröffentlicht werden. Interface-Endpunkte unterstützen privates DNS, das den öffentlichen Service-Hostnamen überschreibt, um auf die private IP des Endpunkts aufzulösen, sodass SDKs und CLIs keine Code-Änderungen benötigen. Da sie auf ENIs basieren, finden Sicherheitsgruppen Anwendung.

S3Endpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
    VpcEndpointType: Gateway
    RouteTableIds: [!Ref PrivateRouteTableA, !Ref PrivateRouteTableB]
    PolicyDocument:
      Statement:
        - Effect: Allow
          Principal: "*"
          Action: ["s3:PutObject"]
          Resource: "arn:aws:s3:::example-bucket/*"
          Condition:
            StringEquals:
              aws:SourceVpce: !Ref S3Endpoint

SecretsManagerEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcId: !Ref VPC
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds: [!Ref PrivateSubnetA, !Ref PrivateSubnetB]
    SecurityGroupIds: [!Ref EndpointSG]

Die Kostenlogik ist entscheidend: Jeder Datenverkehr, der ein privates Subnetz zu einem öffentlichen AWS-Service verlässt, durchläuft standardmäßig ein NAT-Gateway zu etwa 0,045 $/GB. Für eine containerisierte Workload, die 1 TB pro Tag nach S3 überträgt, beträgt der Unterschied zwischen einem Pfad über ein NAT-Gateway und einem Gateway-Endpunkt Tausende von Dollar pro Monat. Interface-Endpunkte lohnen sich, wenn sie den NAT-Egress in großem Umfang ersetzen oder wenn Compliance-Anforderungen das Internet-Routing verbieten.

Fallen: Anhängen einer Sicherheitsgruppe an einen Gateway-Endpunkt (diese haben kein ENI); die Annahme, ein Gateway-Endpunkt sei von On-Premises aus erreichbar (ist er nicht – verwenden Sie einen Interface-Endpunkt oder das hybride Muster EC2 → S3-Gateway-Endpunkt → separater DX-Pfad); Deaktivieren des privaten DNS bei einem Interface-Endpunkt und die Erwartung, dass unveränderte SDK-Aufrufe funktionieren (sie werden den öffentlichen Endpunkt über das Internet ansteuern und den Endpunkt damit komplett nutzlos machen); Erstellen eines Gateway-Endpunkts, aber Vergessen, die Routing-Tabelle des privaten Subnetzes zuzuordnen (der Verkehr nutzt stillschweigend weiterhin den öffentlichen Pfad); der Versuch, einen Gateway-Endpunkt für einen Dienst zu verwenden, der keinen Gateway-Endpunkt hat (z. B. KMS) – nur S3 und DynamoDB kommen in Frage.

Konnektivität zwischen VPCs: Peering vs. Transit Gateway

VPC-Peering ist eine Eins-zu-Eins-, nicht-transitive Layer-3-Verbindung zwischen zwei VPCs, im selben oder in unterschiedlichen Konten, in derselben oder in unterschiedlichen Regionen. Der Datenverkehr läuft über den AWS-Backbone, es gibt keinen Bandbreitenengpass und keine stündliche Gebühr – Sie zahlen nur für die Datenübertragung über AZ-Grenzen oder zwischen Regionen. Zwei Eigenschaften schränken das Peering ein: (1) es ist nicht-transitiv – wenn A mit B und B mit C peert, kann A nicht über B auf C zugreifen; und (2) CIDR-Bereiche dürfen sich nicht überschneiden. Die Verbindung von N VPCs in einer Full-Mesh-Topologie erfordert N(N-1)/2 Peerings mit Änderungen der Routing-Tabellen in beide Richtungen für jedes Peering; bei 30 VPCs sind das 435 Peerings. Zu erwarten, dass Peering auf Hunderte von VPCs skaliert, ist eine Falle.

Transit Gateway (TGW) ist ein regionaler Cloud-Router. Jede VPC, jedes VPN oder jedes Direct Connect Gateway ist ein Attachment, und TGW-Routing-Tabellen steuern, welches Attachment welches Präfix erreichen kann. Dies wandelt ein O(n²)-Mesh in O(n) Attachments um und ermöglicht Hub-and-Spoke-Topologien, bei denen eine Sicherheits-VPC Firewalls hostet, die den gesamten Datenverkehr zwischen den VPCs inspizieren. TGW unterstützt transitives Routing, terminiert nativ VPN- und Direct Connect Gateway-Assoziationen und kann über den Resource Access Manager in AWS Organizations gemeinsam genutzt werden, sodass zentrale Netzwerk-Teams das Routing steuern, während die Workload-Konten die VPCs besitzen. TGW fügt eine stündliche Gebühr pro Attachment und etwa 0,02 $/GB für verarbeitete Daten hinzu.

Für die regionenübergreifende Konnektivität verbindet TGW-Peering TGWs in verschiedenen Regionen über den globalen AWS-Backbone mit verschlüsseltem Datenverkehr – ein TGW pro Region, in einem Mesh- oder Hub-Design gepeert. Dies vermeidet das N-Quadrat-Problem über Regionen hinweg, das durch regionenübergreifendes VPC-Peering wieder eingeführt wird.

Die Hygiene der Routing-Tabellen ist hier der stille Killer. Das Erstellen einer Peering-Verbindung oder eines TGW-Attachments bewirkt nichts, solange nicht explizite CIDR-Routen in den Subnetz-Routing-Tabellen beider VPCs hinzugefügt werden, die auf das pcx- oder tgw- Ziel verweisen, und Sicherheitsgruppen den Verkehr zulassen. Stillschweigende Konnektivitätsfehler lassen sich fast immer auf eine fehlende Route oder eine implizite Ablehnung (Deny) in einer Sicherheitsgruppe zurückführen, die auf den falschen Quell-CIDR verweist.

Hybride Konnektivität: Site-to-Site VPN vs. Direct Connect

Die Wahl zwischen Site-to-Site VPN und Direct Connect ist ein Kompromiss zwischen schneller Bereitstellung und integrierter Verschlüsselung auf der einen Seite und konsistent niedriger Latenz, dedizierter Bandbreite und vorhersagbarem Durchsatz auf der anderen Seite.

Site-to-Site VPN baut zwei IPsec-Tunnel zwischen einem Customer Gateway (lokaler Router) und entweder einem Virtual Private Gateway oder einem Transit Gateway auf. Jeder Tunnel ist auf ca. 1,25 Gbit/s begrenzt. Der Datenverkehr wird auf der Vermittlungsschicht (Network Layer) verschlüsselt, was in Kombination mit TLS die Anforderungen an die Verschlüsselung auf der Netzwerk- und Sitzungsschicht erfüllt. Die Übertragung erfolgt über das öffentliche Internet, weshalb Latenz und Jitter variabel sind, aber die Verbindung ist in Minuten verfügbar und kostet nur Cents pro Stunde. Nutzen Sie es, wenn eine sofortige Verbindung benötigt wird, die Bandbreite moderat ist oder als Backup-Pfad.

Direct Connect (DX) stellt eine dedizierte Glasfaserverbindung (1, 10 oder 100 Gbit/s) von einem lokalen Router zu einem AWS Direct Connect-Standort bereit. Sie umgeht das öffentliche Internet, was zu konsistenter Latenz und höherem Durchsatz führt. Die Egress-Preise für DX sind erheblich niedriger als für Internet-Egress, was bei der Übertragung von Hunderten von Gigabytes pro Tag eine Rolle spielt. Die Bereitstellung dauert Wochen – Cross-Connects, LOAs, BGP-Konfiguration.

Hier gibt es zwei häufige Fallstricke. Erstens, Direct Connect allein verschlüsselt den Datenverkehr nicht. Eine private Leitung ist kein kryptografisch geschützter Kanal. Um eine Verschlüsselungsanforderung über DX zu erfüllen, wird ein Site-to-Site VPN darüber gelegt oder MACsec für die Layer-2-Verschlüsselung auf unterstützten dedizierten Ports verwendet. Zweitens, eine reine DX-Verbindung allein routet nicht zu mehreren VPCs. Ein privates VIF verbindet sich mit einem einzigen Virtual Private Gateway, das an eine einzige VPC angebunden ist. Um viele VPCs zu erreichen – insbesondere über Konten und Regionen hinweg – verwenden Sie ein Direct Connect Gateway, das über ein Transit VIF mit einem Transit Gateway verbunden ist, und binden Sie jede VPC an das TGW an:

On-prem router ── DX ── Transit VIF ── DX Gateway ── TGW ── VPC-Prod
                                                        ├── VPC-Dev
                                                        └── Inspection VPC (GWLB)

Das kanonische Produktionsmuster verwendet zwei DX-Verbindungen an zwei DX-Standorten, die auf separaten Kunden-Routern enden, mit Site-to-Site VPN als automatischem BGP-Failover – BGP AS-Path Prepending oder MED lenken den Verkehr auf DX, solange es aktiv ist; bei einem Ausfall zieht BGP die DX-Routen zurück und das VPN übernimmt.

Load Balancers: ALB, NLB und GWLB

ALB ist Layer 7 und versteht HTTP-Semantik – Host- und Pfad-basiertes Routing, WebSockets, Redirects, Cookie-basierte Sticky Sessions. Er ist das falsche Werkzeug für alles, was nicht HTTP ist: MQTT, reines TCP, Syslog über UDP, SMTP. ALB verwendet eine DNS-basierte Adressierung mit IPs, die sich im Laufe der Zeit ändern; ihm können keine Elastic IPs zugewiesen werden. Wenn Clients Ziel-IPs auf eine Whitelist setzen, ist ein ALB allein ungeeignet – verwenden Sie stattdessen einen NLB mit EIPs oder schalten Sie dem ALB einen Global Accelerator mit seinen zwei statischen Anycast-IPs vor. “Einfach einmal den ALB-DNS auflösen und die IPs in Firewall-Regeln festschreiben” ist eine Falle: AWS ändert sie ohne Vorankündigung.

NLB ist Layer 4 und skaliert auf Millionen von Flows pro Sekunde. Er erhält standardmäßig die echte Quell-IP des Clients (Ziele sehen den echten Client), unterstützt die Zuweisung einer statischen Elastic IP pro AZ und bewältigt TCP/UDP-Workloads mit hohem Durchsatz. In der Vergangenheit unterstützten NLBs keine Security Groups am Load Balancer selbst – Client-CIDRs mussten direkt in der SG des Ziels zugelassen werden. AWS hat 2023 optionale NLB-Security-Groups hinzugefügt, aber viele Designs gehen immer noch vom klassischen Verhalten aus.

Das kanonische Muster für öffentliche Anwendungen ist:

ALB security group:
  Inbound:  TCP 443 from 0.0.0.0/0 (or specific CIDRs)
  Outbound: TCP <backend-port> to backend SG

Backend instance security group:
  Inbound:  TCP <app-port> from ALB security group (source = sg-alb)
  Inbound:  TCP <health-check-port> from ALB security group

Der Verweis auf die Security Group des ALB als Quelle im Backend – anstelle eines CIDR – ist das Muster des geringsten Privilegs (Least Privilege) und deckt automatisch den Health-Check-Verkehr ab, der von den ENIs des ALB ausgeht. Der ALB selbst befindet sich in öffentlichen Subnetzen in mindestens zwei AZs (Routen zum IGW); die Ziele befinden sich in privaten Subnetzen. Einen internet-facing ALB in einem privaten Subnetz zu platzieren, ist eine klassische Fehlkonfiguration – die Registrierung der Ziele ist erfolgreich, aber Clients können ihn nicht erreichen.

Gateway Load Balancer (GWLB) ist speziell für die transparente Einfügung von virtuellen Appliances von Drittanbietern (Firewalls, IDS/IPS, DPI) konzipiert. Er arbeitet auf Layer 3 und leitet alle IP-Protokolle mittels GENEVE-Kapselung über UDP 6081 weiter. Der Verkehr erreicht den GWLB über einen GWLB-Endpunkt (GWLBe) – einen Interface-Endpunkt, der in einem Subnetz sitzt und in Routing-Tabellen als Ziel erscheint:

Destination: 0.0.0.0/0
Target:      vpce-0abc123... (GWLB endpoint)

Der Endpunkt leitet Pakete über PrivateLink an den GWLB weiter, der die Last über die Appliance-Flotte verteilt und dabei Flow Stickiness verwendet, sodass beide Richtungen eines Flows dieselbe Appliance erreichen. In einem Hub-and-Spoke-Inspektionsdesign werden die Spoke-VPCs an ein TGW angebunden, dessen Routing-Tabellen den Ost-West-Verkehr durch die Inspektions-VPC (die den GWLB und die Appliances enthält) zwingen, bevor er die Ziel-VPCs erreicht. Die Ingress-Inspektion verwendet Edge-Routing-Tabellen, die den Verkehr vom IGW zum Web-Tier zuerst durch den GWLBe umleiten:

IGW → (edge route table) → GWLBe → GWLB (inspection VPC)
    → firewall appliances → GWLB → GWLBe → web subnet

Dies ist die richtige Antwort für eine zentralisierte, kontoübergreifende Inspektion – Eigenlösungen mit EC2, benutzerdefinierte Routing-Tabellen-Hacks und Failover-Skripte erfinden das neu, was GWLB nativ bereitstellt.

PrivateLink für Consumer-to-Provider-Services

PrivateLink ermöglicht nicht nur Interface-Endpunkte für AWS-Services, sondern auch private Konnektivität zu Diensten, die von Drittanbietern oder anderen AWS-Konten veröffentlicht werden. Der Anbieter platziert seinen Service hinter einem NLB und erstellt einen VPC-Endpunktdienst. Konsumenten erstellen in ihren eigenen VPCs Interface-Endpunkte, die auf diesen Dienst abzielen.

Die entscheidende Regel zur Direktionalität lautet: Die Verbindung wird immer vom Konsumenten zum Anbieter initiiert. Der Anbieter kann keine Verbindungen in die VPC des Konsumenten initiieren. Der Datenverkehr verlässt niemals das Internet, nur der spezifische Zieldienst ist erreichbar (nicht die gesamte Anbieter-VPC, wie beim Peering), und es treten keine Probleme mit CIDR-Überlappungen auf, da auf jeder Seite nur Endpunkt-IPs offengelegt werden. Dies ist die Standardlösung für ein SaaS- oder Anbieter-Datenbank-Zugriffsmuster, bei dem die Konsumenten-VPC kein IGW, kein VPN und kein Direct Connect hat. VPC-Peering legt ganze CIDR-Bereiche offen und erfordert nicht überlappende IPs; ein TGW-Attachment leitet den Verkehr breit weiter; eine öffentliche API über das Internet ist nicht privat.

Global Accelerator und Route 53

AWS Global Accelerator weist zwei statische Anycast-IPv4-Adressen zu, die von AWS-Edge-Standorten weltweit bekannt gegeben werden. Der Client-Traffic tritt am nächstgelegenen Edge-Standort ein und wird über das AWS-Backbone zum nächstgelegenen fehlerfreien regionalen Endpunkt (ALB, NLB, EIP oder EC2) geleitet. Dies löst zwei Probleme auf einmal: statische IPs vor ALBs (was die Whitelisting-Lücke schließt) und reduzierter Jitter/Latenz für global verteilte Benutzer durch die Abkürzung über das öffentliche Internet. Es beschleunigt nicht zwischenspeicherbaren TCP/UDP-Traffic zu Origins, bei denen CloudFront (das Inhalte zwischenspeichert) nicht anwendbar ist.

Route 53 löst ein anderes Problem – die Traffic-Steuerung auf DNS-Ebene. Global Accelerator beeinflusst die Datenebene selbst; Route 53 beeinflusst nur die DNS-Auflösung, woraufhin die TCP-Verbindung dorthin geht, wo sich die aufgelöste IP befindet. Beide werden häufig kombiniert: Ein Route 53-Alias verweist auf einen Global Accelerator, der vor regionalen ALBs steht.

Routing-Richtlinien von Route 53:

Latenz und Geostandort werden häufig verwechselt: Latenz minimiert die vom Benutzer wahrgenommene RTT; Geostandort erzwingt die Datenresidenz unabhängig von der Latenz. Multi-Region-Failover erfordert Zustandsprüfungen für die primäre Ressource. Alias-Records sind AWS-spezifisch, werden ohne Abfragegebühren direkt zu ALB-, NLB-, CloudFront-, S3-Website- und API-Gateway-Endpunkten aufgelöst und funktionieren – im Gegensatz zu CNAMEs – am Zone Apex.

Route 53 Resolver beantwortet DNS-Anfragen innerhalb einer VPC über die .2-Adresse (VPC-CIDR-Basis + 2). Für hybrides DNS ermöglichen eingehende Endpunkte lokalen (On-Premises) Resolvern die Abfrage privater gehosteter Zonen in AWS; ausgehende Endpunkte mit Weiterleitungsregeln ermöglichen es VPC-Ressourcen, lokale (On-Premises) Namen aufzulösen. Ohne diese können EC2-Instanzen corp.internal nicht auflösen und On-Prem-Server können db.prod.internal nicht auflösen – ein subtiler Fehler, der erst auftritt, wenn Anwendungen mit umgebungsübergreifenden Abfragen beginnen. Interface-Endpunkte erfordern die Option Privates DNS aktivieren, damit SDK-Aufrufe das Endpunkt-ENI erreichen; andernfalls erreichen die Aufrufe weiterhin den öffentlichen Endpunkt über das Internet, was den Zweck zunichtemacht.

Sicherheitsgruppen, NACLs und das Prinzip der geringsten Rechte

Sicherheitsgruppen sind zustandsbehaftet (stateful) – der Rückverkehr wird automatisch zugelassen – und agieren auf der ENI-Ebene. NACLs sind zustandslos (stateless) und agieren an der Subnetz-Grenze. Jede TCP-Regel in einer NACL erfordert eine explizite eingehende und ausgehende Regel; da Clients einen Quell-Port aus dem ephemeren Bereich wählen, muss die Regel für die Rückrichtung die Ports 1024–65535 zulassen (Linux verwendet standardmäßig 32768–60999; der breitere Bereich deckt Windows und andere Stacks ab). Das Vergessen der ephemeren Rückverkehrsregel ist eine klassische Ursache für Verbindungen, die den SYN-Handshake abschließen, aber bei der Antwort hängen bleiben.

Für das Prinzip der geringsten Rechte (Least Privilege) zwischen den Tiers sollten Sicherheitsgruppenregeln auf andere Sicherheitsgruppen-IDs verweisen, nicht auf CIDRs. Dies skaliert mit Auto Scaling und vermeidet starre IP-Whitelists:

sg-web:  ingress 443 from 0.0.0.0/0
sg-app:  ingress 8080 from sg-web
sg-db:   ingress 3306 from sg-app

NACLs sind eine grobe Kontrolle des Explosionsradius (Blast Radius), kein Ersatz für Sicherheitsgruppen. Das Verschärfen von NACLs „für eine tiefengestaffelte Verteidigung“ (Defense in Depth) ohne entsprechende Anpassungen der Sicherheitsgruppen unterbricht häufig ausgehend initiierte Datenflüsse, wie z. B. yum/apt-Updates über ein NAT-Gateway, da der zustandslose Rückverkehr stillschweigend verworfen wird. Routing-Tabellen bestimmen letztendlich die Erreichbarkeit: Selbst eine freizügige Sicherheitsgruppe kann keinen Traffic zustellen, wenn in der Routing-Tabelle ein Eintrag für das Ziel fehlt. Umgekehrt ist ein Gateway-Endpunkt nur dann wirksam, wenn die S3-Präfixlisten-Route tatsächlich in den Routing-Tabellen der Subnetze installiert ist, die den Workload hosten.

Entscheidungsreferenz

← Datentransfer · Alle Domänen · Inhaltsbereitstellung →

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

Amazon durchsuchen →