Migrera Azure Application Gateway och brandväggen för webbprogram från V1 till V2

  • Artikel

Vi meddelade utfasningen av Application Gateway V1 SKU (Standard och WAF) den 28 april 2023. V1 SKU går i pension den 28 april 2026. Mer information finns i Migrera dina Application Gateways från V1 SKU till V2 SKU senast den 28 april 2026.

Azure Application Gateway och Web Application Firewall (WAF) V2 erbjuder nu ytterligare funktioner som automatisk skalning, tillgänglighet, zonredundans, högre prestanda, snabbare åtgärder och förbättrat dataflöde jämfört med V1. Dessutom släpps alla nya funktioner för V2 SKU. Vi rekommenderar starkt att du skapar en migreringsplan nu.

V1-gatewayer uppgraderas inte automatiskt till V2. Använd den här migreringsguiden för att planera och utföra migreringarna.

Det finns två steg i en migrering:

  1. Migrera konfigurationen
  2. Migrera klienttrafiken

Den här artikeln hjälper främst till med konfigurationsmigreringen. Klienttrafikmigrering varierar beroende på miljö. Vissa allmänna rekommendationer finns i den här artikeln.

Förutsättningar

  • Ett Azure-konto med en aktiv prenumeration. Skapa ett konto utan kostnad.
  • En befintlig Application Gateway V1 Standard.
  • Kontrollera att du har de senaste PowerShell-modulerna, eller så kan du använda Azure Cloud Shell i portalen.
  • Om du kör PowerShell lokalt måste du också köra Connect-AzAccount för att skapa en anslutning till Azure.
  • Kontrollera att det inte finns någon befintlig Programgateway med det angivna AppGW V2-namnet och resursgruppens namn i V1-prenumerationen. Detta skriver om befintliga resurser.
  • Om en offentlig IP-adress anges kontrollerar du att den är i ett lyckat tillstånd. Om det inte tillhandahålls och AppGWResourceGroupName tillhandahålls kontrollerar du att den offentliga IP-resursen med namnet AppGWV2Name-IP inte finns i en resursgrupp med namnet AppGWResourceGroupName i V1-prenumerationen.
  • Kontrollera att ingen annan åtgärd planeras för V1-gatewayen eller associerade resurser under migreringen.

Azure Cloud Shell

Azure är värd för Azure Cloud Shell, en interaktiv gränssnittsmiljö som du kan använda via webbläsaren. Du kan använda antingen Bash eller PowerShell med Cloud Shell för att arbeta med Azure-tjänster. Du kan använda förinstallerade Cloud Shell-kommandon för att köra koden i den här artikeln, utan att behöva installera något i din lokala miljö.

Så här startar du Azure Cloud Shell:

Alternativ Exempel/länk
Välj Prova i det övre högra hörnet i en kod eller ett kommandoblock. Om du väljer Prova kopieras inte koden eller kommandot automatiskt till Cloud Shell. Screenshot that shows an example of Try It for Azure Cloud Shell.
Gå till https://shell.azure.com eller Välj knappen Starta Cloud Shell för att öppna Cloud Shell i webbläsaren. Button to launch Azure Cloud Shell.
Välj knappen Cloud Shell på menyn längst upp till höger i Azure-portalen. Screenshot that shows the Cloud Shell button in the Azure portal

Så här använder du Azure Cloud Shell:

  1. Starta Cloud Shell.

  2. Välj knappen Kopiera i ett kodblock (eller kommandoblock) för att kopiera koden eller kommandot.

  3. Klistra in koden eller kommandot i Cloud Shell-sessionen genom att välja Ctrl+Skift+V i Windows och Linux, eller genom att välja Cmd+Shift+V på macOS.

  4. Välj Retur för att köra koden eller kommandot.

Kommentar

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Se Installera Azure PowerShell för att komma igång. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Viktigt!

Kör cmdleten Set-AzContext -Subscription <V1 application gateway SubscriptionId> varje gång innan du kör migreringsskriptet. Detta är nödvändigt för att ställa in den aktiva Azure-kontexten på rätt prenumeration, eftersom migreringsskriptet kan rensa den befintliga resursgruppen om den inte finns i den aktuella prenumerationskontexten. Det här är inte ett obligatoriskt steg för version 1.0.11 och senare av migreringsskriptet.

