Migración de Azure Application Gateway y Web Application Firewall de V1 a V2

Artículo
07/15/2024

Anunciamos el desuso de la SKU de Application Gateway V1 (Estándar y WAF) el 28 de abril de 2023. La SKU V1 se retira el 28 de abril de 2026. Para obtener más información, consulta Migrar las Application Gateways de SKU V1 a SKU V2 antes del 28 de abril de 2026.

Azure Application Gateway y Web Application Firewall (WAF) V2 ahora ofrecen características adicionales, como el escalado automático, la disponibilidad, la redundancia de zona, un mayor rendimiento, las operaciones más rápidas y el rendimiento mejorado en comparación con la V1. Además, todas las características nuevas se publican para la SKU V2. Se recomienda encarecidamente crear un plan de migración ahora.

Las puertas de enlace V1 no se actualizan automáticamente a V2. Use esta guía de migración para ayudarle a planear y llevar a cabo las migraciones.

Hay dos fases en una migración:

Migración de la configuración
Migración del tráfico de cliente

Este artículo ayuda principalmente con la migración de configuración. La migración del tráfico de cliente varía en función del entorno. En este artículo se proporcionan algunas recomendaciones generales.

Requisitos previos

Una cuenta de Azure con una suscripción activa. Cree una cuenta gratuita.
Una instancia de Application Gateway V1 Estándar existente.
Asegúrese de que tiene los módulos más recientes de PowerShell, o bien, puede usar Azure Cloud Shell en el portal.
Si PowerShell se ejecuta localmente, también debe ejecutar Connect-AzAccount para crear una conexión con Azure.
Asegúrate de que no haya ninguna puerta de enlace de aplicación con el nombre de AppGW V2 y el nombre del grupo de recursos proporcionados en la suscripción V1. Esto reescribe los recursos existentes.
Si se proporciona una dirección IP pública, asegúrate de que se encuentra en un estado correcto. Si no se proporciona y se proporciona AppGWResourceGroupName, asegúrate de que el recurso de IP pública con el nombre AppGWV2Name-IP no existe en un grupo de recursos con el nombre AppGWResourceGroupName en la suscripción V1.
Para la SKU V1, se requieren certificados de autenticación para configurar conexiones TLS con servidores back-end. La SKU V2 requiere cargar certificados raíz de confianza para el mismo propósito. Aunque V1 permite el uso de certificados autofirmados como certificados de autenticación, V2 exige generar y cargar un certificado raíz autofirmado si se usan certificados autofirmados en el back-end.
Asegúrate de que ninguna otra operación esté planeada en la puerta de enlace V1 ni ningún recurso asociado durante la migración.

Azure Cloud Shell

En Azure se hospeda Azure Cloud Shell, un entorno de shell interactivo que puede utilizar mediante el explorador. Puede usar Bash o PowerShell con Cloud Shell para trabajar con los servicios de Azure. Puede usar los comandos preinstalados de Cloud Shell para ejecutar el código de este artículo sin tener que instalar nada en su entorno local.

Para iniciar Azure Cloud Shell:

Opción	Ejemplo o vínculo
Seleccione Pruébelo en la esquina superior derecha de un bloque de código o de comandos. Solo con seleccionar Pruébelo no se copia automáticamente el código o comando en Cloud Shell.
Vaya a https://shell.azure.com o seleccione el botón Iniciar Cloud Shell para abrir Cloud Shell en el explorador.
Seleccione el botón Cloud Shell en la barra de menús de la esquina superior derecha de Azure Portal.

Para usar Azure Cloud Shell:

Inicie Cloud Shell.
Seleccione el botón Copiar en un bloque de código (o bloque de comandos) para copiar el código o comando.
Pegue el código o comando en la sesión de Cloud Shell. Para ello, seleccione Ctrl+Mayús+V en Windows y Linux, o bien seleccione Cmd+Mayús+V en macOS.
Seleccione Enter para ejecutar el código o comando.

Nota

Se recomienda usar el módulo Azure Az de PowerShell para interactuar con Azure. Para comenzar, consulte Instalación de Azure PowerShell. Para más información sobre cómo migrar al módulo Az de PowerShell, consulte Migración de Azure PowerShell de AzureRM a Az.

Importante

