Migrar o Gateway de Aplicativo do Azure e o Firewall de Aplicativo Web da V1 para a V2

Anunciámos a descontinuação do Application Gateway V1 SKU (Standard e WAF) a 28 de abril de 2023. O SKU V1 se aposenta em 28 de abril de 2026. Para obter mais informações, consulte Migrar os gateways de aplicações de SKU V1 para 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, recursos WAF aprimorados, proteção contra bots
• Recursos de monitoramento aprimorados: Ao contrário da V1, que só tinha monitoramento de CPU, a V2 fornece monitoramento abrangente para uso de CPU, memória e disco.
• Deteção e mitigação automática aprimoradas: os gateways V2 apresentam mecanismos avançados de deteção e processos de mitigação automatizados que podem identificar e resolver problemas de forma rápida e precisa sem a necessidade de intervenção manual.
• Todos os novos recursos são lançados para a V2 SKU.

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

Há duas etapas em uma migração:

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

Este artigo ajuda principalmente com a migração de configuração. A migração do 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 subscrição ativa. Crie uma conta gratuitamente.
• Um gateway de aplicação existente na versão padrão 1.
• Verifique se você tem os módulos mais recentes do PowerShell ou pode usar o Azure Cloud Shell no portal.
• Se você estiver executando o PowerShell localmente, também precisará executar Connect-AzAccount para criar uma conexão com o Azure.
• Certifique-se de que não haja nenhum gateway de aplicação existente com o nome fornecido do AppGW V2 e o nome do grupo de recursos na assinatura V1. Isto reescreve os recursos existentes.
• Se for fornecido um endereço IP público, verifique se está em bom estado. Se não for fornecido e AppGWResourceGroupName for fornecido, certifique-se de que o recurso de IP público com o nome AppGWV2Name-IP não exista num 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 back-end. O SKU V2 requer o upload de certificados raiz confiáveis para a mesma finalidade. Enquanto a V1 permite o uso de certificados autoassinados como certificados de autenticação, a V2 exige gerar e carregar um certificado raiz autoassinado se certificados autoassinados forem usados no back-end.
• Certifique-se de que nenhuma outra operação esteja planejada no gateway V1 ou em quaisquer recursos associados durante a migração.

Azure Cloud Shell

O Azure aloja o Azure Cloud Shell, um ambiente de shell interativo que pode utilizar através do seu browser. Pode utilizar o Bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. Você pode usar os comandos pré-instalados do Cloud Shell para executar o código neste artigo, sem precisar instalar nada em seu ambiente local.

Para iniciar o Azure Cloud Shell:

Opção	Exemplo/Ligação
Selecione Experimentar no canto superior direito de um código ou bloco de comandos. Selecionar Experimentar não copia automaticamente o código ou comando para o Cloud Shell.
Aceda a https://shell.azure.com ou selecione o botão Iniciar Cloud Shell para abrir o Cloud Shell no browser.
Selecione o botão Cloud Shell na barra de menus, na parte direita 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 comando.

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

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

Migração de configuração

A migração de configuração se concentra 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 as principais tarefas de implantação e configuração.

1. Script de clonagem aprimorado

Esta é a nova experiência que oferece uma experiência de migração melhorada ao:

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

Você pode baixar o script de clonagem Avançado na Galeria do PowerShell.

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

