Automatic zone balance : Azure rééquilibre tes VMSS tout seul

Tu as configuré ton scale set sur trois zones de disponibilité, tu as vérifié la répartition le jour du déploiement, et tout allait bien : cinq VMs par zone. Six mois de scale-in et scale-out plus tard, sans que personne ne s’en aperçoive, la répartition réelle est devenue 2 / 4 / 7. Une panne sur la zone qui en concentre sept, et c’est près de la moitié de ta capacité qui disparaît d’un coup — alors que le scale set avait été pensé, à l’origine, pour tenir une perte de zone sans broncher.

C’est exactement le problème que la fonctionnalité Automatic zone balance pour les Virtual Machine Scale Sets vient corriger, passée en disponibilité générale le 15 octobre 2026. Elle ne remplace pas une stratégie de reprise après sinistre, mais elle règle un angle mort que beaucoup d’équipes découvrent seulement au pire moment.

Le déséquilibre de zone : un problème qui ne se voit pas

Quand tu déploies un scale set sur plusieurs zones de disponibilité, Azure tente de répartir les VMs aussi uniformément que possible à la création. Mais les contraintes de capacité et les opérations de scaling qui s’enchaînent ensuite peuvent faire dériver cette répartition dans le temps, sans qu’aucune alerte ne se déclenche — rien ne casse, rien ne tombe en erreur. Microsoft définit un scale set comme « équilibré » si chaque zone compte le même nombre de VMs à plus ou moins une instance près. En dessous de ce seuil, il est considéré en déséquilibre.

Prends un scale set avec 1 VM en zone 1, 3 en zone 2 et 3 en zone 3 : la zone 1 est sous-provisionnée, les zones 2 et 3 sont sur-provisionnées. Le risque, concrètement, c’est qu’une panne sur une seule zone sur-provisionnée affecte une part disproportionnée de ton application — l’inverse exact de ce que la répartition multi-zone est censée t’apporter.

Comment fonctionne le rééquilibrage

Le mécanisme repose sur une approche « create-before-delete » : Azure crée une nouvelle VM dans la zone sous-provisionnée, attend qu’elle devienne saine, puis supprime une VM de la zone sur-provisionnée. Une seule VM est déplacée à la fois, et les nouvelles instances utilisent toujours le SKU le plus récent défini dans le modèle du scale set.

Le délai d’attente de santé est fixé à 90 minutes. Si la nouvelle VM devient saine dans ce délai, l’ancienne VM de la zone sur-provisionnée est supprimée. Si elle ne le devient pas mais que la VM source, elle, reste saine, c’est la nouvelle VM qui est supprimée — le rééquilibrage échoue proprement plutôt que de dégrader ton application. Si la VM source devient elle-même défaillante pendant l’attente, elle est supprimée et la nouvelle VM est conservée.

Les garde-fous avant qu’un rééquilibrage ne démarre

• Le scale set ne doit pas être marqué pour suppression.
• Aucune opération PUT, PATCH ou POST en cours ou terminée depuis moins de 60 minutes (ajout de VM, suppression, mise à niveau en cours).
• Les VMs sous instance protection policy ne sont jamais déplacées, ni celles déjà désallouées ou en attente de suppression.
• Un scale-in déclenché par l’autoscale pendant un rééquilibrage est différé jusqu’à la fin de l’opération ; un scale-out ou un changement de capacité manuel, lui, annule le rééquilibrage en cours et applique directement la nouvelle capacité.

Détail qui compte en exploitation : le comptage des VMs pour détecter un déséquilibre inclut les instances actives, désallouées et éteintes. Mais le rééquilibrage ne se déclenche que si déplacer une VM active améliore réellement la répartition des VMs actives — une zone qui a le plus de VMs au total mais le moins de VMs actives n’est pas considérée comme sur-provisionnée pour autant.

Ce qu’il faut préparer avant d’activer la fonctionnalité

Trois prérequis, non négociables :

• Le monitoring de santé applicative doit être actif, via l’Application Health Extension ou les health probes du Load Balancer (les deux sont mutuellement exclusifs — un seul des deux mécanismes à la fois).
• Le scale set doit s’étendre sur au moins deux zones de disponibilité, avec toutes les VMs assignées à une zone — les scale sets avec des VMs régionales (non zonales) ne sont pas éligibles.
• Utiliser la version d’API Compute 2024-07-01 ou ultérieure.

Pense aussi à la marge de capacité : le rééquilibrage augmente temporairement ta capacité d’une VM pendant l’opération. Si tu utilises l’autoscale, vérifie que ton instance count maximum et tes règles de scale-in laissent cette marge, et que ton abonnement dispose du quota nécessaire — sans ça, le rééquilibrage ne démarre simplement pas.

Activer automatic zone balance

