Migrieren von Amazon EC2 zu virtuellen Azure-Computern

Wenn Sie Amazon Elastic Compute Cloud (Amazon EC2) verwenden und planen, Ihre Workload nach Azure zu migrieren, kann Dieser Leitfaden Ihnen helfen, den Migrationsprozess, Featurezuordnungen und bewährte Methoden zu verstehen. Es ist für Amazon Web Services (AWS)-Experten gedacht, die mit Amazon EC2 vertraut sind und planen, Workloads auf virtuelle Azure-Computer zu verschieben. Der Leitfaden hebt wichtige Ähnlichkeiten und Unterschiede zwischen den Plattformen hervor und skizziert wichtige architektonische Überlegungen. Außerdem werden bewährte Methoden für Leistung, Kosten und Verfügbarkeit bereitgestellt, um Ihnen bei der Planung und Durchführung einer erfolgreichen Migration zu einer Azure-Infrastruktur als Dienstumgebung (IaaS) zu helfen.

Was Sie erreichen werden

In diesem Handbuch wird beschrieben, wie Sie die folgenden Aufgaben ausführen:

• Ordnen Sie Amazon EC2-Instanzfamilien und -größen der richtigen Azure Virtual Machine (VM)-Serie und SKUs zu.
• Übertragen Sie Amazon Machine Image (AMI)-basierte Workloads in den Microsoft Marketplace oder als benutzerdefinierte Images.
• Entwerfen Sie Azure-Speicherarchitekturen, die vorhandene Leistungsmerkmale des Amazon Elastic Block Store (Amazon EBS) erfüllen oder überschreiten.
• Erstellen Sie Netzwerk-, Sicherheits- und Lastenausgleichsmuster von Amazon Virtual Private Cloud (Amazon VPC) mithilfe von Azure-nativen Diensten neu.
• Erfahren Sie mehr über Verfügbarkeits-, Skalierungs- und Platzierungsstrategien in Azure, die sich an AWS-Designs orientieren.
• Erstellen Sie die erforderlichen Kenntnisse und Fähigkeiten für eine erfolgreiche Migration.
• Überprüfen Sie die Leistung, Resilienz und Funktionalität nach der Migration.

Beispielszenario: Migrieren eines Amazon EC2-basierten Produktionsanwendungsstapels

Eine Organisation führt eine Produktionswebanwendung auf Amazon EC2 aus, die die folgenden Komponenten verwendet:

• Allgemeine Amazon EC2-Instanzen in mehreren Verfügbarkeitszonen
• Amazon Elastic Load Balancing (Amazon ELB)
• Autoskalierungsgruppen (ASGs) für Elastizität
• Amazon EBS-Volumes für beständigen Speicher
• Benutzerdefinierte AMIs als Baseline für Golden Images

Das Ziel besteht darin, diese Workload auf virtuelle Computer zu migrieren, während Sie Verfügbarkeit, Leistung und Skalierungsmerkmale beibehalten.

Verwenden von Azure Migrate zum Migrieren Ihrer Amazon EC2-Instanzen zu Azure

Azure Migrate bietet eine einheitliche Plattform zum Bewerten und Migrieren lokaler Server, Infrastruktur, Anwendungen und Daten. Sie können Azure Migrate verwenden, um Amazon EC2-Instanzen zu Azure zu ermitteln, zu bewerten und zu migrieren.

Weitere Informationen finden Sie unter Migrieren von Amazon EC2-Instanzen mithilfe von Azure Migrate.

Architekturübersicht

In AWS verwendet die Workload Amazon EC2-Instanzen, die über Verfügbarkeitszonen innerhalb einer Amazon VPC verteilt sind. Vorgelagert ist dabei ein Amazon ELB, und die Skalierung erfolgt mithilfe von ASGs. Amazon EBS bietet Speicher und benutzerdefinierte AMIs stellen Bilder bereit.

In Azure bilden die folgenden Komponenten die entsprechende Architektur:

• Virtuelle Maschinen oder Azure-VM-Skalierungsgruppen
• Virtuelles Azure-Netzwerk mit Subnetzen
• Azure Load Balancer oder Azure Application Gateway
• Verwaltete Azure-Datenträger
• Marketplace-Bilder oder benutzerdefinierte Bilder, die in azure Compute Gallery gespeichert sind

Überlegungen zur Produktionsumgebung