Ejecute el cmdlet Set-AzContext -Subscription <V1 application gateway SubscriptionId> cada vez antes de ejecutar el script de migración. Esto es necesario para establecer el contexto de Azure activo en la suscripción correcta, ya que el script de migración podría limpiar el grupo de recursos existente si no existe en el contexto de suscripción actual. Este no es un paso obligatorio para la versión 1.0.11 o anterior del script de migración.

Importante

Ahora hay disponible una nueva versión estable del script de migración, la versión 1.0.11, que contiene correcciones de errores y actualizaciones importantes. Usa esta versión para evitar posibles problemas.

Migración de configuración

En este documento se proporciona un script de Azure PowerShell. Realiza las siguientes operaciones para ayudarle con la configuración:

Crea una puerta de enlace Standard_V2 o WAF_V2 en la subred de red virtual que especifique.
Copia sin problemas la configuración asociada con la puerta de enlace V1 Estándar o WAF en la puerta de enlace Standard_V2 o WAF_V2 recién creada.

Descarga del script

Puedes descargar el script de migración desde la Galería de PowerShell. Hay disponible una nueva versión estable (versión 1.0.11) del script de migración, que incluye actualizaciones principales y correcciones de errores. Se recomienda usar esta versión estable.

Uso del script

Nota:

Dispone de dos opciones en función de sus preferencias y de la configuración del entorno de PowerShell local:

Si no tiene instalados los módulos de Azure Az, o si no le importa desinstalarlos, la mejor alternativa es usar la opción Install-Script para ejecutar el script.
Si necesita conservar los módulos de Azure Az, lo mejor es que descargue el script y lo ejecute directamente.

Para determinar si tiene instalados los módulos de Azure Az, ejecute Get-InstalledModule -Name az. Si no ve ningún módulo de Az instalado, puede usar el método Install-Script.

Instalación con el método Install-Script (recomendado)

Para usar esta opción, los módulos de Azure Az no deben estar instalados en el equipo. En caso de que lo estén, el comando siguiente mostrará un error. Puede desinstalar los módulos de Azure Az o usar la otra opción para descargar manualmente el script y ejecutarlo.

Ejecute el script con el siguiente comando para obtener la última versión:

Install-Script -Name AzureAppGWMigration -Force

Este comando también instala los módulos de Az necesarios.

Instalación directamente con el script

Si tiene instalados algunos módulos de Azure Az y no puede desinstalarlos (o no le interesa hacerlo), puede descargar manualmente el script mediante la pestaña Descarga manual en el vínculo de descarga del script. El script se descarga como un archivo nupkg sin procesar. Para instalar el script desde este archivo nupkg, consulte Descarga manual del paquete.

La versión 1.0.11 es la nueva versión del script de migración que incluye correcciones de errores principales. Se recomienda usar esta versión estable.

Comprobación de la versión del script descargado

Para comprobar la versión del script descargado, los pasos son los siguientes:

Extraiga el contenido del paquete de NuGet.
Abre el archivo .PS1 en la carpeta y comprueba el .VERSION en la parte superior para confirmar la versión del script descargado

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

Asegúrese de usar la versión estable más reciente de la Galería de PowerShell

Ejecución del script

Para ejecutar el script:

Use Connect-AzAccount para conectarse a Azure.
Use Import-Module Az para importar los módulos de Az.
Ejecuta el cmdlet Set-AzContext para establecer el contexto de Azure activo en la suscripción correcta. Este es un paso importante porque el script de migración podría limpiar el grupo de recursos existente si no existe en el contexto de la suscripción actual.
```
Set-AzContext -Subscription '<V1 application gateway SubscriptionId>'
```

Ejecute Get-Help AzureAppGWMigration.ps1 para examinar los parámetros obligatorios:

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 la migración no intentes ninguna otra operación en la puerta de enlace V1 ni en ningún recurso asociado.

Parámetros del script:

resourceId: [String]: Required: este parámetro es el identificador de recurso de Azure para la puerta de enlace de WAF V1 o Estándar V1 existente. Para buscar este valor de cadena, vaya a Azure Portal, seleccione el recurso de puerta de enlace o WAF de la aplicación y haga clic en el vínculo Propiedades de la puerta de enlace. El identificador de recurso se encuentra en esa página.

