Azure Dsv7/Esv7 : les tailles à 248 et 372 vCPU passent en GA

372 vCPU et 2,8 Tio de mémoire sur une seule machine virtuelle : c’est désormais une taille Azure disponible en production, pas une démo de salon. Depuis le 25 août 2026, les tailles à 248 et 372 vCPU des séries D/E v7 sont passées en disponibilité générale, et elles changent la donne pour tout ce qui ne se découpe pas facilement en petits morceaux — grosses bases en mémoire, workloads d’IA à contexte large, applications sensibles à la latence inter-nœuds.

Ce qui change avec ces nouvelles tailles

Les séries concernées sont Dsv7, Ddsv7, Esv7 et Edsv7, toutes bâties sur un processeur Intel Xeon 6 6973P-C (Granite Rapids) cadencé à 3,6 GHz en turbo tous cœurs, avec AVX-512 et Advanced Matrix Extensions. Microsoft annonce jusqu’à 20 % de performance de calcul en plus par rapport à la génération v6 précédente. Les deux tailles phares à retenir :

• Esv7 / Edsv7, 372 vCPU — jusqu’à 2 832 Gio de RAM, jusqu’à 400 Gbps réseau, et jusqu’à 800 000 IOPS / 20 Gio/s vers du stockage distant Premium SSD v2 ou Ultra Disk.
• Ddsv7 / Edsv7, 372 vCPU — avec disque NVMe local, jusqu’à 9,6 millions d’IOPS et 53,76 Gio/s de débit sur le disque temporaire local, d’après la fiche Edsv7-series de Microsoft Learn.

Pour fixer un repère : Standard_E372ids_v7 monte à 500 000 IOPS / 16 000 Mo/s en Premium SSD non mis en cache, et jusqu’à 800 000 IOPS / 20 000 Mo/s en Ultra Disk ou Premium SSD v2 — le haut du tableau des tailles Edsv7, documenté précisément sur la page de la famille D. Ces chiffres n’ont plus grand-chose à voir avec ce qu’on pouvait attendre d’une VM Azure il y a encore deux ans.

Côté disponibilité, la mise à jour couvre huit régions pour l’instant : Central US, East US, East US 2, Germany West Central, South Central US, Sweden Central, West US 2 et West US 3 — à vérifier avant de planifier un déploiement si tu n’es pas déjà dans une de ces zones.

Pour quels workloads ça change vraiment quelque chose

Microsoft cible explicitement les grosses bases en mémoire (SQL Server, SAP HANA, Redis en mode in-memory), les moteurs d’analytique et de data warehousing, et — sans surprise en 2026 — les workloads d’IA agentique à fenêtre de contexte large. Le point commun entre tous ces cas : ce sont des charges qui perdent en performance dès qu’elles doivent se répartir sur plusieurs nœuds et traverser le réseau pour chaque requête. Une base SAP HANA en mémoire qui tenait auparavant sur un cluster de plusieurs VM E v6 moyennes peut désormais tenir sur une seule E372ids_v7, ce qui supprime purement et simplement la latence de sharding inter-nœuds.

Ça a aussi une conséquence qu’on mentionne rarement dans les annonces marketing : moins de VM pour le même volume de calcul, c’est moins de licences par cœur à gérer si tu es sous licensing SQL Server Enterprise par cœur physique, et une surface d’administration réduite. Le revers de la médaille, c’est la concentration du risque — une seule VM de cette taille qui tombe, c’est potentiellement toute ta base qui part avec elle, pas un nœud sur quatre. Le Live Migration et les Memory Preserving Updates restent supportés sur ces séries, ce qui limite l’exposition aux redémarrages de maintenance planifiée, mais ça ne protège pas d’une panne applicative.

Le piège à connaître avant de migrer

Ces séries fonctionnent uniquement sur des VM de génération 2 (Gen2) et nécessitent une image qui supporte NVMe — un prérequis déjà posé par la bascule Trusted Launch par défaut sur les VM Gen2 dont on parlait en septembre. Si tu tentes de redéployer une image personnalisée ancienne, sans pilote NVMe, sur une taille Ddsv7 ou Edsv7, le déploiement échoue avec un message d’erreur explicite plutôt qu’un démarrage silencieusement dégradé — ce n’est pas un bug, c’est documenté comme un comportement attendu. Vérifie le support NVMe de ton image avant de migrer, pas après.

Autre point à ne pas laisser de côté : la variante Dsv7 « sans suffixe d » n’a aucun stockage local, contrairement à Ddsv7. Si ton workload a besoin du disque NVMe local — par exemple pour profiter du Full Caching des Ephemeral OS Disks passé en GA en septembre — c’est Ddsv7 ou Edsv7 qu’il te faut, pas Dsv7. Avec un disque local pouvant atteindre plusieurs téraoctets sur ces tailles, la contrainte « stockage local ≥ 2× la taille du disque OS + 1 Gio » exigée par le Full Caching devient triviale à satisfaire, même avec une image OS volumineuse.

Comment déployer une de ces tailles

Rien de nouveau côté outillage — ces tailles se créent comme n’importe quelle autre VM Azure, à condition de cibler une des régions disponibles :

az vm create \
  --resource-group mon-groupe-ressources \
  --name vm-sap-hana-01 \
  --image Ubuntu2404 \
  --size Standard_E372ids_v7 \
  --location swedencentral \
  --generation V2 \
  --admin-username azureuser \
  --generate-ssh-keys

Avant de lancer ce genre de déploiement en production, passe par la calculatrice de prix Azure — une VM à 372 vCPU n’a pas le même ticket d’entrée qu’une D4s_v5, et le coût du stockage Ultra Disk ou Premium SSD v2 associé se facture à part.

FAQ

Ces tailles remplacent-elles les séries v6 existantes ?
Non, les tailles v6 restent disponibles et ne sont pas annoncées en retrait. Les v7 s’ajoutent en haut de gamme, avec un plafond de vCPU et de débit nettement supérieur, pas comme un remplacement généralisé du catalogue existant.

Faut-il forcément du NVMe pour utiliser ces tailles ?
Oui pour le stockage local des variantes Ddsv7/Edsv7 — l’image OS doit supporter NVMe, sous peine d’échec de déploiement. Les variantes Dsv7/Esv7 sans stockage local n’ont pas cette contrainte puisqu’elles n’exposent pas de disque NVMe du tout.

Ces tailles sont-elles disponibles partout ?
Non, seulement dans huit régions pour l’instant (Central US, East US, East US 2, Germany West Central, South Central US, Sweden Central, West US 2, West US 3). Vérifie la disponibilité régionale avant d’engager un projet dessus.

En pratique

Si tu gères une base en mémoire ou un moteur d’analytique qui souffre aujourd’hui du sharding entre plusieurs VM, c’est le moment de recalculer le coût d’une consolidation sur une seule instance E372ids_v7 ou D372 — moins de nœuds à patcher, moins de licences par cœur à suivre, et une latence inter-nœuds qui disparaît purement et simplement. Vérifie juste le support NVMe de tes images avant de lancer le premier test, et commence par une région où ces tailles sont déjà disponibles.