Wenn Sie von Amazon EC2 zu virtuellen Computern wechseln, planen Sie die folgenden Überlegungen:

• Unterschiede bei vm-Größenanpassung, Datenträgerleistungskopplung und Netzwerkgrenzwerten
• Kompatibilität von Bildformaten und Agenten, da AMIs nicht direkt importiert werden können.
• Verfügbarkeitskonstrukte, z. B. Verfügbarkeitszonen im Vergleich zu Verfügbarkeitsgruppen
• Evaluation von Netzwerksicherheitsrichtlinien und Dienstintegration
• Unterschiede bei Überwachung, Protokollierung und Automatisierung

Schritt 1: Planen

Inventarisieren Sie die vorhandene Amazon EC2-Workload und erfassen Sie, wie sie sich in der Produktion verhält.

Die wichtigsten Bewertungsaktivitäten umfassen die folgenden Elemente:

• Identifizieren Sie Amazon EC2-Instanzenfamilien, -größen und -CPU-Architektur, wie x86 oder ARM64.
• Erfassen Sie Basis- und Spitzen-CPU-, -Arbeitsspeicher-, -Datenträger-Eingabe-/Ausgabevorgänge pro Sekunde (IOPS), -Durchsatz, -Latenz und -Netzwerknutzung.
• Dokumentieren Sie Amazon EBS-Volumetypen und Leistungseinstellungen.
• Überprüfen Sie ASG-Richtlinien und Platzierungsstrategien.
• Aufzählen von Sicherheitsgruppen- und Netzwerkzugriffskontrolllisten (NaCL)-Regeln.
• Identifizieren Sie AMI-Quellen, z. B. öffentliche, Anbieter oder benutzerdefinierte Bilder.

Formalisieren Sie Ihre Ergebnisse, indem Sie jede Funktion in eine der folgenden Gruppen kategorisieren:

• Direkte Übereinstimmungen in Azure
• Übereinstimmungen mit Konfigurationsunterschieden
• Funktionen, die alternative Designs erfordern

Direkte Funktionszuordnung

Fähigkeitenabweichungen und alternative Strategien

Einige Amazon EC2-Funktionen ordnen Azure nicht direkt zu:

• AMI-Portabilität: Azure unterstützt keinen Lift-and-Shift-Ansatz für AMIs. Sie müssen Bilder in Marketplace-Bilder umwandeln oder als benutzerdefinierte Bilder neu erstellen.
• Burstingverhalten: AWS unterstützt CPU-Bursts über die t-Familie hinaus. Azure schränkt CPU-Bursts auf die B-Serie ein.
• Datenträgerleistungsskala: AWS entkoppelt die Datenträgerleistung von der Instanzgröße. In Azure beschränken sowohl die Datenträger-SKU- als auch die VM-Größe die Datenträgerleistung.
• Hypervisorzugriff: Amazon EC2 Bare-Metal-Instanzen machen mehr Kontrolle als Azure-VMs verfügbar. Verwenden Sie für Hardwareisolationsanforderungen in Azure Den dedizierten Azure-Host.

Schritt 2: Vorbereiten

Bereiten Sie die Azure-Umgebung vor der Migration von Workloads vor:

• Entwerfen Sie virtuelle Azure-Netzwerke und Subnetze, die mit der vorhandenen Amazon VPC-Segmentierung übereinstimmen.
• Einrichten der Identitäts- und Zugriffssteuerung mithilfe der rollenbasierten Zugriffssteuerung (Azure RBAC).
• Wählen Sie Verfügbarkeitszonen oder Verfügbarkeitsgruppen basierend auf Ihren Workloadanforderungen und regionaler Unterstützung aus.
• Wählen Sie Basis-Marketplace-Images aus, die mit der Betriebssystemversion, Der Architektur und dem Startmodus übereinstimmen.
• Entfernen Sie AWS-spezifische Agents, und stellen Sie sicher, dass azure VM Agent unterstützt wird.
• Verwenden Sie Azure Migrate für ermittlungs-, Abhängigkeitszuordnungserstellung und Empfehlungen zur Rechtesetzung, wenn Sie mehrere virtuelle Computer migrieren.

Schritt 3: Ausführen

Jede Phase des Migrationsprozesses erfordert sorgfältige Planung und Ausführung, um einen erfolgreichen Übergang von Amazon EC2 zu virtuellen Computern sicherzustellen. In diesem Abschnitt wird beschrieben, wie Compute-, Images-, Speicher-, Netzwerk- und Verfügbarkeitsfeatures migriert werden.

