Verlagern von Azure-App Services in eine andere Region

In diesem Artikel wird beschrieben, wie Sie App Service-Ressourcen in eine andere Azure-Region verschieben.

Es gibt verschiedene Gründe, warum Sie vielleicht Ihre vorhandenen Azure-Ressourcen aus einer Region in eine andere verschieben möchten. Möglicherweise möchten Sie Folgendes ausführen:

• Nutzen Sie die Vorteile einer neuen Azure-Region.
• Stellen Sie Features oder Dienste bereit, die nur in bestimmten Regionen verfügbar sind.
• Erfüllen Sie interne Richtlinien- und Governanceanforderungen.
• Ausrichtung an Unternehmenszusammenschlüssen und -übernahmen
• Erfüllen Sie Kapazitätsplanungsanforderungen.

App Service-Ressourcen sind regionsspezifisch und können nicht in andere Regionen verschoben werden. Sie müssen eine Kopie Ihrer vorhandenen App Service-Ressourcen in der Zielregion erstellen und Ihren Inhalt dann in die neue App verschieben. Wenn Ihre Quell-App eine benutzerdefinierte Domäne verwendet, können Sie sie zu der neuen App in der Zielregion migrieren, nachdem die Verlagerung abgeschlossen ist.

Um das Kopieren Ihrer App zu vereinfachen, können Sie eine einzelne App Service-App in einem App Service-Plan in einer anderen Region sichern und wiederherstellen.

Voraussetzungen

• Stellen Sie sicher, dass sich die App Service-App in der Azure-Region befindet, aus der Sie sie verschieben möchten.
• Stellen Sie sicher, dass die Zielregion App Service und alle zugehörigen Dienste unterstützt, deren Ressourcen verschoben werden sollen.
• Überprüfen Sie, ob ausreichende Berechtigungen zum Bereitstellen von App Service-Ressourcen für das Zielabonnement und die Zielregion vorhanden sind.
• Überprüfen Sie, ob einer Azure-Richtlinie eine Regionseinschränkung zugewiesen ist.
• Berücksichtigen Sie alle Betriebskosten, da die Compute-Ressourcenpreise von Region zu Region variieren können. Rufen Sie den Preisrechner auf, um Ihre möglichen Kosten abzuschätzen.

Vorbereiten

Ermitteln Sie alle App Service-Ressourcen, die Sie aktuell verwenden. Beispiel:

• App Service-Apps
• App Service-Pläne
• Bereitstellungsslots
• In Azure erworbene benutzerdefinierte Domänen
• TLS-/SSL-Zertifikate
• Integration des virtuellen Azure-Netzwerks
• Hybridverbindungen
• Verwaltete Identitäten
• Sicherungseinstellungen

Bestimmte Ressourcen (z.B. importierte Zertifikate oder Hybridverbindungen) umfassen eine Integration in andere Azure-Dienste. Informationen dazu, wie Sie diese Ressourcen innerhalb von Regionen verschieben, finden Sie in der Dokumentation zu den jeweiligen Diensten.

Plan

Dieser Abschnitt ist eine Planungscheckliste in den folgenden Bereichen:

• Status-, Speicher- und nachgeordnete Abhängigkeiten
• Zertifikate
• Konfiguration
• VNet-Konnektivität / benutzerdefinierte Namen / DNS
• Identities
• Dienstendpunkte

Status-, Speicher- und nachgeordnete Abhängigkeiten

• Ermitteln Sie, ob Ihre App Service-App statusbehaftet oder statusfrei ist. Es wird zwar empfohlen, dass App Service-Apps statusfrei sind und nur die Dateien auf dem %HOME%\site-Laufwerk sein sollten, die zum Ausführen der bereitgestellten Anwendung mit temporären Dateien erforderlich sind, es ist jedoch weiterhin möglich, den Runtime-Anwendungsstatus auf dem virtuellen %HOME%\site-Laufwerk zu speichern. Wenn Ihre Anwendung den Status im gemeinsam genutzten Speicherpfad der App schreibt, sollten Sie auf jeden Fall planen, wie Sie diesen Status während einer Ressourcenverschiebung verwalten.

  Tipp

  Sie können Kudu zusammen mit dem Portalzugriff verwenden, um eine Dateizugriffs-API (Virtual File System, VFS) bereitzustellen, die Dateien im %HOME%\site-Verzeichnis lesen/schreiben kann. Weitere Informationen finden Sie im Kudu Wiki.