Viktigt!

En ny stabil version av migreringsskriptet, version 1.0.11, är tillgänglig nu, som innehåller viktiga felkorrigeringar och uppdateringar. Använd den här versionen för att undvika potentiella problem.

Konfigurationsmigrering

Ett Azure PowerShell-skript finns i det här dokumentet. Den utför följande åtgärder för att hjälpa dig med konfigurationen:

  • Skapar en ny Standard_V2 eller WAF_V2 gateway i ett virtuellt nätverksundernät som du anger.
  • Kopierar sömlöst konfigurationen som är associerad med V1 Standard- eller WAF-gatewayen till den nyligen skapade Standard_V2 eller WAF_V2 gateway.

Ladda ned skriptet

Du kan ladda ned migreringsskriptet från PowerShell-galleriet. En ny stabil version (version 1.0.11) av migreringsskriptet är tillgänglig, som innehåller viktiga uppdateringar och felkorrigeringar. Vi rekommenderar att du använder den här stabila versionen.

Använda skriptet

Kommentar

Kör cmdleten Set-AzContext -Subscription <V1 application gateway SubscriptionId> varje gång innan du kör migreringsskriptet. Detta är nödvändigt för att ställa in den aktiva Azure-kontexten på rätt prenumeration, eftersom migreringsskriptet kan rensa den befintliga resursgruppen om den inte finns i den aktuella prenumerationskontexten. Det här är inte ett obligatoriskt steg för version 1.0.11 och senare av migreringsskriptet.

Det finns två alternativ för dig beroende på din lokala Installation och inställningar för PowerShell-miljön:

  • Om du inte har installerat Azure Az-modulerna eller inte har något emot att avinstallera Azure Az-modulerna är det bästa alternativet att använda Install-Script alternativet för att köra skriptet.
  • Om du behöver behålla Azure Az-modulerna är det bästa valet att ladda ned skriptet och köra det direkt.

Kör för att avgöra om du har Azure Az-modulerna installerade Get-InstalledModule -Name az. Om du inte ser några installerade Az-moduler kan du använda Install-Script metoden.

Om du vill använda det här alternativet får du inte ha Azure Az-modulerna installerade på datorn. Om de är installerade visas ett fel i följande kommando. Du kan antingen avinstallera Azure Az-modulerna eller använda det andra alternativet för att ladda ned skriptet manuellt och köra det.

Kör skriptet med följande kommando för att hämta den senaste versionen:

Install-Script -Name AzureAppGWMigration -Force

Det här kommandot installerar också de nödvändiga Az-modulerna.

Installera med skriptet direkt

Om du har installerat vissa Azure Az-moduler och inte kan avinstallera dem (eller inte vill avinstallera dem) kan du manuellt ladda ned skriptet med hjälp av fliken Manuell nedladdning i länken för skriptnedladdning. Skriptet laddas ned som en rå nupkg-fil. Information om hur du installerar skriptet från den här nupkg-filen finns i Manuell pakethämtning.

Version 1.0.11 är den nya versionen av migreringsskriptet som innehåller större felkorrigeringar. Vi rekommenderar att du använder den här stabila versionen.

Så här kontrollerar du versionen av det nedladdade skriptet

Så här kontrollerar du versionen av det nedladdade skriptet:

  • Extrahera innehållet i NuGet-paketet.
  • .PS1 Öppna filen i mappen och kontrollera .VERSION längst upp för att bekräfta versionen av det nedladdade skriptet
<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

Så här kör du skriptet

Kör skriptet så här:

  1. Använd Connect-AzAccount för att ansluta till Azure.

  2. Använd Import-Module Az för att importera Az-modulerna.

  3. Kör cmdleten Set-AzContext för att ange den aktiva Azure-kontexten till rätt prenumeration. Det här är ett viktigt steg eftersom migreringsskriptet kan rensa den befintliga resursgruppen om den inte finns i den aktuella prenumerationskontexten.

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

  4. Kör Get-Help AzureAppGWMigration.ps1 för att undersöka de obligatoriska parametrarna:

    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

Kommentar

Under migreringen försöker du inte utföra någon annan åtgärd på V1-gatewayen eller några associerade resurser.

