Migrar o Gateway de Aplicativo do Azure e o Firewall de Aplicativo Web do v1 para v2

Anunciamos a substituição do SKU do Gateway de Aplicativo V1 (Standard e WAF) em 28 de abril de 2023. O SKU V1 será desativado em 28 de abril de 2026. Para obter mais informações, consulte Migrar seus Gateways de Aplicativo da SKU V1 para a SKU V2 até 28 de abril de 2026.

A migração para o Gateway de Aplicativo do Azure e o Firewall de Aplicativo Web (WAF) V2 oferece vários benefícios:

• Melhor Resiliência: Redundância AZ, Dimensionamento Automático
• Melhor segurança: integração do Azure Keyvault, funcionalidades aprimoradas do WAF, Proteção contra Bot
• Funcionalidades de monitoramento aprimoradas: ao contrário da V1, que tinha apenas monitoramento de CPU, a V2 fornece monitoramento abrangente para uso de CPU, memória e disco.
• Detecção e Mitigação Automática aprimoradas: os gateways V2 apresentam mecanismos de detecção avançada e processos automatizados de mitigação que podem identificar e resolver problemas com rapidez e precisão sem a necessidade de intervenção manual.
• Todos os novos recursos são disponibilizados para a versão V2 do SKU.

É altamente recomendável que você crie um plano de migração agora. Os gateways V1 não são atualizados automaticamente para a V2. Use este guia de migração para ajudá-lo a planejar e realizar as migrações.

Há duas fases em uma migração:

1. Migrar a configuração
2. Migrar o tráfego de cliente

Este artigo ajuda principalmente com a migração de configuração. A migração de tráfego do cliente varia dependendo do ambiente. Algumas recomendações gerais são fornecidas neste artigo.

Pré-requisitos

• Uma conta do Azure com uma assinatura ativa. Crie uma conta gratuitamente.
• Um Gateway de Aplicativo V1 Standard existente.
• Verifique se você tem os módulos mais recentes do PowerShell ou se pode usar o Azure Cloud Shell no portal.
• Se você estiver executando o PowerShell localmente, também precisará executar o Connect-AzAccount para criar uma conexão com o Azure.
• Verifique se não há nenhum Gateway de aplicativo existente com o nome do AppGW V2 e o nome do Grupo de recursos fornecidos na assinatura V1. Isso regravará os recursos existentes.
• Se um endereço IP público for fornecido, verifique se ele está em um estado bem-sucedido. Se não for fornecido e AppGWResourceGroupName for fornecido, certifique-se de que o recurso IP público com o nome AppGWV2Name-IP não exista em um grupo de recursos com o nome AppGWResourceGroupName na assinatura V1.
• Para o SKU V1, os certificados de autenticação são necessários para configurar conexões TLS com servidores de back-end. O SKU V2 requer o carregamento de certificados raiz confiáveis para a mesma finalidade. Embora o V1 permita o uso de certificados autoassinados como certificados de autenticação, o V2 exige a geração e o carregamento de um certificado raiz autoassinado se certificados autoassinados forem usados no back-end.
• Verifique se nenhuma outra operação está planejada no gateway V1 ou nos recursos associados durante a migração.

Azure Cloud Shell

O Azure hospeda o Azure Cloud Shell, um ambiente de shell interativo que pode ser usado por meio do navegador. É possível usar o Bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. É possível usar os comandos pré-instalados do Cloud Shell para executar o código neste artigo, sem precisar instalar nada no seu ambiente local.

Para iniciar o Azure Cloud Shell:

Opção	Exemplo/Link
Selecione Experimentar no canto superior direito de um bloco de código ou de comando. Selecionar Experimentar não copia automaticamente o código nem o comando para o Cloud Shell.
Acesse https://shell.azure.com ou selecione o botão Iniciar o Cloud Shell para abri-lo no navegador.
Selecione o botão Cloud Shell na barra de menus no canto superior direito do portal do Azure.

Para usar o Azure Cloud Shell:

1. Inicie o Cloud Shell.

2. Selecione o botão Copiar em um bloco de código (ou bloco de comando) para copiar o código ou o comando.

3. Cole o código ou comando na sessão do Cloud Shell ao pressionar Ctrl+Shift+V no Windows e no Linux, ou selecionando Cmd+Shift+V no macOS.

4. Pressione Enter para executar o código ou o comando.

Migração da configuração

