VpnGw1–5 : fin des opérations le 30 septembre et migrations d'office déjà lancées — le runbook de bascule vers les SKU AZ

Il reste environ six semaines. Passé le 30 septembre 2026, une passerelle VPN Azure restée sur un SKU VpnGw1 à VpnGw5 non compatible zones continuera de faire passer du trafic — mais vous ne pourrez plus rien y modifier. Pas de nouvelle connexion, pas de changement de politique IPsec, pas d’ajustement BGP. En parallèle, depuis le mois d’août, Microsoft migre d’office les IP publiques Basic encore attachées à des passerelles, sans notification par ressource. Beaucoup d’équipes découvriront le sujet par un ticket de production ou un terraform apply qui échoue.

Le calendrier réel, sans approximation

Trois dates structurent la consolidation des SKU de passerelle :

Le mot « retrait » induit en erreur : le plan de données n’est pas coupé du jour au lendemain. Ce qui disparaît, c’est le plan de contrôle. Concrètement, après cette date, sur une passerelle non migrée : impossible d’ajouter ou de supprimer une connexion S2S, de modifier une PSK ou une politique IKE personnalisée, de changer les paramètres BGP, d’activer l’actif-actif, de mettre à jour un pool P2S ou un certificat racine. Une passerelle figée est une passerelle que vous ne pouvez plus dépanner autrement qu’en la recréant — donc avec une coupure subie, non planifiée.

Le second volet concerne les IP publiques Basic. La migration à l’initiative du client s’est terminée le 30 juin 2026 ; les demandes d’extension étaient automatiquement approuvées jusqu’au 31 juillet. Depuis août 2026, Microsoft bascule les ressources restantes vers des IP publiques Standard, pendant les heures creuses régionales, sans notification par passerelle. Attendez-vous à une brève interruption de connectivité au moment de la bascule ; entre-temps, la couverture SLA n’est pas garantie pour les configurations non migrées. Le même mouvement s’applique aux passerelles ExpressRoute.

Deux confusions à dissiper, parce qu’elles circulent beaucoup : le SKU Basic de passerelle n’est pas concerné par cette échéance de septembre 2026 (il a son propre cycle de vie et ses propres limitations, mais ce n’est pas le même sujet), et Generation1 n’a pas de date de retrait annoncée. Un VpnGw2 Gen1 doit migrer vers un SKU AZ ; il n’est pas obligé de passer en Gen2 dans la foulée, même si c’est souvent souhaitable.

Inventaire en 20 minutes

Avant toute décision, il faut un état des lieux exhaustif du tenant. Azure Resource Graph répond en quelques secondes, tous abonnements confondus :

resources
| where type =~ 'microsoft.network/virtualnetworkgateways'
| extend skuName      = tostring(properties.sku.name),
         gwType       = tostring(properties.gatewayType),
         generation   = tostring(properties.vpnGatewayGeneration),
         activeActive = tobool(properties.activeActive),
         ipconfs      = properties.ipConfigurations
| mv-expand ipconfs
| extend pipId = tolower(tostring(ipconfs.properties.publicIPAddress.id))
| join kind=leftouter (
    resources
    | where type =~ 'microsoft.network/publicipaddresses'
    | project pipId = tolower(id),
              pipSku = tostring(sku.name),
              pipAlloc = tostring(properties.publicIPAllocationMethod)
  ) on pipId
| extend actionRequise = (skuName !endswith 'AZ') or (pipSku =~ 'Basic')
| project subscriptionId, resourceGroup, name, location, gwType, skuName,
          generation, activeActive, pipSku, pipAlloc, actionRequise
| order by actionRequise desc, location asc

Exécution et export :

az extension add --name resource-graph 2>/dev/null
az graph query -q "$(cat gw-inventory.kql)" --first 1000 \
  --query "data" -o tsv > inventaire-passerelles.tsv

Deux corrélations à ajouter manuellement, car elles ne sont pas dans le Resource Graph :

• La disponibilité des zones dans la région. Un SKU AZ se déploie aussi dans une région sans zones de disponibilité : vous obtenez alors le SKU, la grille tarifaire et la pérennité, mais pas la redondance de zone. C’est un point à documenter explicitement pour ne pas vendre au métier une résilience inexistante.
• La criticité fonctionnelle. Classez chaque passerelle : tunnels de production, liens vers des sites industriels (souvent avec des fenêtres de maintenance quasi nulles), VPN partenaires (coordination externe obligatoire, donc délai long), P2S (impact utilisateur diffus mais massif), VNet-to-VNet.