• Suchen Sie im Anwendungscode nach interner Zwischenspeicherung und Status.

• Deaktivieren Sie die Sitzungsaffinitätseinstellung. Wenn möglich, empfehlen wir, die Sitzungsaffinitätseinstellung zu deaktivieren. Das Deaktivieren der Sitzungsaffinität verbessert den Lastenausgleich für eine horizontale Skalierung. Jeder interne Status kann sich auf die Planung des Cutovers einer Workload auswirken – insbesondere, wenn erforderlich ist, dass keine Downtime auftritt. Wenn möglich, kann es von Vorteil sein, jeden Anwendungsstatus so umzugestalten, dass die Anwendung in Vorbereitung auf die Verschiebung statusfrei ist.

• Analysieren Sie Datenbankverbindungszeichenfolgen. Datenbankverbindungszeichenfolgen sind in den App-Einstellungen zu finden. Sie können jedoch auch hartcodiert oder in Konfigurationsdateien verwaltet werden, die mit der Anwendung ausgeliefert werden. Analysieren und planen Sie die Datenmigration/Replikation im Rahmen der Planung auf höherer Ebene ein, um die Workload zu verschieben. Bei gesprächsintensiven oder Latenz-kritischen Anwendungen wirkt es sich auf die Leistungsfähigkeit der Anwendung in der Zielregion ungünstig aus, auf Datenquellen in der Quellregion zurückzugreifen.

• Analysieren Sie die externe Zwischenspeicherung (z. B. Redis). Anwendungscaches sollten so nah wie möglich an der Anwendung bereitgestellt werden. Analysieren Sie, wie Caches gefüllt werden, Ablauf-/Entfernungsrichtlinien und alle Auswirkungen, die ein kalter Cache möglicherweise auf die ersten Benutzer hat, die nach dem Cutover auf die Workload zuzugreifen.

• Analysieren und Einplanen von API- (oder Anwendungs-)Abhängigkeiten Die regionsübergreifende Kommunikation ist wesentlich weniger leistungsfähig, wenn die App in der Zielregion auf Abhängigkeiten zurückgreift, die sich noch in der Quellregion befinden. Es wird empfohlen, alle nachgeordneten Abhängigkeiten im Rahmen der Workloadverlagerung zu verschieben. Allerdings sind *lokale* Ressourcen die Ausnahme, insbesondere die Ressourcen, die geografisch näher an der Zielregion liegen (wie dies bei Rückführungsszenarien der Fall sein kann).

  Azure Container Registry kann eine nachgeordnete (Runtime-)Abhängigkeit für App Service sein, die für die Ausführung für Custom Container Images konfiguriert ist. Es ist sinnvoller, dass sich die Container Registry in derselben Region wie die App selbst befindet. Erwägen Sie, die erforderlichen Images in eine neue ACR in der Ziel-Abruf-Region hochzuladen. Andernfalls sollten Sie das Georeplikationsfeature verwenden, wenn Sie beabsichtigen, die Images in der Quellregion beizubehalten.

• Analysieren und planen Sie regionale Dienste ein. Application Insights- und Log Analytics-Daten sind regionale Dienste. Erwägen Sie die Erstellung des neuen Application Insights- und Log Analytics-Speichers in der Zielregion. Bei App Insights wirkt sich eine neue Ressource auch auf die Verbindungszeichenfolge aus, die im Rahmen der Änderung in App Configuration aktualisiert werden muss.

