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

Es gibt eine Reihe verschiedener Arten von Zertifikaten, die bei der Planung Ihrer App Service-Verlagerung berücksichtigt werden müssen:

• ein kostenloses verwaltetes Zertifikat von App Service kann nicht exportiert werden.
• ein App Service Certificate durch Azure Key Vault kann mithilfe von PS1/CLI exportiert werden.
• ein Zertifikat, das Sie außerhalb von App Service verwalten.
• ein App Service Certificate, das nicht über Azure Key Vault verwaltet wird, kann exportiert werden.
• App Service Certificate-Ressourcen können in eine neue Ressourcengruppe oder in ein neues Abonnement, aber nicht zwischen Regionen verschoben werden. Regionsübergreifende Verlagerungen werden von App Service Certificates nicht unterstützt.
• Verwaltete Zertifikate, die Sie in Azure Key Vault verwalten und speichern, müssten zuerst aus dem Quell-Key Vault exportiert und erneut in den Ziel-Key Vault importiert werden, der der Ziel-App zugeordnet ist.

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

• Überprüfen Sie App Configuration auf Umgebung und regionsspezifische Einstellungen, die möglicherweise geändert werden müssen. Stellen Sie sicher, dass Sie die Datenträgerdateikonfiguration prüfen, die möglicherweise mit den App-Einstellungen außer Kraft gesetzt wird.

• Berücksichtigen Sie, dass die Konfiguration auch von einer zentralen (nachgeordneten) Datenbankabhängigkeit oder einem Dienst wie Azure Application Configuration verwaltet werden kann.

• Erstellen Sie Key Vault-Verweise für App Service erneut. Key Vault-Verweise beziehen sich auf den eindeutigen MSI, der der Ressource zugewiesen ist (die Zugriff auf die KV-Datenebene hat), und der Key Vault selbst muss sich sehr wahrscheinlich in derselben Quellregion befinden. VZ Key Vault-Inhalte können nicht über eine geografische Azure-Grenze exportiert werden.

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}.azurwwebsites.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

• Erstellen Sie Identitäten verwalteter App Service-Dienste in der neuen Zielregion erneut.

• Weisen Sie dem neuen MSI Zugriff auf den Downstream-Anmeldeinformationsdienst (RBAC) zu. In der Regel benutzt eine automatisch erstellte Microsoft Entra ID App (eine von EasyAuth verwendete) standardmäßig den App-Ressourcennamen. Eventuell muss hier das Neuerstellen einer neuen Ressource in der Zielregion bedacht werden. Ein benutzerdefinierter Dienstprinzipal wäre nützlich – da er sowohl auf die Quelle als auch auf das Ziel mit zusätzlichen Zugriffsberechtigungen für Zielbereitstellungsressourcen angewendet werden kann.

• 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