Parametrar för skriptet:

  • resourceId: [String]: Krävs: Den här parametern är Azure-resurs-ID:t för din befintliga Standard V1- eller WAF V1-gateway. Om du vill hitta det här strängvärdet går du till Azure-portalen, väljer din programgateway eller WAF-resurs och klickar på länken Egenskaper för gatewayen. Resurs-ID:t finns på den sidan.

    Du kan också köra följande Azure PowerShell-kommandon för att hämta resurs-ID:t:

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

  • subnetAddressRange: [String]: Krävs: Den här parametern är det IP-adressutrymme som du har allokerat (eller vill allokera) för ett nytt undernät som innehåller din nya V2-gateway. Adressutrymmet måste anges i CIDR-notationen. Exempel: 10.0.0.0/24. Du behöver inte skapa det här undernätet i förväg, men CIDR måste vara en del av VNET-adressutrymmet. Skriptet skapar det åt dig om det inte finns och om det finns använder det det befintliga (se till att undernätet antingen är tomt, endast innehåller V2 Gateway om det finns och har tillräckligt med tillgängliga IP-adresser).

  • appgwName: [String]: Valfritt. Det här är en sträng som du anger som namn på den nya Standard_V2 eller WAF_V2 gatewayen. Om den här parametern inte anges används namnet på din befintliga V1-gateway med suffixet _V2 läggs till.

  • AppGWResourceGroupName: [String]: Valfritt. Namnet på resursgruppen där du vill att V2 Application Gateway-resurser ska skapas (standardvärdet är <V1-app-gw-rgname>)

Kommentar

