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

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 más información, consulte Migrar las Application Gateways de SKU V1 a SKU V2 antes del 28 de abril de 2026.

La migración a Azure Application Gateway y Web Application Firewall (WAF) V2 ofrece varias ventajas:

• Mejor resiliencia: redundancia de zonas de disponibilidad (AZ), escalado automático
• Mejor seguridad: integración de Azure Keyvault, funcionalidades de WAF mejoradas, Protección contra bots
• Funcionalidades de supervisión mejoradas: a diferencia de V1, que solo tenía supervisión de CPU, V2 proporciona una supervisión completa para el uso de CPU, memoria y disco.
• Detección mejorada y mitigación automática: las puertas de enlace V2 incluyen mecanismos de detección avanzados y procesos de mitigación automatizados que pueden identificar y resolver problemas de forma rápida y precisa sin necesidad de intervención manual.
• Todas las nuevas funcionalidades se han lanzado para 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:

1. Migración de la configuración
2. 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úrese 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úrese 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 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. Al seleccionar Probar no se copia automáticamente el código ni el 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:

1. Inicie Cloud Shell.

2. Seleccione el botón Copiar en un bloque de código (o bloque de comandos) para copiar el código o comando.

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

4. Seleccione Enter para ejecutar el código o comando.

Migración de configuración

La migración de configuración se centra en configurar la nueva puerta de enlace V2 con la configuración del entorno V1 existente. Se proporcionan dos scripts de Azure PowerShell diseñados para facilitar la migración de configuraciones de V1 (Estándar o WAF) a puertas de enlace V2 (Standard_V2 o WAF_V2). Estos scripts ayudan a simplificar el proceso de transición mediante la automatización de las tareas clave de implementación y configuración.

1. Script de clonación mejorada

Esta es la nueva experiencia que ofrece una experiencia de migración mejorada mediante:

• Eliminar la necesidad de introducir manualmente certificados SSL de front-end y certificados raíz de confianza de back-end.
• Apoyo al despliegue de puertas de enlace V2 exclusivamente privadas.

Puede descargar el script de clonación mejorada desde la Galería de PowerShell.

Parámetros para el script: Este script toma los parámetros siguientes:

• AppGw V1 ResourceId -obligatorio: este parámetro es el id. 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
  

• SubnetAddressRange -Required: la dirección de subred en notación CIDR, donde se va a implementar Application Gateway V2
• AppGwName -Optional: nombre de la puerta de enlace de aplicaciones v2. Valor predeterminado = {AppGwV1 Name}_migrated
• AppGwResourceGroupName -Optional: nombre del grupo de recursos donde se creará La puerta de enlace de aplicaciones V2. Si no se proporciona, se usará el grupo de recursos de Application Gateway V1.
• PrivateIPAddress -Opcional: dirección IP privada que se va a asignar a Application Gateway V2. Si no se proporciona, se asignará una dirección IP privada aleatoria.
• ValidateBackendHealth -Optional: Validación posterior a la migración mediante la comparación de la respuesta de ApplicationGatewayBackendHealth. Si no se establece, se omitirá esta validación.
• PublicIpResourceId -opcional: si la resourceId de la dirección IP pública ya existe, se puede asociar a la puerta de enlace de aplicación. Si no se proporciona, el nombre de dirección IP pública será {AppGwName}-IP.
• DisableAutoscale -Optional: Deshabilitación de la configuración de escalado automático para instancias de Application Gateway V2, false de forma predeterminada
• WafPolicyName -Optional: nombre de la directiva waf que se creará a partir de la configuración de WAF V1 y se asociará a la puerta de enlace de WAF v2.

Ejecución del script

Para ejecutar el script:

1. Use Connect-AzAccount para conectarse a Azure.
2. Use Import-Module Az para importar los módulos de Az.
3. Ejecute 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>'
   

4. Instale el script siguiendo los pasos: Instalación del script
5. Ejecute el script con los parámetros adecuados. Podría tardar entre cinco y siete minutos en finalizar.

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

   Ejemplo

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

• Después de finalizar el script, revise la configuración de puerta de enlace V2 en Azure Portal y pruebe la conectividad enviando tráfico directamente a la dirección IP de la puerta de enlace V2.
• El script relaja la validación TLS de back-end de forma predeterminada (sin cadena de certificados, expiración o validación de SNI) durante la clonación. Si se requieren certificados de autenticación o validación TLS más estrictos, el cliente puede actualizar su instancia de Application Gateway V2 después de la creación para agregar certificados raíz de confianza y habilitar esta característica según sus necesidades.
• Para el paso a través de NTLM/Kerberos, establezca la conexión de back-end dedicada en "true" en la configuración HTTP después de la clonación.

Advertencias

• 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
• Si tiene el modo FIPS habilitado para la puerta de enlace V1, no se migrará a la nueva puerta de enlace V2.
• El nuevo WAFV2 está configurado para usar CRS 3.0 de forma predeterminada. Sin embargo, dado que CRS 3.0 está en la ruta de desuso, se recomienda actualizar al conjunto de reglas más reciente, DRS 2.1 después de la migración. Para obtener más información, consulte Reglas y grupos de reglas de CRS y DRS, tenga un grupo de seguridad de red o rutas definidas por el usuario asociadas a la subred de puerta de enlace V2 y asegúrese de que cumplan los requisitos de NSG y UDR para una migración correcta.