A migração de configuração concentra-se na configuração do novo gateway V2 com as configurações do seu ambiente V1 existente. Fornecemos dois scripts do Azure PowerShell projetados para facilitar a migração de configurações de gateways V1 (Standard ou WAF) para V2 (Standard_V2 ou WAF_V2). Esses scripts ajudam a simplificar o processo de transição automatizando tarefas de implantação e configuração de chaves.

1. Script de clonagem aprimorado

Essa é a nova experiência que oferece uma experiência de migração aprimorada:

• Eliminando a necessidade de entrada manual dos certificados SSL de front-end e certificados raiz confiáveis de back-end.
• Suporte à implantação de gateways V2 somente privados.

Você pode baixar o script de clonagem avançado da Galeria do PowerShell.

Parâmetros para o script: Esse script usa os parâmetros abaixo:

• AppGw V1 ResourceId -Required: esse parâmetro é a ID de Recurso do Azure para seu gateway V1 Standard ou WAF V1 existente. Para localizar esse valor de cadeia de caracteres, navegue até o portal do Azure, selecione o recurso de gateway de aplicativo ou WAF e clique no link Propriedades para o gateway. A ID do Recurso está localizada nessa página. Você também pode executar os seguintes comandos do Azure PowerShell para obter a ID do recurso:

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

• SubnetAddressRange -Required: o endereço de sub-rede na notação CIDR, em que o Gateway de Aplicativo V2 deve ser implantado
• AppGwName -Opcional: nome do gateway de aplicativo v2. Valor Padrão = {AppGwV1 Name}_migrated
• AppGwResourceGroupName -Opcional: nome do grupo de recursos em que o Gateway de Aplicativo V2 será criado. Se não for fornecido, será usado o grupo de recursos do Gateway de Aplicativo V1.
• PrivateIPAddress -Opcional: endereço IP privado a ser atribuído ao Gateway de Aplicações V2, opcional. Se não for fornecido, o IP privado aleatório será atribuído.
• ValidateBackendHealth -Opcional: validação pós-migração comparando a resposta ApplicationGatewayBackendHealth. Se não for definido, essa validação será ignorada.
• PublicIpResourceId -Opcional: O resourceId do endereço IP público (se já existir) pode ser vinculado ao gateway de aplicação. Se não for fornecido, o nome IP público será {AppGwName}-IP.
• DisableAutoscale -Optional: desabilitar a configuração de dimensionamento automático para as instâncias do Gateway de Aplicativo V2, falso por padrão
• WafPolicyName -Opcional: nome da política waf que será criada a partir da Configuração do WAF V1 e será anexada ao gateway waf v2.

Como executar o script

Para executar o script:

1. Use Connect-AzAccount para se conectar ao Azure.
2. Use Import-Module Az para importar os módulos Az.
3. Execute o cmdlet Set-AzContext para definir o contexto ativo do Azure como a assinatura correta. Essa é uma etapa importante porque o script de migração pode limpar o grupo de recursos existente se ele não existir no contexto de assinatura atual.

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