También puede ejecutar los siguientes comandos de Azure PowerShell para obtener el identificador de recurso:
```
$appgw = Get-AzApplicationGateway -Name <V1 gateway name> -ResourceGroupName <resource group Name>
$appgw.Id
```
subredAddressRange: [String]: Required: este parámetro es el espacio de direcciones IP que ha asignado (o desea asignar) para una nueva subred que contenga la nueva puerta de enlace V2. El espacio de direcciones debe especificarse en notación CIDR. Por ejemplo: 10.0.0.0/24. No es necesario crear esta subred de antemano, pero el CIDR debe formar parte del espacio de direcciones de la red virtual. El script lo crea automáticamente si no existe y, si existe, usará el existente (asegúrese de que la subred esté vacía, solo contenga la puerta de enlace V2 si existe y tenga suficientes direcciones IP disponibles).
appgwName: [String]: Optional. Se trata de una cadena que se especifica para su uso como nombre de la nueva puerta de enlace Standard_V2 o WAF_V2. Si no se proporciona este parámetro, se usará el nombre de la puerta de enlace V1 existente con el sufijo _V2 anexado.
AppGWResourceGroupName: [String]: opcional. Nombre del grupo de recursos en el que desea que se creen los recursos de Application Gateway V2 (el valor predeterminado es <V1-app-gw-rgname>)

Nota:

Asegúrate de que no haya ninguna puerta de enlace de aplicación con el nombre de AppGW V2 y el nombre del grupo de recursos proporcionados en la suscripción V1. Esto reescribe los recursos existentes.

sslCertificates: [PSApplicationGatewaySslCertificate]: Optional. La lista separada por comas de objetos PSApplicationGatewaySslCertificate que cree para representar los certificados TLS/SSL de la puerta de enlace V1 debe cargarse en la nueva puerta de enlace V2. Para cada uno de los certificados TLS/SSL configurados para la puerta de enlace Estándar V1 o WAF V1, puede crear un objeto PSApplicationGatewaySslCertificate con el comando New-AzApplicationGatewaySslCertificate que se muestra aquí. Necesita la ruta de acceso del archivo del certificado TLS/SSL y la contraseña.