Zertifikate

App Service Certificate-Ressourcen können in eine neue Ressourcengruppe oder in ein neues Abonnement, aber nicht zwischen Regionen verschoben werden. Zertifikate, die exportiert werden können, können auch in die App oder in Key Vault in der neuen Region importiert werden. Dieser Export- und Importvorgang entspricht einem Wechsel zwischen Regionen.

Es gibt verschiedene Arten von Zertifikaten, die bei der Planung Ihrer Dienstverlagerung berücksichtigt werden müssen:

Bescheinigungstyp	Exportable	Kommentare
Von App Service verwaltet	No	Erstellen Sie diese Zertifikate in der neuen Region neu.
Über Azure Key Vault verwaltet	Ja	Diese Zertifikate können aus Key Vault exportiert und dann in Key Vault in der neuen Region importiert werden.
Privater Schlüssel (selbstverwaltet)	Ja	Zertifikate, die Sie außerhalb von Azure erworben haben, können aus App Service exportiert und dann entweder in die neue App importiert oder in der neuen Region in Key Vault importiert werden.
Öffentlicher Schlüssel	No	Ihre App verfügt möglicherweise über Zertifikate mit nur einem öffentlichen Schlüssel und keinem Geheimnis, die für den Zugriff auf andere gesicherte Endpunkte verwendet werden. Rufen Sie die erforderlichen Zertifikatdateien für öffentliche Schlüssel ab, und importieren Sie sie in die App in der neuen Region.

Weitere zu berücksichtigende Punkte:

• Wenn die SSL-Verbindung einer App Service-App an eine für eine bestimmte App festgelegte IP gebunden ist, können App Assigned Addresses für Zulassungsauflistungsaufrufe von Drittanbieternetzwerken in App Service genutzt werden. Ein Netzwerk-/IT-Administrator möchte z. B. ausgehende Aufrufe aus einem lokalen Netzwerk oder VNet sperren, um eine statische, bekannte Adresse zu verwenden. Wenn das Feature „App Assigned Address“ in Verwendung ist, sollten Upstream-Firewallregeln, z. B. interne, externe oder von Dritten, für diejenigen, die Aufrufe in die App ausführen, überprüft und die neue Adresse sollte ihnen mitgeteilt werden. Firewallregeln können interne, externe oder von Dritten sein, z. B. von Partnern oder bekannten Kunden.

• Berücksichtigen Sie alle Upstream-Network Virtual Appliances (NVA) oder Reverseproxys. Die NVA-Konfiguration muss möglicherweise geändert werden, wenn Sie den Hostheader oder die SSL-Beendigung umschreiben.

Hinweis

App Service-Umgebung ist das einzige App Service-Angebot, das nachgeordnete Aufrufe nachgelagerter Anwendungsabhängigkeiten über SSL ermöglicht, wenn die SSL-Verschlüsselung sich auf selbstsignierte Zertifikate/PKI stützt, die mit nicht standardmäßigen Stammzertifizierungsstellen-Zertifikaten erstellt wurde. Der Mehrmandantendienst bietet Kunden keinen Zugriff für den Upload in den vertrauenswürdigen Zertifikatspeicher.

App Service Environment lässt noch keinen SSL-Zertifikatkauf zu, nur Bring Your Own-Zertifikate sind erlaubt. IP-SSL ist nicht möglich (und wäre sinnlos), SNI dagegen schon. Die interne App Service-Umgebung wäre nicht mit einer öffentlichen Domäne verknüpft, daher müssen die verwendeten SSL-Zertifikate vom Kunden bereitgestellt werden und sind dadurch transportierbar, z. B. Zertifikate für die interne Verwendung, die mithilfe von PKI generiert werden. App Service-Umgebung v3 im externen Modus nutzt die gleichen Features wie der reguläre Mehrmandanten-App Service.

Konfiguration