4. Instale o script seguindo as etapas – Instalar Script
5. Execute o script usando os parâmetros apropriados. Isso pode levar de cinco a sete minutos para ser concluído.

   ./AzureAppGWClone.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>
   -privateIpAddress <private IP string>
   -publicIpResourceId <public IP name string>
   - disableAutoscale
   -wafpolicyname <wafpolicyname>
   

   Exemplo

   ./AzureAppGWClone.ps1 `
   -resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
   -subnetAddressRange 10.0.0.0/24 `
   -appgwname "MynewV2gw" `
   -AppGWResourceGroupName "MyResourceGroup" `
   -privateIpAddress "10.0.0.1" `
   -publicIpResourceId "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
   

Recommendations

• Após a conclusão do script, examine a configuração do gateway V2 no portal do Azure e teste a conectividade enviando tráfego diretamente para o IP do gateway V2.
• O script relaxa a validação de TLS de back-end por padrão (sem cadeia de certificados, expiração ou validação de SNI) durante a clonagem. Se forem necessários certificados de validação ou autenticação TLS mais estritos, o cliente poderá atualizar sua pós-criação do Gateway de Aplicativo V2 para adicionar certificados raiz confiáveis e habilitar esse recurso de acordo com suas necessidades.
• Quanto à passagem NTLM/Kerberos, defina a conexão de back-end dedicada como "verdadeiro" nas configurações de HTTP após a clonagem.

Advertências

• Você deve fornecer um espaço de endereço de IP para outra sub-rede na sua rede virtual em que seu gateway V1 está localizado. O script não pode criar o gateway V2 em uma sub-rede que já tenha um gateway V1. Se a sub-rede já tiver um gateway V2, o script ainda poderá funcionar, desde que haja espaço suficiente no endereço de IP disponível.
• Se você tiver um grupo de segurança de rede ou rotas definidas pelo usuário associadas à sub-rede de gateway V2, verifique se eles aderem aos Requisitos de NSG e Requisitos de UDR para uma migração bem-sucedida
• Se você tiver o modo FIPS habilitado para o gateway V1, ele não será migrado para o novo gateway V2.
• O novo WAFV2 é configurado para usar o CRS 3.0 por padrão. No entanto, como o CRS 3.0 está no caminho para a substituição, recomendamos atualizar para o conjunto de regras mais recente, DRS 2.1 após a migração. Para obter mais detalhes, consulte Regras e grupos de regras de CRS e DRS que tenham um grupo de segurança de rede ou rotas definidas pelo usuário associadas à sub-rede do gateway V2, certifique-se de que elas estejam em conformidade com os requisitos NSG e UDR para obter uma migração bem-sucedida.

2. Script de clonagem herdado

Esse é o script de clonagem mais antigo, que facilita a transição:

• Criar um novo Gateway de Aplicação Standard_V2 ou WAF_V2 em uma sub-rede de rede virtual especificada pelo usuário.
• Copiando automaticamente a configuração de um gateway Standard ou WAF V1 existente para o gateway V2 recém-criado.
• Requer que o cliente forneça certificados de autenticação e SSL como entrada e não dá suporte apenas a gateways V2 privados Você pode baixar esse script de clonagem da Galeria do PowerShell

Parâmetros para o script: O script herdado usa os parâmetros abaixo:

• resourceId: [String]: Obrigatório: esse parâmetro é a ID de Recurso do Azure do seu gateway V1 ou WAF V1 padrão existente. Para localizar esse valor de cadeia de caracteres, navegue até o portal do Azure, selecione o recurso de gateway de aplicativo ou WAF e clique no link Propriedades para o gateway. A ID do Recurso está localizada nessa página. Você também pode executar os seguintes comandos do Azure PowerShell para obter a ID do recurso:

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

• subnetAddressRange: [String]: Obrigatório: esse parâmetro é o espaço de endereço de IP que você alocou (ou quer alocar) em uma nova sub-rede que contém o seu novo gateway V2. O espaço de endereço deve ser especificado na notação CIDR. Por exemplo: 10.0.0.0/24. Você não precisa criar essa sub-rede com antecedência, mas o CIDR precisa fazer parte do espaço de endereço da VNET. O script o cria para você se ele não existir e, se existir, ele usa o existente (certifique-se de que a sub-rede esteja vazia, contenha apenas o gateway V2, se houver, e tenha IPs disponíveis suficientes).
• appgwName: [String]: opcional. Essa é uma cadeia de caracteres que você especifica para usar como o nome do novo gateway de Standard_V2 ou WAF_V2. Se esse parâmetro não for fornecido, o nome do gateway V1 existente será usado com o sufixo _V2 acrescentado.
• AppGwResourceGroupName: [Cadeia de caracteres]: Opcional. Nome do grupo de recursos em que você quer que os recursos do Gateway de Aplicativo V2 sejam criados (o valor padrão será <V1-app-gw-rgname>)

• sslCertificates: [PSApplicationGatewaySslCertificate]: Opcional. Uma lista separada por vírgulas de objetos PSApplicationGatewaySslCertificate que você criou para representar os certificados TLS/SSL do seu gateway V1 deve ser carregada no novo gateway V2. Para cada um dos seus certificados TLS/SSL configurados para seu gateway Standard V1 ou WAF V1, você pode criar um novo objeto PSApplicationGatewaySslCertificate pelo comando New-AzApplicationGatewaySslCertificate mostrado aqui. Você precisa do caminho e da senha para o arquivo de certificado TLS/SSL.

  Esse parâmetro só será opcional se você não tiver ouvintes HTTPS configurados no seu gateway V1 ou WAF. Se tiver pelo menos uma configuração de ouvinte HTTPS, deverá especificar esse parâmetro.

       $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
  

  Você pode passar $mySslCert1, $mySslCert2 (separado por vírgula) no exemplo anterior como valores para esse parâmetro no script.

• sslCertificates de Keyvault: opcional. Você pode baixar os certificados armazenados no Azure Key Vault e passá-los para o script de migração. Para baixar o certificado como um arquivo PFX, execute o comando a seguir. Esses comandos acessam a SecretId e salvam o conteúdo como um arquivo PFX.

      $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)
  

  Para cada certificado baixado do Keyvault, você pode criar um novo objeto PSApplicationGatewaySslCertificate pelo comando New-AzApplicationGatewaySslCertificate mostrado aqui. Você precisa do caminho e da senha para o arquivo de certificado TLS/SSL.

  //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. Uma lista separada por vírgulas de objetos PSApplicationGatewayTrustedRootCertificate criada para representar os certificados Raiz Confiáveis para autenticação das instâncias de back-end do gateway v2.

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

  Para criar uma lista de objetos PSApplicationGatewayTrustedRootCertificate, confira New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress: [String]: opcional. Um endereço de IP privado específico que você quer associar ao seu novo gateway v2. Isso deve ser da mesma VNet que você aloca no seu novo gateway V2. Se isso não for especificado, o script alocará um endereço de IP privado no seu gateway V2.

• publicIpResourceId: [String]: opcional. O resourceId do recurso de endereço IP público (SKU padrão) existente na assinatura que você deseja alocar para o novo gateway V2. Se o nome do recurso de IP público for fornecido, verifique se ele existe no estado bem-sucedido. Se não for especificado, o script alocará um novo IP público no mesmo grupo de recursos. O nome é o nome do gateway V2 com -IP acrescentado. Se AppGWResourceGroupName for fornecido e um endereço de IP público não for fornecido, verifique se o recurso de IP público com o nome AppGWV2Name-IP não existe em um grupo de recursos com o nome AppGWResourceGroupName na assinatura V1.

• validateMigration: [switch]: opcional. Use esse parâmetro para habilitar o script para fazer algumas validações básicas de comparação de configuração após a criação do gateway V2 e a cópia de configuração. Por padrão, nenhuma validação é feita.

• enableAutoScale: [switch]: opcional. Use esse parâmetro para habilitar o script para habilitar o dimensionamento automático no novo gateway V2 depois que ele for criado. Por padrão, o dimensionamento automático está desabilitado. Você pode habilitá-lo manualmente mais tarde no gateway v2 recém-criado.

Como executar o script

Para executar o script:

1. Use Connect-AzAccount para se conectar ao Azure.
2. Use Import-Module Az para importar os módulos Az.
3. Execute o cmdlet Set-AzContext para definir o contexto ativo do Azure como a assinatura correta. Essa é uma etapa importante porque o script de migração pode limpar o grupo de recursos existente se ele não existir no contexto de assinatura atual.

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

4. Instale o script seguindo as etapas – Instalar Script
5. Execute Get-Help AzureAppGWMigration.ps1 para examinar os parâmetros necessários:
6. Execute o script usando os parâmetros apropriados. Isso pode levar de cinco a sete minutos para ser concluído.

      ./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
   

   Exemplo

      ./AzureAppGWMigration.ps1 `
      -resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/publicIPAddresses/MyPublicIP" `
      -validateMigration -enableAutoScale
   