Compute

Wenn Sie von Amazon EC2 zu virtuellen Computern migrieren, müssen Sie wissen, wie Instanzfamilien der Azure VM-Serie zugeordnet werden, um Ihre Workloads effektiv zu planen. Beide Plattformen organisieren ihre Computeangebote nach Leistungsmerkmalen, aber ihre Benennungskonventionen und Konfigurationsoptionen unterscheiden sich.

Amazon EC2-Instanzfamilien

AWS organisiert Computeressourcen in Instanzenfamilien basierend auf dem Workloadtyp:

• Allgemeiner Zweck: Ausgewogene CPU, Arbeitsspeicher und Netzwerk, wie t3 und m5.
• Für Compute optimiert: Hohes Verhältnis von CPU zu Arbeitsspeicher für rechenintensive Aufgaben wie c5 und c6g.
• Speicher optimiert: Großer Speicherbedarf für In-Memory-Datenbanken oder Analysen, wie r5 und x1e.
• Speicher optimiert: Hoher Datenträgerdurchsatz für große Datensätze, wie i3 und d2.
• Beschleunigtes Computing: GPU-basierte Workloads für maschinelles Lernen oder Grafik, z. B. p3 und g4dn.

AWS-Instanzen skalieren vertikal durch Auswahl größerer Größen innerhalb einer Familie, also z. B. Wechsel von m5.large zu m5.4xlarge, und horizontal mithilfe von ASGs.

Azure VM-Serie

Azure verwendet VM-Datenreihen zum Kategorisieren von Computeressourcen:

• D-Serie: Allgemeine Workloads, ähnlich wie die AWS-Familie m
• F-Serie: Rechenleistung optimiert, vergleichbar mit den AWS-Instanzen c
• E-Serie: Speicher optimiert, ähnlich wie die AWS-Familie r
• M-Serie: Ultrahocher Speicher für SAP HANA und große Datenbanken
• L-Serie: Speicher, der mit lokalen NICHT-volatilen Memory Express (NVMe)-Datenträgern optimiert und mit der AWS-Familie i vergleichbar ist
• NC-, ND- und NP-Serie: GPU-fähig für KI- und Machine-Learning-Workloads, ähnlich wie die AWS-Familien p und g

Azure definiert VM-Größen durch eine SKU, z. B. Standard_D4s_v5. Die SKU gibt die folgenden Eigenschaften an:

• Anzahl virtueller CPU (vCPU)
• Speicher, ausgedrückt in gibibytes (GiB)
• Temporärer Speicher
• Generation

Weitere Informationen finden Sie unter Benennungskonventionen für VM-Größen.

Wichtige Unterschiede

• Benennung: AWS verwendet Familie und Größe, zum Beispiel c5.xlarge. Azure verwendet VM-Serien und VM-SKUs, wie z.B. Standard_F4s_v2.
• Leistungsstufen: Azure legt die Datenträgerleistung gemäß vm-Größe und Datenträger-SKU fest. AWS verwendet amazon EBS-optimierte Instanzen.
• Regionale Verfügbarkeit: Die Features variieren je nach Region auf beiden Plattformen. In Azure sind Features wie Verfügbarkeitszonen und Spotkapazität nur in bestimmten Regionen verfügbar.
• Burstbare Optionen: Die AWS-Familie t unterstützt Burst-Workloads, und AWS bietet Burst-Fähigkeit für andere berechtigte Instanzgrößen. Azure beschränkt die Bursting-Funktion auf die B-Serie.
• Hypervisorzugriff: Einige AWS-Größen ermöglichen eine direktere Kontrolle über den Hypervisor, z. B. i3.metal. Azure bietet weniger Kontrolle auf dieser Ebene.

Zuordnungsstrategie

Verwenden Sie die Dokumentation zur Größe der Azure-VM und den AWS-Instanztyp-Leitfaden, um die folgenden Aufgaben auszuführen.