C’est ce tableau de criticité, pas le nombre de passerelles, qui détermine votre planning.

Matrice d’impact : qui n’a rien à faire, qui doit agir

Vous pouvez laisser Microsoft faire si la passerelle utilise déjà une IP publique Standard, si le palier équivalent en AZ suffit (VpnGw2 → VpnGw2AZ), si l’architecture n’évolue pas et si vous acceptez une fenêtre choisie par Microsoft. Les mises à niveau techniques associées, y compris le passage à Generation2 quand il s’applique, sont diffusées par les service updates de la plateforme, sans coupure attendue.

Vous devez migrer vous-même dans au moins cinq cas :

1. Une IP publique Basic est encore attachée — vous ne voulez pas que la bascule se fasse un mardi à 3 h du matin sans préavis, surtout si votre pare-feu on-premise filtre par IP source.
2. Vous changez de palier (VpnGw1 → VpnGw3AZ) : c’est un redimensionnement, donc une réinitialisation du plan de données et une coupure de quelques minutes.
3. Vous passez en actif-actif à cette occasion : une seconde IP publique et une seconde configuration IP apparaissent, ce qui impose une reconfiguration côté peer.
4. La région n’a pas de zones : la migration reste obligatoire, mais l’argumentaire de résilience tombe, et il faut peut-être en profiter pour rediscuter la topologie.
5. Vous avez un gel de production ou un comité de changement qui exige une fenêtre nominative.

Le piège classique est le redimensionnement croisé : même palier ne veut pas dire même opération. Une transition entre générations (Generation1 → Generation2) et un changement de famille ne se traitent pas comme un simple ajustement de sku.name. Testez toujours l’opération sur une passerelle de recette avant de la jouer en production, et vérifiez le comportement retourné plutôt que de le déduire du nom du SKU.

Runbook de bascule manuelle

Préparation

Gelez les déploiements sur les groupes de ressources concernés (Azure Policy en deny temporaire ou verrou ReadOnly sur le RG, avec procédure de levée documentée). Sauvegardez ensuite tout ce qui n’est pas reconstructible depuis votre IaC :

