Migrer la passerelle Azure Application Gateway et le pare-feu d’applications web de V1 à V2

Nous avons annoncé la dépréciation de la référence SKU Application Gateway V1 (Standard et WAF) le 28 avril 2023. La référence SKU V1 prend sa retraite le 28 avril 2026. Pour plus d’informations, consultez Effectuer une migration de vos passerelles d’application de la référence SKU V1 vers la V2 avant le 28 avril 2026.

La migration vers Azure Application Gateway et le pare-feu d’applications web (WAF) V2 offre plusieurs avantages :

• Meilleure résilience : redondance de zone de disponibilité (AZ), mise à l’échelle automatique.
• Meilleure sécurité : Intégration d’Azure Keyvault, fonctionnalités WAF améliorées, Bot Protection
• Fonctionnalités de surveillance améliorées : Contrairement à V1, qui ne surveillait que le processeur, V2 offre une surveillance complète de l’utilisation du processeur, de la mémoire et du disque.
• Amélioration de la détection et de l’atténuation automatique : les passerelles V2 présentent des mécanismes de détection avancés et des processus d’atténuation automatisés qui peuvent rapidement et précisément identifier et résoudre les problèmes sans intervention manuelle.
• Toutes les nouvelles fonctionnalités sont publiées pour le SKU V2.

Il est vivement recommandé de créer un plan de migration maintenant. Les passerelles V1 ne sont pas automatiquement mises à niveau vers V2. Utilisez ce guide de migration pour vous aider à planifier et à effectuer les migrations.

Il existe deux phases dans une migration :

1. Migrer la configuration
2. Migrer le trafic client

Cet article aide principalement à la migration de la configuration. La migration du trafic client varie en fonction de l’environnement. Certaines recommandations générales sont fournies dans cet article.

Prérequis

• Compte Azure avec un abonnement actif. Créez un compte gratuitement.
• Une Application Gateway V1 standard existante.
• Assurez-vous que vous disposez des tout derniers modules PowerShell, sinon vous pouvez utiliser Azure Cloud Shell dans le portail.
• Si vous exécutez PowerShell en local, vous devez également exécuter Connect-AzAccount pour créer une connexion avec Azure.
• Vérifiez qu’il n’existe pas de passerelle applicative avec le nom AppGW V2 fourni et le nom du groupe de ressources dans l’abonnement V1. Cette opération réécrit les ressources existantes.
• Si une adresse IP publique est fournie, vérifiez qu’elle est dans l’état Réussi. Si elle n’est pas fournie et qu’AppGwResourceGroupName est fourni, vérifiez que la ressource IP publique nommée AppGWV2Name-IP n’existe pas dans un groupe de ressources nommé AppGwResourceGroupName dans l’abonnement V1.
• Pour la référence SKU V1, les certificats d’authentification sont requis pour configurer des connexions TLS avec des serveurs principaux. La référence SKU V2 nécessite le chargement de certificats racines approuvés aux mêmes fins. Bien que la V1 autorise l’utilisation de certificats auto-signés comme certificats d’authentification, la V2 impose de générer et charger un certificat racine auto-signé si des certificats auto-signés sont utilisés dans le back-end.
• Vérifiez qu’aucune autre opération n’est planifiée sur la passerelle V1 ou sur une des ressources associées pendant la migration.

Azure Cloud Shell

Azure héberge Azure Cloud Shell, un environnement d’interpréteur de commandes interactif que vous pouvez utiliser dans votre navigateur. Vous pouvez utiliser Bash ou PowerShell avec Cloud Shell pour utiliser les services Azure. Vous pouvez utiliser les commandes préinstallées Cloud Shell pour exécuter le code de cet article sans avoir à installer quoi que ce soit dans votre environnement local.

Pour démarrer Azure Cloud Shell :

Choix	Exemple/Lien
Sélectionnez Essayer en haut à droite d’un bloc de code ou de commande. Cette action n’a pas pour effet de copier automatiquement le code ni la commande dans Cloud Shell.
Accédez à https://shell.azure.com ou sélectionnez le bouton Lancer Cloud Shell pour ouvrir Cloud Shell dans votre navigateur.
Sélectionnez le bouton Cloud Shell dans la barre de menus en haut à droite du portail Azure.

