Freigeben über

Migrieren von Azure Application Gateway und Web Application Firewall von V1 zu V2

  • Artikel

Wir haben am 28. April 2023 die Deaktivierung der Anwendungsgateway-V1-SKU (Standard und WAF) angekündigt. Die SKU V1 wird am 28. April 2026 eingestellt. Weitere Informationen finden Sie unter Migrieren Ihrer Application Gateways von V1-SKU zu V2-SKU bis zum 28. April 2026.

Azure Application Gateway and Web Application Firewall (WAF) V2 bietet jetzt zusätzliche Features wie Automatische Skalierung, Verfügbarkeit, Zonenredundanz, höhere Leistung, schnellere Vorgänge und verbesserten Durchsatz im Vergleich zu V1. Außerdem werden alle neuen Features für die V2-SKU veröffentlicht. Es wird dringend empfohlen, dass Sie jetzt einen Migrationsplan erstellen.

V1-Gateways werden nicht automatisch auf V2 aktualisiert. Dieser Migrationsleitfaden hilft Ihnen bei der Planung und Durchführung der Migrationen.

Es gibt zwei Phasen in einer Migration:

  1. Migrieren der Konfiguration
  2. Migrieren des Clientdatenverkehrs

Dieser Artikel hilft in erster Linie bei der Konfigurationsmigration. Die Migration des Clientdatenverkehrs variiert je nach Umgebung. Einige allgemeine Empfehlungen finden Sie in diesem Artikel.

Voraussetzungen

  • Ein Azure-Konto mit einem aktiven Abonnement. Sie können kostenlos ein Konto erstellen.
  • Ein vorhandenes Anwendungsgateway V1 Standard.
  • Stellen Sie sicher, dass Sie über die aktuellen PowerShell-Module verfügen, oder verwenden Sie Azure Cloud Shell im Portal.
  • Wenn Sie PowerShell lokal ausführen, müssen Sie auch Connect-AzAccount ausführen, um eine Verbindung mit Azure herzustellen.
  • Vergewissern Sie sich, dass im V1-Abonnement kein Anwendungsgateway mit dem angegebenen AppGW-V2-Namen und Ressourcengruppennamen vorhanden ist. Dadurch werden die vorhandenen Ressourcen umgeschrieben.
  • Wird eine öffentliche IP-Adresse bereitgestellt, vergewissern Sie sich, dass sie sich im Zustand „Erfolgreich“ befindet. Wird stattdessen „AppGWResourceGroupName“ bereitgestellt, stellen Sie sicher, dass die öffentliche IP-Ressource mit dem Namen „AppGWV2Name-IP“ nicht in einer Ressourcengruppe mit dem Namen „AppGWResourceGroupName“ im V1-Abonnement vorhanden ist.
  • Für die V1-SKU sind Authentifizierungszertifikate erforderlich, um TLS-Verbindungen mit Back-End-Servern einzurichten. Die V2-SKU erfordert das Hochladen von vertrauenswürdigen Stammzertifikaten für denselben Zweck. Während V1 die Verwendung von selbstsignierten Zertifikaten als Authentifizierungszertifikate zulässt, erfordert V2 das Generieren und Hochladen eines selbstsignierten Stammzertifikats, wenn selbstsignierte Zertifikate im Back-End verwendet werden.
  • Stellen Sie sicher, dass während der Migration kein anderer Vorgang für das V1-Gateway oder eine der zugehörigen Ressourcen geplant ist.

Azure Cloud Shell

Azure hostet Azure Cloud Shell, eine interaktive Shell-Umgebung, die Sie über Ihren Browser nutzen können. Sie können entweder Bash oder PowerShell mit Cloud Shell verwenden, um mit Azure-Diensten zu arbeiten. Sie können die vorinstallierten Befehle von Cloud Shell verwenden, um den Code in diesem Artikel auszuführen, ohne etwas in Ihrer lokalen Umgebung installieren zu müssen.

Starten von Azure Cloud Shell:

Option Beispiel/Link
Wählen Sie rechts oben in einem Code- oder Befehlsblock die Option Ausprobieren aus. Durch die Auswahl von Ausprobieren wird der Code oder Befehl nicht automatisch in Cloud Shell kopiert. Screenshot: Beispiel von „Jetzt testen“ für Azure Cloud Shell.
Rufen Sie https://shell.azure.com auf, oder klicken Sie auf die Schaltfläche Cloud Shell starten, um Cloud Shell im Browser zu öffnen. Schaltfläche zum Starten von Azure Cloud Shell.
Wählen Sie im Azure-Portal rechts oben im Menü die Schaltfläche Cloud Shell aus. Screenshot: Schaltfläche „Cloud Shell“ im Azure-Portal