$rg = 'rg-net-hub'
$export = @()
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName $rg | ForEach-Object {
  $c = $_
  $export += [pscustomobject]@{
    Name           = $c.Name
    Type           = $c.ConnectionType
    Protocol       = $c.ConnectionProtocol
    EnableBgp      = $c.EnableBgp
    IpsecPolicies  = $c.IpsecPolicies
    UsePolicyBased = $c.UsePolicyBasedTrafficSelectors
    DpdTimeout     = $c.DpdTimeoutSeconds
    LocalGateway   = $c.LocalNetworkGateway2.Id
    SharedKey      = (Get-AzVirtualNetworkGatewayConnectionSharedKey `
                       -Name $c.Name -ResourceGroupName $rg)
  }
}
$export | ConvertTo-Json -Depth 10 | Out-File .\connexions-backup.json

Ce fichier contient des PSK en clair : générez-le dans un runner éphémère, stockez-le dans Key Vault, purgez-le après validation. Notez aussi l’ASN BGP, les adresses de peering APIPA (indispensables pour les tunnels actif-actif avec BGP), les préfixes annoncés, les certificats racine P2S et le pool d’adresses clients.

Exécution

L’ordre compte. IP publique Basic → Standard d’abord, SKU ensuite : l’inverse vous expose à deux coupures au lieu d’une. Pour un redimensionnement au sein de la même génération, l’opération reste simple :

az network vnet-gateway update \
  --resource-group rg-net-hub --name gw-hub-weu \
  --sku VpnGw2AZ

Cas particuliers :

• S2S multi-tunnels : les connexions survivent à la migration, mais les tunnels se renégocient. Sur un hub à 20 connexions, la remontée n’est pas simultanée ; prévoyez plusieurs minutes avant convergence complète et surveillez les connexions dont le peer a un dead peer detection agressif.
• P2S : le pool d’adresses et les certificats racine sont portés par la passerelle. Après bascule, régénérez et redistribuez les profils clients si l’adresse ou le FQDN change ; c’est le point qui génère le plus d’appels au support.
• VNet-to-VNet : migrez les deux extrémités dans la même fenêtre, sinon vous cumulez deux interruptions.
• Virtual WAN : les passerelles VPN d’un hub Virtual WAN suivent le cycle de vie du hub et ne se manipulent pas comme une virtualNetworkGateways classique. Ne les traitez pas dans le même runbook.

Vérification post-bascule

az network vpn-connection show -g rg-net-hub -n cn-site-lyon \
  --query "{status:connectionStatus, in:ingressBytesTransferred, out:egressBytesTransferred}"

az network vnet-gateway list-bgp-peer-status -g rg-net-hub -n gw-hub-weu -o table
az network vnet-gateway list-learned-routes   -g rg-net-hub -n gw-hub-weu -o table
az network vnet-gateway list-advertised-routes -g rg-net-hub -n gw-hub-weu --peer 10.10.0.5 -o table

Comptez les préfixes appris et annoncés, et comparez au relevé pré-migration : un tunnel « Connected » avec la moitié des routes est un incident qui ne se déclarera qu’aux heures ouvrées. Complétez par les métriques TunnelAverageBandwidth, TunnelEgressPacketDropCount et un test applicatif de bout en bout (pas un simple ping : une transaction réelle, base de données ou API).

Côté on-premise

Sur Fortinet, Cisco ou pfSense, si l’IP publique de la passerelle Azure ne change pas et que la PSK est conservée, aucune reconfiguration n’est requise — les phases 1 et 2 se renégocient seules. Ce qui change les choses : le passage en actif-actif, qui expose deux IP publiques Azure et impose de déclarer un second peer, un second tunnel et, si BGP est utilisé, une seconde session avec ses adresses APIPA. Vérifiez aussi que vos ACL et vos règles de filtrage n’épinglent pas l’ancienne IP publique Basic.

Infrastructure as Code : éviter le destroy/create silencieux

C’est le risque le plus sous-estimé. Après une migration exécutée par Microsoft, votre état Terraform ne reflète plus la réalité. Un plan distrait proposera de « corriger » le SKU… en recréant la passerelle.

terraform plan -refresh-only          # constater le drift sans le corriger
terraform apply -refresh-only         # aligner l'état sur la réalité
terraform plan | grep -n "forces replacement"

Dans azurerm_virtual_network_gateway, un changement de sku se fait en place ; en revanche generation, type et vpn_type déclenchent un remplacement. Ne faites jamais confiance à votre mémoire : cherchez explicitement # forces replacement dans la sortie du plan avant chaque apply sur une passerelle.

Pour les attributs que la plateforme peut modifier sans vous, ignore_changes est acceptable temporairement et sur un périmètre étroit :

resource "azurerm_virtual_network_gateway" "hub" {
  name       = "gw-hub-weu"
  sku        = "VpnGw2AZ"
  generation = "Generation2"
  # ...

  lifecycle {
    prevent_destroy = true
    ignore_changes  = [tags]
  }
}

prevent_destroy est ici la vraie protection : il transforme une erreur silencieuse en échec explicite. Côté Bicep, le raisonnement est identique — un déploiement en mode Complete sur le groupe de ressources reste la façon la plus rapide de supprimer une passerelle par inadvertance.

Enfin, verrouillez le futur par la policy plutôt que par la vigilance :

{
  "policyRule": {
    "if": {
      "anyOf": [
        {
          "allOf": [
            { "field": "type", "equals": "Microsoft.Network/virtualNetworkGateways" },
            { "field": "Microsoft.Network/virtualNetworkGateways/sku.name",
              "notIn": ["VpnGw1AZ","VpnGw2AZ","VpnGw3AZ","VpnGw4AZ","VpnGw5AZ",
                        "ErGw1AZ","ErGw2AZ","ErGw3AZ"] }
          ]
        },
        {
          "allOf": [
            { "field": "type", "equals": "Microsoft.Network/publicIPAddresses" },
            { "field": "Microsoft.Network/publicIPAddresses/sku.name", "equals": "Basic" }
          ]
        }
      ]
    },
    "then": { "effect": "deny" }
  }
}

Déployez-la d’abord en audit pour mesurer le parc non conforme, puis en deny une fois la migration terminée.

Zone-redundant ≠ haute disponibilité

Un SKU AZ apporte deux choses distinctes qu’on confond souvent. Le mode zone-redundant répartit les instances de la passerelle sur plusieurs zones de la région : la perte d’une zone ne coupe pas le service. Le mode zonal épingle la passerelle à une zone précise, utile pour la colocaliser avec une charge de travail, mais sans redondance intrinsèque. Et dans une région sans zones, le SKU AZ ne fournit ni l’un ni l’autre.

Surtout, la redondance de zone ne protège que le côté Azure. Une passerelle zone-redundant reliée à un unique boîtier on-premise, alimenté par un seul lien opérateur, a toujours le même point de défaillance unique. La haute disponibilité réelle exige la combinaison : passerelle active-active, deux tunnels vers deux équipements distincts, deux accès WAN, et BGP pour arbitrer. Le SLA affiché et le RTO observé sont deux grandeurs différentes — la seconde dépend surtout de vos timers de détection et de la convergence de vos routes.

Cette échéance forcée est donc une bonne occasion de rouvrir le dossier topologie : consolidation hub-and-spoke, bascule vers Virtual WAN si le nombre de sites explose, ou couplage ExpressRoute avec un VPN S2S en secours.

L’angle FinOps

Point rarement mis en avant : les tarifs des SKU AZ sont, à palier équivalent, inférieurs à ceux des SKU non-AZ correspondants — mais la nouvelle grille ne s’applique évidemment qu’après migration. Rester sur un SKU non-AZ revient donc à payer plus cher un service qui offre moins de garanties et qui perdra bientôt son plan de contrôle. Vérifiez la grille de votre région : sur un parc de plusieurs dizaines de passerelles, l’écart n’est pas anecdotique.

L’erreur symétrique consiste à profiter de la migration pour surdimensionner « au cas où ». Dimensionnez sur les métriques réelles : TunnelAverageBandwidth au 95e percentile, nombre de tunnels S2S et de connexions P2S simultanées, débit agrégé aux heures de pointe. Un VpnGw3AZ acheté pour un pic mensuel de 200 Mbit/s est une dette récurrente.

Le cas ExpressRoute

Les passerelles ExpressRoute suivent la même logique de consolidation vers les SKU ErGwXAZ, avec une différence de parcours : les migrations sont largement initiées par Microsoft, et l’outil de migration effectue des contrôles de prérequis en amont. Les points de vigilance spécifiques : l’état du circuit et de ses peerings doit être sain avant la bascule, la connexion entre le circuit et la passerelle est conservée mais les sessions BGP se renégocient, et une architecture ExpressRoute + VPN de secours doit être testée dans le bon ordre — vous ne voulez pas migrer les deux chemins la même nuit. Si vous exploitez FastPath ou un ExpressRoute Direct, validez la compatibilité du SKU cible avant de planifier.

Checklist J-30 / J-7 / J+1

J-30 — Inventaire ARG consolidé et signé ; classement de criticité validé par les métiers ; identification des VPN partenaires nécessitant une coordination externe ; test de la procédure complète sur une passerelle de recette ; passage de la policy en audit.

J-7 — Fenêtres réservées et communiquées ; sauvegarde des configurations en Key Vault ; relevés de référence capturés (statut des connexions, sessions BGP, préfixes appris/annoncés, débit moyen) ; gel des déploiements IaC ; procédure de rollback écrite, y compris le scénario « recréation complète » avec son RTO estimé ; astreinte réseau on-premise confirmée.

J+1 — Comparaison des relevés avant/après ; vérification des routes apprises et annoncées sur chaque peer ; tests applicatifs de bout en bout ; terraform plan -refresh-only sur tous les workspaces concernés ; levée du gel ; bascule de la policy en deny.

Pour le comité de changement, le message tient en trois lignes : une échéance imposée par l’éditeur, une fenêtre choisie par nous plutôt que subie, une coupure de quelques minutes par passerelle avec un rollback documenté. L’alternative — ne rien faire — n’est pas le statu quo : c’est une bascule à une date inconnue, sans notification, sur une passerelle qu’on ne pourra plus reconfigurer.

La vraie difficulté de cette migration n’est pas technique : redimensionner un SKU tient en une commande. Elle est organisationnelle. Il faut retrouver qui possède chaque tunnel, obtenir une fenêtre sur des liens industriels qui n’en ont jamais, coordonner des partenaires externes, et empêcher un pipeline IaC de détruire une passerelle que la plateforme vient de migrer sous vos pieds. Les équipes qui traiteront cela en septembre feront le travail dans l’urgence, avec des passerelles déjà partiellement modifiées par Microsoft et un état Terraform désaligné. Celles qui lancent la requête Resource Graph aujourd’hui auront, dans une heure, la seule chose qui compte vraiment : la liste nominative de ce qui va casser.