• Sie können eine Momentaufnahme der vorhandenen App-Einstellungen und Verbindungszeichenfolgen aus dem Azure-Portal erfassen. Erweitern Sie Einstellungen>Umgebungsvariablen, wählen Sie Erweiterte Bearbeitung entweder unter App-Einstellungen oder Verbindungszeichenfolgen aus, und speichern Sie die JSON-Ausgabe, die die vorhandenen Einstellungen oder Verbindungen enthält. Sie müssen diese Einstellungen in der neuen Region nachbilden, die Werte selbst werden sich aber wohl aufgrund der nachfolgenden Regionsänderungen in den verbundenen Diensten ändern.

• Vorhandene Key Vault-Verweise können nicht über eine geografische Azure-Grenze exportiert werden. Sie müssen alle erforderlichen Verweise in der neuen Region neu erstellen.

• Ihre App-Konfiguration wird möglicherweise von Azure App Configuration oder von einer anderen zentralen (nachgeschalteten) Datenbankabhängigkeit verwaltet. Überprüfen Sie alle App Configuration-Speicher oder ähnliche Speicher für umgebungs- und regionsspezifische Einstellungen, die möglicherweise Änderungen erfordern.

• Stellen Sie sicher, dass Sie die Datenträgerdateikonfiguration prüfen, die möglicherweise mit den Anwendungseinstellungen außer Kraft gesetzt wird.

VNet-Konnektivität / benutzerdefinierte Namen / DNS

• App Service-Umgebung ist ein in VNet eingebrachter Einmandantendienst. Die Netztechnologie der App Service-Umgebung unterscheidet sich von dem Mehrmandanten-App Service, der einen oder beide „privaten Endpunkte“ oder „regionale VNet-Integration“ erfordert. Zu den anderen Optionen, die möglicherweise im Spiel sind, gehören die Legacy-P2S VPN-basierte VNet-Integration und Hybrid Connections (ein Azure Relay-Dienst).

  Hinweis

  ASEv3 Networking wird vereinfacht: Der Azure Management-Datenverkehr und die App Service-Umgebungen-eigenen nachgeordneten Abhängigkeiten sind für das Virtual Network des Kunden nicht sichtbar, was die erforderliche Konfiguration erheblich vereinfacht, wenn der Kunde einen erzwungenen Tunnel für den gesamten Datenverkehr verwendet oder eine Teilmenge des ausgehenden Datenverkehrs über eine Network Virtual Appliance/Firewall sendet.

  Hybrid Connections (Azure Relay) sind regional. Wenn Hybrid Connections verwendet werden und obwohl ein Azure Relay Namespace in eine andere Region verschoben werden kann, wäre es einfacher, die Hybrid Connection erneut bereitzustellen (stellen Sie sicher, dass die Hybridverbindung in der neuen Region für die Bereitstellung der Zielressourcen eingerichtet ist) und sie erneut mit dem Hybridverbindungsmanager zu verknüpfen. Der Standort des Hybridverbindungsmanagers sollte sorgfältig überlegt werden.

• Folgen Sie der Strategie für eine Betriebsbereitschaftsregion. Stellen Sie sicher, dass Kernnetztechnologie und Konnektivität, Hubnetzwerk, Domänencontroller, DNS, VPN oder Express Route usw. vor der Ressourcenverlagerung vorhanden sind und getestet werden.

• Überprüfen sie alle Upstream- oder Downstream-Netzwerk-ACLs und die Konfiguration. Ziehen Sie z. B. einen externen nachgeordneten Dienst in Betracht, der nur Ihren App-Datenverkehr zulässt. Ein Migrieren zu einem neuen Application Plan für einen Mehrmandanten-App Service würde dann auch eine Änderung der ausgehenden IP-Adressen bedeuten.