Pour utiliser Azure Cloud Shell, procédez comme suit :

1. Démarrez Cloud Shell.

2. Sélectionnez le bouton Copier sur un bloc de code (ou un bloc de commande) pour copier le code ou la commande.

3. Collez le code ou la commande dans la session Cloud Shell en sélectionnant Ctrl+Maj+V (sur Windows et Linux) ou Cmd+Maj+V (sur macOS).

4. Sélectionnez Entrer pour exécuter le code ou la commande.

Remarque

Nous vous recommandons d’utiliser le module Azure Az PowerShell pour interagir avec Azure. Pour bien démarrer, consultez Installer Azure PowerShell. Pour savoir comment migrer vers le module Az PowerShell, consultez Migrer Azure PowerShell à partir d’AzureRM vers Az.

Migration de la configuration

La migration de configuration se concentre sur la configuration de la nouvelle passerelle V2 avec les paramètres de votre environnement V1 existant. Nous fournissons deux scripts Azure PowerShell conçus pour faciliter la migration des configurations de V1 (Standard ou WAF) vers des passerelles V2 (Standard_V2 ou WAF_V2). Ces scripts facilitent le processus de transition en automatisant les tâches de déploiement et de configuration clés.

1. Script de clonage amélioré

Il s’agit de la nouvelle expérience qui offre une expérience de migration améliorée par :

• Élimination de la nécessité d’une entrée manuelle de certificats SSL front-end et de certificats racines approuvés par le back-end.
• Prise en charge du déploiement de passerelles V2 privées uniquement.

Remarque

Si la passerelle Application Gateway V1 existante est configurée avec un front-end privé uniquement, vous devez inscrire la fonctionnalité EnableApplicationGatewayNetworkIsolation dans l’abonnement pour le déploiement privé avant d’exécuter le script de migration. Cette étape est nécessaire pour éviter les échecs de déploiement.

Remarque

Les déploiements d’Application Gateway privés doivent avoir la délégation de sous-réseau configurée sur Microsoft.Network/applicationGateways. Procédez comme suit pour configurer la délégation de sous-réseau.

Vous pouvez télécharger le script de clonage amélioré à partir de PowerShell Gallery.

Paramètres du script : Ce script prend les paramètres ci-dessous :

• AppGw V1 ResourceId -Obligatoire : ce paramètre est l’ID de ressource Azure de votre passerelle Standard V1 ou WAF V1 existante. Pour trouver cette valeur de chaîne, accédez au portail Azure, sélectionnez votre passerelle d’application ou votre ressource WAF, puis cliquez sur le lien Propriétés de la passerelle. L’ID de ressource figure dans cette page. Vous pouvez également exécuter les commandes Azure PowerShell suivantes pour obtenir l’ID de ressource :

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

• SubnetAddressRange -Obligatoire : adresse de sous-réseau en notation CIDR, où Application Gateway V2 doit être déployé
• AppGwName -Facultatif : nom de la passerelle d’application v2. Valeur par défaut = {AppGwV1 Name}_migrated
• AppGwResourceGroupName -Facultatif : nom du groupe de ressources où V2 Application Gateway sera créé. S’il n’est pas fourni, le groupe de ressources Application Gateway V1 est utilisé.
• PrivateIPAddress -Facultatif : adresse IP privée à attribuer à Application Gateway V2. S’il n’est pas fourni, une adresse IP privée aléatoire est affectée.
• ValidateBackendHealth -Facultatif : après la validation de la migration en comparant la réponse ApplicationGatewayBackendHealth. Si elle n’est pas définie, cette validation est ignorée.
• PublicIpResourceId -Facultatif : l’ID de ressource d’adresse IP publique (s’il existe déjà) peut être attaché à la passerelle d’application. S’il n’est pas fourni, le nom d’adresse IP publique est {AppGwName}-IP.
• DisableAutoscale -Facultatif : désactiver la configuration de mise à l’échelle automatique pour les instances Application Gateway V2, false par défaut
• WafPolicyName -Facultatif : nom de la stratégie WAF qui sera créée à partir de la configuration WAF V1 et qui sera attachée à la passerelle WAF v2.

