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.
Migrieren Sie Ihr Netzwerk zu AWS
Mit AWS Transform können Sie Ihr Netzwerk AWS in einem Bruchteil der Zeit migrieren, die für die manuelle Planung und Bereitstellung erforderlich ist. AWS Transform verwendet einen AI-powered Agenten, um die Konfiguration Ihrer Quellumgebung in produktionsbereite AWS Netzwerkressourcen zu übersetzen, darunter VPCs, Subnetze, Sicherheitsgruppen, NAT-Gateways, Transit-Gateways, elastische IPs, Routen und Routing-Tabellen. Sie überprüfen und ändern die generierte Netzwerkkonfiguration vor der Bereitstellung über eine Konversationsschnittstelle. Sie können die Bereitstellung direkt mit AWS Transform durchführen oder Self-Deployment wählen und Infrastructure as Code (IaC) in Ihrem bevorzugten Format erhalten: AWS Cloud Development Kit (AWS CDK) Landing Zone Accelerator (LZA) oder Terraform. HashiCorp
Der AWS Transform-Agent führt Sie durch die folgenden Schritte und kümmert sich um die Analyse und Generierung, während Sie die Entscheidungen treffen:
Laden Sie Ihre Quellnetzwerkdatei hoch.
Laden Sie zusätzliche Konfigurationsdateien hoch (optional, für RVTools-Umgebungen).
Wählen Sie eine Netzwerktopologie aus.
Wählen Sie eine Strategie für die Zuordnung von Sicherheitsgruppen aus.
Überprüfen und optimieren Sie Ihr Netzwerk.
Generieren Sie ein Netzwerkdiagramm (optional).
Konfigurieren Sie das Ressourcen-Tagging.
Stellen Sie Ihr Netzwerk bereit.
Anmerkung
Bei Bereitstellungen mit mehreren Konten müssen Sie kontoübergreifende IAM-Rollen und vertrauenswürdigen Zugriff für AWS Organisationen konfigurieren, bevor Sie mit der Netzwerkmigration beginnen. Weitere Informationen zu Migrationstypen finden Sie unter. Schritt 1: Auswahl des Migrationstyps
Schritt 1: Zuordnung des Quellnetzwerks
AWS Transform generiert die Zielnetzwerkinfrastruktur aus einer Vielzahl von Quellnetzwerkkonfigurationsdateien. Laden Sie eine oder mehrere Konfigurationsdateien aus Ihrer Quellumgebung hoch, und AWS Transform verwendet die Informationen, um Zielnetzwerke wie Amazon-VPCs, Subnetze und Sicherheitsgruppen zu generieren. AWS Transform generiert zwar keine Firewall- oder Load Balancer-Ressourcen, aber die Konfiguration dieser Netzwerkelemente kann als Eingabe für die Generierung von Zielnetzwerken verwendet werden.
AWS Transform akzeptiert Konfigurationsdateien aus den folgenden Quelltypen:
-
Softwaredefinierte Netzwerke (SDN): Import/Export für VMware NSX-Netzwerkvirtualisierung oder Cisco ACI-Konfiguration für Cisco Application Centric Infrastructure.
-
VMware vSphere-Netzwerke: RVTools. https://www.dell.com/en-us/shop/vmware/sl/rvtools
Wenn Sie RVTools-Dateien verwenden, generiert AWS Transform nur Amazon VPC-Konfigurationen. Sicherheitsgruppenkonfigurationen erfordern zusätzliche Eingaben von Firewalls oder softwaredefinierten Netzwerkdateien. Weitere Informationen zur Generierung von Sicherheitsgruppen aus zusätzlichen Dateien finden Sie unter Zusätzliche Konfigurationsdateien. -
Netzwerke, die auf Firewall-Konfigurationsdaten basieren: Exportieren Sie Dateien aus Palo Alto Networks Firewall, Fortinet FortiGate Firewall oder Cisco ACI. Weitere Informationen zu unterstützten Versionen und Extraktionsanweisungen finden Sie unter Extrahieren der Konfigurationsdatei.
-
Hybride Netzwerke, auf denen sowohl VMware-Workloads als auch Workloads anderer Anbieter ausgeführt werden: AWS Transform Discovery Tool oder ModelizeIT.
-
Andere Dateitypen: AWS Transform akzeptiert auch andere Netzwerkkonfigurationsdateien wie Checkpoint- und F5-Konfigurationen. Wenn Ihre Konfigurationsdatei keines der oben aufgeführten Formate ist, konvertiert AWS Transform sie automatisch und verwendet sie zur Generierung von Zielnetzwerken. Diese Konvertierung kann je nach Dateigröße und Komplexität bis zu zwei Stunden dauern.
Anmerkung
Die maximal unterstützte Quellnetzwerkdateigröße beträgt 70 MB.
Anmerkung
Damit veraltete Sicherheitsgruppenregeln während der Netzwerküberprüfung entfernt werden können, senden Sie zusammen mit Ihrer Quellnetzwerkkonfiguration Daten zum beobachteten Netzwerkverkehr aus dem AWS Transform Discovery Tool oder ModelizeIT. Weitere Informationen finden Sie unter Geführte Netzwerkempfehlungen.
Warnung
Laden Sie RVTools nur von der offiziellen Dell-Website unter herunter. https://www.dell.com/en-us/shop/vmware/sl/rvtools
Jedes Quellnetzwerksegment ist einer eigenen VPC zugeordnet. Die Netzwerksegmentierung variiert je nach Quelltyp:
-
vNetwork: AWS Transformiert Gruppen-VMs nach vSwitch und virtuellem LAN (VLAN). VLANs können unter mehreren vSwitches erscheinen (außer VLAN 0).
-
NSX-Netzwerke: Segmentieren AWS Sie das Netzwerk auf der Grundlage von Tier-1 Routern, gruppieren Sie die Router und erfassen Sie ihre Segmente.
Schritt 2: Zusätzliche Konfigurationsdateien
Für RVTools-Quellumgebungen können Sie optional zusätzliche Konfigurationsdateien hochladen, um die Generierung von Sicherheitsgruppen zu ermöglichen. Wenn Sie keine zusätzlichen Konfigurationsdateien hochladen, werden keine Sicherheitsgruppen für Ihre RVTools-based Migration generiert.
AWS Transform unterstützt die folgenden zusätzlichen Konfigurationsdateitypen. Sie können nur eine Konfigurationsdatei von einer Plattform hochladen.
-
Cisco Application Centric Infrastructure (ACI) bietet Netzwerkrichtlinienkonfigurationen.
-
Palo Alto Networks bietet Firewall-Sicherheitsrichtlinien.
-
Fortinet FortiGate bietet Firewall-Sicherheitsrichtlinien.
Wenn Sie eine Firewall oder eine Cisco ACI-Datei hochladen, generiert AWS Transform Netzwerkinfrastruktur und Sicherheitsgruppen. Wenn Sie eine RVTools-Datei alleine hochladen, generiert AWS Transform nur die Netzwerkinfrastruktur.
Weitere Informationen zu unterstützten Versionen und Extraktionsanweisungen finden Sie unter Extrahieren der Konfigurationsdatei.
Schritt 3: Netzwerktopologien
Während des Netzwerkdefinitionsschritts wählen Sie eine Netzwerktopologie aus. Sie können die isolierte VPCS-Topologie oder die Hub-and-Spoke-Topologie wählen.
Isolierte VPCs
Was wird bereitgestellt
Isolierte VPCs sind unabhängige Netzwerkumgebungen, in AWS denen sie als separate Einheiten funktionieren. Ihre VPCs sind vollständig isoliert und es gibt keine integrierten Kommunikationswege zwischen ihnen. Diese Trennung bietet den höchsten Schutz der Netzwerkgrenzen.
AWS Transform erstellt die folgenden Ressourcen:
Eine dedizierte VPC für jedes erkannte Quellnetzwerksegment.
Private Subnetze, die auf Ihrer Quellnetzwerkkonfiguration basieren.
Sicherheitsgruppen (wenn Sie Firewall- oder SDN-Konfigurationsdateien bereitgestellt haben).
Vervollständigen Sie Ihre Einrichtung
AWS Transform stellt die Kernnetzwerkinfrastruktur für Sie bereit. Sie stellen die endgültige Konnektivitäts- und Sicherheitskonfiguration entsprechend den Anforderungen Ihres Unternehmens fertig.
Gehen Sie wie folgt vor, um den Internetzugang für eine isolierte VPC zu aktivieren:
Erstellen Sie ein Internet-Gateway und hängen Sie es an die VPC an.
Erstellen Sie öffentliche Subnetze in jeder Availability Zone, in der Sie Internetzugang benötigen. Fügen Sie eine Route hinzu, die
0.0.0.0/0auf das Internet-Gateway verweist. Weitere Informationen zur Subnetzkonfiguration finden Sie unter Subnetze für Ihre VPC.Erstellen Sie NAT-Gateways in den öffentlichen Subnetzen (eines pro AZ für hohe Verfügbarkeit). Weisen Sie jedem NAT-Gateway eine Elastic IP zu.
Aktualisieren Sie Ihre privaten Subnetz-Routing-Tabellen. Fügen Sie eine Route hinzu, die auf das NAT-Gateway in derselben AZ
0.0.0.0/0verweist.Überprüfen Sie Ihre Sicherheitsgruppenregeln. Stellen Sie sicher, dass die Regeln für ausgehenden Datenverkehr den Datenverkehr zulassen, den Ihre Workloads benötigen (HTTPS, DNS usw.).
Richten Sie für die VPC-to-VPC Kommunikation VPC-Peering oder ein Transit Gateway ein und aktualisieren Sie die Routing-Tabellen in jeder VPC, um den Datenverkehr an die Peering-Verbindung oder den TGW-Anhang weiterzuleiten.
Hub und Spoke
In diesem Modell fungiert ein AWS Transit Gateway als zentraler Hub, der mehrere Workload-VPCs (die Spokes) miteinander verbindet.
Was wird bereitgestellt
AWS Transform erstellt die folgenden Ressourcen:
Spoke-VPCs: Eine VPC pro erkanntem Quellnetzwerksegment mit privaten Subnetzen und einem Transit Gateway-Anhang.
Inspektion-VPC: Hostet Ihre Firewall-Appliance zur Überprüfung des Datenverkehrs. Der gesamte VPC-übergreifende Verkehr wird über diese VPC geleitet. Der Transit Gateway-Anhang verwendet den Appliance-Modus, eine Einstellung, die sicherstellt, dass der Datenverkehr für beide Verbindungsrichtungen symmetrisch durch dieselbe Appliance fließt.
Eingehende VPC: Verarbeitet den vom öffentlichen Internet in Ihr Netzwerk eingehenden Datenverkehr (von Norden nach Süden eingehend). Beinhaltet ein Internet-Gateway und öffentliche Subnetze in mehreren Availability Zones.
Ausgehende VPC: verarbeitet den Datenverkehr, der Ihr Netzwerk in das öffentliche Internet verlässt (von Norden nach Süden). Beinhaltet ein Internet-Gateway, NAT-Gateways mit elastischen IP-Adressen in jeder Availability Zone für hohe Verfügbarkeit und private Subnetze für den Transit Gateway-Anschluss.
Transit Gateway-Routentabellen: Zwei Routing-Tabellen leiten den Datenverkehr durch die Inspection-VPC. Die Tabelle „Uninspected“ ist Spoke-VPCs, eingehenden VPCs und ausgehenden VPCs zugeordnet. Sie leitet den gesamten Verkehr weiter (0.0.0. 0/0) an den Inspection-VPC-Anhang und ist die Standard-Zuordnungs-Routing-Tabelle. Die Tabelle Inspected ist der Inspection VPC zugeordnet. Sie enthält weitergeleitete Routen von allen Spoke-VPCs und ist die Standard-Propagierungs-Routing-Tabelle.
Bei Bereitstellungen mit mehreren Konten wird das Transit Gateway über AWS Resource Access Manager (RAM) von allen Konten gemeinsam genutzt.
Datenverkehrsfluss
Der gesamte VPC-übergreifende Verkehr folgt diesem Pfad:
Der Datenverkehr von einer Spoke-VPC wird an das Transit Gateway gesendet (Standardroute 0.0.0). 0/0).
Die Routing-Tabelle „Uninspected“ leitet den Datenverkehr an die Inspection-VPC weiter.
Ihre Firewall in der Inspection-VPC überprüft den Datenverkehr und leitet ihn zurück an das Transit Gateway weiter.
Die Inspected-Routing-Tabelle leitet den Datenverkehr mithilfe propagierter Routen an die Zielspoke-VPC weiter.
Für ausgehenden Internetverkehr leitet die Inspected Routing-Tabelle den Verkehr an die ausgehende VPC weiter. NAT-Gateways übersetzen private IP-Adressen, bevor der Datenverkehr an das Internet-Gateway weitergeleitet wird. Die öffentliche Routing-Tabelle für ausgehende VPC enthält spezifische Routen für jeden Spoke-VPC Classless Inter-Domain Routing (CIDR) -Bereich zurück zum Transit Gateway. Diese Routen ermöglichen es dem Rückverkehr, die richtige Spoke-VPC zu erreichen.
Der eingehende Internetverkehr gelangt über das Internet-Gateway der eingehenden VPC und folgt demselben Prüfpfad, um Spoke-VPCs zu erreichen.
Vervollständigen Sie Ihre Einrichtung
AWS Transform stellt die Kernnetzwerkinfrastruktur für Sie bereit, einschließlich Transit Gateway, Spoke-VPCs und Traffic-Routing. Sie schließen die Firewallkonfiguration und die Einrichtung des eingehenden Dienstes ab, um den Sicherheitsanforderungen Ihres Unternehmens zu entsprechen.
Anmerkung
Standardmäßig durchläuft der VPC-übergreifende Datenverkehr die Inspektion-VPC ohne Inspektion. Sie müssen eine Firewall bereitstellen, um die Überprüfung des Datenverkehrs zu aktivieren.
Stellen Sie eine Firewall bereit: Erstellen Sie zusätzliche Subnetze in der Inspektion-VPC für die Firewall-Endpunkte. AWS Transform erstellt Subnetze nur für den Transit Gateway-Anhang. Leiten Sie den Verkehr von den TGW-Anhangssubnetzen zu den Firewall-Endpunkten und von den Firewall-Subnetzen zurück zum Transit Gateway. Sie können die AWS Network Firewall oder eine Appliance eines Drittanbieters bereitstellen. Weitere Informationen zum Bereitstellen einer Firewall mit einem Transit Gateway finden Sie unter Erstellen einer Firewall mit einem Transit Gateway.
Überprüfen Sie die Konnektivität: Nachdem Sie die Firewall bereitgestellt haben, testen Sie den ausgehenden Internetzugang von einer Spoke-VPC-Instance aus (z. B.curl https://aws.amazon.com). Sie können Reachability Analyzer verwenden, um Verbindungsprobleme zu beheben.
Eingehende Dienste einrichten: Um öffentlich zugängliche Dienste zu hosten, stellen Sie einen Application Load Balancer oder Network Load Balancer in den öffentlichen Subnetzen der eingehenden VPC bereit. Konfigurieren Sie Zielgruppen, die über das Transit Gateway auf Instances in Ihren Spoke-VPCs verweisen, und stellen Sie sicher, dass die Inspected-Routing-Tabelle Rückrouten zur Inbound-VPC enthält.
Wenn Sie die Kommunikation zwischen den VPCs genau steuern möchten, wählen Sie die Option Isolierte VPCs und ändern Sie das generierte Netzwerk, um die spezifischen Kommunikationspfade zu erstellen, die Sie benötigen.
Schritt 4: Zuordnung der Sicherheitsgruppen
Wählen Sie aus, wie Ihre Quell-Sicherheitsrichtlinien in AWS Sicherheitsgruppen übersetzt werden. AWS Transform erstellt Sicherheitsgruppen auf der Grundlage Ihrer Quellumgebungskonfigurationen. Sicherheitsrichtlinien, Sicherheitsrichtlinienregeln, Gateway-Richtlinien und Gateway-Richtlinienregeln werden in Sicherheitsgruppen konvertiert.
Wichtig
AWS Transform erstellt Sicherheitsgruppen nach bestem Wissen und Gewissen, die zu Ihrer Quellumgebung passen. Überprüfen und ändern Sie die generierten Sicherheitsgruppen, um sicherzustellen, dass sie den Anforderungen und Sicherheitsrichtlinien Ihres Unternehmens entsprechen.
Referenzierung von Sicherheitsgruppen
Wenn Sicherheitsgruppen generiert werden, verwendet AWS Transform die Referenzierung von Sicherheitsgruppen, sofern dies unterstützt wird. Durch die Referenzierung von Sicherheitsgruppen werden Sicherheitsregeln festgelegt, die auf einer anderen Sicherheitsgruppen-ID und nicht auf bestimmten IP-Adressbereichen (CIDR-Blöcke) basieren. Dieser Ansatz bietet flexiblere und wartbarere Sicherheitskonfigurationen.
Ihre Sicherheitsgruppenregeln können nur auf andere Sicherheitsgruppen innerhalb derselben VPC oder in einer VPC verweisen, die innerhalb derselben Region verbunden ist. Cross-account Referenzen werden ebenfalls unterstützt. Sie können in einer nicht verbundenen VPC oder regionsübergreifend nicht auf eine Sicherheitsgruppe verweisen. Bei verbundenen VPCs unterstützen nur Regeln für eingehenden Datenverkehr VPC-Sicherheitsgruppenverweise. Für ausgehende Regeln müssen Regeln verwendet werden. CIDR-based Wie AWS Transform Sicherheitsgruppenregeln erstellt, hängt von der ausgewählten Netzwerktopologie ab:
Hub and Spoke: Transit Gateway bietet Netzwerkkonnektivität zwischen VPCs. AWS Transform verwendet Referenzierung sowohl für VPC-interne als auch für Cross-Ingress-Regeln. VPC/cross-account Cross-VPC/cross-account Ausgangsregeln (ausgehender Verkehr) verwenden Regeln. CIDR-based
Isolierte VPCs: Ihre VPCs haben keine Netzwerkkonnektivität zwischen ihnen. AWS Transform verwendet die Referenzierung nur für Regeln innerhalb der VPC. Alle VPC- und kontoübergreifenden Regeln verwenden Regeln. CIDR-based
CIDR-based Regeln werden auch verwendet, wenn die Quellkonfigurationen nicht symmetrisch sind.
Wählen Sie eine der folgenden Strategien für die Zuordnung von Sicherheitsgruppen:
-
MAP: Übersetzt Sicherheitsregeln aus Ihrer Quellumgebung in AWS Sicherheitsgruppen und Regeln. Verwenden Sie diese Option für Migrationen mit statischer IP-Adressierung.
-
MAP_DHCP (Mit DHCP-Unterstützung übersetzen): Übersetzt Sicherheitsregeln aus Ihrer Quellumgebung mit DHCP-Kompatibilität. DHCP weist IP-Adressen dynamisch aus dem CIDR-Bereich des Subnetzes zu. Infolgedessen werden die VPC-übergreifenden Ausgangsregeln erweitert, sodass sie dem vollständigen CIDR des Zielsubnetzes entsprechen. Ein engerer CIDR würde IPs blockieren, die außerhalb dieses Bereichs liegen. DHCP-assigned Überprüfen Sie diese Regeln nach der Migration.
Verwenden Sie diese Option für die DHCP-Unterstützung bei der Kommunikation zwischen VPC Transit Gateway. Funktioniert auch mit statischen IPs, erzeugt aber möglicherweise umfassendere Regeln als MAP.
-
SKIP: Übersetzt keine Sicherheitsregeln. Konfigurieren Sie AWS Sicherheitsgruppen nach der Migration manuell. Funktioniert sowohl mit statischen IP- als auch mit DHCP-Umgebungen. Für RVTools-Quellumgebungen ohne zusätzliche Konfigurationsdateien verwendet AWS Transform automatisch SKIP.
Anmerkung
Ihre Mapping-Strategie bestimmt Ihre IP-Zuweisungsoptionen. MAP unterstützt nur statische IP-Adressen. MAP_DHCP und SKIP unterstützen sowohl statische als auch DHCP.
Ansätze zur IP-Migration
Sie haben zwei Möglichkeiten zur Netzwerkkonfiguration für Ihre Migration:
Auswahl des Netzwerkbereichs
-
Bestehende Bereiche beibehalten (Beibehaltung von IP-Adressbereichen): Behalten Sie die ursprünglichen IP-Adressbereiche während der Migration bei. Ideal für Migrationen, bei denen Sie Anwendungen AWS ohne Änderungen (Lift-and-Shift) dorthin verschieben, insbesondere bei älteren Anwendungen, die fest codierte IP-Abhängigkeiten oder bestehende Firewallregeln haben.
-
Aktualisierung auf neue IP-Bereiche (CIDR-Update): Sie können jeden VPC-CIDR-Bereich während der Migration ändern, und AWS Transform leitet Änderungen automatisch an Subnetze, Routing-Tabellen und Sicherheitsgruppen weiter.
Zuweisung von IP-Adressen
-
Feste IP-Adressen (statisch): AWS Transform weist statische IP-Adressen auf der Grundlage des CIDR zu. Dies ist am besten für Anwendungen geeignet, die ein vorhersehbares Netzwerkverhalten, DNS-Verwaltung oder IP-based Zugriffskontrolle erfordern. IPs bleiben auch bei Instance-Neustarts über Elastic Network Interfaces (ENIs) erhalten. Dabei handelt es sich um virtuelle Netzwerkkarten, die an Ihre Instances angeschlossen sind.
-
Dynamische IP-Zuweisung (AWS DHCP): Weisen Sie beim Start der Instance automatisch IP-Adressen aus Subnetzpools zu. Optimal für Anwendungen, die für die Ausführung in der Cloud konzipiert sind und Workloads automatisch skalieren. Reduziert den Betriebsaufwand, erfordert jedoch, dass Anwendungen DNS oder Service Discovery verwenden.
Sie können beide Bereichsauswahlen mit beiden IP-Zuweisungsmethoden kombinieren.
Anmerkung
Die Strategie für die Zuweisung von IP-Adressen wird auf Wellenebene festgelegt. Sie können bestimmten Servern unterschiedliche Strategien zuweisen, indem Sie die Wave-Datei anpassen. Wenn Sie beispielsweise einen statischen IP-Adressansatz für die Wave gewählt haben, aber einem bestimmten Server einen dynamischen Ansatz zuweisen möchten, würden Sie [RESET_VALUE] wie unter Konfiguration bearbeiten im MGN-Benutzerhandbuch beschrieben vorgehen.
Schritt 5: Überprüfen und optimieren Sie Ihr Netzwerk
Nachdem AWS Transform Ihre Zielnetzwerkkonfiguration generiert hat, können Sie die lokalen Netzwerksegmente überprüfen, die zur AWS Infrastruktur konvergiert sind. Verwenden Sie die visuelle Oberfläche, um Ihr Netzwerk zu überprüfen, und die Chat-Oberfläche, um Änderungen vorzunehmen und Empfehlungen zu erhalten. AWS Transform führt eine kaskadierende Wirkungsanalyse durch und implementiert die erforderlichen Änderungen, um die Netzwerkkonsistenz und die Einhaltung der Best Practices zu gewährleisten. Sie können AWS Transform auch bitten, Ihr Netzwerk zu analysieren und Optimierungen vorzuschlagen. Weitere Informationen finden Sie unter Empfehlungen mit Anleitungen.
Bestehende VPCs in Ihrem Zielkonto
Wenn Ihr Zielkonto bereits VPCs aus früheren Migrationsphasen oder parallelen Infrastrukturprojekten enthält, erkennt AWS Transform diese automatisch und zeigt sie während des Überprüfungsprozesses zusammen mit Ihren zugewiesenen VPCs an. Bei Migrationen mit mehreren Konten erkennt AWS Transform vorhandene VPCs auf allen Konten in Ihrem Unternehmen. AWS
Diese Transparenz hilft Ihnen zu verstehen, wie Ihr geplantes Netzwerk mit Ihrer vorhandenen Infrastruktur zusammenhängt, potenzielle CIDR-Konflikte zu identifizieren und vor der Bereitstellung fundierte Entscheidungen zu treffen.
Anmerkung
AWS Transform erkennt nur vorhandene VPCs (keine Subnetze oder andere Ressourcen). Die Erkennung ist schreibgeschützt. AWS Transform ändert Ihre vorhandenen VPCs nicht.
Optimieren Sie Ihr Netzwerk
Anmerkung
Diese Vorgänge gelten nur für Workload-VPCs. Für Appliance-VPCs in der Hub and Spoke-Topologie (Inspection, Inbound, Outbound) wird nur das Ändern der IP-Adresse unterstützt.
Sie können Lösch-, Merge- und Split-Operationen nicht rückgängig machen. Prüfen Sie Ihre Konfiguration sorgfältig, bevor Sie diese Änderungen anwenden.
Die folgenden Operationen sind für VPCs verfügbar:
Löschen: Eine VPC dauerhaft aus der Konfiguration entfernen. Verwenden Sie dies für veraltete Netzwerksegmente, zu AWS denen nicht migriert werden sollte.
Ausschließen: Eine VPC vorübergehend aus der Migration entfernen, um Strategien zur schrittweisen Migration zu nutzen. Ausgeschlossene VPCs werden nicht bereitgestellt, können aber später wieder aufgenommen werden.
Einbeziehen: Fügen Sie eine zuvor ausgeschlossene VPC wieder in die Migration ein.
Zusammenführen: Kombinieren Sie zwei VPCs zu einer. Die erste VPC behält ihre Identität und übernimmt alle Subnetze der zweiten VPC. Sicherheitsgruppen werden in die zusammengeführte VPC verschoben und ihre Zuordnungen werden entsprechend neu erstellt. Der CIDR der ersten VPC wird auf den kleinsten CIDR-Bereich erweitert, der beide ursprünglichen CIDRs enthält, und das Routing wird automatisch aktualisiert. Die zweite VPC wird aus der Konfiguration entfernt.
Anforderungen für die Zusammenführung:
Subnetz-CIDRs dürfen sich zwischen den beiden VPCs nicht überschneiden.
Der zusammengeführte CIDR darf /16 nicht überschreiten.
Bei Bereitstellungen mit mehreren Konten müssen beide VPCs demselben Konto zugewiesen sein.
IP-Adresse ändern: Ändern Sie die Basis-IP-Adresse eines VPC-CIDR unter Beibehaltung derselben Präfixlänge. AWS Transform übersetzt automatisch alle Subnetz-CIDRs mit demselben Offset. Wenn Sie beispielsweise eine VPC von bis ändern, wird ein
10.0.0.0/16Subnetz von bis10.20.0.0/16verschoben.10.0.1.0/2410.20.1.0/24Sicherheitsgruppenregeln, die exakt dem alten VPC-CIDR entsprechen, werden automatisch aktualisiert. Regeln, die sich teilweise überschneiden oder nicht mit dem alten CIDR übereinstimmen, werden nicht geändert. Überprüfen Sie diese Regeln nach der Änderung.
Umbenennen: Ändern Sie den Namen einer VPC so, dass er den Benennungskonventionen Ihres Unternehmens für Kostenzuweisung, Compliance-Überwachung und Betriebsstandards entspricht.
Größe ändern: Ändern Sie die Präfixlänge eines VPC-CIDR, um den IP-Adressbereich zu erweitern oder zu verkleinern.
Verringerung der Präfixlänge (mehr IPs, z. B. /20 bis /16): Subnetze passen immer noch in den größeren Bereich. Es sind keine Änderungen am Subnetz erforderlich.
Erhöhung der Präfixlänge (weniger IPs, z. B. /16 bis /20): Subnetze, die außerhalb des neuen Bereichs liegen, müssen zuerst mithilfe der Subnetzgrößenänderung in der Größe geändert werden.
Sicherheitsgruppenregeln, die exakt dem alten VPC-CIDR entsprechen, werden automatisch aktualisiert. Regeln, die sich teilweise überschneiden oder nicht mit dem alten CIDR übereinstimmen, werden nicht geändert. Überprüfen Sie diese Regeln nach der Größenänderung.
Anforderungen zur Größenänderung:
Der neue CIDR muss zwischen /16 und /28 liegen.
Der neue CIDR darf sich nicht mit anderen VPCs im Netzwerk überschneiden (Hub-and-Spoke-Topologie).
Bei der Reduzierung des CIDR müssen alle vorhandenen Subnetze in das neue CIDR passen. Passen Sie bei Bedarf zuerst die Größe der Subnetze an.
Teilen: Teilen Sie eine VPC auf der Grundlage der von Ihnen angegebenen CIDR-Grenzen in zwei VPCs auf. Subnetze werden der neuen VPC zugewiesen, deren CIDR sie enthält. Sicherheitsgruppen werden auf beide neuen VPCs geklont, aber die CIDRs der Sicherheitsgruppenregeln werden nicht automatisch aktualisiert. Überprüfen Sie Ihre Regeln nach der Aufteilung, um sicherzustellen, dass die VPC-übergreifende Kommunikation erwartungsgemäß funktioniert. Die ursprüngliche VPC wird durch die beiden neuen VPCs ersetzt.
Aufgeteilte Anforderungen:
Sie müssen genau zwei CIDR-Bereiche angeben.
Die beiden CIDRs dürfen sich nicht überschneiden.
Jeder CIDR muss zwischen /16 und /28 liegen.
Jedes Subnetz muss genau in einen der beiden CIDRs passen. Wenn ein Subnetz nicht passt, wird der Vorgang abgelehnt.
Die folgenden Operationen sind für Subnetze verfügbar:
IP-Adresse ändern: Ändern Sie die Basis-IP-Adresse eines Subnetz-CIDR unter Beibehaltung derselben Präfixlänge.
Löschen: Entfernt ein Subnetz dauerhaft aus der Konfiguration, ohne die übergeordnete VPC zu beeinträchtigen.
Größe ändern: Ändern Sie die Präfixlänge eines Subnetz-CIDR, um den IP-Adressbereich zu erweitern oder zu verkleinern.
Anforderungen an die Größe des Subnetzes:
Der neue CIDR muss zwischen /16 und /28 liegen.
Der neue CIDR darf sich nicht mit anderen Subnetzen in derselben VPC überschneiden.
Das neue CIDR muss sich innerhalb des übergeordneten VPC-CIDR befinden.
Nach jedem Vorgang bewertet AWS Transform die Referenzierung von Sicherheitsgruppen neu, wodurch CIDR-based Regeln möglicherweise in Sicherheitsgruppenverweise umgewandelt werden oder umgekehrt. Überprüfen Sie Ihre Sicherheitsgruppenregeln, nachdem Sie Änderungen vorgenommen haben, um sicherzustellen, dass sie Ihren Anforderungen entsprechen.
Empfehlungen zum Thema Netzwerk mit Anleitung
AWS Transform analysiert automatisch Ihr zugeordnetes Netzwerk und zeigt priorisierte Empfehlungen über die Chat-Oberfläche an. So werden Optimierungen identifiziert, die in der Regel eine manuelle Überprüfung durch Netzwerkarchitekten erfordern würden. Die Empfehlungen basieren auf Ihren Netzwerkdaten und müssen von Ihnen bestätigt werden, bevor Änderungen übernommen werden.
AWS Transform empfiehlt möglicherweise die folgenden Optimierungen:
CIDR-Konfliktlösung: Kennzeichnet überlappende CIDR-Bereiche zwischen Ihren zugewiesenen VPCs und vorhandenen VPCs in allen Konten in Ihrer Organisation. AWS Widersprüchliche VPCs werden zuerst angezeigt. Sie können Konflikte lösen, indem Sie die zugeordnete VPC erneut adressieren, sie ausschließen oder löschen oder den Konflikt bestätigen und ihn nach der Bereitstellung selbst lösen.
Standardisierung der Benennung: Kennzeichnet VPC-Namen, die keinem einheitlichen Muster folgen (z. B. Namen, die Hardwarereferenzen enthalten). AWS Transform fragt nach Ihrer Cloud-Namenskonvention, bevor Ersetzungen vorgeschlagen werden.
Überprüfung des Umfangs: Identifiziert Netzwerksegmente, zu denen möglicherweise keine Migration erforderlich ist AWS, z. B. ältere Systeme oder Konstrukte, deren Außerbetriebnahme noch aussteht. AWS Transform bittet Sie um Ihre Bestätigung, bevor ein Konstrukt ausgeschlossen wird.
Richtige Dimensionierung der VPC-Kapazität: Zeigt VPCs an, bei denen der CIDR für die darin enthaltenen Subnetze zu groß oder zu klein erscheint. AWS Transform zeigt die aktuellen Kapazitätsdaten an und lässt Sie entscheiden, ob Sie die Größe ändern möchten.
Sicherheitsüberprüfung: Kennzeichnet Sicherheitsgruppenregeln, die uneingeschränkten eingehenden Datenverkehr zulassen (0.0.0. 0/0) für Ihre Bewertung.
-
Entfernung veralteter Sicherheitsgruppenregeln: Identifiziert ungenutzte Firewallregeln für eingehenden Datenverkehr, die aus Ihrer lokalen Umgebung migriert wurden, und schlägt vor, sie zu entfernen, damit Sie kein Sicherheitsrisiko weitertragen, das keinen Zweck mehr erfüllt. Um ungenutzte Regeln zu identifizieren, verwendet AWS Transform beobachtete Netzwerkverkehrsdaten, die vom AWS Transform Discovery Tool oder ModelizeIT erfasst wurden. Sie müssen diese Verkehrsdaten zusammen mit Ihrer Quellnetzwerkeingabe einreichen. AWS Transform vergleicht Ihre migrierten Firewallregeln mit dem beobachteten Datenverkehr im Beobachtungsfenster, der in diesen Daten erfasst wurde, und kennzeichnet eine Regel als unbenutzt, wenn kein eingehender Verkehr mit ihr übereinstimmt. Ohne Verkehrsdaten kann AWS Transform nicht feststellen, welche Regeln ungenutzt sind, und schlägt auch nicht vor, sie zu entfernen. AWS Transform entfernt nur ungenutzte (eingehende) Eingangsregeln. Das Fehlen eines beobachteten eingehenden Datenverkehrs ist ein zuverlässiges Signal dafür, dass eine Regel nicht verwendet wird. Überprüfen Sie die empfohlenen Entfernungsmaßnahmen, bevor Sie sie anwenden, um sicherzustellen, dass sie Ihren Sicherheitsrichtlinien entsprechen.
VPC-Konsolidierung: Identifiziert fragmentierte VPCs, die durch physische Infrastrukturgrenzen und nicht durch logische Isolationsanforderungen getrennt zu sein scheinen, und schlägt vor, sie zusammenzuführen.
Anmerkung
Alle Empfehlungen müssen ausdrücklich von Ihnen bestätigt werden, bevor AWS Transform Änderungen vornimmt. AWS Transform geht Kompromisse ein, wenn sich eine Empfehlung auf mehrere Aspekte Ihres Netzwerks auswirkt.
Schritt 6: Netzwerkdiagramm
Nachdem Sie die generierten VPC-Konfigurationen überprüft haben, können Sie optional ein Netzwerkdiagramm erstellen, um Ihre Netzwerktopologie zu visualisieren. AWS Transform unterstützt die folgenden Diagrammformate:
Mermaid-Code (.mmd): Dieses Format erzeugt eine textbasierte Diagrammdefinitionsdatei, die Sie mit Werkzeugen rendern können. Mermaid-compatible
Bild (.png): Dieses Format erzeugt ein gerendertes Bild Ihrer Netzwerktopologie.
Schritt 7: Konfigurieren Sie das Ressourcen-Tagging
Ihre Netzwerkressourcen sind für den Start und die Replikation markiert. Sie können auch benutzerdefinierte Tags und MAP-Tags ( AWS Migration Acceleration Program) hinzufügen.
Automatische Tags für Start und Replikation
AWS Transform kennzeichnet Ihre migrierten Netzwerkressourcen (VPCs, Subnetze, Sicherheitsgruppen und Routing-Tabellen) automatisch mit den folgenden Tags:
Schlüssel:
CreatedByWert:AWSApplicationMigrationServiceSchlüssel:
ATWorkspaceWert:workspace-id
Diese Tags ermöglichen die Verwendung der VPC und des Subnetzes zum Starten von Test- und Cutover-Instances. AWS
Anmerkung
Ihre migrierten VPCs und Subnetze verfügen standardmäßig nicht über eine Internetverbindung und eignen sich daher nicht als Staging-Bereiche für die Replikation.
Um die VPC und das Subnetz auch als Staging-Bereich (Replikation) zu verwenden, fügen Sie die folgenden Tags manuell hinzu:
Schlüssel:
CreatedForWert:AWSTransformSchlüssel:
ATWorkspaceWert:workspace-id
Sie können diese Tags auch auf jede vorhandene AWS Netzwerkressource anwenden, um sie für die Replikation verfügbar zu machen.
Finde deine Workspace-ID in der URL der AWS Transform-Web-App: https://... workspace-id /workspace//-id job/job
Benutzerdefinierte Tags
Zusätzlich zu den Tags, die von AWS Transform automatisch angewendet werden, kannst du optional benutzerdefinierte Tags hinzufügen, um deine migrierten Netzwerkressourcen zu organisieren, die Kosten zu verfolgen und die Einhaltung der Vorschriften zu verwalten. Sie können benutzerdefinierte Tags auf zwei Ebenen anwenden:
Job-level Tags: Gilt für alle Ressourcen, die durch diesen Job erstellt wurden, einschließlich aller VPCs, Subnetze, Sicherheitsgruppen und Routing-Tabellen.
VPC-level Tags: Auf eine bestimmte VPC anwenden und automatisch auf alle zugehörigen Ressourcen (Subnetze, Sicherheitsgruppen, Routing-Tabellen) übertragen.
Anmerkung
Maximal 40 Tags pro Anfrage. Jedes Tag erfordert einen Schlüssel und einen Wert. AWS Es gelten die Tagging-Konventionen.
AWS Transform wendet diese Tags an, wenn es die Infrastructure-as-Code-Vorlagen generiert.
AWS Migration Acceleration Program
Wenn Ihre Migration Teil des AWS Migration Acceleration Program (MAP 2.0) ist, wendet AWS Transform ein MAP-Tag auf Ihre Ressourcen an. Wenn Sie Ihre MPE-ID zu einem früheren Zeitpunkt des Migrationsprozesses angegeben haben, wird das Tag automatisch angewendet. Andernfalls fragt AWS Transform, nachdem Sie die generierten VPC-Konfigurationen überprüft haben, ob Sie über eine MAP-Vereinbarung verfügen, und fordert Sie auf, Ihre MPE-ID anzugeben. Die MPE-ID ist ein 10-stelliger Code mit Großbuchstaben und Ziffern (z. B. ABCDE12345). Das angewendete Tag verwendet das Format:
-
Schlüssel:
map-migratedWert:migMPE_ID
Schritt 8: Stellen Sie Ihr Netzwerk bereit
Wählen Sie nach dem Tagging Ihre Bereitstellungsstrategie aus:
-
AWS Transform-managed Bereitstellung: AWS Transform verwendet CloudFormation Vorlagen für die Bereitstellung Ihres Netzwerks und führt Reachability Analyzer aus, um die Konnektivität zwischen Subnetzen über mehrere VPCs hinweg und innerhalb derselben VPC zu überprüfen.
Anmerkung
Sie müssen eine ausdrückliche Genehmigung einholen, bevor Ihre Anfrage zur Netzwerkbereitstellung ausgeführt wird. Weitere Informationen finden Sie unter Genehmigungsverfahren für die Bereitstellung.
-
Self-deployment: AWS Transform generiert IaC-Vorlagen (Infrastructure as Code). CloudFormation Vorlagen werden standardmäßig generiert. Sie können auch zusätzliche Ausgabeformate auswählen:
AWS CDK generiert ein TypeScript Projekt für die programmatische Bereitstellung der Infrastruktur.
HashiCorp Terraform generiert HCL-Vorlagen ( HashiCorp Configuration Language) für die Verwaltung von Netzwerkressourcen.
Landing Zone Accelerator (LZA) generiert eine Datei network-config.yaml für die LZA-Netzwerkkonfiguration.
Anmerkung
Wenn Sie die Bereitstellung über die Landing Zone Accelerator (LZA) -Pipeline durchführen, müssen sich Ihr AWS Transform-Konto und Ihre LZA-Installation in derselben Organisation befinden. AWS Die Bereitstellung schlägt fehl, wenn die Organisations-IDs nicht übereinstimmen.
Verwenden Sie für die Selbstbereitstellung den bereitgestellten Link, um eine ZIP-Datei mit den generierten Vorlagen herunterzuladen. Der ZIP-Ordner enthält eine README.md Datei, in der erklärt wird, wie die generierten Vorlagen verwendet werden.
Um sicherzustellen, dass die heruntergeladene Datei nicht beschädigt oder manipuliert wurde, generieren Sie eine Prüfsumme, laden Sie sie herunter und vergleichen Sie sie dann mithilfe openssl dgst -sha256 -binary <file.zip> | base64 eines Befehls mit einem lokal generierten Hash.
Genehmigungsprozess für die Bereitstellung
Um sicherzustellen, dass Netzwerkänderungen den Sicherheitsstandards und architektonischen Anforderungen Ihres Unternehmens entsprechen, durchlaufen alle Bereitstellungsanfragen einen Genehmigungsworkflow. Sie müssen eine ausdrückliche Genehmigung einholen, bevor Ihre Anfrage zur Netzwerkbereitstellung ausgeführt wird. Wenn Sie eine Bereitstellungsanfrage einreichen, wird diese automatisch über die Registerkarte „ AWS Transformationsgenehmigungen“ an autorisierte Genehmigungsberechtigte weitergeleitet. Genehmigungsberechtigte überprüfen sowohl CloudFormation Vorlagen als auch Netzwerkkonfigurationen, um die Einhaltung der Sicherheitsstandards und architektonischen Anforderungen sicherzustellen. Jede Einreichung löst einen neuen Prüfzyklus aus, und die Bereitstellung erfolgt erst nach Erhalt der Bestätigung. Wenn ein Genehmiger Ihre Anfrage ablehnt, wenden Sie sich direkt an ihn, um die erforderlichen Änderungen zu besprechen. AWS Transform verfolgt alle Genehmigungsentscheidungen zu Prüfungszwecken und führt den Verlauf der Implementierung.
Löschen Sie die bereitgestellten Netzwerkressourcen
Wenn Sie eine Bereitstellung rückgängig machen müssen, können Sie die Netzwerkressourcen löschen, die AWS Transform bereitgestellt hat. Sie können Ressourcen sofort nach Abschluss der Bereitstellung löschen. Wenn Sie die bereitgestellten Netzwerkressourcen nach der Bereitstellung ändern, können die Ressourcen nicht automatisch gelöscht werden.
-
AWS Transform-managed Bereitstellungen: AWS Transform entfernt alle CloudFormation Stapel, die während der Bereitstellung erstellt wurden. Für diese Aktion ist eine Genehmigung auf der Registerkarte „ AWS Transform Approvals“ erforderlich.
-
Self-deployments: Sie müssen die bereitgestellten Ressourcen manuell über die AWS Managementkonsole oder AWS CLI löschen.
Extraktion der Konfigurationsdatei
Wenn Ihre Quellumgebung Cisco ACI, Palo Alto Networks oder Fortinet verwendet, müssen Sie eine Konfigurationsdatei extrahieren FortiGate, um sie Transform zur Verfügung zu stellen. AWS Sie können diese Dateien als eigenständige Quelldateien verwenden, um Netzwerkinfrastruktur und Sicherheitsgruppen zu generieren, oder als ergänzende Dateien zusammen mit einem RVTools-Upload, um die Generierung von Sicherheitsgruppen hinzuzufügen. Der Extraktionsvorgang ist in beiden Fällen derselbe.
Gehen Sie wie folgt vor, um Konfigurationsdateien aus Ihrer Firewall und Netzwerkumgebungen zu extrahieren. Aktuelle Informationen finden Sie in der Dokumentation des Anbieters.
Fortinet FortiGate
Die Firmware-Version muss v7.0 oder höher sein.
Sie benötigen
super_adminunseresuper_admin_readonlyRechte auf globaler Ebene.Schritte:
Stellen Sie über SSH oder den integrierten CLI-Client eine Verbindung zur Firewall her
Ausführen:
show | grep ""(| grep ""deaktiviert die Paginierung)Speichern Sie die gesamte Ausgabe ab dem Befehl in einer Datei
show
Palo Alto Networks
Die Firmware-Version muss 10.1 oder höher sein.
Sie benötigen die Superadmin-Rolle.
Stellen Sie über SSH eine Verbindung zur Firewall her, führen Sie die folgenden Befehle aus, um die Paginierung zu deaktivieren, das Ausgabeformat festzulegen, in den Konfigurationsmodus zu wechseln und die Konfiguration und die vordefinierten Objekte zu exportieren. Speichern Sie die Ausgaben:
set cli pager off set cli config-output-format set configure show # Save as palo-conf.txt show predefined # Save as palo-default.txt
Cisco ACI
Die Firmware-Version muss 6.0 oder höher sein.
Sie benötigen die Admin-Rolle mit allen Rechten und ein konfiguriertes Ziel für Secure Copy Protocol (SCP), SSH File Transfer Protocol (SFTP) oder File Transfer Protocol (FTP).
Schritte:
Stellen Sie über Ihren Browser eine Verbindung zum Application Policy Infrastructure Controller (APIC) her
Öffnen Sie das Admin-Menü und wählen Sie Config Rollbacks
Wählen Sie im Dialogfeld „Einen Snapshot erstellen“ die Option „Remote-Standort“ und wählen Sie „Jetzt einen Snapshot erstellen“.
Nachdem Sie die Meldung „Übertragung erfolgreich“ erhalten haben, stellen Sie eine Verbindung zum Remote-Standortserver her und rufen Sie die neueste Snapshot-Datei (.gz-Datei) ab