• AppGw V1 ResourceId -Required: Este parâmetro é a ID de Recurso do Azure para seu gateway Standard V1 ou WAF V1 existente. Para encontrar esse valor de cadeia de caracteres, navegue até o portal do Azure, selecione seu gateway de aplicativo ou recurso WAF e clique no link Propriedades do gateway. O ID do recurso está localizado 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, onde o Application Gateway V2 deve ser implantado
• AppGwName -Optional: Nome do gateway de aplicativo v2. Valor padrão = {AppGwV1 Name}_migrated
• AppGwResourceGroupName -Optional: Nome do grupo de recursos onde o V2 Application Gateway será criado. Se não for fornecido, o grupo de recursos do Application Gateway V1 será usado.
• PrivateIPAddress -Optional: Endereço IP privado a ser atribuído ao Application Gateway V2. Se não for fornecido, o IP privado aleatório será atribuído.
• ValidateBackendHealth -Optional: Validação pós-migração comparando a resposta ApplicationGatewayBackendHealth. Se não estiver definida, esta validação será ignorada.
• PublicIpResourceId -Optional: O endereço IP público resourceId (se já existir) pode ser anexado ao gateway de aplicativo. Se não for fornecido, o nome do IP público será {AppGwName}-IP.
• DisableAutoscale -Optional: Desabilite a configuração de dimensionamento automático para instâncias do Application Gateway V2, false por padrão
• WafPolicyName -Optional: 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 Set-AzContext cmdlet para definir o contexto ativo do Azure para 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 os passos do Install Script
5. Execute o script usando os parâmetros apropriados. Pode levar de cinco a sete minutos para terminar.

   ./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, revise 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 TLS de back-end por padrão (sem cadeia de certificados, expiração ou validação SNI) durante a clonagem. Se forem necessários certificados de autenticação ou validação TLS mais rígidos, o cliente poderá atualizar sua pós-criação do Application Gateway V2 para adicionar certificados raiz confiáveis e habilitar esse recurso de acordo com sua necessidade.
• Para passagem NTLM/Kerberos, defina a conexão de back-end dedicada como "true" nas configurações HTTP após a clonagem.

Advertências

• Você deve fornecer um espaço de endereço IP para outra sub-rede dentro de sua rede virtual onde 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 de endereço IP suficiente.
• Se você tiver um grupo de segurança de rede ou rotas definidas pelo usuário associadas à sub-rede do gateway V2, certifique-se de que eles cumpram os requisitos NSG e UDR para uma migração bem-sucedida
• Se você tiver o modo FIPS habilitado para seu gateway V1, ele não será migrado para seu novo gateway V2.
• O novo WAFV2 está configurado para usar CRS 3.0 por padrão. No entanto, como o CRS 3.0 está programado para ser descontinuado, recomendamos a atualização para o conjunto de regras mais recente, o DRS 2.1, após a migração. Para obter mais detalhes, consulte Grupos de regras CRS e DRS e as regras e verifique se têm um grupo de segurança de rede ou rotas definidas pelo usuário associadas à sub-rede do gateway V2, certificando-se de que cumprem os requisitos NSG e UDR para uma migração bem-sucedida.

2. Script de clonagem herdado

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

• Criar um novo Standard_V2 ou WAF_V2 Application Gateway em uma sub-rede de rede virtual especificada pelo usuário.
• Copiar 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 SSL e de autenticação como entrada e não suporta apenas gateways V2 privados. Você pode transferir este script de clonagem da Galeria do PowerShell

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

• resourceId: [String]: Obrigatório: este parâmetro é a ID de Recurso do Azure para seu gateway Standard V1 ou WAF V1 existente. Para encontrar esse valor de cadeia de caracteres, navegue até o portal do Azure, selecione seu gateway de aplicativo ou recurso WAF e clique no link Propriedades do gateway. O ID do recurso está localizado 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: Este parâmetro é o espaço de endereço IP que você alocou (ou deseja alocar) para uma nova sub-rede que contém 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 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 V2 Gateway, se houver, e tenha IPs disponíveis suficientes).
• appgwName: [String]: Opcional. Esta é uma cadeia de caracteres que você especifica para usar como o nome para o novo Standard_V2 ou WAF_V2 gateway. Se esse parâmetro não for fornecido, o nome do gateway V1 existente será usado com o sufixo _V2 acrescentado.
• AppGWResourceGroupName: [String]: Opcional. Nome do grupo de recursos onde você deseja que os recursos do Gateway de Aplicativo V2 sejam criados (o valor padrão é <V1-app-gw-rgname>)

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

  Esse parâmetro só será opcional se você não tiver ouvintes HTTPS configurados para seu gateway V1 ou WAF. Se você 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.