Caveats\Limitations

• O novo gateway v2 tem novos endereços de IP públicos e privados. Não é possível mover os endereços de IP associados ao gateway v1 existente diretamente para o v2. Porém, você pode alocar um endereço de IP público ou privado existente (não alocado) no novo gateway V2.
• Você deve fornecer um espaço de endereço de IP para outra sub-rede na sua rede virtual em que seu gateway V1 está localizado. O script não pode criar o gateway V2 em uma sub-rede que já tenha um gateway V1. Se a sub-rede já tiver um gateway V2, o script ainda poderá funcionar, desde que haja espaço suficiente no endereço de IP disponível.
• Se você tiver um grupo de segurança de rede ou rotas definidas pelo usuário associadas à sub-rede de gateway V2, verifique se eles seguem os requisitos de NSG e os requisitos de UDR para uma migração bem-sucedida.
• As políticas de ponto de extremidade de serviço de rede virtual atualmente não têm suporte em uma sub-rede do Gateway de Aplicativo.
• Para migrar uma configuração TLS/SSL, você deve especificar todos os certificados TLS/SSL usados no gateway V1.
• Se você tiver o modo FIPS habilitado para o gateway V1, ele não será migrado para o novo gateway V2.
• WAFv2 é criado no modo de configuração do WAF antigo; A migração para a política do WAF é necessária.
• O novo WAFv2 é configurado para usar o CRS 3.0 por padrão. No entanto, como o CRS 3.0 está no caminho para a substituição, recomendamos atualizar para o conjunto de regras mais recente, DRS 2.1 após a migração. Para obter mais detalhes, consulte as regras e grupos de regras de CRS e DRS