Comment exécuter le script

Pour exécuter le script :

1. Utilisez Connect-AzAccount pour vous connecter à Azure.
2. Utilisez Import-Module Az pour importer les modules Az.
3. Exécutez la cmdlet Set-AzContext pour définir le contexte Azure actif sur l’abonnement approprié. C’est une étape importante, car le script de migration peut nettoyer le groupe de ressources existant s’il n’existe pas dans le contexte d’abonnement actuel.

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

4. Installez le script en suivant les étapes d’installation du script
5. Exécutez le script en utilisant les paramètres appropriés. Cette opération peut prendre entre cinq et sept minutes.

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

   Exemple

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

• Une fois le script terminé, passez en revue la configuration de la passerelle V2 dans le portail Azure et testez la connectivité en envoyant le trafic directement à l’adresse IP de la passerelle V2.
• Le script assouplit la validation TLS principale par défaut (aucune chaîne de certificats, expiration ou validation SNI) pendant le clonage. Si des certificats de validation ou d’authentification TLS plus stricts sont requis, le client peut mettre à jour son application V2 après la création pour ajouter des certificats racines approuvés et activer cette fonctionnalité en fonction de ses besoins.
• Pour le passage NTLM/Kerberos, définissez la connexion principale dédiée sur « true » dans les paramètres HTTP après le clonage.

Avertissements

• Vous devez fournir un espace d’adressage IP pour un autre sous-réseau au sein de votre réseau virtuel où se trouve votre passerelle V1. Le script ne peut pas créer la passerelle V2 dans un sous-réseau qui a déjà une passerelle V1. Si le sous-réseau dispose déjà d’une passerelle V2, le script peut toujours fonctionner, à condition que suffisamment d’espace d’adressage IP soit disponible.
• Si vous avez un groupe de sécurité réseau ou des routes définies par l’utilisateur associés au sous-réseau de passerelle V2, assurez-vous qu’ils respectent les exigences NSG et les exigences UDR pour une migration réussie
• Si le mode FIPS est activé pour votre passerelle V1, il n’est pas migré vers votre nouvelle passerelle V2.
• Le nouveau WAFV2 est configuré pour utiliser CRS 3.0 par défaut. Toutefois, étant donné que CRS 3.0 se trouve sur le chemin de la dépréciation, nous vous recommandons de procéder à la mise à niveau vers le dernier jeu de règles, DRS 2.1 après la migration. Pour plus de détails, reportez-vous aux groupes de règles CRS et DRS et aux règles ayant un groupe de sécurité réseau ou des itinéraires définis par l'utilisateur associés au sous-réseau de passerelle V2, assurez-vous qu'ils respectent les exigences NSG et les exigences UDR pour une migration réussie.

Remarque

Pendant la migration, n’essayez aucune autre opération sur la passerelle V1 ou les ressources associées.

2. Script de clonage ancien

Il s’agit de l’ancien script de clonage, qui facilite la transition par :

• Création d’un nouveau Standard_V2 ou WAF_V2 Application Gateway dans un sous-réseau de réseau virtuel spécifié par l’utilisateur.
• Copie automatique de la configuration à partir d’une passerelle Standard ou WAF V1 existante vers la passerelle V2 nouvellement créée.
• Nécessite que le client fournisse des certificats SSL et authentification en tant qu’entrée et ne prend pas en charge les passerelles V2 privées uniquement, vous pouvez télécharger ce script de clonage à partir de PowerShell Gallery

Paramètres du script : Le script hérité prend les paramètres ci-dessous :