1. Identifizieren Sie Ihre Amazon EC2-Instanzfamilie und -größe.
2. Ordnen Sie eine Azure-VM-Serie mit dem entsprechenden CPU-zu-Arbeitsspeicher-Verhältnis und der erforderlichen CPU-Architektur zu, wie zum Beispiel x86 oder ARM.
3. Überprüfen Sie die Speicher- und Netzwerkanforderungen, um eine Überbereitstellung oder Unterbereitstellung zu verhindern.
   • Richten Sie einen Basisplan in AWS ein. Erfassen Sie die typischen und Spitzenwerte der Amazon EBS IOPS, des Durchsatzes und der Latenz sowie die Nutzung der Netzwerkbandbreite und der Pakete pro Sekunde (PPS).
   • Zuordnung zu Azure-Grenzwerten. Vergewissern Sie sich, dass die Datenträger-SKU und VM-Größenbeschränkungen sowie die Netzwerkgrenzwerte des virtuellen Computers überprüft werden und ob Azure-beschleunigtes Netzwerk unterstützt wird.
   • Testen Sie in Azure. Führen Sie schnelle Speicher- und Netzwerk-Benchmarks aus, bevor Sie die VM-Größe abschließen.
4. Wenn Sie Beschleuniger wie GPU oder Field-Programmable Gate Array (FPGA) verwenden, stellen Sie sicher, dass die Azure VM-Serie diese unterstützt.
5. Berücksichtigen Sie Azure-spezifische Features wie Spot-VMs für Kosteneinsparungen oder Skalierungssätze für virtuelle Maschinen für die Flexibilität.

Bilder

Wenn Sie Workloads migrieren, die von einem AMI ausgehen, planen Sie einen Schritt für die Image-Konvertierung.

Suchen eines übereinstimmenden (Katalogbilds)

Beginnen Sie mit der Identifizierung, was das AMI darstellt:

• Betriebssystemverteilung und -version, wie Ubuntu 22.04, RHEL 8.9 und Windows Server 2022
• CPU-Architektur wie x86_64 im Vergleich ARM64
• Startmodus- und VM-Generierungsannahmen, z. B. UEFI mit Gen2-VMs oder BIOS mit Gen1-VMs
• Installierte Komponenten wie Überwachungs-Agents, Sicherheitstools und Web- und App-Laufzeiten
• Lizenzierungsmodell, wie Bring-your-own im Vergleich zu von Marketplace bereitgestellten Modellen

Suchen Sie dann ein entsprechendes Azure-Image:

• Marketplace-Images stimmen am besten mit öffentlichen AMIs überein.
• Images, die Ihre Organisation über Compute Gallery veröffentlicht, sind privaten oder freigegebenen AMIs am ähnlichsten.

Wenn Ihre AWS-Workload von einem Anbieter-AMI, wie z. B. einer Firewall, einem Gerät oder einem gehärteten Image abhängig ist, identifizieren Sie das entsprechende Angebot des Anbieters im Marketplace und bestätigen Sie, dass es die folgenden Anforderungen erfüllt:

• Unterstützte VM-Größen und erforderliche Netzwerkfeatures
• Erforderliches Datenträgerlayout und erforderliche Leistung
• Lizenz- und Supportbedingungen

Selbst erstellen (benutzerdefiniert zu benutzerdefiniert)

Wenn es sich bei dem AMI um ein benutzerdefiniertes Bild handelt, z. B. ein goldenes Bild, einen gehärteten Basisplan oder ein Bild mit einer vorinstallierten App, ist das Azure-Äquivalent ein benutzerdefiniertes Bild, das Sie in der Compute Gallery speichern und versionieren.

Führen Sie die folgenden Schritte als empfohlenen Ausgangspunkt aus:

1. Wählen Sie ein sauberes Basisimage aus Marketplace aus, das dem benötigten Betriebssystem, der Version und der Architektur entspricht.
2. Automatisieren Sie die Anpassung , indem Sie Pakete, Konfigurationen, Agents und Härtungen über eine wiederholbare Pipeline anwenden.
3. Überprüfen Sie das Image , wenn Sie Test-VMs bereitstellen und Rauchtests ausführen.
4. Veröffentlichen und versionieren Sie das Bild im Compute Gallery, und replizieren Sie es in Zielregionen.

Betrachten Sie die folgenden gängigen Toolmuster:

• Azure VM Image Builder ist ein verwalteter Imagebuilddienst für die Imageerstellung und -verteilung.
• HashiCorp Packer, einschließlich der Azure-Builder, dient zum Erstellen von Images in kontinuierlichen Integrations- und kontinuierlichen Bereitstellungs-Pipelines (CI/CD).
• Konfigurationsverwaltungstools wie Ansible, Chef oder Puppet helfen, Anpassungen reproduzierbar zu halten.