So verwenden Sie Azure Cloud Shell:

  1. Starten Sie Cloud Shell.

  2. Wählen Sie die Schaltfläche Kopieren für einen Codeblock (oder Befehlsblock) aus, um den Code oder Befehl zu kopieren.

  3. Fügen Sie den Code oder Befehl mit STRG+UMSCHALT+V unter Windows und Linux oder CMD+UMSCHALT+V unter macOS in die Cloud Shell-Sitzung ein.

  4. Drücken Sie die EINGABETASTE, um den Code oder Befehl auszuführen.

Hinweis

Es wird empfohlen, das Azure Az PowerShell-Modul für die Interaktion mit Azure zu verwenden. Informationen zu den ersten Schritten finden Sie unter Installieren von Azure PowerShell. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.

Wichtig

Führen Sie das Set-AzContext -Subscription <V1 application gateway SubscriptionId>-Cmdlet jedes Mal vor dem Ausführen des Migrationsskripts aus. Dies ist erforderlich, um den aktiven Azure-Kontext auf das richtige Abonnement festzulegen, da das Migrationsskript möglicherweise die vorhandene Ressourcengruppe bereinigen kann, wenn er nicht im aktuellen Abonnementkontext vorhanden ist. Dieser Schritt ist für Version 1.0.11 und höher des Migrationsskripts nicht obligatorisch.

Wichtig

Mit Version 1.0.11 ist jetzt eine neue stabile Version des Migrationsskripts verfügbar, die wichtige Fehlerbehebungen und Updates enthält. Verwenden Sie diese Version, um mögliche Probleme zu vermeiden.

Konfiguration der Migration

In diesem Dokument wird ein Azure PowerShell-Skript bereitgestellt. Es führt die folgenden Vorgänge aus, um Sie bei der Konfiguration zu unterstützen:

  • Es wird ein neues Standard_V2- oder WAF_V2-Gateway in einem von Ihnen angegebenen Subnetz eines virtuellen Netzwerks erstellt.
  • Die Konfiguration, die zu dem V1-Standard oder -WAF-Gateway gehört, wird nahtlos in das neu erstellte Standard_V2- oder WAF_V2-Gateway kopiert.

Herunterladen des Skripts

Sie können das Migrationsskript aus dem PowerShell-Katalog herunterladen. Ein neues stabiles Release (Version 1.0.11) des Migrationsskripts ist verfügbar, das wichtige Updates und Fehlerbehebungen enthält. Es wird empfohlen, diese stabile Version zu verwenden.

Verwenden des Skripts

Hinweis

Führen Sie das Set-AzContext -Subscription <V1 application gateway SubscriptionId>-Cmdlet jedes Mal vor dem Ausführen des Migrationsskripts aus. Dies ist erforderlich, um den aktiven Azure-Kontext auf das richtige Abonnement festzulegen, da das Migrationsskript möglicherweise die vorhandene Ressourcengruppe bereinigen kann, wenn er nicht im aktuellen Abonnementkontext vorhanden ist. Dieser Schritt ist für Version 1.0.11 und höher des Migrationsskripts nicht obligatorisch.

Je nach dem, wie Ihre lokale PowerShell-Umgebung eingerichtet und eingestellt ist, gibt es zwei Optionen für Sie:

  • Haben Sie die Azure Az-Module nicht installiert, oder haben Sie kein Problem damit, die Azure Az-Module zu deinstallieren, sollten Sie die Install-Script-Option verwenden, um das Skript auszuführen.
  • Wenn Sie die Azure Az-Module beibehalten müssen, besteht die beste Vorgehensweise darin, das Skript herunterzuladen und direkt auszuführen.

Um festzustellen, ob Sie die Azure Az-Module installiert haben, führen Sie Get-InstalledModule -Name az aus. Werden keine installierten Az-Module angezeigt, können Sie die Install-Script-Methode verwenden.

Damit Sie diese Option nutzen können, dürfen keine Azure Az-Module auf Ihrem Computer installiert sein. Wenn diese installiert sind, zeigt der folgende Befehl einen Fehler an. Sie können entweder die Azure Az-Module deinstallieren oder die andere Option nutzen, um das Skript manuell herunterzuladen und es auszuführen.