• Certificados SSL do 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 seguinte comando. Esses comandos acessam 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 um dos certificados baixados do Keyvault, você pode criar um novo objeto PSApplicationGatewaySslCertificate por meio do comando New-AzApplicationGatewaySslCertificate mostrado aqui. Você precisa do caminho para seu arquivo TLS/SSL Cert e da senha.

  //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]: Opcional. Uma lista separada por vírgulas de objetos PSApplicationGatewayTrustedRootCertificate que você/vós cria para representar os Trusted Root certificates para autenticação das suas 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, consulte New-AzApplicationGatewayTrustedRootCertificate.

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

• publicIpResourceId: [String]: Opcional. O resourceId do recurso de endereço IP público existente (SKU padrão) em sua assinatura que você deseja alocar para o novo gateway V2. Se o nome do recurso IP público for fornecido, verifique se ele existe no estado concluído com sucesso. Se isso não for especificado, o script alocará um novo endereço IP público no mesmo grupo de recursos. O nome é o nome do gateway V2 com -IP anexado. Se AppGWResourceGroupName for fornecido e um endereço IP público não for fornecido, verifique se o recurso IP público com 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 permitir que o script faça 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 após sua criação. Por padrão, o dimensionamento automático está desativado. Você sempre 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 Set-AzContext cmdlet para definir o contexto ativo do Azure para 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 os passos do Install Script
5. Execute Get-Help AzureAppGWMigration.ps1 para examinar os parâmetros necessários:
6. Execute o script usando os parâmetros apropriados. Pode levar de cinco a sete minutos para terminar.

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

Advertências\Limitações

• O novo gateway V2 tem novos endereços IP públicos e privados. Não é possível mover os endereços IP associados ao gateway V1 existente sem problemas para V2. No entanto, você pode alocar um endereço IP público ou privado existente (não alocado) para o novo gateway V2.
• Você deve fornecer um espaço de endereço IP para outra sub-rede dentro de sua rede virtual onde 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 de endereço IP suficiente.
• Se você tiver um grupo de segurança de rede ou rotas definidas pelo usuário associadas à sub-rede do gateway V2, certifique-se de que eles cumpram os requisitos NSG e UDR para uma migração bem-sucedida.
• Atualmente, não há suporte para políticas de ponto de ligação de serviço de rede virtual numa sub-rede do Application Gateway.
• Para migrar uma configuração TLS/SSL, você deve especificar todos os certificados TLS/SSL usados em seu gateway V1.
• Se você tiver o modo FIPS habilitado para seu gateway V1, ele não será migrado para seu novo gateway V2.
• WAFv2 é criado no modo de configuração WAF antigo; é necessária a migração para a política WAF.
• O novo WAFv2 está configurado para usar CRS 3.0 por padrão. No entanto, como o CRS 3.0 está programado para ser descontinuado, recomendamos a atualização para o conjunto de regras mais recente, o DRS 2.1, após a migração. Para obter mais detalhes, consulte Grupos de regras e regras 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 do Azure Az instalados ou não se importar em desinstalar os módulos do Azure Az, a melhor opção é usar a Install-Script opção para executar o script.
• Se você precisar manter os módulos do Azure Az, sua melhor aposta é baixar o script e executá-lo diretamente. Para determinar se você tem os módulos do Azure Az instalados, execute Get-InstalledModule -Name az. Se não vires nenhum módulo Az instalado, podes utilizar 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 do Azure Az instalados no seu computador. Se estiverem instalados, o comando a seguir exibirá um erro. Você pode desinstalar os módulos do Azure Az 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 clonagem aprimorada 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

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

Instalar usando o script diretamente