Berücksichtigen Sie diese betrieblichen Anforderungen, um Ihre Checkliste Wo anfangen zu planen:

• Verallgemeinerung:
  • Führen Sie unter Windows Sysprep aus, bevor Sie das Image erfassen.
  • Installieren Sie unter Linux den Azure Linux VM Agent (waagent), bevor Sie das Image erfassen.
• Treiber und Agents: Stellen Sie sicher, dass das Image den Azure VM-Agent unterstützt, und entfernen Sie alle AWS-spezifischen Agents oder Tools, die nicht mehr angewendet werden.
• VM-Generation: Wählen Sie "Gen1" oder "Gen2" früh aus, da ihre Basisbildauswahl normalerweise die Generation bestimmt.
• Identität und Geheime Schlüssel: Verwenden Sie verwaltete Identität und Azure Key Vault, anstatt geheime Schlüssel in Bilder einzubetten.
• Updates: Patchen Sie das Image während des Builds, und definieren Sie einen Bildaktualisierungsrhythmen.

Lagerung

Die Speicherarchitektur ist ein wichtiger Faktor, wenn Sie von Amazon EC2 zu virtuellen Computern migrieren. Beide Plattformen bieten dauerhafte und kurzlebige Speicheroptionen, aber Implementierungs- und Leistungsmodelle unterscheiden sich.

Amazon EC2-Speicheroptionen

• Amazon EBS: Beständiger Blockspeicher für Amazon EC2-Instanzen. Unterstützt SSD-Volumes (Solid State Drive) und Festplattenlaufwerke (HDD):
  • Universelle SSD, die gp3 und gp2 verwendet.
  • Bereitgestellte IOPS-SSD, die io1 und io2 verwendet.
  • Eine durchsatzoptimierte HDD, die st1 verwendet.
  • Kalte-Festplatte, die sc1 verwendet
• Netzwerkspeicher (NAS): Gemeinsamer Dateispeicher für Linux- und Windows-Workloads:
  • Amazon Elastic File System (Amazon EFS)
  • Amazon FSx, wie Windows File Server, NetApp ONTAP und Lustre
• Instanzspeicher: Ephemeralspeicher, der physisch an den Host angefügt ist. Daten werden gelöscht, wenn die Instanz stoppt oder beendet wird.
• Amazon Simple Storage Service (Amazon S3): Objektspeicher für unstrukturierte Daten, Sicherungen und Archivierungsspeicher.

Zu den wichtigsten Features der Amazon EC2-Speicheroptionen gehören die folgenden Elemente:

• Snapshots für Amazon EBS-Volumes werden in Amazon S3 gespeichert.
• Die Leistung hängt vom Volumentyp und der Größe ab.
• Verschlüsselung über AWS Key Management Service (AWS KMS).

Azure VM Storage-Optionen

• Verwaltete Datenträger: Azure verwaltet beständigen Blockspeicher:
  • Azure Standard HDD: Kostenwirksam für seltenen Zugriff, Nichtproduktionsworkloads und langfristige Sicherungen.
  • Azure Standard SSD: Ausgewogene Leistung für allgemeine Workloads.
  • Azure Premium SSD: Geringe Latenz für Produktions- und leistungsabhängige Apps.
  • Azure Ultra Disk Storage: Hoher Durchsatz für datenintensive Workloads.
• Kurzlebige Betriebssystemdatenträger: Temporärer Speicher für zustandslose Workloads.
• Externer Speicher (NAS und Objektspeicher): Netzwerkgebundener und objektbasierter Speicher für freigegebenen Dateizugriff, Sicherungen, Archivierung und umfangreiche Daten:
  • Azure Blob Storage (Speicherdienst von Azure für unstrukturierte Daten)
  • Azure Files
  • Azure NetApp-Dateien

Zu den wichtigsten Features von Azure VM Storage-Optionen gehören die folgenden Elemente:

• Datenträgerleistungsstufen hängen von vm-Größe und Datenträger-SKU ab.
• Azure VM Storage umfasst integrierte Snapshot-Funktionen und integriert in Azure Backup.
• Verschlüsselung im Ruhezustand verwendet Standardschlüssel und unterstützt vom Kunden verwaltete Schlüssel.

Architekturunterschiede

In Bezug auf NAS entsprechen Amazon EFS und Amazon FSx am besten Azure Files und Azure NetApp Files.

Überlegungen zur Speichermigration