Führen Sie das Skript mit dem folgenden Befehl aus, um die neueste Version zu erhalten:

Install-Script -Name AzureAppGWMigration -Force

Mit diesem Befehl werden auch die erforderlichen Az-Module installiert.

Installieren durch direktes Verwenden des Skripts

Wenn Sie einige Azure Az-Module installiert haben und diese nicht deinstallieren können (oder möchten), laden Sie das Skript manuell herunter, indem Sie die Registerkarte Manual Download im Skript-Downloadlink verwenden. Das Skript wird als reine NUPKG-Datei heruntergeladen. Informationen, wie das Skript aus dieser NUPKG-Datei installiert wird, finden Sie unter Manuelles Herunterladen des Pakets.

Version 1.0.11 ist die neue Version des Migrationsskripts, die wichtige Fehlerbehebungen enthält. Es wird empfohlen, diese stabile Version zu verwenden.

So überprüfen Sie die Version des heruntergeladenen Skripts

Gehen Sie wie folgt vor, um die Version des heruntergeladenen Skripts zu überprüfen:

  • Entpacken Sie den Inhalt des NuGet-Pakets.
  • Öffnen Sie im Ordner die Datei .PS1, und überprüfen Sie die Angabe .VERSION oben, um die Version des heruntergeladenen Skripts zu bestätigen.
<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.
  • Stellen Sie sicher, dass Sie die neueste stabile Version aus dem PowerShell-Katalog verwenden

Wie wird das Skript ausgeführt

So führen Sie das Skript aus

  1. Verwenden Sie Connect-AzAccount, um eine Verbindung mit Azure herzustellen.

  2. Verwenden Sie Import-Module Az, um die Az-Module zu importieren.

  3. Führen Sie das Cmdlet Set-AzContext aus, um den aktiven Azure-Kontext auf das korrekte Abonnement festzulegen. Dies ist ein wichtiger Schritt, da das Migrationsskript möglicherweise die vorhandene Ressourcengruppe bereinigt, wenn sie im aktuellen Abonnementkontext nicht vorhanden ist.

    Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'

  4. Führen Sie Get-Help AzureAppGWMigration.ps1 aus, um sich die erforderlichen Parameter anzusehen:

    AzureAppGWMigration.ps1
 -resourceId <V1 application gateway Resource ID>
 -subnetAddressRange <subnet space you want to use>
 -appgwName <string to use to append>
 -AppGWResourceGroupName <resource group name you want to use>
 -sslCertificates <comma-separated SSLCert objects as above>
 -trustedRootCertificates <comma-separated Trusted Root Cert objects as above>
 -privateIpAddress <private IP string>
 -publicIpResourceId <public IP name string>
 -validateMigration -enableAutoScale

Hinweis

Führen Sie während der Migration für das V1-Gateway oder eine der zugehörigen Ressourcen keine anderen Vorgänge aus.

Parameter für das Skript:

  • resourceId: [Zeichenfolge]: Erforderlich: – Dieser Parameter ist die Azure-Ressourcen-ID für Ihr vorhandenes Standard-V1- oder WAF-V1-Gateway. Um diesen Zeichenfolgenwert zu finden, navigieren Sie zum Azure-Portal, wählen Sie Ihr Anwendungsgateway oder Ihre WAF-Ressource aus, und klicken Sie auf den Link Eigenschaften für das Gateway. Die Ressourcen-ID wird auf dieser Seite angezeigt.

    Sie können auch die folgenden Azure PowerShell-Befehle ausführen, um die Ressourcen-ID zu ermitteln:

    $appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