• resourceId : [String] : obligatoire: ce paramètre est l’ID de ressource Azure pour votre passerelle Standard V1 ou WAF V1 existante. Pour trouver cette valeur de chaîne, accédez au portail Azure, sélectionnez votre passerelle d’application ou votre ressource WAF, puis cliquez sur le lien Propriétés de la passerelle. L’ID de ressource figure dans cette page. Vous pouvez également exécuter les commandes Azure PowerShell suivantes pour obtenir l’ID de ressource :

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

• subnetAddressRange : [String] : obligatoire: ce paramètre est l’espace d’adressage IP que vous avez alloué (ou souhaitez allouer) pour un nouveau sous-réseau qui contient votre nouvelle passerelle V2. L’espace d’adressage doit être spécifié dans la notation CIDR. Par exemple : 10.0.0.0/24. Vous n’avez pas besoin de créer ce sous-réseau à l’avance, mais le CIDR doit faire partie de l’espace d’adressage du réseau virtuel. Le script le crée pour vous s’il n’existe pas et s’il existe, il utilise celui existant (assurez-vous que le sous-réseau est vide, contient uniquement la passerelle V2 le cas échéant et dispose de suffisamment d’adresses IP disponibles).
• appgwName : [String] :facultatif. Il s’agit d’une chaîne que vous spécifiez comme nom de la nouvelle passerelle Standard_v2 ou WAF_v2. Si ce paramètre n’est pas fourni, le nom de votre passerelle V1 existante est utilisé avec le suffixe _V2 ajouté.
• AppGwResourceGroupName : [String] : facultatif. Nom du groupe de ressources dans lequel vous souhaitez que les ressources Application Gateway V2 soient créées (la valeur par défaut est <V1-app-gw-rgname>)

Remarque

Vérifiez qu’il n’existe pas de passerelle applicative avec le nom AppGW V2 fourni et le nom du groupe de ressources dans l’abonnement V1. Cette opération réécrit les ressources existantes.

• sslCertificates : [PSApplicationGatewaySslCertificate] :facultatif . Une liste séparée par des virgules des objets PSApplicationGatewaySslCertificate que vous créez pour représenter les certificats TLS/SSL à partir de votre passerelle V1 doit être chargée sur la nouvelle passerelle V2. Pour chacun des certificats TLS/SSL configurés pour votre passerelle Standard V1 ou WAF v1, vous pouvez créer un nouvel objet PSApplicationGatewaySslCertificate via la commande New-AzApplicationGatewaySslCertificate illustrée ici. Vous avez besoin du mot de passe et du chemin d'accès à votre fichier de certificat TLS/SSL.

  Ce paramètre n’est facultatif que si vous n’avez pas d’écouteurs HTTPS configurés pour votre passerelle V1 ou pare-feu d’applications web. Si vous avez au moins une configuration d’écouteur HTTPS, vous devez spécifier ce paramètre.

       $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
  

  Vous pouvez transmettre $mySslCert1, $mySslCert2 (séparés par des virgules) dans l’exemple précédent en tant que valeurs pour ce paramètre dans le script.

• sslCertificates de KeyVault :facultatif. Vous pouvez télécharger les certificats stockés dans Azure Key Vault et le transmettre au script de migration. Pour télécharger le certificat sous forme de fichier PFX, exécutez la commande suivante. Ces commandes accèdent à SecretId, puis enregistrent le contenu sous la forme d’un fichier 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)
  

  Pour chacun des certificats téléchargés à partir du coffre de clés, vous pouvez créer un objet PSApplicationGatewaySslCertificate via la commande New-AzApplicationGatewaySslCertificate présentée ici. Vous avez besoin du mot de passe et du chemin d'accès à votre fichier de certificat TLS/SSL.

  //Convert the downloaded certificate to SSL object
  $password = ConvertTo-SecureString  <password> -AsPlainText -Force 
  $cert = New-AzApplicationGatewaySSLCertificate -Name <certname> -CertificateFile <Cert-File-Path-1> -Password $password 
  

• trustedRootCertificates : [PSApplicationGatewayTrustedRootCertificate] : facultatif. Liste séparée par des virgules d’objets PSApplicationGatewayTrustedRootCertificate que vous créez pour représenter les certificats racines approuvés pour l’authentification de vos instances back-end à partir de votre passerelle v2.

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

  Pour créer une liste d’objets PSApplicationGatewayTrustedRootCertificate, consultez New-AzApplicationGatewayTrustedRootCertificate.