• Zuordnen von Amazon EBS-Volumes zu Azure Managed Disk Tiers:
  • Die gp2 und gp3 Volumentypen entsprechen der Standard-SSD für leichten oder moderaten Gebrauch.
  • Volumetyp gp2 wird SSD Premium zugeordnet.
  • Der gp3 Volumetyp ist premium SSD v2 zugeordnet.
  • Volumetyp io2 wird Disk Storage Ultra zugeordnet.
• Überprüfen sie die IOPS- und Durchsatzanforderungen. Premium SSD und Ultra Disk Storage unterstützen hochleistungsintensive Workloads.
• Plan zur Verschlüsselungskonformität. Verwenden Sie Azure-Datenträgerverschlüsselung und Key Vault für vertrauliche Daten.
• Für die Migration externer Speicher können Sie die folgenden Ansätze verwenden:
  • Migrieren Sie Amazon S3 zu Blob Storage mithilfe von AzCopy- oder Azure Storage-Migrationstools.
  • Migrieren Sie Amazon EFS und Amazon FSx zu Azure Files für allgemeine Dateifreigaben oder zu Azure NetApp Files für leistungsstarke NAS.

Überprüfen Sie IOPS- und Durchsatzanforderungen sorgfältig, da sowohl die Datenträger-SKU als auch die VM-Größe die Leistung des Azure-Datenträgers einschränken.

Vernetzung

Die Netzwerkarchitektur ist eine wichtige Komponente, wenn Sie von Amazon EC2 zu virtuellen Computern migrieren. Beide Plattformen bieten sichere, isolierte Netzwerke, aber Terminologie, Konfiguration und Featuresätze unterscheiden sich.

Amazon EC2-Netzwerk

• Amazon VPC: Logische Isolation von Ressourcen innerhalb von AWS.
• Subnetze: Netzwerksegmente innerhalb eines Amazon VPC zur Isolierung und Segmentierung.
• Sicherheitsgruppen: Zustandsbehaftete Firewallregeln, die auf Instanzebene angewendet werden.
• Netzwerk-ACLs: Zustandslose Regeln, die auf Subnetzebene angewendet werden.
• Elastische IP-Adressen: Statische öffentliche IP-Adressen für Instanzen.
• Lastenausgleich: Amazon ELB unterstützt Layer-4- und Layer-7-Datenverkehr.
• Hybridkonnektivität: Ein virtuelles privates Netzwerk (VPN) und AWS Direct Connect für private Links zu lokalen Standorten.

Azure VM-Netzwerkkomponenten

• Virtuelles Netzwerk: Eine isolierte und segmentierte Netzwerkumgebung, die einem Amazon VPC entspricht.
• Subnetze: Netzwerksegmente innerhalb eines virtuellen Netzwerks, die Isolation bereitstellen und Netzwerksicherheitsgruppen (NSGs) für die Datenverkehrsfilterung unterstützen.
• NSGs: Zustandsbehaftete Regeln für eingehenden und ausgehenden Datenverkehr, die auf der Ebene des Subnetzes oder der Netzwerkschnittstellenkarte (Network Interface Card, NIC) angewendet werden.
• Azure Firewall: Eine verwaltete, cloudbasierte Firewall, die für die zentralisierte Richtlinienerzwingung verwendet wird.
• Azure Private Link: Privater IP-Adressbasierter Zugriff auf Azure-Dienste.
• Öffentliche IP-Adressen: Statische oder dynamische öffentliche IP-Adressen, die Sie Ressourcen zuweisen.
• Lastenausgleich: Load Balancer auf Ebene 4 und Anwendungsgateway auf Ebene 7 mit SSL-Termination (Secure Sockets Layer) und Azure Web Application Firewall.
• Azure Bastion: Secure Remote Desktop Protocol (RDP) und Secure Shell (SSH)-Zugriff ohne Verfügbarmachen öffentlicher IP-Adressen.
• Azure ExpressRoute: Private dedizierte Konnektivität mit Azure für Hybridszenarien.

Wichtige Unterschiede

Überlegungen zur Migration