$appgw.Id

  • subnetAddressRange: [Zeichenfolge]: Erforderlich:: Dieses Parameter ist der IP-Adressraum, den Sie einem neuen Subnetz, das Ihr neues V2-Gateway enthält, zugewiesen haben (oder zuweisen möchten). Der Adressraum muss in der CIDR-Notation angegeben werden. Beispiel: 10.0.0.0/24. Sie müssen dieses Subnetz nicht im Voraus erstellen, aber das CIDR muss Teil des VNET-Adressraums sein. Wenn das Subnetz nicht vorhanden ist, erstellt das Skript es; wenn es vorhanden ist, wird dieses vorhandene Subnetz verwendet. (Stellen Sie sicher, dass das Subnetz leer ist oder nur das V2-Gateway enthält (sofern vorhanden) und über genügend verfügbare Ps verfügt).

  • appgwName: [Zeichenfolge]: Optional. Dies ist eine Zeichenfolge, die als der Name des neuen Standard_V2- oder WAF_V2-Gateways verwendet werden soll. Ist dieser Parameter nicht angegeben, wird der Name Ihres vorhandenen V1-Gateways verwendet, an den das Suffix _V2 angefügt ist.

  • AppGWResourceGroupName: [Zeichenfolge]: Optional: Name der Ressourcengruppe, in der V2-Anwendungsgateway-Ressourcen erstellt werden sollen (Standardwert ist <V1-app-gw-rgname>)

Hinweis

Vergewissern Sie sich, dass im V1-Abonnement kein Anwendungsgateway mit dem angegebenen AppGW-V2-Namen und Ressourcengruppennamen vorhanden ist. Dadurch werden die vorhandenen Ressourcen umgeschrieben.

  • sslCertificates: [PSApplicationGatewaySslCertificate]: Optional. Eine Liste aus PSApplicationGatewaySslCertificate-Objekten, die Sie mit Kommas als Trennzeichen erstellt haben und in der die TLS/SSL-Zertifikate aus Ihrem V1-Gateway aufgeführt sind, muss in das neue V2-Gateway hochgeladen werden. Für jedes Ihrer TLS/SSL-Zertifikate, die für Ihr Standard-V1- oder -WAF-V1-Gateway konfiguriert sind, können Sie über den hier gezeigten New-AzApplicationGatewaySslCertificate-Befehl ein neues PSApplicationGatewaySslCertificate-Objekt erstellen. Sie benötigen den Pfad zu Ihrer TLS/SSL-Zertifikatsdatei und das Kennwort.

    Dieser Parameter ist nur optional, wenn Sie für das V1-Gateway oder die V1-WAF keine HTTPS-Listener konfiguriert haben. Sobald Sie mindestens einen HTTPS-Listener eingerichtet haben, müssen Sie diesen Parameter angeben.

    $password = ConvertTo-SecureString <cert-password> -AsPlainText -Force
$mySslCert1 = New-AzApplicationGatewaySslCertificate -Name "Cert01" `
  -CertificateFile <Cert-File-Path-1> `
  -Password $password
$mySslCert2 = New-AzApplicationGatewaySslCertificate -Name "Cert02" `
  -CertificateFile <Cert-File-Path-2> `
  -Password $password

    Sie können $mySslCert1, $mySslCert2 (durch Komma getrennt) aus dem vorherigen Beispiel als Werte für diesen Parameter im Skript übergeben.

  • sslCertificates aus Keyvault: Optional. Sie können die in Azure Key Vault gespeicherten Zertifikate herunterladen und an das Migrationsskript übergeben. Führen Sie den folgenden Befehl aus, um das Zertifikat als PFX-Datei herunterzuladen. Mit diesen Befehlen wird auf die SecretId zugegriffen, und anschließend wird der Inhalt als PFX-Datei gespeichert.

     $vaultName = ConvertTo-SecureString <kv-name> -AsPlainText -Force
 $certificateName = ConvertTo-SecureString <cert-name> -AsPlainText -Force
 $password = ConvertTo-SecureString <password> -AsPlainText -Force

 $pfxSecret = Get-AzKeyVaultSecret -VaultName $vaultName -Name $certificateName -AsPlainText
 $secretByte = [Convert]::FromBase64String($pfxSecret)
 $x509Cert = New-Object Security.Cryptography.X509Certificates.X509Certificate2
 $x509Cert.Import($secretByte, $null, [Security.Cryptography.X509Certificates.X509KeyStorageFlags]::Exportable)
 $pfxFileByte = $x509Cert.Export([Security.Cryptography.X509Certificates.X509ContentType]::Pkcs12, $password)

 # Write to a file
 [IO.File]::WriteAllBytes("KeyVaultcertificate.pfx", $pfxFileByte)

    Für jedes von Keyvault heruntergeladene Zertifikat können Sie ein neues PSApplicationGatewaySslCertificate-Objekt über den hier gezeigten Befehl New-AzApplicationGatewaySslCertificate erstellen. Sie benötigen den Pfad zu Ihrer TLS/SSL-Zertifikatsdatei und das Kennwort.

    //Convert the downloaded certificate to SSL object