Instalando o script

Há duas opções para você dependendo da configuração e das preferências do ambiente do PowerShell local:

• Se você não tiver os módulos Az do Azure instalados ou não desinstalar os módulos Az do Azure, a melhor opção é usar a opção Install-Script para executar o script.
• Se precisar manter os módulos Az do Azure, o melhor a fazer é baixar o script e executá-lo diretamente. Para determinar se você tem os módulos Az do Azure instalados, execute Get-InstalledModule -Name az. Se você não encontrar nenhum módulo Az instalado, poderá usar o método Install-Script.

Instalar usando o método Install-Script (recomendado)

Para usar essa opção, você não deve ter os módulos Az do Azure instalados no computador. Se estiverem instalados, o comando a seguir exibirá um erro. Você pode desinstalar os módulos Az do Azure ou usar a outra opção para baixar o script manualmente e executá-lo.

Execute o script com o seguinte comando para obter a versão mais recente:

• Para otimizar a clonagem, utilize o script de retenção de IP público — Install-Script -Name AzureAppGWIPMigrate -Force

• Para script de clonagem aprimorado – Install-Script -Name AzureAppGWClone -Force

• Para o script de clonagem herdado – Install-Script -Name AzureAppGWMigration -Force

Esse comando também instala os módulos Az necessários.

Instalar usando o script diretamente

Se você tiver alguns módulos do Az do Azure instalados e não puder desinstalá-los (ou não quiser desinstalá-los), poderá baixar manualmente o script usando a guia Download Manual no link de download do script.

O script será baixado como um arquivo nupkg bruto. Para instalar o script a partir do arquivo nupkg, confira Download manual do pacote.

Para o script de clonagem herdado, a versão 1.0.11 é a nova versão do script de migração que inclui correções de bug principais. Use a versão estável mais recente da Galeria do PowerShell

Como verificar a versão do script baixado

Para verificar a versão do script baixado, as etapas são as seguintes:

1. Extrair o conteúdo do pacote do NuGet.
2. Abra o arquivo .PS1 na pasta e verifique o .VERSION na parte superior para confirmar a versão do script baixado

<#PSScriptInfo
.VERSION 1.0.10
.GUID be3b84b4-e9c5-46fb-a050-699c68e16119
.AUTHOR Microsoft Corporation
.COMPANYNAME Microsoft Corporation
.COPYRIGHT Microsoft Corporation. All rights reserved.

Migração de tráfego

Pré-requisitos

• Primeiro, verifique se o script criou com êxito um novo gateway V2 com a configuração exata migrada do gateway V1. Você pode fazer essa verificação no portal do Azure.
• Também envie uma pequena quantidade de tráfego pelo gateway V2 como um teste manual.

Script de retenção de IP público

Depois de migrar com êxito a configuração e testar completamente seu novo gateway V2, esta etapa se concentra no redirecionamento do tráfego ao vivo. Fornecemos um script do Azure PowerShell projetado para manter o endereço IP público da V1.

• Troca o IP público: esse script reserva o IP público básico da V1, converte-o em Standard e o anexa ao gateway V2. Isso redireciona efetivamente todo o tráfego de entrada para o gateway V2.
• Tempo de inatividade esperado: essa operação de troca de IP normalmente resulta em um breve tempo de inatividade de aproximadamente 1 a 5 minutos. Planeje adequadamente.
• Após uma execução de script bem-sucedida, o IP público é movido do Gateway de Aplicativo V1 para o Gateway de Aplicativo V2, com o Gateway de Aplicativo V1 recebendo um novo IP público.

Você pode baixar esse script de retenção de IP público na Galeria do PowerShell

Parâmetros para o script:

Esse script requer os seguintes parâmetros obrigatórios:

• V1 ResourceId - A ID do recurso do Gateway de Aplicativo V1 cujo IP público será reservado e associado à V2.
• V2 ResourceId – A ID do recurso do Gateway de Aplicativo V2 ao qual o IP público V1 será atribuído. O gateway V2 pode ser criado manualmente ou usando qualquer um dos scripts de clonagem.

Depois de baixar e instalar o script