• privateIpAddress : [String] :facultatif . Adresse IP privée spécifique que vous souhaitez associer à votre nouvelle passerelle V2. Elle doit provenir du même réseau virtuel que vous allouez pour votre nouvelle passerelle V2. Si elle n’est pas spécifiée, le script alloue une adresse IP privée pour votre passerelle V2.

• publicIpResourceId : [String] :facultatif . ResourceId de l’adresse IP publique (référence SKU standard) existante dans votre abonnement que vous voulez allouer à la nouvelle passerelle V2. Si le nom de la ressource IP publique est fourni, vérifiez qu’il existe dans l’état Réussi. S’il n’est pas spécifié, le script alloue une nouvelle adresse IP publique dans le même groupe de ressources. Ce nom est le nom de la passerelle V2 avec -IP ajouté. Si AppGWResourceGroupName est fourni et qu’une adresse IP publique n’est pas fournie, vérifiez que la ressource IP publique portant le nom AppGWV2Name-IP n’existe pas dans un groupe de ressources portant le nom AppGWResourceGroupName dans l’abonnement V1.

• validateMigration : [switch] :facultatif . Utilisez ce paramètre pour permettre au script d’effectuer des validations de comparaison de configuration de base après la création de la passerelle V2 et la copie de la configuration. Par défaut, aucune validation n’est effectuée.

• enableAutoScale : [switch] :facultatif . Utilisez ce paramètre pour permettre au script d’activer la mise à l’échelle automatique sur la nouvelle passerelle V2 après sa création. Par défaut, la mise à l’échelle automatique est désactivée. Vous pouvez toujours l’activer manuellement par la suite sur la passerelle V2 nouvellement créée.

Comment exécuter le script

Pour exécuter le script :

1. Utilisez Connect-AzAccount pour vous connecter à Azure.
2. Utilisez Import-Module Az pour importer les modules Az.
3. Exécutez la cmdlet Set-AzContext pour définir le contexte Azure actif sur l’abonnement approprié. C’est une étape importante, car le script de migration peut nettoyer le groupe de ressources existant s’il n’existe pas dans le contexte d’abonnement actuel.

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

4. Installez le script en suivant les étapes d’installation du script
5. Exécutez Get-Help AzureAppGWMigration.ps1 pour examiner les paramètres requis :
6. Exécutez le script en utilisant les paramètres appropriés. Cette opération peut prendre entre cinq et sept minutes.

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

   Exemple

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

Mises en garde/Limitations

• La nouvelle passerelle V2 a de nouvelles adresses IP publiques et privées. Il n’est pas possible de déplacer de façon transparente les adresses IP associées à la passerelle V1 existante vers la version 2. Toutefois, vous pouvez allouer une adresse IP publique ou privée existante (non allouée) à la nouvelle passerelle V2.
• Vous devez fournir un espace d’adressage IP pour un autre sous-réseau au sein de votre réseau virtuel où se trouve votre passerelle V1. Le script ne peut pas créer la passerelle V2 dans un sous-réseau qui a déjà une passerelle V1. Si le sous-réseau dispose déjà d’une passerelle V2, le script peut toujours fonctionner, à condition que suffisamment d’espace d’adressage IP soit disponible.
• Si vous avez un groupe de sécurité réseau ou des itinéraires définis par l’utilisateur associés au sous-réseau de passerelle V2, vérifiez qu’ils respectent les exigences du groupe de sécurité réseau et les exigences UDR pour une migration réussie.
• Les stratégies de points de terminaison de service de réseau virtuel ne sont actuellement pas prises en charge dans un sous-réseau Application Gateway.
• Pour migrer une configuration TLS/SSL, vous devez spécifier tous les certificats TLS/SSL utilisés sur votre passerelle V1.
• Si le mode FIPS est activé pour votre passerelle V1, il n’est pas migré vers votre nouvelle passerelle V2.
• WAFv2 étant créé dans le mode de configuration de l’ancien WAF, la migration vers la stratégie WAF est nécessaire.
• Le nouveau WAFv2 est configuré pour utiliser CRS 3.0 par défaut. Toutefois, étant donné que CRS 3.0 se trouve sur le chemin de la dépréciation, nous vous recommandons de procéder à la mise à niveau vers le dernier jeu de règles, DRS 2.1 après la migration. Pour plus d’informations, reportez-vous aux groupes de règles et règles CRS et DRS