• In den meisten Fällen ist es am besten, sicherzustellen, dass die VNets der Zielregion über einen eindeutigen Adressraum verfügen. Ein eindeutiger Adressraum erleichtert die VNet-Konnektivität, falls erforderlich, um z. B. Daten zu replizieren. Daher ist es in diesen Szenarien implizit erforderlich, Folgendes zu ändern:

  • Privates DNS
  • jede hartcodierte oder externe Konfiguration, die Ressourcen nach IP-Adresse (ohne Hostname) referenziert
  • Netzwerk-ACLs einschließlich Network Security Groups und Firewallkonfiguration (bedenken Sie hier auch die Auswirkungen auf lokale NVAs)
  • alle Routingregeln, benutzerdefinierte Route Tables

  Überprüfen Sie außerdem die Konfiguration einschließlich regionsspezifischer IP-Bereiche/Dienst-Tags, wenn vorhandene DevOps-Bereitstellungsressourcen übertragen werden.

• Weniger Änderungen sind für vom Kunden bereitgestellte private DNS erforderlich, die für die Weiterleitung an Azure-Domänen und Azure DNS Private Zones konfiguriert sind. Da private Endpunkte jedoch auf einem Ressourcen-FQDN basieren und dies häufig auch der Ressourcenname ist (der in der Zielregion erwartungsgemäß anders ist), denken Sie daran, für die Konfiguration die Gegenprobe zu machen, um sicherzustellen, dass FQDNs, auf die in der Konfiguration verwiesen wird, entsprechend aktualisiert werden.

• Erstellen Sie private Endpunkte, falls verwendet, in der Zielregion erneut. Das Gleiche gilt für die regionale VNet-Integration.

• DNS für App Service-Umgebung wird in der Regel über die private benutzerdefinierte DNS-Lösung von Kunden verwaltet (es gibt eine manuelle Außerkraftsetzung von Einstellungen, die auf Pro-App-Basis verfügbar ist). App Service-Umgebung bietet einen Lastenausgleich für den ein-/ausgehenden Datenverkehr, während App Service selbst nach Hostheadern filtert. Daher können mehrere benutzerdefinierte Namen auf denselben Eingangsendpunkt von App Service-Umgebung verweisen. App Service-Umgebung erfordert keine Domänenüberprüfung.

  Hinweis

  Kudu-Endpunkt für App Service-Umgebung v3 ist nur unter {resourcename}.scm.{asename}.appserviceenvironment.net verfügbar. Weitere Informationen zu DNS und Netztechnologie von App Service-Umgebung v3 finden Sie unter Netztechnologie von App Service-Umgebung.

  Für App Service-Umgebung verfügt der Kunde über das Routing und somit die Ressourcen, die für den Cutover verwendet werden. Wo immer der Zugriff auf die App Service-Umgebung extern aktiviert ist – in der Regel über eine Layer 7 NVA oder Reverse Proxy – kann Traffic Manager oder Azure Front Door/ein anderer globaler L7-Lastenausgleichsdienst verwendet werden.

• Für die öffentliche Mehrmandantenversion des Diensts wird ein Standardname {resourcename}.azurewebsites.net für die Endpunkte der Datenebene bereitgestellt, zusammen mit einem Standardnamen für den Kudu-Endpunkt (SCM). Da der Dienst standardmäßig einen öffentlichen Endpunkt bereitstellt, muss die Bindung überprüft werden, um das Domäneneigentum zu bestätigen. Sobald die Bindung jedoch vorhanden ist, ist weder eine erneute Überprüfung noch erforderlich, dass öffentliche DNS-Einträge auf den App Service-Endpunkt verweisen.

• Wenn Sie eine benutzerdefinierte Domäne verwenden, binden Sie sie präemptiv an die Ziel-App. Überprüfen und aktivieren Sie die Domäne in der Ziel-App.

Identities

• Sie müssen alle systemseitig zugewiesenen verwalteten Identitäten zusammen mit Ihrer App in der neuen Zielregion neu erstellen. In der Regel benutzt eine automatisch erstellte Microsoft Entra ID-App, die von EasyAuth verwendet wird, standardmäßig den App-Ressourcennamen.