$password = ConvertTo-SecureString  <password> -AsPlainText -Force 
$cert = New-AzApplicationGatewaySSLCertificate -Name <certname> -CertificateFile <Cert-File-Path-1> -Password $password

  • trustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: Optional. Eine Liste aus PSApplicationGatewayTrustedRootCertificate-Objekten, die Sie mit Kommas als Trennzeichen erstellt haben und in der die vertrauenswürdigen Stammzertifikate aufgeführt sind, die zur Authentifizierung Ihrer Back-End-Instanzen aus Ihrem v2-Gateway verwendet werden.

    $certFilePath = ".\rootCA.cer"
$trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath

    Informationen, wie eine Liste aus PSApplicationGatewayTrustedRootCertificate-Objekten erstellt wird, finden Sie unter New-AzApplicationGatewayTrustedRootCertificate.

  • privateIpAddress: [Zeichenfolge]: Optional. Eine bestimmte private IP-Adresse, die Sie Ihrem neuen V2-Gateway zuordnen möchten. Diese Adresse muss aus dem VNet stammen, das Sie für Ihr neues V2-Gateway zuordnen. Ist dieser Parameter nicht angegeben, weist das Skript eine private IP-Adresse für Ihr V2-Gateway zu.

  • publicIpResourceId: [Zeichenfolge]: Optional. Die Ressourcen-ID einer vorhandenen öffentlichen IP-Adresse (Standard-SKU-Ressource) in Ihrem Abonnement, die Sie dem neuen V2-Gateway zuordnen möchten. Wird der Ressourcenname einer öffentlichen IP-Adresse bereitgestellt, vergewissern Sie sich, dass sie sich im Zustand „Erfolgreich“ befindet. Wird keine öffentliche IP-Adresse angegeben, weist das Skript eine neue öffentliche IP-Adresse in der gleichen Ressourcengruppe zu. Der Name besteht aus dem Namen des V2-Gateways mit dem Zusatz -IP. Wird keine öffentliche IP-Adresse, sondern„AppGWResourceGroupName“ bereitgestellt, stellen Sie sicher, dass die öffentliche IP-Ressource mit dem Namen „AppGWV2Name-IP“ nicht in einer Ressourcengruppe mit dem Namen „AppGWResourceGroupName“ im V1-Abonnement vorhanden ist.

  • validateMigration: [Schalter]: Optional. Verwenden Sie diesen Parameter, wenn das Skript nach der Erstellung des V2-Gateways und dem Kopieren der Konfiguration einige grundlegende Vergleichsprüfungen der Konfiguration durchführen soll. Standardmäßig erfolgt keine Prüfung.

  • enableAutoScale: [Schalter]: Optional. Verwenden Sie diesen Parameter, wenn das Skript die automatische Skalierung für das neue V2-Gateway nach der Erstellung aktivieren soll. Standardmäßig ist automatische Skalierung deaktiviert. Sie können automatische Skalierung später für das neu erstellte V2-Gateway jederzeit manuell aktivieren.

  1. Führen Sie das Skript mit den entsprechenden Parametern aus. Es kann fünf bis sieben Minuten dauern, bis es fertig ist.

    Beispiel

    AzureAppGWMigration.ps1 `
   -resourceId /subscriptions/aaaa0000-bb11-2222-33cc-444444dddddd/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
   -subnetAddressRange 10.0.0.0/24 `
   -appgwname "MynewV2gw" `
   -AppGWResourceGroupName "MyResourceGroup" `
   -sslCertificates $mySslCert1,$mySslCert2 `
   -trustedRootCertificates $trustedCert `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/aaaa0000-bb11-2222-33cc-444444dddddd/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   -validateMigration -enableAutoScale