Remarque

L’authentification par relais NTLM et Kerberos est prise en charge par Application Gateway V2. Pour plus d’informations, reportez-vous aux connexions principales dédiées.

Installation du script

Remarque

Exécutez l’applet de commande Set-AzContext -Subscription <V1 application gateway SubscriptionId> chaque fois avant d’exécuter le script de migration. Cela est nécessaire pour définir le contexte Azure actif sur l’abonnement approprié, car le script de migration peut nettoyer le groupe de ressources existant s’il n’existe pas dans le contexte d’abonnement actuel.

Vous disposez de deux options selon vos préférences et votre configuration de l’environnement PowerShell local :

• Si vous n’avez pas installé les modules Azure Az ou si vous êtes prêt à désinstaller les modules Azure Az, la meilleure option consiste à utiliser l’option Install-Script pour exécuter le script.
• Si vous devez conserver les modules Azure Az, la meilleure solution qui s’offre à vous consiste à télécharger le script et à l’exécuter directement. Pour déterminer si vous avez installé les modules Azure Az, exécutez Get-InstalledModule -Name az. Si vous ne voyez aucun module Az installé, vous pouvez utiliser la méthode Install-Script.

Installer en utilisant la méthode Install-Script (recommandé)

Pour pouvoir utiliser cette option, les modules Azure Az ne doivent pas être installés sur votre ordinateur. S’ils sont installés, la commande suivante affiche une erreur. Vous pouvez désinstaller les modules Azure Az ou utiliser l’autre option pour télécharger le script manuellement et l’exécuter.

Exécutez le script avec la commande suivante pour récupérer la version la plus récente :

• Pour le clonage amélioré du script de rétention d’adresses IP publiques – Install-Script -Name AzureAppGWIPMigrate -Force

• Pour un script de clonage amélioré - Install-Script -Name AzureAppGWClone -Force

• Pour le script de clonage hérité - Install-Script -Name AzureAppGWMigration -Force

Cette commande installe également les modules Az requis.

Installer en utilisant directement le script

Si certains modules Azure Az sont installés et ne peuvent pas être désinstallés (ou si vous ne souhaitez pas les désinstaller), vous pouvez télécharger manuellement le script en utilisant l’onglet Téléchargement manuel dans le lien de téléchargement du script.

Le script est téléchargé sous forme de fichier nupkg brut. Pour installer le script à partir de ce fichier nupkg, consultez Téléchargement manuel de package.

Pour le script de clonage hérité, la version 1.0.11 est la nouvelle version du script de migration qui inclut des correctifs de bogues majeurs. Veillez à utiliser la dernière version stable de PowerShell Gallery

Comment vérifier la version du script téléchargé

Pour vérifier la version du script téléchargé, les étapes sont les suivantes :

1. Extrayez le contenu du package NuGet.
2. Ouvrez le fichier .PS1 dans le dossier et vérifiez la .VERSION en haut pour confirmer la version du script téléchargé

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

Migration du trafic

Prérequis

• Tout d’abord, vérifiez soigneusement que le script a réussi à créer une nouvelle passerelle V2 en migrant la configuration exacte à partir de votre passerelle V1. Vous pouvez vérifier cela à partir du portail Azure.
• De plus, envoyez une petite quantité de trafic via la passerelle V2 en tant que test manuel.

Script de rétention IP publique

Après avoir correctement migré la configuration et testé minutieusement votre nouvelle passerelle V2, cette étape se concentre sur la redirection du trafic en direct. Nous fournissons un script Azure PowerShell conçu pour conserver l’adresse IP publique de V1.