Dans le portail, c’est une case à cocher dans l’onglet Santé, sous la section Résilience, une fois le monitoring de santé configuré. En API REST ou via Azure CLI/PowerShell, ça passe par la propriété resiliencyPolicy du modèle du scale set :

PUT /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachineScaleSets/{vmScaleSetName}?api-version=2024-07-01

{
  "properties": {
    "resiliencyPolicy": {
      "AutomaticZoneRebalancingPolicy": {
        "Enabled": true,
        "RebalanceStrategy": "Recreate",
        "RebalanceBehavior": "CreateBeforeDelete"
      }
    }
  }
}

Activer automatic zone balance active aussi, par défaut, les automatic instance repairs — les deux mécanismes se complètent (l’un répare les VMs individuellement défaillantes, l’autre rééquilibre la répartition entre zones). Si tu as une raison précise de vouloir l’un sans l’autre, un paramètre automaticRepairsPolicy.enabled: false séparé permet de désactiver les instance repairs tout en gardant le rééquilibrage de zone actif.

Pour vérifier qu’un rééquilibrage a bien eu lieu, filtre les Activity Logs du scale set sur l’opération BalanceVMsAcrossZones, ou interroge l’Instance View API : le tableau orchestrationServices de la réponse contient l’état du service AutomaticZoneRebalancing et l’horodatage de son dernier changement de statut.

Les limites à connaître avant de l’activer partout

Le point le plus important : automatic zone balance détruit et recrée des VMs. Les ID d’instance, la configuration réseau spécifique à l’instance et les disques ne sont pas préservés dans cette opération. C’est pensé pour des charges stateless — un tiers web ou API derrière un load balancer, typiquement — pas pour des VMs avec un état local qui compte.

Ajoute à ça que le rééquilibrage reste une opération « best-effort » : s’il n’y a pas de capacité disponible dans la zone sous-provisionnée, l’opération est simplement retardée, sans garantie de délai. Et si une VM utilise un SKU différent du modèle actuel du scale set, elle perd ce SKU particulier une fois déplacée, puisque les nouvelles instances créées reprennent toujours le SKU le plus récent défini dans le modèle.

Faut-il l’activer par défaut ?

Pour un tier stateless derrière un Load Balancer ou une Application Gateway, oui, sans hésiter — c’est exactement le type de résilience passive qu’on voudrait avoir sans y penser, dans la même logique que le passage de Trusted Launch en option par défaut sur les VMs Gen2 : une protection qui ne coûte rien à l’usage et qu’on n’a plus besoin de se souvenir d’activer. Pour des scale sets avec des VMs qui portent un état local — cache applicatif réchauffé, disques de données attachés avec des données spécifiques à l’instance, configuration post-démarrage coûteuse à refaire — c’est une autre histoire : active plutôt une instance protection policy sur les instances concernées avant d’allumer le rééquilibrage automatique, pour éviter qu’Azure ne les recycle au mauvais moment. Et si tu veux un contrôle plus strict qu’un simple best-effort, la fonctionnalité complémentaire de placement de zone automatique (encore en préversion) permet d’imposer un équilibrage strict via zoneBalance et maxZoneCount — au prix d’un taux d’allocation potentiellement plus faible en cas de contrainte de capacité.

FAQ

Automatic zone balance protège-t-il contre une panne de zone en cours ?

Non. La documentation Microsoft est explicite sur ce point : la fonctionnalité ne surveille pas la santé des VMs en cas de panne de zone et ne doit pas être utilisée comme mécanisme de reprise après panne de zone. Elle corrige un déséquilibre de répartition en amont, pas une panne en cours.

Est-ce compatible avec des VMs de SKU différents dans le même scale set ?

Partiellement. Le rééquilibrage fonctionne, mais toute VM déplacée perd son SKU d’origine au profit du SKU le plus récent défini dans le modèle du scale set — à anticiper si tu fais cohabiter plusieurs générations de VMs intentionnellement.

Ça marche aussi sur les scale sets en mode Flexible orchestration ?

La documentation Microsoft présente la fonctionnalité pour les scale sets zone-spanning en général ; le suivi de l’état du service d’orchestration via l’Instance View API est en revanche spécifiquement documenté pour le mode Uniform. Vérifie le comportement exact sur le mode Flexible avant de t’appuyer dessus en production.

En pratique

Si tu as des scale sets zone-spanning qui tournent depuis plusieurs mois sans qu’on ait jamais revérifié leur répartition, c’est probablement le bon moment de regarder l’Activity Log ou l’onglet Résilience du portail. La dérive ne fait pas de bruit — jusqu’au jour où une zone tombe et où tu découvres, dans le mauvais ordre, à quel point la répartition s’était faite inégale. Ça rejoint une logique déjà vue avec le passage en GA d’Ephemeral OS Disk avec Full Caching : Azure muscle petit à petit la résilience par défaut de ses VMs, sans attendre que tu ailles la chercher toi-même.