Vorbehalte/Einschränkungen

  • Das neue V2-Gateway hat neue öffentliche und private IP-Adressen. Es ist nicht möglich, die IP-Adressen, die dem vorhandenen V1-Gateway zugeordnet sind, nahtlos in V2 zu verschieben. Sie können dem neuen V2-Gateway jedoch eine vorhandene (nicht zugeordnete) öffentliche oder private IP-Adresse zuordnen.
  • Sie müssen einen IP-Adressraum für ein anderes Subnetz in Ihrem virtuellen Netzwerk bereitstellen, in dem sich Ihr V1-Gateway befindet. Mit dem Skript kann das V2-Gateway nicht in einem vorhandenen Subnetz erstellt werden, in dem es bereits ein V1-Gateway gibt. Wenn das Subnetz bereits über ein V2-Gateway verfügt, funktioniert das Skript möglicherweise noch, sofern genügend IP-Adressraum verfügbar ist.
  • Wenn Sie dem Subnetz des V2-Gateways eine Netzwerksicherheitsgruppe oder benutzerdefinierte Routen zugeordnet haben, vergewissern Sie sich, dass sie die NSG-Anforderungen und UDR-Anforderungen erfüllen, um eine erfolgreiche Migration sicherzustellen
  • Richtlinien für VNET-Dienstendpunkte werden derzeit in einem Application Gateway-Subnetz nicht unterstützt.
  • Um eine TLS/SSL-Konfiguration zu migrieren, müssen Sie alle TLS/SSL-Zertifikate angeben, die in Ihrem V1-Gateway verwendet werden.
  • Haben Sie für Ihr V1-Gateway den FIPS-Modus aktiviert, wird dieser nicht in Ihr neues V2-Gateway migriert. Der FIPS-Modus wird in V2 nicht unterstützt.
  • Wenn Sie nur über ein privates IP-Gateway V1 verfügen, generiert das Skript eine private und öffentliche IP-Adresse für das neue V2-Gateway. Das private IP-Gateway V2 befindet sich derzeit in der öffentlichen Vorschau. Sobald es allgemein verfügbar ist, können Kunden das Skript verwenden, um ihr privates IP V1-Gateway auf ein privates IP V2-Gateway zu übertragen.
  • Die NTLM- und Kerberos-Authentifizierung wird von Application Gateway V2 nicht unterstützt. Das Skript kann nicht erkennen, ob das Gateway diese Art von Datenverkehr bedient, und kann bei Ausführung als Breaking Change von V1- auf V2-Gateways darstellen.
  • WAFv2 wird im alten WAF-Konfigurationsmodus erstellt. Eine Migration zur WAF-Richtlinie ist erforderlich.

Datenverkehrsmigration

Überprüfen Sie zunächst, ob das Skript erfolgreich ein neues V2-Gateway mit genau der Konfiguration erstellt hat, die aus Ihrem V1-Gateway migriert wurde. Sie können dies über das Azure-Portal prüfen.

Senden Sie außerdem etwas Datenverkehr über das V2-Gateway als manuellen Test.

Es folgen einige Szenarien, in denen Ihr aktuelles Anwendungsgateway (Standard) Clientdatenverkehr empfangen kann, sowie unsere Empfehlungen für jedes Szenario:

  • Eine benutzerdefinierte DNS-Zone (z. B. „contoso.com“), in der auf die Front-End-IP-Adresse (mit einem A-Eintrag) verwiesen wird, die Ihrem Standard-V1- oder WAF-V1-Gateway zugeordnet ist.

    Sie können Ihren DNS-Eintrag so aktualisieren, dass er auf die Front-End-IP-Adresse oder DNS-Bezeichnung verweist, die Ihrem Standard_V2-Anwendungsgateway zugeordnet ist. Abhängig davon, welche Gültigkeitsdauer für Ihren DNS-Eintrag konfiguriert ist, kann es einige Zeit dauern, bis Ihr gesamter Clientdatenverkehr zu Ihrem neuen V2-Gateway migriert wird.

  • Eine benutzerdefinierte DNS-Zone (z. B. „contoso.com“), die auf die DNS-Bezeichnung (Beispiel: myappgw.eastus.cloudapp.azure.com mit einem CNAME-Eintrag) verweist, die Ihrem V1-Gateway zugeordnet ist.

    Sie haben dabei zwei Möglichkeiten:

    • Wenn Sie öffentliche IP-Adressen in Ihrem Anwendungsgateway verwenden, können Sie eine kontrollierte, präzise Migration durchführen, indem Sie ein Traffic Manager-Profil verwenden, um Datenverkehr inkrementell an das neue V2-Gateway weiterzuleiten (gewichtete Routingmethode für Datenverkehr).

      Hierzu können Sie die DNS-Bezeichnungen vom V1- und vom V2-Anwendungsgateway zu dem Traffic Manager-Profil hinzufügen und Ihren benutzerdefinierten DNS-Eintrag (z. B. www.contoso.com) über CNAME-Einträge zur Traffic Manager-Domäne (z. B. „contoso.trafficmanager.net“) umleiten.

    • Alternativ können Sie Ihren benutzerdefinierten Domänen-DNS-Eintrag so aktualisieren, dass er auf die DNS-Bezeichnung des neuen V2-Anwendungsgateways verweist. Abhängig davon, welche Gültigkeitsdauer für Ihren DNS-Eintrag konfiguriert ist, kann es einige Zeit dauern, bis Ihr gesamter Clientdatenverkehr zu Ihrem neuen V2-Gateway migriert wird.

  • Ihre Client stellen Verbindungen mit der Front-End-IP-Adresse Ihres Anwendungsgateways her.

    Aktualisieren Sie Ihre Clients, sodass diese die IP-Adressen verwenden, die dem neu erstellten V2-Anwendungsgateway zugeordnet sind. Es empfiehlt sich, dass Sie IP-Adressen nicht direkt verwenden. Dazu bietet es sich an, dass Sie die DNS-Namensbezeichnung (z. B. „yourgateway.eastus.cloudapp.azure.com“), die Ihrem Anwendungsgateway zugeordnet ist, über CNAME-Einträge auf Ihre eigene benutzerdefinierte DNS-Zone (z. B. „contoso.com“) umleiten.