Se tiver alguns módulos do Azure Az instalados e não os conseguires desinstalar (ou não quiseres desinstalá-los), podes descarregar manualmente o script utilizando a aba de download manual no link de download do script.

O script é baixado como um arquivo nupkg bruto. Para instalar o script a partir desse arquivo nupkg, consulte 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 as principais correções de bugs. Certifique-se de usar 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. Extraia o conteúdo do pacote NuGet.
2. Abra o .PS1 arquivo 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 verificar isso no portal do Azure.
• Também envie uma pequena quantidade de tráfego através do gateway V2 como um teste manual.

Script de retenção de IP público

Depois de migrar com sucesso 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.

• Swaps Public IP: Este script reserva o IP público básico da V1, converte-o em Standard e anexa-o ao gateway V2. Isso efetivamente redireciona todo o tráfego de entrada para o gateway V2.
• Tempo de inatividade esperado: Esta operação de troca de IP normalmente resulta em um breve tempo de inatividade de aproximadamente 1-5 minutos. Planeie em conformidade.
• Após uma execução de script bem-sucedida, o IP público é movido do Application Gateway V1 para o Application Gateway V2, com o Application Gateway 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:

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

• V1 ResourceId – O ID de recurso do V1 Application Gateway cujo IP público será reservado e associado à V2.
• V2 ResourceId – A ID do recurso do V2 Application Gateway 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 `

Quando a troca de IP estiver concluída, os clientes devem verificar as operações de controle e plano de dados no gateway V2. Todas as ações do plano de controle, exceto Excluir, serão desabilitadas no gateway V1.

Recomendações de migração de tráfego

A seguir estão alguns cenários em que seu gateway de aplicativo atual (Padrão) 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 IP frontal (usando um registo A) associado ao seu gateway Standard V1 ou WAF V1. Você pode atualizar o seu registo DNS para apontar para o IP de frontend ou o rótulo DNS associado ao gateway de aplicação Standard_V2. Dependendo do TTL configurado no seu registo DNS, pode demorar algum tempo até que todo o tráfego do cliente migre para o seu 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 registo CNAME) associado ao seu gateway V1. Tem duas opções:
  • Se você usar endereços IP públicos em seu gateway de aplicativo, poderá fazer uma migração controlada e granular usando um perfil do Gerenciador de Tráfego para rotear incrementalmente o tráfego (método de roteamento de tráfego ponderado) para o novo gateway V2. Você pode fazer isso adicionando as etiquetas DNS dos gateways de aplicativos V1 e V2 ao perfil do Gerenciador de Tráfego e criando um CNAME para o seu registro DNS personalizado (por exemplo, www.contoso.com) para o 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 no seu registo DNS, pode demorar algum tempo até que todo o tráfego do cliente migre para o seu novo gateway V2.
• Seus clientes se conectam ao endereço IP frontend do gateway de aplicativo. Atualize seus clientes para usar o endereço IP associado ao gateway de aplicativo V2 recém-criado. Recomendamos que 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 CNAME para sua própria zona DNS personalizada (por exemplo, contoso.com).

Pós-migração

Quando 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 a desativação e exclusão do recurso antigo do V1 Application Gateway para evitar custos desnecessários.

Considerações sobre preços

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

Orientações em matéria de eficiência de custos

O SKU V2 vem com uma série de vantagens, como um aumento de desempenho de 5x, segurança aprimorada com integração do Key Vault, atualizações mais rápidas de regras de segurança no WAF_V2, regras personalizadas do WAF, associações de políticas e proteção de bot. 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 períodos de tráfego intenso e evitar violações de dados dispendiosas.

Existem cinco variantes disponíveis no V1 SKU com base no nível e tamanho - Standard_Small, Standard_Medium, Standard_Large, WAF_Medium e WAF_Large.

Para mais preocupações em relação aos 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óximos passos

Saiba mais sobre o Application Gateway V2