Ephemeral OS Disk avec Full Caching : la GA qui muscle la résilience de tes VMs Azure

Une panne de stockage distant qui fait tomber tes VM stateless, ça n’a rien de théorique — les coupures liées aux intempéries ou aux incidents d’alimentation en ont fait l’expérience à plus d’un admin. Azure vient de rendre généralement disponible une option qui change la donne pour ce scénario précis : le full caching pour les disques OS éphémères. Voyons ce que ça change concrètement, pour qui, et comment l’activer.

Un rappel rapide : à quoi sert un disque OS éphémère

Un disque OS éphémère (Ephemeral OS Disk) est créé directement sur le stockage local de la VM plutôt que sur le stockage Azure distant. Résultat : latence de lecture/écriture plus faible, réimagage bien plus rapide, et aucun coût de disque managé associé. La contrepartie logique, c’est que ces disques sont pensés pour des charges de travail sans état (stateless) : pas de déallocation possible, pas de snapshot, pas d’Azure Backup ni d’Azure Site Recovery dessus. Si ta VM doit survivre à un redémarrage avec ses données intactes, ce n’est pas l’outil qu’il te faut.

Jusqu’ici, le mode par défaut — le partial caching — répartissait le disque OS entre un disque de différences en local (qui reçoit toutes les écritures) et un disque de base sur le stockage managé (qui sert les lectures des fichiers d’origine). Ça fonctionne bien, mais ça garde une dépendance résiduelle au stockage distant pour les lectures.

Ce que change le full caching (désormais GA)

Avec le full caching, l’intégralité du disque OS est mise en cache sur le stockage local : la dépendance au stockage distant disparaît complètement en régime stabilisé. Concrètement, à la création de la VM, l’espace de stockage local disponible est réduit de deux fois la taille du disque OS, cet espace servant à stocker la copie complète du disque. La mise en cache se fait en arrière-plan après le démarrage de la VM, donc sans impact sur le temps de création.

Le bénéfice est double : de meilleures performances (plus aucune latence de lecture/écriture distante en régime stabilisé) et une résilience accrue face aux coupures de stockage distant, puisque le disque OS reste disponible même si Azure Storage rencontre un incident dans la région. C’est exactement le scénario visé par Microsoft : limiter les interruptions de service causées par des événements externes (intempéries, coupures d’alimentation) plutôt que par une panne applicative.

Prérequis et VM compatibles

Avant de te lancer, vérifie ces points :

• Le disque OS doit être stateless (c’est déjà une condition du mode éphémère en général).
• La taille du stockage local de la taille de VM choisie doit être supérieure à 2 fois la taille du disque OS + 1 Gio.
• Il faut utiliser la version d’API 2025-04-01 ou ultérieure.
• Seules les tailles de VM avec 8 vCPU ou plus sont éligibles pour l’instant (le support des tailles à 2 et 4 vCPU est prévu pour une version future) : toutes les séries N, L, M et H, ainsi que les séries D, DC, E, Eb et EC en v5/v6/v7, et les séries F en v6/v7.

Autre bonne nouvelle côté budget : le full caching ne coûte rien de plus que les tarifs standards de VM et de disque — un point confirmé explicitement dans la FAQ officielle Microsoft Learn. Si tu suis de près tes coûts Azure comme on en parlait dans notre article FinOps sur Cost Management, c’est un gain de résilience qui ne vient pas grignoter ton budget.

Comment l’activer

Avec Azure CLI

az vm create \
  --resource-group monGroupeRessources \
  --name maVM \
  --image imageChoisie \
  --size Standard_D8ds_v6 \
  --ephemeral-os-disk true \
  --ephemeral-os-disk-placement NvmeDisk \
  --ephemeral-os-disk-enable-full-caching true \
  --os-disk-caching ReadOnly \
  --admin-username azureuser \
  --generate-ssh-keys

Le paramètre clé est --ephemeral-os-disk-enable-full-caching true. Pour un scale set, le même paramètre s’applique avec az vmss create.

Avec un template ARM

Ajoute la propriété diffDiskSettings à la ressource Microsoft.Compute/virtualMachines (ou virtualMachineScaleSets), en définissant enableFullCaching à true et en utilisant la version d’API 2025-04-01 ou ultérieure. Si tu déploies tes VM via des modules standardisés — comme les Azure Verified Modules abordés dans notre article sur les Azure Landing Zones — c’est le genre de paramètre à intégrer directement dans ton module de VM réutilisable plutôt qu’à activer VM par VM.

Pour quelles charges de travail ça change vraiment la donne

Le full caching a un intérêt particulier pour les charges IO-intensives et stateless : entraînement et inférence IA, bases de données à quorum, analytique de données, traitement temps réel. Ce sont des workloads où éliminer la latence de lecture/écriture distante en régime stabilisé se traduit directement par un gain de débit mesurable, pas juste un confort théorique.

FAQ

Puis-je activer le full caching sur une VM existante ?

Non. Comme pour le mode éphémère en général, le full caching ne peut être configuré qu’à la création de la VM ou du scale set, pas appliqué après coup.

Quelle différence avec le mode partiel (par défaut) ?

En mode partiel, les écritures vont sur un disque local et les lectures des fichiers d’origine viennent d’un disque de base distant. En full caching, tout le disque OS — lectures et écritures en régime stabilisé — reste local, ce qui élimine la dépendance résiduelle au stockage distant.

Le full caching fonctionne-t-il sur les VM à 2 ou 4 vCPU ?

Pas encore : seules les tailles à 8 vCPU ou plus sont éligibles aujourd’hui. Le support des plus petites tailles est prévu pour une version future, sans date précise communiquée.

Est-ce compatible avec Azure Kubernetes Service ?

Une version équivalente pour les node pools AKS existe, mais elle est encore en préversion (et uniquement à la création d’un node pool, pas en mise à jour d’un pool existant) — à ne pas confondre avec la disponibilité générale sur les VM et VMSS classiques.

Ce qu’il faut retenir

Le full caching pour les disques OS éphémères est l’un de ces changements peu spectaculaires mais concrètement utiles : zéro coût additionnel, configuration à la création de VM, et un vrai gain de résilience pour tes workloads stateless les plus sensibles à la latence. Si tu déploies des VM ou des scale sets IO-intensifs sur des tailles éligibles, c’est une case à cocher qui ne coûte rien à essayer dès ton prochain déploiement.