• Benutzerseitig zugewiesene verwaltete Identitäten können auch nicht in Regionen verschoben werden. Um benutzerseitig zugewiesene verwaltete Identitäten in derselben Ressourcengruppe mit Ihrer App beizubehalten, müssen Sie sie in der neuen Region neu erstellen. Weitere Informationen finden Sie unter Verlagern verwalteter Identitäten für Azure-Ressourcen in eine andere Region.

• Gewähren Sie den verwalteten Identitäten die gleichen Berechtigungen in Ihren verschobenen Diensten wie die ursprünglichen Identitäten, die sie ersetzen, einschließlich Gruppenmitgliedschaften.

• Planen Sie das Verlagern des Identity Provider (IDP) in die Zielregion ein. Obwohl Microsoft Entra ID ein globaler Dienst ist, stützen sich einige Lösungen auf einen lokalen (oder nachgeordneten lokalen) IDP.

• Aktualisieren Sie alle Ressourcen für den App Service, die möglicherweise auf Kudu FTP-Anmeldeinformationen angewiesen sind.

Dienstendpunkte

Die Endpunkte des virtuellen Netzwerkdiensts für Azure App Service beschränken den Zugriff auf angegebene virtuelle Netzwerke. Die Endpunkte können auch den Zugriff auf eine Liste von IPv4-Adressbereichen (Internet Protocol, Version 4) beschränken. Allen Benutzern, die außerhalb dieser Quellen eine Verbindung mit Event Hubs herstellen, wird der Zugriff verweigert. Wenn Dienstendpunkte in der Quellregion für die Event Hubs-Ressource konfiguriert wurden, muss das auch im Zielwert der Fall sein.

Für eine erfolgreiche Wiederherstellung von Azure App Service in der Zielregion müssen vorher das VNet und das Subnetz erstellt werden. Wenn die Verschiebung dieser beiden Ressourcen mit dem Azure Resource Mover-Tool durchgeführt wird, werden die Dienstendpunkte nicht automatisch konfiguriert. Daher müssen sie manuell konfiguriert werden, was über das Azure-Portal, die Azure CLI oder über Azure PowerShell erfolgen kann.

Verschieben

Um App Service-Ressourcen zu verschieben, können Sie entweder das Azure-Portal oder Infrastructure as Code (IaC) nutzen.

Verschieben mithilfe des Microsoft Azure-Portals

Der größte Vorteil der Verwendung des Microsoft Azure-Portals zum Verschieben ist seine Einfachheit. Die App, der Plan und der Inhalt sowie viele Einstellungen werden in die neue App Service-Ressource und den neuen Plan geklont.

Beachten Sie, dass Sie für App Service-Umgebung-Ebenen (isoliert) zuerst die gesamte App Service-Umgebung in einer anderen Region erneut bereitstellen müssen, und dann können Sie mit der erneuten Bereitstellung der einzelnen Pläne in der neuen App Service-Umgebung in der neuen Region beginnen.

So verschieben Sie Ihre App Service-Ressourcen mithilfe des Microsoft Azure-Portals in eine neue Region:

1. Erstellen Sie eine Sicherung der Quell-App.
2. Erstellen Sie eine App in einem neuen App Service-Plan in der Zielregion.
3. Stellen Sie die App aus der Sicherung in der Ziel-App wieder her.
4. Bei Verwendung einer benutzerdefinierten Domäne binden Sie sie im Vorfeld an die Ziel-App mit asuid. und aktivieren Sie die Domäne in der Ziel-App.
5. Wählen Sie für alle anderen Einstellungen in Ihrer Ziel-App dieselben Einstellungen wie in der Quell-App, und überprüfen Sie Ihre Konfiguration.
6. Wenn alle Voraussetzungen erfüllt sind und die benutzerdefinierte Domäne auf die Ziel-App zeigen kann, ordnen Sie den Domänennamen neu zu.

Verschieben mithilfe von IaC