Kontrollera att det inte finns någon befintlig Programgateway med det angivna AppGW V2-namnet och resursgruppens namn i V1-prenumerationen. Detta skriver om befintliga resurser.

  • sslCertificates: [PSApplicationGatewaySslCertificate]: Valfritt. En kommaavgränsad lista över PSApplicationGatewaySslCertificate-objekt som du skapar för att representera TLS/SSL-certifikaten från din V1-gateway måste laddas upp till den nya V2-gatewayen. För vart och ett av dina TLS/SSL-certifikat som konfigurerats för din Standard V1- eller WAF V1-gateway kan du skapa ett nytt PSApplicationGatewaySslCertificate-objekt via New-AzApplicationGatewaySslCertificate kommandot som visas här. Du behöver sökvägen till TLS/SSL Cert-filen och lösenordet.

    Den här parametern är bara valfri om du inte har HTTPS-lyssnare konfigurerade för din V1-gateway eller WAF. Om du har minst en HTTPS-lyssnarkonfiguration måste du ange den här parametern.

    $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

    Du kan skicka in $mySslCert1, $mySslCert2 (kommaavgränsade) i föregående exempel som värden för den här parametern i skriptet.

  • sslCertificates från Keyvault: Valfritt. Du kan ladda ned certifikaten som lagras i Azure Key Vault och skicka dem till migreringsskriptet. Om du vill ladda ned certifikatet som en PFX-fil kör du följande kommando. Dessa kommandon kommer åt SecretId och sparar sedan innehållet som en PFX-fil.

     $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 vart och ett av certifikatet som hämtats från Keyvault kan du skapa ett nytt PSApplicationGatewaySslCertificate-objekt via kommandot New-AzApplicationGatewaySslCertificate som visas här. Du behöver sökvägen till TLS/SSL Cert-filen och lösenordet.

    //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]: Valfritt. En kommaavgränsad lista över PSApplicationGatewayTrustedRootCertificate-objekt som du skapar för att representera betrodda rotcertifikat för autentisering av dina serverdelsinstanser från din v2-gateway.

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

    Information om hur du skapar en lista över PSApplicationGatewayTrustedRootCertificate-objekt finns i New-AzApplicationGatewayTrustedRootCertificate.

  • privateIpAddress: [String]: Valfritt. En specifik privat IP-adress som du vill associera med din nya V2-gateway. Detta måste vara från samma virtuella nätverk som du allokerar för din nya V2-gateway. Om detta inte anges allokerar skriptet en privat IP-adress för din V2-gateway.

  • publicIpResourceId: [String]: Valfritt. ResourceId för befintlig offentlig IP-adressresurs (standard-SKU) i din prenumeration som du vill allokera till den nya V2-gatewayen. Om det finns ett offentligt IP-resursnamn kontrollerar du att det finns i tillståndet lyckades. Om detta inte anges allokerar skriptet en ny offentlig IP-adress i samma resursgrupp. Namnet är V2-gatewayens namn med -IP tillagt. Om AppGWResourceGroupName har angetts och en offentlig IP-adress inte har angetts kontrollerar du att den offentliga IP-resursen med namnet AppGWV2Name-IP inte finns i en resursgrupp med namnet AppGWResourceGroupName i V1-prenumerationen.

  • validateMigration: [switch]: Valfritt. Använd den här parametern för att aktivera skriptet för att utföra vissa grundläggande konfigurationsjämförelsevalideringar efter att V2-gatewayen har skapats och konfigurationskopian. Som standard görs ingen validering.

  • enableAutoScale: [switch]: Valfritt. Använd den här parametern för att aktivera skriptet för att aktivera automatisk skalning på den nya V2-gatewayen när den har skapats. Som standard inaktiveras automatisk skalning. Du kan alltid aktivera den manuellt senare på den nyligen skapade V2-gatewayen.

  1. Kör skriptet med lämpliga parametrar. Det kan ta fem till sju minuter att slutföra.

    Exempel

    AzureAppGWMigration.ps1 `
   -resourceId /subscriptions/8b1d0fea-8d57-4975-adfb-308f1f4d12aa/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/8b1d0fea-8d57-4975-adfb-308f1f4d12aa/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   -validateMigration -enableAutoScale

Varningar\Begränsningar

  • Den nya V2-gatewayen har nya offentliga och privata IP-adresser. Det går inte att flytta IP-adresserna som är associerade med den befintliga V1-gatewayen sömlöst till V2. Du kan dock allokera en befintlig (oallokerad) offentlig eller privat IP-adress till den nya V2-gatewayen.
  • Du måste ange ett IP-adressutrymme för ett annat undernät i ditt virtuella nätverk där V1-gatewayen finns. Skriptet kan inte skapa V2-gatewayen i ett undernät som redan har en V1-gateway. Om undernätet redan har en V2-gateway kan skriptet fortfarande fungera, förutsatt att tillräckligt med IP-adressutrymme är tillgängligt.
  • Om du har en nätverkssäkerhetsgrupp eller användardefinierade vägar kopplade till V2-gatewayundernätet kontrollerar du att de följer NSG-kraven och UDR-kraven för en lyckad migrering
  • Principer för tjänstslutpunkter för virtuella nätverk stöds för närvarande inte i ett Application Gateway-undernät.
  • Om du vill migrera en TLS/SSL-konfiguration måste du ange alla TLS/SSL-certifikat som används i din V1-gateway.
  • Om fips-läget är aktiverat för din V1-gateway migreras det inte till din nya V2-gateway. FIPS-läge stöds inte i V2.
  • Om du bara har en privat IP-gateway genererar skriptet en privat och offentlig IP-adress för den nya V2-gatewayen. Den privata IP-endast V2-gatewayen är för närvarande i offentlig förhandsversion. När det blir allmänt tillgängligt kan kunderna använda skriptet för att överföra sin privata IP-endast V1-gateway till en privat IP endast V2-gateway.
  • NTLM- och Kerberos-autentisering stöds inte av Application Gateway V2. Skriptet kan inte identifiera om gatewayen betjänar den här typen av trafik och kan utgöra en icke-bakåtkompatibel ändring från V1 till V2-gatewayer om den körs.
  • WAFv2 skapas i gammalt WAF-konfigurationsläge. migrering till WAF-princip krävs.

Trafikmigrering

Kontrollera först att skriptet har skapat en ny V2-gateway med den exakta konfigurationen som migrerats från V1-gatewayen. Du kan kontrollera detta från Azure-portalen.

Skicka också en liten mängd trafik via V2-gatewayen som ett manuellt test.

Följande är några scenarier där din aktuella programgateway (Standard) kan ta emot klienttrafik och våra rekommendationer för var och en:

  • En anpassad DNS-zon (till exempel contoso.com) som pekar på klientdelens IP-adress (med hjälp av en A-post) som är associerad med din Standard V1- eller WAF V1-gateway.

    Du kan uppdatera DNS-posten så att den pekar på klientdelens IP- eller DNS-etikett som är associerad med din Standard_V2 programgateway. Beroende på vilken TTL som konfigurerats på DNS-posten kan det ta ett tag innan all klienttrafik migreras till din nya V2-gateway.

  • En anpassad DNS-zon (till exempel contoso.com) som pekar på DNS-etiketten (till exempel myappgw.eastus.cloudapp.azure.com med hjälp av en CNAME-post) som är associerad med din V1-gateway.

    Du kan välja mellan två alternativ:

    • Om du använder offentliga IP-adresser på din programgateway kan du utföra en kontrollerad, detaljerad migrering med hjälp av en Traffic Manager-profil för att stegvis dirigera trafik (viktad trafikroutningsmetod) till den nya V2-gatewayen.

      Du kan göra detta genom att lägga till DNS-etiketterna för både V1- och V2-programgatewayerna i Traffic Manager-profilen och CNAMEing din anpassade DNS-post (till exempel www.contoso.com) i Traffic Manager-domänen (till exempel contoso.trafficmanager.net).

    • Eller så kan du uppdatera dns-posten för den anpassade domänen så att den pekar på DNS-etiketten för den nya V2-programgatewayen. Beroende på vilken TTL som konfigurerats på DNS-posten kan det ta ett tag innan all klienttrafik migreras till din nya V2-gateway.

  • Dina klienter ansluter till klientdels-IP-adressen för din programgateway.

    Uppdatera dina klienter så att de använder IP-adresserna som är associerade med den nyligen skapade V2-programgatewayen. Vi rekommenderar att du inte använder IP-adresser direkt. Överväg att använda DNS-namnetiketten (till exempel yourgateway.eastus.cloudapp.azure.com) som är associerad med din programgateway som du kan CNAME till din egen anpassade DNS-zon (till exempel contoso.com).

Överväganden för prissättning

Prismodellerna skiljer sig åt för Application Gateway V1- och V2-SKU:er. V2 debiteras baserat på förbrukning. Se Priser för Application Gateway innan du migrerar för prisinformation.

Vägledning för kostnadseffektivitet

V2 SKU har en rad fördelar, till exempel en prestandaökning på 5x, förbättrad säkerhet med Key Vault-integrering, snabbare uppdateringar av säkerhetsregler i WAF_V2, ANPASSADE WAF-regler, principassociationer och botskydd. Det erbjuder också hög skalbarhet, optimerad trafikroutning och sömlös integrering med Azure-tjänster. Dessa funktioner kan förbättra den övergripande användarupplevelsen, förhindra långsammare tider med tung trafik och undvika dyra dataintrång.

Det finns fem tillgängliga varianter i V1 SKU baserat på nivå och storlek – Standard_Small, Standard_Medium, Standard_Large, WAF_Medium och WAF_Large.

SKU V1 Fast pris/mån V2 Fast pris/mo Rekommendation
Standardmedium 102.2 179.8 V2 SKU kan hantera ett större antal begäranden än en V1-gateway, så vi rekommenderar att du konsoliderar flera V1-gatewayer till en enda V2-gateway för att optimera kostnaden. Se till att konsolideringen inte överskrider gränserna för Application Gateway. Vi rekommenderar 3:1-konsolidering.
WAF Medium 183.96 262.8 Samma som för Standard Medium
Standard Large 467.2 179.58 För dessa varianter kan du i de flesta fall få en bättre prisförmån jämfört med V1 om du flyttar till en V2-gateway.
WAF Large 654.08 262.8 Samma som för Standard Large

Kommentar

Beräkningarna som visas här baseras på USA, östra och för en gateway med 2 instanser i V1. Den variabla kostnaden i V2 baseras på en av de tre dimensionerna med högst användning: Nya anslutningar (50/s), Beständiga anslutningar (2 500 beständiga anslutningar/min), dataflöde (1 CU kan hantera 2,22 Mbit/s).

De scenarier som beskrivs här är exempel och är endast i illustrationssyfte. Prisinformation enligt din region finns på sidan Prissättning.

Om du vill ha mer information om prissättningen kan du samarbeta med din CSAM eller kontakta vårt supportteam för att få hjälp.

Vanliga frågor

Vanliga frågor om migrering finns här

Nästa steg

Läs mer om Application Gateway V2