Execute AzureAppGWIPMigrate.ps1 com os parâmetros necessários:

   ./AzureAppGWIPMigrate.ps1
    -v1resourceId <V1 application gateway Resource ID>
    -v2resourceId <V2 application gateway Resource ID>

Exemplo

 ./AzureAppGWIPMigrate.ps1 `
 -v1resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv1appgateway `
 -v2resourceId /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/MyResourceGroup/providers/Microsoft.Network/applicationGateways/myv2appgateway `

Depois que a troca de IP for concluída, os clientes deverão verificar as operações de controle e plano de dados no gateway V2. Todas as ações do plano de controle, exceto Delete, serão desabilitadas no gateway V1.

Recomendações de Migração de Tráfego

Veja a seguir alguns cenários em que o gateway de aplicativo atual (Standard) pode receber tráfego de cliente e nossas recomendações para cada um:

• Uma zona DNS personalizada (por exemplo, contoso.com) que aponta para o endereço de IP de front-end (usando um registro A) associado ao gateway standard V1 ou WAF V1. Você pode atualizar seu registro DNS para apontar para o IP de front-end ou rótulo DNS associado ao seu gateway de aplicativo Standard_V2. Dependendo do TTL configurado em seu registro DNS, pode levar algum tempo para que todo o tráfego do cliente migre para o novo gateway V2.
• Uma zona DNS personalizada (por exemplo, contoso.com) que aponta para o rótulo DNS (por exemplo: myappgw.eastus.cloudapp.azure.com usando um registro CNAME) associado ao seu gateway V1. Você tem duas opções:
  • Se você usar endereços de IP públicos no seu gateway de aplicativo, poderá fazer uma migração granular controlada usando um perfil do Gerenciador de Tráfego para rotear incrementalmente o tráfego (método de roteamento de tráfego ponderado) no novo gateway V2. Você pode fazer isso adicionando os rótulos DNS dos gateways de aplicativo V1 e V2 no Perfil do Gerenciador de Tráfegoe ao CNAMEing do registro DNS personalizado (por exemplo, www.contoso.com) ao domínio do Gerenciador de Tráfego (por exemplo, contoso.trafficmanager.net).
  • Ou você pode atualizar seu registro DNS de domínio personalizado para apontar para o rótulo DNS do novo gateway de aplicativo V2. Dependendo do TTL configurado em seu registro DNS, pode levar algum tempo para que todo o tráfego do cliente migre para o novo gateway V2.
• Os clientes se conectam ao endereço IP de front-end do gateway de aplicativo. Atualize seus clientes para usar o endereço IP associado ao gateway de aplicativo V2 recém-criado. Recomendamos que você não use endereços IP diretamente. Considere usar o rótulo de nome DNS (por exemplo, yourgateway.eastus.cloudapp.azure.com) associado ao gateway de aplicativo, que você pode fazer o registro CNAME para a própria zona DNS personalizada (por exemplo, contoso.com).

Pós-migração

Depois que a migração de tráfego for bem-sucedida e depois de verificar totalmente se o aplicativo está sendo executado corretamente por meio do gateway V2, você poderá planejar com segurança o encerramento e a exclusão do recurso antigo do Gateway de Aplicativo V1 para evitar custos desnecessários.

Considerações de preço

Os modelos de preços são diferentes nos SKUs do Gateway de Aplicativo V1 e V2. A V2 é cobrada com base no consumo. Consulte Preços do Gateway de Aplicativo antes de migrar para obter informações sobre preços.

Diretrizes de eficiência de custo

O SKU V2 vem com uma variedade de vantagens, como um aumento de desempenho de 5x, segurança aprimorada com a integração do Key Vault, atualizações mais rápidas de regras de segurança em WAF_V2, regras personalizadas do WAF, associações de política e proteção contra Bots. Ele também oferece alta escalabilidade, roteamento de tráfego otimizado e integração perfeita com os serviços do Azure. Esses recursos podem melhorar a experiência geral do usuário, evitar lentidão durante tempos de tráfego pesado e evitar violações de dados caras.

Há cinco variantes disponíveis no SKU V1 com base na camada e tamanho - Standard_Small, Standard_Medium, Standard_Large, WAF_Medium e WAF_Large.

Para mais dúvidas sobre preços, trabalhe com seu CSAM ou entre em contato com nossa equipe de suporte para obter assistência.

Perguntas comuns

Perguntas comuns sobre migração podem ser encontradas aqui

Próximas etapas

Saiba mais sobre o gateway de aplicativo V2