Preisinformationen

Die Preismodelle unterscheiden sich für die Anwendungsgateway-V1- und V2-SKUs. V2 wird basierend auf dem Verbrauch berechnet. Sehen Sie sich vor der Migration die Preise für Application Gateway an, um Informationen zu den Preisen zu erhalten.

Leitfaden zur Kosteneffizienz

Die V2-SKU bietet eine Reihe von Vorteilen, wie z. B. eine 5fache Leistungssteigerung, verbesserte Sicherheit mit Key Vault-Integration, schnellere Updates von Sicherheitsregeln in WAF_V2, WAF Custom-Regeln, Richtlinienzuordnungen und Bot-Schutz. Außerdem bietet sie hohe Skalierbarkeit, optimiertes Datenverkehrsrouting und eine nahtlose Integration mit Azure-Diensten. Diese Funktionen können die allgemeine Benutzererfahrung verbessern, Verlangsamungen in Zeiten mit hohem Datenverkehr verhindern und teure Datenschutzverletzungen vermeiden.

Es gibt fünf Varianten in V1-SKU basierend auf der Ebene und Größe - Standard_Small, Standard_Medium, Standard_Large, WAF_Medium und WAF_Large.

SKU V1 Festpreis/Mt. V2 Festpreis/Mt. Empfehlung
Standard medium 102.2 179.8 V2-SKU kann eine größere Anzahl von Anforderungen als ein V1-Gateway verarbeiten. Daher empfehlen wir, mehrere V1-Gateways in ein einzelnes V2-Gateway zu konsolidieren, um die Kosten zu optimieren. Stellen Sie sicher, dass die Konsolidierung die Anwendungsgateway-Grenzwerte nicht überschreitet. Es wird eine Konsolidierung von 3:1 empfohlen.
WAF Medium 183.96 262.8 Identisch mit Standard Medium
Standard groß 467.2 179.58 Bei diesen Varianten kann der Wechsel zu einem V2-Gateway in den meisten Fällen einen besseren Preisvorteil als bei V1 bieten.
WAF Large 654.08 262.8 Identisch mit Standard Large

Hinweis

Die hier gezeigten Berechnungen basieren auf USA, Osten und für ein Gateway mit 2 Instanzen in V1. Die variablen Kosten in V2 basieren auf einer der drei Dimensionen mit der höchsten Nutzung: Neue Verbindungen (50/Sek.), persistente Verbindungen (2500 persistente Verbindungen/Min.), Durchsatz (1 CU kann 2,22 MBit/s verarbeiten).

Die hier beschriebenen Szenarien sind Beispiele und dienen nur zur Veranschaulichung. Aktuelle Preisinformationen für Ihre Region finden Sie auf der Seite mit der Preisübersicht.

Wenn Sie weitere Fragen zur Preisgestaltung haben, wenden Sie sich bitte an Ihren CSAM oder an unser Support-Team, das Sie gerne unterstützt.

Häufig gestellte Fragen

Allgemeine Fragen zur Migration finden Sie hier

Nächste Schritte

Informationen zu Application Gateway V2