2. Script de clonación heredado

Este es el script de clonación anterior, que facilita la transición mediante:

• Creación de una nueva Standard_V2 o WAF_V2 Application Gateway en una subred de red virtual especificada por el usuario.
• Copia automáticamente la configuración desde una puerta de enlace estándar o WAF V1 existente a la puerta de enlace V2 recién creada.
• Requiere que el cliente proporcione certificados SSL y autenticación como entrada y no admita puertas de enlace V2 privadas. Puede descargar este script de clonación desde la Galería de PowerShell.

Parámetros para el script: El script heredado toma los parámetros siguientes:

• resourceId: [String]: Required: este parámetro es el id. 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
  

• subnetAddressRange: [String]: Required: este parámetro es el espacio de direcciones IP que ha asignado (o quiere 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]: Opcional. 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>)

• sslCertificates: [PSApplicationGatewaySslCertificate]: Opcional. 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, a continuación, guardan el contenido como un 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]: Opcional. 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]: Opcional. 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]: Opcional. 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úrese 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]: Opcional. 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]: Opcional. 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.

Ejecución del script

Para ejecutar el script:

1. Use Connect-AzAccount para conectarse a Azure.
2. Use Import-Module Az para importar los módulos de Az.
3. Ejecute 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>'
   

4. Instale el script siguiendo los pasos: Instalación del script
5. Ejecute Get-Help AzureAppGWMigration.ps1 para examinar los parámetros obligatorios:
6. Ejecute el script con los parámetros adecuados. Podría tardar entre cinco y siete minutos en finalizar.

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

   Ejemplo

      ./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 cumplen los requisitos de NSG y los requisitos de UDR para una migración correcta.
• 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.
• WAFv2 se crea en el modo de configuración de WAF antiguo; se requiere la migración a la directiva WAF.
• El nuevo WAFv2 está configurado para usar CRS 3.0 de forma predeterminada. Sin embargo, dado que CRS 3.0 está en la ruta de desuso, se recomienda actualizar al conjunto de reglas más reciente, DRS 2.1 después de la migración. Para más información, consulte Grupos de reglas y reglas de CRS y DRS.

Instalación del script

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:

• Para la clonación mejorada del script de retención de direcciones IP públicas: Install-Script -Name AzureAppGWIPMigrate -Force

• Para el script de clonación mejorada: Install-Script -Name AzureAppGWClone -Force

• Para el script de clonación heredado: 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.

Para el script de clonación heredado, la versión 1.0.11 es la nueva versión del script de migración que incluye correcciones de errores principales. Asegúrese de usar la versión estable más reciente de la Galería de PowerShell

Comprobación de la versión del script descargado

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

1. Extraiga el contenido del paquete de NuGet.
2. 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.

Migración del tráfico

Requisitos previos

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

Script para conservación de IP pública

Después de migrar correctamente la configuración y probar exhaustivamente la nueva puerta de enlace V2, este paso se centra en redirigir el tráfico activo. Proporcionamos un script de Azure PowerShell diseñado para conservar la dirección IP pública de V1.

• Intercambia la dirección IP pública: este script reserva la dirección IP pública básica de V1, la convierte en Estándar y la asocia a la puerta de enlace V2. Esto redirige eficazmente todo el tráfico entrante a la puerta de enlace V2.
• Tiempo de inactividad esperado: esta operación de intercambio de IP suele dar lugar a un breve tiempo de inactividad de aproximadamente 1 a 5 minutos. Planifique en consecuencia.
• Después de ejecutar un script correcto, la dirección IP pública se mueve de Application Gateway V1 a Application Gateway V2, con Application Gateway V1 recibiendo una nueva dirección IP pública.

Puede descargar este script de retención de IP pública desde la Galería de PowerShell.

Parámetros para el script:

Este script requiere los siguientes parámetros obligatorios:

• ResourceId V1: El identificador de recurso de la Puerta de Enlace de Aplicaciones V1, cuya dirección IP pública se reservará y se asociará a V2.
• ResourceId V2: el identificador de recurso de la puerta de enlace de aplicaciones V2 a la que se asignará la dirección IP pública V1. La puerta de enlace V2 se puede crear manualmente o usar cualquiera de los scripts de clonación.

Después de descargar e instalar el script

Ejecute AzureAppGWIPMigrate.ps1 con los parámetros necesarios:

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

Ejemplo

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

Una vez completado el intercambio de IP, los clientes deben comprobar las operaciones del plano de datos y de control en la puerta de enlace V2. Todas las acciones del plano de control excepto Eliminar se deshabilitarán en la puerta de enlace V1.

Recomendaciones de migración de tráfico

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

• 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 aplicación Standard_V2. Según el TTL configurado en el registro DNS, puede tardar un tiempo en migrar todo el tráfico de cliente a la nueva puerta de enlace V2.
• 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, puede tardar un tiempo en migrar todo el tráfico de cliente a la nueva puerta de enlace V2.
• 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 la dirección IP asociada 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).

Después de la migración

Una vez que la migración del tráfico se realiza correctamente y después de comprobar completamente que la aplicación se ejecuta correctamente a través de la puerta de enlace V2, puede planear de forma segura retirar y eliminar el recurso de Application Gateway V1 antiguo para evitar costos innecesarios.

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.

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