Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Beibehaltung von routingfähigem IP-Speicherplatz in VPC-Designs mit mehreren Konten für Subnetze ohne Arbeitslast
Erstellt von Adam Spicer (AWS)
Code-Repository: Nicht routbares sekundäres | Umgebung: Produktion | Technologien: Infrastruktur DevOps; Management und Verwaltung; Netzwerke |
AWS-Services: AWS Transit Gateway; Amazon VPC; Elastic Load Balancing (ELB) |
Übersicht
Amazon Web Services (AWS) hat bewährte Methoden veröffentlicht, die die Verwendung von dedizierten Subnetzen in einer Virtual Private Cloud (VPC) sowohl für Transit-Gateway-Anhänge als auch für Gateway Load Balancer-Endpunkte (zur Unterstützung von AWS Network Firewall oder Appliances von Drittanbietern) empfehlen. Diese Subnetze werden verwendet, um elastische Netzwerkschnittstellen für diese Services zu enthalten. Wenn Sie sowohl AWS Transit Gateway als auch einen Gateway Load Balancer verwenden, werden in jeder Availability Zone zwei Subnetze für die VPC erstellt. Aufgrund der Art und Weise, wie VPCs konzipiert sind, dürfen diese zusätzlichen Subnetze nicht kleiner als eine /28-Maske sein und können wertvollen routingfähigen IP-Speicherplatz beanspruchen, der andernfalls für routingfähige Workloads verwendet werden könnte. Dieses Muster zeigt, wie Sie einen sekundären, nicht routbaren CIDR-Bereich (Classless Inter-Domain Routing) für diese dedizierten Subnetze verwenden können, um routingfähigen IP-Bereich zu erhalten.
Voraussetzungen und Einschränkungen
Voraussetzungen
Architektur
Zielarchitektur
Dieses Muster umfasst zwei Referenzarchitekturen: Eine Architektur hat Subnetze für Transit Gateway (TGW) -Anlagen und einen Gateway Load Balancer-Endpunkt (GWLBE), und die zweite Architektur hat Subnetze nur für TGW-Anlagen.
Architektur 1 ‒ TGW-verbundene VPC mit Eingangs-Routing zu einer Appliance
Das folgende Diagramm stellt eine Referenzarchitektur für eine VPC dar, die sich über zwei Availability Zones erstreckt. Beim Eingang verwendet die VPC ein Eingangs-Routing-Muster
Dieses Muster verwendet einen nicht routbaren CIDR-Bereich für das TGW-Anhangs-Subnetz und das GWLBE-Subnetz. In der TGW-Routingtabelle ist dieses nicht routbare CIDR mit einer (statischen) Blackhole-Route konfiguriert, wobei eine Reihe speziellerer Routen verwendet wird. Wenn die Routen an die TGW-Routingtabelle weitergegeben würden, würden diese spezifischeren Blackhole-Routen gelten.
In diesem Beispiel ist das routbare CIDR /23 aufgeteilt und vollständig routingfähigen Subnetzen zugewiesen.
Architektur 2 — TGW-angeschlossene VPC
Das folgende Diagramm stellt eine weitere Referenzarchitektur für eine VPC dar, die sich über zwei Availability Zones erstreckt. Ein TGW-Anhang unterstützt ausgehenden Datenverkehr (Egress) von den privaten Subnetzen zu einer separaten VPC. Es verwendet einen CIDR-Bereich, der nicht routbar ist, nur für das TGW-Anhangs-Subnetz. In der TGW-Routingtabelle ist dieser nicht routbare CIDR mit einer Blackhole-Route konfiguriert, wobei eine Reihe speziellerer Routen verwendet wird. Wenn die Routen an die TGW-Routingtabelle weitergegeben würden, würden diese spezifischeren Blackhole-Routen gelten.
In diesem Beispiel ist das routbare CIDR /23 aufgeteilt und vollständig routingfähigen Subnetzen zugewiesen.
Tools
AWS-Services und -Ressourcen
Amazon Virtual Private Cloud (Amazon VPC) hilft Ihnen, AWS-Ressourcen in einem von Ihnen definierten virtuellen Netzwerk zu starten. Dieses virtuelle Netzwerk ähnelt einem herkömmlichen Netzwerk, das Sie in Ihrem eigenen Rechenzentrum betreiben würden, mit den Vorteilen der skalierbaren Infrastruktur von AWS. In diesem Muster werden sekundäre VPC-CIDRs verwendet, um routingfähigen IP-Speicherplatz in Workload-CIDRs beizubehalten.
Internet-Gateway-Ingress-Routing
(Edge-Zuordnungen) kann zusammen mit Gateway Load Balancer-Endpunkten für dedizierte, nicht routbare Subnetze verwendet werden. AWS Transit Gateway ist ein zentraler Hub, der VPCs und lokale Netzwerke verbindet. Bei diesem Muster sind VPCs zentral an ein Transit-Gateway angeschlossen, und die Transit-Gateway-Anlagen befinden sich in einem dedizierten, nicht routbaren Subnetz.
Gateway-Load Balancer ermöglichen Ihnen die Bereitstellung, Skalierung und Verwaltung virtueller Geräte, wie Firewalls, Systeme zur Angriffserkennung und -Abwehr und Deep-Packet-Inspection-Systeme. Das Gateway dient als einziger Eingangs- und Ausgangspunkt für den gesamten Verkehr. In diesem Muster können Endpunkte für einen Gateway Load Balancer in einem dedizierten, nicht routbaren Subnetz verwendet werden.
Die AWS Network Firewall ist ein zustandsbehafteter, verwalteter Netzwerk-Firewall sowie Service zur Erkennung und Verhinderung von Eindringlingen für VPCs in der AWS-Cloud. In diesem Muster können Endpunkte für eine Firewall in einem dedizierten, nicht routbaren Subnetz verwendet werden.
Code-Repository
Ein Runbook und CloudFormation AWS-Vorlagen für dieses Muster sind im Repository GitHub Non-Routable Secondary CIDR
Bewährte Methoden
AWS Transit Gateway
Verwenden Sie für jeden Transit-Gateway-VPC-Anhang ein separates Subnetz.
Weisen Sie den Transit-Gateway-Anhangssubnetzen ein /28-Subnetz aus dem sekundären, nicht routbaren CIDR-Bereich zu.
Fügen Sie in jeder Transit-Gateway-Routingtabelle eine statische, spezifischere Route für den nicht routbaren CIDR-Bereich als schwarzes Loch hinzu.
Gateway Load Balancer und Ingress-Routing
Verwenden Sie Ingress-Routing, um den Datenverkehr vom Internet zu den Gateway Load Balancer-Endpunkten weiterzuleiten.
Verwenden Sie für jeden Gateway Load Balancer-Endpunkt ein separates Subnetz.
Weisen Sie den Gateway Load Balancer-Endpunktsubnetzen ein /28-Subnetz aus dem sekundären, nicht routbaren CIDR-Bereich zu.
Epen
| Aufgabe | Beschreibung | Erforderliche Fähigkeiten |
|---|---|---|
Ermitteln Sie den CIDR-Bereich, der nicht routbar ist. | Ermitteln Sie einen nicht routbaren CIDR-Bereich, der für das Transit-Gateway-Anhangssubnetz und (optional) für alle Gateway Load Balancer- oder Network Firewall Firewall-Endpunktsubnetze verwendet wird. Dieser CIDR-Bereich wird als sekundärer CIDR für die VPC verwendet. Er darf nicht vom primären CIDR-Bereich der VPC oder dem größeren Netzwerk aus routbar sein. | Cloud-Architekt |
Ermitteln Sie routbare CIDR-Bereiche für VPCs. | Ermitteln Sie einen Satz routingfähiger CIDR-Bereiche, die für Ihre VPCs verwendet werden. Dieser CIDR-Bereich wird als primärer CIDR-Bereich für Ihre VPCs verwendet. | Cloud-Architekt |
VPCs erstellen. | Erstellen Sie Ihre VPCs und hängen Sie sie an das Transit-Gateway an. Jede VPC sollte einen primären CIDR-Bereich haben, der routbar ist, und einen sekundären CIDR-Bereich, der nicht routbar ist, basierend auf den Bereichen, die Sie in den beiden vorherigen Schritten festgelegt haben. | Cloud-Architekt |
| Aufgabe | Beschreibung | Erforderliche Fähigkeiten |
|---|---|---|
Erstellen Sie spezifischere CIDRs, die nicht routbar sind, als schwarze Löcher. | In jeder Routingtabelle für Transit-Gateways muss eine Reihe von Blackhole-Routen für die nicht routbaren CIDRs erstellt werden. Diese sind so konfiguriert, dass sichergestellt ist, dass jeglicher Datenverkehr vom sekundären VPC-CIDR nicht routbar bleibt und nicht in das größere Netzwerk gelangt. Diese Routen sollten spezifischer sein als das nicht routbare CIDR, das auf der VPC als sekundäres CIDR festgelegt ist. Wenn das sekundäre, nicht routbare CIDR beispielsweise 100.64.0.0/26 ist, sollten die Blackhole-Routen in der Transit-Gateway-Routingtabelle 100.64.0.0/27 und 100.64.0.32/27 lauten. | Cloud-Architekt |
Zugehörige Ressourcen
Zusätzliche Informationen
Der nicht routbare sekundäre CIDR-Bereich kann auch nützlich sein, wenn Sie mit größeren skalierten Containerbereitstellungen arbeiten, die eine große Anzahl von IP-Adressen erfordern. Sie können dieses Muster mit einem privaten NAT-Gateway verwenden, um ein nicht routbares Subnetz zum Hosten Ihrer Container-Bereitstellungen zu verwenden. Weitere Informationen finden Sie im Blogbeitrag So lösen Sie die Erschöpfung privater IP-Adressen mit Private NAT
