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

Article
07/15/2024

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.

Azure Application Gateway et le pare-feu d’applications web (WAF) V2 offrent désormais des fonctionnalités supplémentaires telles que la mise à l’échelle automatique, la disponibilité, la redondance de zone, des performances plus élevées, des opérations plus rapides et un débit amélioré par rapport à V1. En outre, toutes les nouvelles fonctionnalités sont publiées pour la référence 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 :

Migrer la configuration
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 :

Option	Exemple/Lien
Sélectionnez Essayer dans le coin supérieur droite d’un bloc de codes ou de commandes. La sélection de Essayer ne copie pas 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 :

Démarrez Cloud Shell.
Sélectionnez le bouton Copier sur un bloc de codes (ou un bloc de commandes) pour copier le code ou la commande.
Collez le code ou la commande dans la session Cloud Shell en sélectionnant Ctrl+Maj+V sur Windows et Linux ou en sélectionnant Cmd+Maj+V sur macOS.
Sélectionnez Entrer pour exécuter le code ou la commande.

Notes

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 depuis AzureRM vers Az.

Important

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. Cette étape n’est pas obligatoire pour les versions 1.0.11 et ultérieures du script de migration.

Important

Une nouvelle version stable du script de migration, la version 1.0.11, est désormais disponible et contient d’importants correctifs de bogue et mises à jour. Utilisez cette version pour éviter les problèmes potentiels.

Migration de la configuration

Un script Azure PowerShell est fourni dans ce document. Il effectue les opérations suivantes pour vous aider à configurer :

Il crée une nouvelle passerelle Standard_v2 ou WAF_v2 dans un sous-réseau de réseau virtuel que vous spécifiez.
Il copie en toute transparence la configuration associée à la passerelle WAF ou Standard v1 vers la passerelle Standard_V2 ou WAF_V2 nouvellement créée.

Téléchargement du script

Vous pouvez télécharger le script de migration à partir de PowerShell Gallery. Une nouvelle version stable (version 1.0.11) du script de migration est disponible et comprend des mises à jour et des correctifs de bogues majeurs. Nous vous recommandons d’utiliser cette version stable.

Utilisation du script

Remarque

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 :

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.

La version 1.0.11 est la nouvelle version du script de migration qui comprend des correctifs de bogues majeurs. Nous vous recommandons d’utiliser cette version stable.

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 :

Extrayez le contenu du package NuGet.
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.

Veillez à utiliser la dernière version stable de PowerShell Gallery

Comment exécuter le script

Pour exécuter le script :

Utilisez Connect-AzAccount pour vous connecter à Azure.
Utilisez Import-Module Az pour importer les modules Az.
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>'
```

Exécutez Get-Help AzureAppGWMigration.ps1 pour examiner les paramètres requis :

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

Remarque

Pendant la migration, n’essayez pas d’autre opération sur la passerelle V1 ou une des ressources associées.

Paramètres liés au script :

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]: Optional. 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 mais pas d’adresse IP publique, 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.
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.

Exécutez le script en utilisant les paramètres appropriés. Cette opération peut prendre entre cinq et sept minutes.

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 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
Les stratégies de points de terminaison de service de réseau virtuel ne sont 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. Le mode FIPS n’est pas pris en charge dans v2.
Si vous disposez d’une passerelle IP privée uniquement V1, le script génère une adresse IP privée et publique pour la nouvelle passerelle V2. La passerelle IP privée uniquement V2 est actuellement en préversion publique. Dès qu'il sera disponible, les clients pourront utiliser le script pour transférer leur passerelle IP privée V1 vers une passerelle IP privée V2.
L’authentification NTLM et Kerberos n’est pas prise en charge par Application Gateway V2. Le script ne peut pas détecter si la passerelle gère ce type de trafic et peut créer un changement cassant des passerelles V1 à V2 s’il est exécuté.
WAFv2 étant créé dans le mode de configuration de l’ancien WAF, la migration vers la stratégie WAF est nécessaire.

Migration du trafic

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.

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

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, la migration de tout votre trafic client vers votre nouvelle passerelle V2 peut prendre un certain temps.
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 possibilités :
- 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, la migration de tout votre trafic client vers votre nouvelle passerelle V2 peut prendre un certain temps.
Vos clients se connectent à l’adresse IP de front-end de votre passerelle d’application.

Mettez à jour vos clients pour utiliser la ou les adresses IP associées à 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).

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.

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 2 instances dans V1. Le coût variable dans V2 est basé sur l’une des 3 dimensions avec une utilisation la plus élevée : nouvelles connexions (50/s), connexions persistantes (2500 connexions persistantes/min), Débit (1 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

Partager via

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

Prérequis

Azure Cloud Shell

Migration de la configuration

Téléchargement du script

Utilisation du script

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

Installer en utilisant directement le script

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

Comment exécuter le script

Mises en garde/Limitations

Migration du trafic

Considérations relatives aux tarifs

Conseils sur l’efficacité des coûts

Questions courantes

Étapes suivantes

Commentaires

Ressources supplémentaires