• Échange l’adresse IP publique : ce script réserve l’adresse IP publique de base de V1, la convertit en standard et l’attache à la passerelle V2. Cela redirige efficacement tout le trafic entrant vers la passerelle V2.
• Temps d’arrêt attendu : cette opération d’échange IP entraîne généralement un bref temps d’arrêt d’environ 1 à 5 minutes. Planifiez en conséquence.
• Une fois qu’un script a réussi, l’adresse IP publique est déplacée d’Application Gateway V1 vers Application Gateway V2, avec Application Gateway V1 recevant une nouvelle adresse IP publique.

Remarque

Le script de migration IP ne prend pas en charge les ressources d’adresse IP publique qui ont un nom DNS commençant par un caractère numérique. Cette limitation existe, car les ressources d’adresse IP publique n’autorisent pas les étiquettes de noms DNS qui commencent par un nombre. Ce problème est plus susceptible de se produire pour les passerelles V1 créées avant mai 2023, lorsque les adresses IP publiques ont été automatiquement affectées à un nom DNS par défaut du formulaire {GUID}.cloudapp.net. Pour poursuivre la migration, mettez à jour la ressource d’adresse IP publique pour utiliser une étiquette de nom DNS commençant par une lettre avant d’exécuter le script. En savoir plus sur la configuration du DNS d’adresse IP publique

Vous pouvez télécharger ce script de rétention d’adresse IP publique à partir de PowerShell Gallery

Paramètres du script :

Ce script nécessite les paramètres obligatoires suivants :

• V1 ResourceId : ID de ressource de la passerelle Application Gateway V1 dont l’adresse IP publique sera réservée et associée à V2.
• V2 ResourceId : ID de ressource de la passerelle Application Gateway V2 à laquelle l’adresse IP publique V1 sera affectée. La passerelle V2 peut être créée manuellement ou en utilisant l’un des scripts de clonage.

Après avoir téléchargé et installé le script

Exécutez AzureAppGWIPMigrate.ps1 avec les paramètres requis :

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

Exemple

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

Une fois l’échange IP terminé, les clients doivent vérifier les opérations de contrôle et de plan de données sur la passerelle V2. Toutes les actions du plan de contrôle, à l’exception de Delete, sont désactivées sur la passerelle V1.

Remarque

Pendant la migration IP, n’essayez aucune autre opération sur la passerelle V1 & V2 ou les ressources associées.

Remarque

L’échange IP public effectué par ce script est irréversible. Une fois lancé, il n’est pas possible de rétablir l’adresse IP sur la passerelle V1 à l’aide du script.

Recommandations relatives à la migration du trafic

Voici quelques scénarios dans lesquels votre passerelle d’application actuelle (Standard) peut recevoir le trafic client et nos recommandations pour chacune d’elles :

• Zone DNS personnalisée (par exemple, contoso.com) qui pointe vers l’adresse IP du front-end (à l’aide d’un enregistrement A) associée à votre passerelle Standard V1 ou WAF V1. Vous pouvez mettre à jour votre enregistrement DNS pour pointer vers l’étiquette DNS ou l’adresse IP de front-end associée à votre passerelle d’application Standard_V2. Selon la durée de vie configurée sur votre enregistrement DNS, il peut prendre un certain temps pour que tout le trafic client migre vers votre nouvelle passerelle V2.
• Zone DNS personnalisée (par exemple, contoso.com) qui pointe vers l’étiquette DNS (par exemple : myappgw.eastus.cloudapp.azure.com à l’aide d’un enregistrement CNAME) associé à votre passerelle V1. Vous avez deux choix :
  • Si vous utilisez des adresses IP publiques sur votre passerelle d’application, vous pouvez effectuer une migration granulaire contrôlée en utilisant un profil Traffic Manager pour acheminer de façon incrémentielle le trafic (méthode de routage du trafic par pondération) vers la nouvelle passerelle V2. Vous pouvez procéder en ajoutant les étiquettes DNS des deux passerelles d’application V1 et V2 au profil Traffic Manager et en liant via CNAME votre enregistrement DNS personnalisé (par exemple, www.contoso.com) au domaine Traffic Manager (par exemple, contoso.trafficmanager.net).
  • Ou, vous pouvez mettre à jour votre enregistrement DNS de domaine personnalisé pour pointer vers l’étiquette DNS de la nouvelle passerelle d’application V2. Selon la durée de vie configurée sur votre enregistrement DNS, il peut prendre un certain temps pour que tout le trafic client migre vers votre nouvelle passerelle V2.