Nutzen Sie IaC, wenn eine vorhandene Pipeline für Continuous Integration und Continuous Delivery/Deployment (CI/CD) vorhanden ist oder erstellt werden kann. Mit einer CI/CD-Pipeline kann Ihre App Service-Ressource durch eine Bereitstellungsaktion oder eine Kudu-ZIP-Bereitstellung in der Zielregion erstellt werden.

SLA-Anforderungen sollten bestimmen, wie viel zusätzlicher Aufwand erforderlich ist. Beispiel: Ist dies eine erneute Bereitstellung mit begrenzter Downtime, oder ist es ein nahezu in Echtzeit erforderlicher Cutover mit minimaler bis gar keiner Downtime?

Die Einbeziehung externer, globaler Datenverkehrsrouting-Edgedienste, wie Traffic Manager oder Azure Front Door, trägt dazu bei, externen Benutzern und Anwendungen den Cutover zu erleichtern.

Tipp

Es ist möglich, Traffic Manager (ATM) zu verwenden, wenn App Services hinter privaten Endpunkten fehlschlägt. Obwohl die privaten Endpunkte von Traffic Manager Probes nicht erreichbar sind – wenn alle Endpunkte herabgestuft werden, ermöglicht ATM das Routing. Weitere Informationen erhalten Sie unter Steuern des Azure App Service-Datenverkehrs mit Azure Traffic Manager.

Überprüfen

Testen und überprüfen Sie Azure App Service mit den empfohlenen Richtlinien, nachdem die Verlagerung abgeschlossen ist:

• Führen Sie eine Feuerprobe und einen Integrationstest aus, nachdem der Azure App Service in die Zielregion verschoben wurde. Sie können einen Test manuell oder über ein Skript ausführen. Überprüfen Sie unbedingt, ob alle Konfigurationen und abhängigen Ressourcen ordnungsgemäß verknüpft sind und auf alle konfigurierten Daten zugegriffen werden kann.

• Überprüfen Sie alle Azure App Service-Komponenten und Integrationen.

• Führen Sie Integrationstests für die Bereitstellung in der Zielregion durch, einschließlich aller formalen Regressionstests. Integrationstests sollten sich an der üblichen Rhythm of Business-Bereitstellung und Testprozessen ausrichten, die für die Workload gelten.

• Setzen Sie in einigen Szenarien, insbesondere wenn die Verlagerung Aktualisierungen, Änderungen an den Anwendungen oder an Azure-Ressourcen oder eine Änderung des Nutzungsprofils umfasst, Auslastungstests ein, um zu überprüfen, ob die neue Workload für den Zweck geeignet ist. Auslastungstests sind auch eine Möglichkeit, Vorgänge zu überprüfen und die Abdeckung zu überwachen. Setzen Sie beispielsweise Auslastungstests ein, um zu überprüfen, ob die erforderliche Infrastruktur und Anwendungsprotokolle ordnungsgemäß generiert werden. Auslastungstests sollten mit festgelegten Workloadleistungs-Baselines verglichen werden.

Tipp

Eine App Service-Verlagerung ist auch eine Möglichkeit, die Verfügbarkeits- und Notfallwiederherstellungsplanung neu zu bewerten. App Service und App Service-Umgebung (App Service Environment v3) unterstützen Verfügbarkeitszonen, und es wird empfohlen, eine Verfügbarkeitszonenkonfiguration vorzunehmen. Beachten Sie die Voraussetzungen für Bereitstellung, Preise und Einschränkungen, und berücksichtigen Sie diese in der Ressourcenverschiebungsplanung. Weitere Informationen zu Verfügbarkeitszonen und App Service finden Sie unter Zuverlässigkeit in Azure App Service.

Bereinigung

Löschen Sie die Quell-App und den App Service-Plan. Für einen App Service-Plan eines kostenpflichtigen Tarifs fallen auch dann Gebühren an, wenn keine App ausgeführt wird.

Nächste Schritte

Klonen der Azure App Service-App mit PowerShell