1. Planen Sie die Architektur des virtuellen Netzwerks: Richten Sie sich an vorhandenem Amazon-VPC-Design für Subnetzsegmentierung aus.
2. Sicherheitsregeln: Konvertieren Sie AWS-Sicherheitsgruppenregeln in NSGs. Überprüfen Sie eingehenden und ausgehenden Datenverkehr.
3. Hybridkonnektivität: Ersetzen Sie AWS Direct Connect durch ExpressRoute für private Konnektivität.
4. Lastenausgleich: Ordnen Sie Amazon ELB-Konfigurationen dem Lastenausgleichsmodul oder dem Anwendungsgateway zu.
5. Zugriffssteuerung: Verwenden Sie Azure Bastion für den sicheren Remotezugriff, anstatt öffentliche IP-Adressen verfügbar zu stellen.

Clustering, Verfügbarkeit und Zonen

Hochverfügbarkeits- und Resilienzstrategien variieren zwischen Amazon EC2 und virtuellen Computern. Diese Konzepte sind für eine fehlertolerante Architektur unerlässlich.

Verfügbarkeitsfeatures für Amazon EC2

• Verfügbarkeitszonen: Isolierte Standorte innerhalb einer Region zur Redundanz.
• ASGs: Automatische Skalierung der Instanzenanzahl basierend auf Bedarf.
• Amazon ELB: Datenverkehrsverteilung über mehrere Instanzen hinweg.
• Platzierungsgruppen: Instanzplatzierung für Workloads mit geringer Latenz oder hohem Durchsatz.

Verfügbarkeitsfeatures für Azure-VM

• Verfügbarkeitszonen: Trennen Sie rechenzentren innerhalb einer Region physisch zur Ausfallsicherheit auf Zonenebene.
• Verfügbarkeitsgruppen: Logische Gruppierung zum Schutz vor Ausfällen auf Rackebene.
• Skalierungssätze für virtuelle Computer: Integrierte Orchestrierung für horizontale Workloadskalierung.
• Lastenausgleich und Anwendungsgateway: Layer-4- und Layer-7-Datenverkehrsverteilung.

Mapping-Übersetzung

Bewährte Methoden

• Bereitstellung über mehrere Zonen hinweg für eine Notfallwiederherstellung.
• Verwenden Sie Skalierungssätze für virtuelle Maschinen mit automatischen Skalierungsrichtlinien für die Flexibilität.
• Verwenden Sie ZRS für kritische Daten.
• Integrieren Sie Azure Monitor für Integritätsprüfungen und Benachrichtigungen.

Skalierung und Platzierung

AWS und Azure verwenden unterschiedliche Konstrukte zum Skalieren und Platzieren. Diese Unterschiede wirken sich auf die Flexibilität und Fehlerisolation während der Migration aus.

AWS-Ansatz

• ASGs: Passen Sie die Anzahl der Amazon EC2-Instanzen basierend auf Bedarf automatisch an, indem Sie Startvorlagen verwenden, die die Instanzkonfiguration und den Lebenszyklus definieren, einschließlich NICs und Datenträgern.
• Partitionsplatzierungsgruppen: Verteilen Sie Amazon EC2-Instanzen über mehrere Partitionen für Resilienz- und Workloads mit geringer Latenz.

Azure-Ansatz

• Skalierungssätze für virtuelle Computer: Bietet systemeigene Orchestrierung für die horizontale Skalierung, die in Load Balancer oder Application Gateway integriert ist.
• VM-Profile: Definiert die VM-Konfiguration und unterstützt die umfassende Löschung für die Ressourcenbereinigung.
• Fehlerdomänen und Verfügbarkeitsgruppen: Stellt die Isolation auf Rackebene bereit, die der AWS-Partitionierung ähnelt. Verwenden Sie für dedizierte Hardware dedizierten Host.

Wichtige Unterschiede

Schritt 4: Auswerten

Führen Sie nach Abschluss der Migration die folgenden Überprüfungsschritte aus:

• Validieren Sie den Betriebssystemstart und die Gesundheit des Agenten.
• Vergewissern Sie sich, dass der Datenträgerdurchsatz, die Latenz und die Netzwerkleistung den Erwartungen entsprechen.
• Testen Sie das Skalierungsverhalten und den Lastenausgleich.
• Überprüfen der Anwendungsfunktionalität und Abhängigkeiten.
• Richten Sie Azure Monitor-Warnungen und -Protokollierung ein.

Die erfolgreiche Überprüfung weist darauf hin, dass die Arbeitsauslastung für die Produktionskürzung bereit ist.

Verwandte Inhalte

• Übersicht über virtuelle Computer
• Azure für AWS-Spezialisten
• Vergleichen von AWS- und Azure-Computediensten
• Migrieren einer Workload von AWS zu Azure