• Vos clients se connectent à l’adresse IP de front-end de votre passerelle d’application. Mettez à jour vos clients pour utiliser l’adresse IP associée à la passerelle d’application V2 nouvellement créée. Nous vous recommandons de ne pas utiliser directement des adresses IP. Envisagez d’utiliser l’étiquette de nom DNS (par exemple, yourgateway.eastus.cloudapp.azure.com) associée à votre passerelle d’application que vous pouvez lier via CNAME à votre propre zone DNS personnalisée (par exemple, contoso.com).

Après la migration

Une fois la migration du trafic réussie et après avoir vérifié entièrement que l’application s’exécute correctement via la passerelle V2, vous pouvez planifier en toute sécurité la désactivation et la suppression de l’ancienne ressource Application Gateway V1 pour éviter les coûts inutiles.

Considérations relatives aux tarifs

Les modèles tarifaires sont différents pour les références SKU Application Gateway V1 et V2. V2 est facturé en fonction de la consommation. Consultez tarification d’Application Gateway avant de migrer pour obtenir des informations de tarification.

Conseils sur l’efficacité des coûts

La référence SKU V2 offre une gamme d’avantages tels qu’une amélioration des performances de 5x, une sécurité améliorée avec l’intégration de Key Vault, des mises à jour plus rapides des règles de sécurité dans WAF_V2, des règles personnalisées WAF, des associations de stratégie et la protection bot. Il offre également une scalabilité élevée, un routage optimisé du trafic et une intégration transparente avec les services Azure. Ces fonctionnalités peuvent améliorer l’expérience utilisateur globale, empêcher les ralentissements pendant les temps de trafic lourd et éviter les violations de données coûteuses.

Il existe cinq variantes disponibles dans la référence SKU V1 en fonction du niveau et de la taille : Standard_Small, Standard_Medium, Standard_Large, WAF_Medium et WAF_Large.

Référence (SKU)	Prix fixe V1/mo	Prix fixe V2/mo	Recommandation
Moyen standard	102.2	179.8	La référence SKU V2 peut gérer un plus grand nombre de requêtes qu’une passerelle V1. Nous vous recommandons donc de consolider plusieurs passerelles V1 dans une seule passerelle V2 pour optimiser le coût. Vérifiez que la consolidation ne dépasse pas les limites de Application Gateway. Nous vous recommandons de consolider 3 :1.
WAF Moyen	183.96	262.8	Identique à la moyenne standard
Grande taille standard	467,2	179.58	Pour ces variantes, dans la plupart des cas, le passage à une passerelle V2 peut vous offrir un meilleur avantage tarifaire par rapport à V1.
WAF large	654.08	262.8	Identique à la taille Large standard

Remarque

Les calculs présentés ici sont basés sur usa Est et pour une passerelle avec deux instances dans V1. Le coût variable dans V2 est basé sur l’une des trois dimensions avec une utilisation la plus élevée : nouvelles connexions (50/s), connexions persistantes (2500 connexions persistantes/min), Débit (un cu peut gérer 2,22 Mbits/s).

Les scénarios décrits ici sont des exemples et sont à des fins d’illustration uniquement. Pour obtenir des informations sur la tarification en fonction de votre région, consultez la page relative à la tarification.

Pour plus d’informations sur la tarification, contactez votre CSAM ou contactez notre équipe de support technique pour obtenir de l’aide.

Questions courantes

Vous trouverez les questions courantes sur la migration ici

Étapes suivantes

En savoir plus sur Application Gateway V2