Este parámetro solo es opcional si no tiene clientes de escucha HTTPS configurados para la puerta de enlace V1 o WAF. Si tiene al menos un programa de instalación del agente de escucha HTTPS, debe especificar este 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
```
Puede pasar $mySslCert1, $mySslCert2 (separados por comas) en el ejemplo anterior como valores para este parámetro en el script.

sslCertificates de Keyvault: Optional. Puede descargar los certificados almacenados en Azure Key Vault y pasarlos al script de migración. Para descargar el certificado en forma de archivo PFX, ejecute el siguiente comando. Estos comandos acceden a SecretId y, después, guardan el contenido en forma de archivo 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 uno de los certificados descargados desde Keyvault, puede crear un nuevo objeto PSApplicationGatewaySslCertificate mediante el comando New-AzApplicationGatewaySslCertificate que se muestra aquí. Necesita la ruta de acceso del archivo del certificado TLS/SSL y la contraseña.

//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. Se trata de una lista de objetos PSApplicationGatewayTrustedRootCertificate separados por comas que se crea para representar los certificados raíz de confianza para la autenticación de las instancias de back-end de la puerta de enlace v2.
```
$certFilePath = ".\rootCA.cer"
$trustedCert = New-AzApplicationGatewayTrustedRootCertificate -Name "trustedCert1" -CertificateFile $certFilePath
```
Para crear una lista de objetos PSApplicationGatewayTrustedRootCertificate, consulte New-AzApplicationGatewayTrustedRootCertificate.
privateIpAddress: [String]: Optional. Dirección IP privada específica que quiere asociar a la nueva puerta de enlace V2. Debe ser de la misma red virtual que asigne a la nueva puerta de enlace V2. Si esto no se especifica, el script asigna una dirección IP privada para la puerta de enlace V2.
publicIpResourceId: [String]: Optional. El identificador de recurso de una dirección IP pública existente (SKU estándar) en la suscripción que quiere asignar a la nueva puerta de enlace V2. Si se proporciona el nombre del recurso de IP pública, asegúrate de que existe en estado correcto. Si esto no se especifica, el script asigna una nueva dirección IP pública en el mismo grupo de recursos. El nombre es el mismo de la puerta de enlace V2 con -IP anexado. Si se proporciona AppGWResourceGroupName y no se proporciona una dirección IP pública, asegúrate de que el recurso IP público con el nombre AppGWV2Name-IP no existe en un grupo de recursos con el nombre AppGWResourceGroupName en la suscripción V1.
validateMigration: [switch]: Optional. Usa este parámetro para habilitar que el script realice algunas validaciones de comparación de la configuración básica tras la creación de la puerta de enlace V2 y la copia de la configuración. De forma predeterminada, no se realiza ninguna validación.
enableAutoScale: [switch]: Optional. Usa este parámetro para habilitar que el script habilite el escalado automático en la nueva puerta de enlace V2 después de crearla. De forma predeterminada, el escalado automático está deshabilitado. Puede habilitarlo manualmente más adelante en la puerta de enlace V2 recién creada.

Ejecute el script con los parámetros adecuados. Podría tardar entre cinco y siete minutos en finalizar.

Los

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

Advertencias y limitaciones

La nueva puerta de enlace V2 tiene nuevas direcciones IP públicas y privadas. No es posible mover fácilmente las direcciones IP asociadas a la puerta de enlace V1 existente a V2. Sin embargo, puede asignar una dirección IP pública o privada existente (sin asignar) a la nueva puerta de enlace V2.
Debe proporcionar un espacio de direcciones IP para otra subred dentro de la red virtual en la que está ubicada la puerta de enlace V1. El script no puede crear la puerta de enlace V2 en una subred que ya tenga una puerta de enlace V1. Si la subred ya tiene una puerta de enlace V2, es posible que el script siga funcionando, siempre que haya suficiente espacio de direcciones IP disponible.
Si tiene un grupo de seguridad de red o rutas definidas por el usuario asociadas a la subred de puerta de enlace V2, asegúrese de que se ajusta a los requisitos de grupo de seguridad de red y a los requisitos de UDR para que la migración se realice correctamente
Actualmente, no se admiten directivas de punto de conexión de servicio de red virtual en una subred de Application Gateway.
Para migrar una configuración de TLS/SSL, debe especificar todos los certificados TLS/SSL que se usan en la puerta de enlace V1.
Si tiene el modo FIPS habilitado para la puerta de enlace V1, no se migrará a la nueva puerta de enlace V2. El modo FIPS no se admite en V2.
Si tiene una puerta de enlace de IP privada solo V1, el script genera una dirección IP privada y pública para la nueva puerta de enlace V2. La puerta de enlace de IP privada solo V2 se encuentra actualmente en versión preliminar pública. Una vez que esté disponible con carácter general, los clientes pueden usar el script para transferir su puerta de enlace de IP privada solo V1 a una puerta de enlace privada solo V2.
La autenticación NTLM y Kerberos no es compatible con Application Gateway V2. El script no puede detectar si la puerta de enlace atiende este tipo de tráfico y puede suponer un cambio importante en las puertas de enlace V1 a V2 si se ejecuta.
WAFv2 se crea en el modo de configuración de WAF antiguo; se requiere la migración a la directiva WAF.

Migración del tráfico

En primer lugar, asegúrese de que el script ha creado correctamente una puerta de enlace V2 con la configuración exacta migrada a través de la puerta de enlace V1. Puede comprobarlo desde Azure Portal.

Como prueba manual, envíe una pequeña cantidad de tráfico a través de la puerta de enlace V2.

A continuación se indican algunos escenarios en los que la puerta de enlace de aplicaciones actual (Estándar) puede recibir tráfico de cliente y nuestras recomendaciones en cada caso:

Zona DNS personalizada (por ejemplo, contoso.com) que apunta a la dirección IP de front-end (mediante un registro A) asociada a la puerta de enlace Estándar V1 o WAF V1.

Puede actualizar el registro DNS para que apunte a la etiqueta DNS o IP de front-end asociada a la puerta de enlace de aplicaciones Standard_V2. Según el TTL configurado en el registro DNS, el proceso de migrar todo el tráfico de cliente a la nueva puerta de enlace V2 podría tardar unos minutos.
Zona DNS personalizada (por ejemplo, contoso.com) que apunta a la etiqueta DNS (por ejemplo: myappgw.eastus.cloudapp.azure.com con un registro CNAME) asociada a la puerta de enlace V1.

Tiene dos opciones:
- Si usa direcciones IP públicas en la puerta de enlace de aplicaciones, puede llevar a cabo una migración pormenorizada controlada mediante un perfil de Traffic Manager para enrutar el tráfico de forma incremental (método de enrutamiento de tráfico ponderado) a la nueva puerta de enlace V2.
  
  Para hacerlo, agregue las etiquetas DNS de las puertas de enlace de aplicaciones V1 y V2 al perfil de Traffic Manager y asigne el registro CNAME del DNS personalizado (por ejemplo, www.contoso.com) en el dominio Traffic Manager (por ejemplo, contoso.trafficmanager.net).
- También puede actualizar el registro DNS del dominio personalizado para que apunte a la etiqueta DNS de la nueva puerta de enlace de aplicaciones V2. Según el TTL configurado en el registro DNS, el proceso de migrar todo el tráfico de cliente a la nueva puerta de enlace V2 podría tardar unos minutos.
Los clientes se conectan a la dirección IP de front-end de la puerta de enlace de aplicaciones.

Actualice los clientes para que usen las direcciones IP asociadas a la puerta de enlace de aplicaciones V2 recién creada. Se recomienda que no use direcciones IP directamente. Considere la posibilidad de usar la etiqueta de nombre DNS (por ejemplo, yourgateway.eastus.cloudapp.azure.com) asociada a la puerta de enlace de aplicaciones cuyo registro CNAME pueda asignar a su propia zona DNS personalizada (por ejemplo, contoso.com).

Consideraciones sobre precios

Los modelos de precios son diferentes para las SKU V1 y V2 de Application Gateway. V2 se cobra en función del consumo. Consulte Precios de Application Gateway antes de migrar para obtener información sobre precios.

Guía de rentabilidad

La SKU V2 incluye una serie de ventajas, como un aumento del rendimiento de 5x, una seguridad mejorada con la integración de Key Vault, actualizaciones más rápidas de reglas de seguridad en WAF_V2, reglas personalizadas de WAF, asociaciones de directivas y protección contra bots. También ofrece alta escalabilidad, enrutamiento de tráfico optimizado y fácil integración con los servicios de Azure. Estas características pueden mejorar la experiencia general del usuario, evitar ralentizaciones durante momentos de tráfico pesado y evitar infracciones de datos costosas.

Hay cinco variantes disponibles en la SKU V1 en función del nivel y el tamaño: Standard_Small, Standard_Medium, Standard_Large, WAF_Medium y WAF_Large.

SKU	V1 Precio fijo/mes	V2 Precio fijo/mes	Recomendación
Standard Medium	102.2	179.8	La SKU V2 puede controlar un mayor número de solicitudes que una puerta de enlace V1, por lo que se recomienda consolidar varias puertas de enlace V1 en una sola puerta de enlace V2 para optimizar el costo. Asegúrese de que la consolidación no supere los límites de Application Gateway. Se recomienda la consolidación 3:1.
WAF Medio	183.96	262.8	Igual que para Estándar Medio
Estándar Grande	467.2	179.58	Para estas variantes, en la mayoría de los casos, pasar a una puerta de enlace V2 puede proporcionarle una mejor ventaja de precio en comparación con V1.
WAF Grande	654.08	262.8	Igual que para Estándar Grande

Nota:

Los cálculos que se muestran aquí se basan en este de EE. UU. y para una puerta de enlace con 2 instancias en V1. El costo variable en V2 se basa en una de las 3 dimensiones con el uso más alto: Nuevas conexiones (50/s), Conexiones persistentes (2500 conexiones persistentes/min), Rendimiento (1 CU puede controlar 2,22 Mbps).

Los escenarios que se describen aquí son ejemplos y solo tienen fines ilustrativos. Para obtener información sobre los precios en su región, consulte la página de precios.

Para obtener más información sobre los precios, trabaje con su CSAM o póngase en contacto con nuestro equipo de soporte técnico para obtener ayuda.

Preguntas frecuentes

Puede encontrar preguntas comunes sobre la migración aquí

Pasos siguientes

Información sobre Application Gateway V2

Compartir a través de

Migración de Azure Application Gateway y Web Application Firewall de V1 a V2

Requisitos previos

Azure Cloud Shell

Migración de configuración

Descarga del script

Uso del script

Instalación con el método Install-Script (recomendado)

Instalación directamente con el script

Comprobación de la versión del script descargado

Ejecución del script

Advertencias y limitaciones

Migración del tráfico

Consideraciones sobre precios

Guía de rentabilidad

Preguntas frecuentes

Pasos siguientes

Comentarios

Recursos adicionales