Migrar o Gateway de Aplicativo do Azure e o Firewall de Aplicativo Web da V1 para a V2
Anunciamos a substituição do Application Gateway V1 SKU (Standard e WAF) em 28 de abril de 2023. O SKU V1 se aposenta em 28 de abril de 2026. Para obter mais informações, consulte Migrar seus gateways de aplicativos de SKU V1 para SKU V2 até 28 de abril de 2026.
O Gateway de Aplicativo do Azure e o WAF (Web Application Firewall) V2 agora oferecem recursos adicionais, como dimensionamento automático, disponibilidade, redundância de zona, maior desempenho, operações mais rápidas e taxa de transferência aprimorada em comparação com a V1. Além disso, todos os novos recursos são lançados para 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:
- Migrar a configuração
- 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 Application Gateway V1 Standard existente.
- 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-AzAccountpara criar uma conexão com o Azure. - Certifique-se de que não há nenhum gateway de aplicativo existente com o nome do AppGW V2 fornecido e o nome do grupo de recursos na assinatura V1. Isso reescreve 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 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:
Inicie o Cloud Shell.
Selecione o botão Copiar em um bloco de código (ou bloco de comando) para copiar o código ou comando.
Cole o código ou comando na sessão do Cloud Shell selecionando Ctrl+Shift+V no Windows e Linux ou selecionando Cmd+Shift+V no macOS.
Selecione Enter para executar o código ou comando.
Nota
Recomendamos que utilize o módulo Azure Az do PowerShell para interagir com o Azure. Para começar, consulte Instalar o Azure PowerShell. Para saber como migrar para o módulo do Az PowerShell, veja Migrar o Azure PowerShell do AzureRM para o Az.
Importante
Execute o Set-AzContext -Subscription <V1 application gateway SubscriptionId> cmdlet sempre antes de executar o script de migração. Isso é necessário para definir o contexto ativo do Azure para a assinatura correta, porque o script de migração pode limpar o grupo de recursos existente se ele não existir no contexto de assinatura atual. Esta não é uma etapa obrigatória para a versão 1.0.11 & acima do script de migração.
Importante
Uma nova versão estável do script de migração, a versão 1.0.11 está disponível agora, que contém importantes correções de bugs e atualizações. Use esta versão para evitar possíveis problemas.
Migração de configuração
Um script do Azure PowerShell é fornecido neste documento. Ele executa as seguintes operações para ajudá-lo com a configuração:
- Cria um novo gateway de Standard_V2 ou WAF_V2 em uma sub-rede de rede virtual que você especificar.
- Copia perfeitamente a configuração associada ao gateway V1 Standard ou WAF para o gateway Standard_V2 ou WAF_V2 recém-criado.
Download do script
Você pode baixar o script de migração da Galeria do PowerShell. Uma nova versão estável (Versão 1.0.11) do script de migração está disponível, que inclui atualizações importantes e correções de bugs. Recomenda-se o uso desta versão estável.
Usando o script
Nota
Execute o Set-AzContext -Subscription <V1 application gateway SubscriptionId> cmdlet sempre antes de executar o script de migração. Isso é necessário para definir o contexto ativo do Azure para a assinatura correta, porque o script de migração pode limpar o grupo de recursos existente se ele não existir no contexto de assinatura atual.
Esta não é uma etapa obrigatória para a versão 1.0.11 & acima do script de migração.
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-Scriptopçã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 você não vir nenhum módulo Az instalado, então você pode usar o Install-Script método.
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:
Install-Script -Name AzureAppGWMigration -Force
Este comando também instala os módulos Az necessários.
Instalar usando o script diretamente
Se você tiver alguns módulos do Azure Az 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 de script. O script é baixado como um arquivo nupkg bruto. Para instalar o script a partir desse arquivo nupkg, consulte Download manual do pacote.
A versão 1.0.11 é a nova versão do script de migração que inclui grandes correções de bugs. Recomenda-se o uso desta versão estável.
Como verificar a versão do script baixado
Para verificar a versão do script baixado, as etapas são as seguintes:
- Extraia o conteúdo do pacote NuGet.
- Abra o
.PS1arquivo na pasta e verifique o.VERSIONna 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.
- Certifique-se de usar a versão estável mais recente da Galeria do PowerShell
Como executar o script
Para executar o script:
Use
Connect-AzAccountpara se conectar ao Azure.Use
Import-Module Azpara importar os módulos Az.Execute o
Set-AzContextcmdlet 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>'Execute
Get-Help AzureAppGWMigration.ps1para examinar os parâmetros necessários: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
Nota
Durante a migração, não tente nenhuma outra operação no gateway V1 ou em quaisquer recursos associados.
Parâmetros para o script:
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.IdsubnetAddressRange: [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>)
Nota
Certifique-se de que não há nenhum gateway de aplicativo existente com o nome do AppGW V2 fornecido e o nome do grupo de recursos na assinatura V1. Isso reescreve os recursos existentes.
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-AzApplicationGatewaySslCertificatecomando 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 $passwordVocê pode passar (
$mySslCert1, $mySslCert2separado por vírgula) no exemplo anterior como valores para esse parâmetro no script.sslCertificates 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 $passwordtrustedRootCertificates: [PSApplicationGatewayTrustedRootCertificate]: Opcional. Uma lista separada por vírgulas de objetos PSApplicationGatewayTrustedRootCertificate que você cria para representar os certificados Trusted Root para autenticação de suas instâncias de back-end do gateway v2.
$certFilePath = ".\rootCA.cer" $trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePathPara 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 bem-sucedido. 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.
Execute o script usando os parâmetros apropriados. Pode levar de cinco a sete minutos para terminar.
Exemplo
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
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 extremidade de serviço de rede virtual em uma 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. O modo FIPS não é suportado na V2.
- Se você tiver um gateway V1 somente IP privado, o script gerará um endereço IP privado e público para o novo gateway V2. O gateway V2 somente IP privado está atualmente em visualização pública. Uma vez que ele se torne geralmente disponível, os clientes podem utilizar o script para transferir seu gateway V1 somente IP privado para um gateway V2 somente IP privado.
- A autenticação NTLM e Kerberos não é suportada pelo Application Gateway V2. O script não consegue detetar se o gateway está servindo esse tipo de tráfego e pode representar uma alteração de quebra de gateways V1 para V2 se executado.
- WAFv2 é criado no modo de configuração WAF antigo; é necessária a migração para a política WAF.
Migração de tráfego
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.
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 frontend (usando um registro A) associado ao gateway Standard V1 ou WAF V1.
Você pode atualizar seu registro DNS para apontar para o IP frontend ou rótulo DNS associado ao gateway de aplicativo Standard_V2. Dependendo do TTL configurado no seu registo DNS, poderá 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 registro 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 os rótulos DNS dos gateways de aplicativos V1 e V2 ao perfil do Gerenciador de Tráfego e CNAMEing seu 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 no seu registo DNS, poderá 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(s) endereço(s) IP(s) associado(s) 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 CNAME para sua própria zona DNS personalizada (por exemplo, contoso.com).
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.
| SKU | V1 Preço fixo/mês | V2 Preço fixo/mês | Recomendação |
|---|---|---|---|
| Médio padrão | 102.2 | 179.8 | O SKU V2 pode lidar com um número maior de solicitações do que um gateway V1, por isso recomendamos consolidar vários gateways V1 em um único gateway V2, para otimizar o custo. Certifique-se de que a consolidação não exceda os limites do Application Gateway. Recomendamos a consolidação 3:1. |
| Médio WAF | 183.96 | 262.8 | O mesmo que para o Standard Medium |
| Standard Grande | 467.2 | 179.58 | Para essas variantes, na maioria dos casos, mudar para um gateway V2 pode fornecer um melhor benefício de preço em comparação com V1. |
| WAF Grande | 654.08 | 262.8 | O mesmo que para Standard Large |
Nota
Os cálculos mostrados aqui são baseados no Leste dos EUA e para um gateway com 2 instâncias em V1. O custo variável em V2 é baseado em uma das 3 dimensões com maior uso: Novas conexões (50/seg), Conexões persistentes (2500 conexões persistentes/min), Taxa de transferência (1 pode lidar com 2,22 Mbps).
Os cenários descritos aqui são exemplos e são apenas para fins ilustrativos. Para obter informações sobre preços de acordo com a sua região, consulte a página Preços.
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