6 — Virtual Machines

IaaS Azure → VM Windows ou Linux. Tu gères l'OS, MS gère la couche infra (hyperviseur, hardware, réseau physique).

A. Présentation

Familles de VM (sizes)

À retenir (pièges classiques)

• Billing PAYG : VM Stopped = tu paies toujours. Stopped (Deallocated) = tu paies seulement le storage des disks. Bouton "Stop" depuis le portail = deallocate. shutdown /s depuis l'OS = stopped (toujours payé).
• Tu ne peux pas changer : nom de la VM, VNet, region. Workaround = recréer la VM en attachant les disques existants.
• Ressources VM = NIC + OS Disk + Data Disks + (option) Public IP → toutes dans la même region.
• Quotas par sub (Subscription > Usage + quotas) limitent le nb de cores par famille → demander increase si besoin.

🚨 Quota vCPU ≠ billing : Stopped (Deallocated) arrête le billing compute ✅ mais la VM continue de consommer le quota vCPU (régional + family) jusqu'à delete. Pour libérer du quota → supprimer la VM, pas juste deallocate.

⚠️ Piège exam : dans un calcul "puis-je créer VM X dans cette region ?", compter les VMs Stopped Deallocated dans la consommation totale du quota.

Move VMs (déplacement)

Move = la VM garde son resource ID (cross-RG/sub) ou en obtient un nouveau (cross-region). Penser à mettre à jour les références (RBAC, locks, scripts).

Generation 1 vs 2

Le choix Gen1/Gen2 dépend de l'image Marketplace. Migration Gen1 → Gen2 possible via outil MS pour Windows (et upgrade vers Trusted Launch dans la foulée).

Pricing models

Pour AZ-104 : Spot ≠ prod critique. RI/Savings = optimiser une charge connue.

Azure Hybrid Benefit (AHB) — détails

• Pour qui : tu as déjà une licence Windows Server ou SQL Server avec Software Assurance (SA) ou abonnement on-prem.
• Effet : Azure ne te facture que la VM compute "Linux equivalent" (sans license Windows incluse), tu réutilises ta licence existante.
• Activation : à la création (Azure Hybrid Benefit: Yes) ou après (VM > Configuration > Operating system: License type).
• Combinable avec Reserved Instances → cumul des remises (jusqu'à -85% vs PAYG total).
• Couvre aussi : AKS nodes Windows, Azure SQL DB / MI (License-included → BYOL).
• ⚠️ Tu déclares respecter les termes de la SA — Microsoft peut auditer.

Lifecycle states

B. Disks

Types de disques managés

Ultra Disk et Premium SSD v2 = uniquement disques de données (pas OS).

Rôles des disques

• OS Disk (C: Windows / / Linux) : créé avec la VM, contient l'OS.
• Data Disks : ajoutables/détachables à chaud (sauf reduce size). Limite par taille de VM.
• Temp Disk (D: Windows / /dev/sdb Linux) : non persistant, perdu au deallocate. Pour swap/cache uniquement, jamais des données critiques.

Snapshots & Images

• Snapshot : copie point-in-time d'un disk → restore rapide, recréer un disk identique.
• Capture image (depuis VM généralisée) → modèle pour créer N VMs identiques.

C. Networking

• 1+ NIC par VM (nb max selon size). Multi-NIC souvent pour appliances réseau.
• 1+ IP configuration par NIC :
  • Private IP : obligatoire (Dynamic ou Static)
  • Public IP : optionnelle (ressource séparée à attacher)
• ⚠️ Pour resize NIC ou attach NIC additionnelle → la VM doit être Stopped (Deallocated).
• Voir fiche 4 pour NSG/ASG, fiche 5 pour routing/peering.

D. Images

Sources

• Azure Marketplace : Microsoft + éditeurs tiers (Windows Server, Ubuntu, RedHat, etc.). Souvent BYOL ou licences incluses.
• Custom images : capturées depuis tes propres VMs.

Workflow custom image

1. Configurer la VM "golden" (apps, settings)
2. Généraliser :
   • Windows : sysprep /generalize /oobe /shutdown + supprimer dossier C:\Windows\Panther
   • Linux : waagent -deprovision+user
3. Capturer depuis le portail → choisir la cible :
   • Managed image : modèle simple, 1 region, pas de versioning
   • Azure Compute Gallery (recommandé) : versioning, multi-region replication, RBAC, partage cross-tenant

Une fois la VM généralisée, elle ne redémarre pas normalement → utilisable seulement comme template.

E. Configuration & Management

Outils pour configurer/automatiser

Hors AZ-104 mais à savoir : Azure Arc étend ces outils aux VMs hors Azure.

Azure Update Manager

Service natif de patching des VMs Azure (et Arc-enabled). Successeur d'Azure Automation Update Management.

• Périodic assessment : scan régulier (24h par défaut) → liste des updates manquants par VM.
• Patching :
  • On-demand : déclencher manuellement
  • Automatic VM guest patching : auto pour patches Critical/Security (peu de contrôle)
  • Maintenance configuration + Schedule ⭐ : fenêtre de maintenance custom (jour/heure, récurrence) appliquée à des VMs/RG/MG
• Hotpatching (Windows Server Datacenter Azure Edition) : patches sans reboot.
• Pre/post-maintenance events : scripts à exécuter avant/après le patching.
• Pas de Log Analytics workspace requis (contrairement à l'ancien service).
• Couvre Windows + Linux + SQL Server (Azure VMs et Arc-enabled).

Pour AZ-104 : retenir Maintenance configuration = la nouvelle façon de planifier le patching à grande échelle.

F. VM Scale Sets (VMSS)

Groupe de VMs identiques scalable horizontalement (out/in) avec auto-update et HA.

Orchestration modes

Mode immuable : choisi à la création, non modifiable après. Pour migrer Uniform → Flexible : recréer.

Scaling

• Manual : tu fixes le nombre d'instances.
• Autoscale :
  • Metric-based : CPU, mémoire, queue length, custom metric (Log Analytics)
  • Schedule-based : à heure fixe / récurrent
  • Profiles ordre de priorité : dates spécifiques > jours récurrents > default
  • Multi-rules : si plusieurs scale-out triggers en même temps, la règle qui ajoute le plus de VMs gagne.

Upgrade Policy (Uniform uniquement)

• Manual : tu déclenches Reimage ou Upgrade instance par instance après modif du model
• Automatic : MS push les changements sur toutes les instances (downtime possible)
• Rolling : par batches avec health checks

Resize d'une instance individuelle dans VMSS Uniform = redémarrage de toutes les instances. À planifier.

G. High Availability

Comparatif

Availability Set (AS)

• Fault Domain (FD) : groupe physique (rack, alim, réseau). Default 2, max 3.
• Update Domain (UD) : groupes pour MAJ MS (1 UD à la fois). Default 5, max 20.
• VMs réparties round-robin sur FD/UD à la création.
• ❌ Settings FD/UD non modifiables après création de l'AS.
• ❌ VM existante ne peut pas être ajoutée à un AS post-création.
• ⚠️ Toutes les VMs d'un AS doivent être dans la même region + même RG.

💡 Noms exacts des champs ARM/Bicep/Terraform :

• platformFaultDomainCount (FD) — règle : si FD=1 alors UD=1 obligatoire (sinon erreur Azure). Pour FD=2/3 → UD libre.
• platformUpdateDomainCount (UD)

Exemple piège exam : "Au moins 2 VMs disponibles pendant la maintenance planifiée" → maintenance planifiée = update domain → besoin UD ≥ 3 (pour qu'au pire 1 UD en cours de maj, les 2 autres tournent). FD=2 minimum (pour la contrainte FD/UD).

Availability Zones (AZ)

• 3 zones physiques par région (datacenters distincts).
• Une VM = 1 seule zone (zonal). Une Public IP / Disk Standard SSD/Premium peut être zone-redundant (réplication entre zones).
• Plusieurs VMs sur 3 AZ ≠ AS : ce sont des mécanismes différents, on ne combine pas AS et AZ pour une même VM.

Une AZ peut contenir plusieurs datacenters. Pour ressources avec besoin de low latency entre VMs dans la même zone, utiliser un PPG en plus.

Proximity Placement Group (PPG)

• Force les ressources à être placées physiquement proches (même DC).
• Contient : VMs, VMSS, Availability Sets.
• Region scope (pas de cross-region).
• Use case : low-latency clusters (HPC, DB répliquée, app + DB).

H. VM Encryption

Customer-Managed Keys (CMK)

• Au lieu des clés platform-managed (PMK), tu fournis tes propres clés via Azure Key Vault.
• Implémentation : Disk Encryption Set (DES) qui pointe vers la key dans le KV.
• Le KV doit avoir Soft delete + Purge protection activés pour CMK.

Pour AZ-104 : retenir que SSE est obligatoire et transparent. ADE = legacy à éviter pour de nouvelles VMs. Pour control des clés → Encryption at Host + DES + CMK.

ADE + KEK — préparation du Key Vault (piège exam, encore en QCM tutorialdojo)

Même si ADE part en retraite 2028, l'exam pose encore des questions sur sa configuration. Pour utiliser un Key Encryption Key (KEK) stocké dans un KV existant pour ADE, 2 actions côté KV :

1. Générer une nouvelle clé crypto dans le KV qui servira de KEK (Keys > Generate/Import). ⚠️ Type = RSA obligatoire (pas EC), taille min 2048 (2048 / 3072 / 4096 supportés). HSM-backed possible (Premium KV ou Managed HSM).
2. Update access policy du KV pour accorder les permissions au resource provider Azure Disk Encryption (pas au RP Microsoft.Compute) — il a besoin de WrapKey / UnwrapKey pour wrapper les clés de chiffrement disk.

⚠️ Pièges typiques tutorialdojo (réponses incorrectes mais plausibles) :

• "Enable soft-delete + purge protection" → c'est best practice KV mais pas un requirement spécifique ADE+KEK.
• "Configure key rotation policy" → bonne pratique, pas un requirement.
• "Grant access to Microsoft.Compute resource provider" → mauvais RP, c'est Azure Disk Encryption qui a besoin de l'accès, pas Compute.

Trusted Launch

Sécurité boot pour VMs Gen2 uniquement → protège contre rootkits / bootkits.

3 composants (activés par défaut quand on choisit Trusted Launch) :

• Secure Boot : vérifie la signature des composants au boot (refuse code non signé)
• vTPM (virtual TPM 2.0) : module crypto virtuel pour stockage de keys, attestation
• Boot Integrity Monitoring (Guest attestation) : reporte l'état du boot dans Azure Monitor

À retenir :

• ✅ Recommandé MS pour toutes nouvelles VMs Gen2 (default depuis 2023 sur la plupart des images).
• Compatible avec la plupart des sizes modernes (vérifier la doc pour les exceptions).
• Upgrade possible : Gen1 → Gen2-Trusted Launch (Windows) ou Gen2 existante → Trusted Launch.
• Prérequis pour Confidential VMs (AMD SEV-SNP / Intel TDX).

I. Troubleshooting & Monitoring

Boot diagnostics

• Capture screenshot console + serial log au boot → utile si la VM ne démarre pas / écran bleu.
• 2 modes :
  • Managed ⭐ (recommandé) : MS gère le storage, pas de config
  • Custom : storage account explicite (legacy)
• Activé par défaut pour les nouvelles VMs.
• Accès : VM > Boot diagnostics > Screenshot / Serial log.

Serial Console

• Accès clavier OS sans réseau (port série) → utile si SSH/RDP HS, mauvaise config réseau, etc.
• Prérequis : Boot diagnostics activé + un user local connu (Linux : root ou créé), Windows (SAC puis cmd).
• Accès : VM > Serial console.

VM Insights

• Solution de monitoring détaillé : performance (CPU/RAM/disk/net) + map (dépendances réseau entre VMs et services).
• Prérequis : Log Analytics workspace + Azure Monitor Agent (AMA, remplace l'ancien MMA) déployé sur la VM.
• Activable au scope sub/RG/VM via Azure Policy ou portail.
• Données envoyées dans Log Analytics → KQL queries possibles.

Pour AZ-104 : Boot diagnostics (screenshot+serial), Serial console (clavier), VM Insights (perf+map). Distinguer les 3.

DEMO — chemins portail

Créer / gérer une VM

1. Virtual machines > Create → image, size, admin creds, disk options, networking, monitoring
2. Option "Delete with VM" sur OS disk + NIC + Public IP → cocher pour cleanup auto
3. Resize : Size blade. Si la size cible n'apparaît pas → stopper la VM (parfois cluster physique limite).
4. Redeploy : Help > Redeploy + reapply → migre la VM sur un autre host (utile en cas de bug host).

Disk operations

1. Snapshot avant changement : VM > Disks > [disk] > Create snapshot
2. Resize OS disk : VM doit être Stopped (Deallocated). Resize uniquement vers le haut.
3. Add data disk : possible à chaud. Côté OS Windows : diskmgmt.msc pour initialiser/format.
4. Convert disk type : Disk > Size + performance > Disk SKU (la VM doit être stoppée).

Image custom + Compute Gallery

1. Préparer la VM "golden" → installer apps + config
2. Généraliser :
   • Windows : RDP → C:\Windows\System32\Sysprep\sysprep.exe → cocher OOBE + Generalize + Shutdown
   • (avant : supprimer C:\Windows\Panther)
3. Compute Gallery > Create (dans la même region/RG idéalement)
4. Depuis la VM généralisée : Capture → choisir Gallery, image definition, version
5. Créer une nouvelle VM depuis : VM > Create > See all images > My items > Shared with me

Custom Script Extension

1. Stocker le script (.ps1 / .sh) dans un Blob (ou Git)
2. VM > Extensions + applications > Add > Custom Script Extension
3. Pointer vers le script (URL Blob avec SAS si privé)
4. Le script s'exécute une seule fois au déploiement de l'extension

CSE dans VMSS via ARM template : pour installer du soft (ex composants web IIS) sur toutes les instances d'un VMSS au déploiement, on déclare l'extension dans la section extensionProfile du VMSS dans l'ARM/Bicep template. Au scaling out → chaque nouvelle instance exécute le script auto. Pas besoin d'Automation Account, juste : (1) écrire le script, (2) référencer son URL dans extensionProfile.

VMSS Flexible

1. Virtual machine scale sets > Create → Orchestration mode: Flexible
2. Choisir VNet/subnet, LB optionnel
3. Scaling : Manual (instance count) ou Custom autoscale
4. Les instances apparaissent dans le RG comme des VMs standard

Autoscale rules

1. VMSS > Scaling > Custom autoscale
2. Default profile : min/max/default + scale rules
3. Add scale-out rule : metric (ex CPU > 75%), aggregation, cooldown, increment
4. Add scale-in rule : symétrique (CPU < 25%)
5. Schedule profile (ex : weekday 9-18h min=4, weekend min=1)

AS + PPG

1. Proximity placement group > Create (region target)
2. Availability set > Create (même region) → choisir le PPG, FD=2 ou 3, UD=5+
3. Avant les VMs : créer AS + PPG d'abord
4. À la création de la VM : Availability options > Availability set → sélectionner

Encryption VM — vue d'ensemble (rappel des 4 couches)

┌────────────────────────────────────────────────────────┐
│ SSE (Storage Service Encryption)                        │
│   ✅ Always-on, AES-256 at-rest côté plateforme         │
│   PMK par défaut (CMK possible via DES)                 │
├────────────────────────────────────────────────────────┤
│ Encryption at Host ⭐ (recommandé MS)                   │
│   Chiffre OS + Data + Temp + Caches AU NIVEAU HOST      │
│   Avant écriture sur stockage                           │
├────────────────────────────────────────────────────────┤
│ ADE (Azure Disk Encryption) — legacy                    │
│   BitLocker (Win) / dm-crypt (Linux) DANS la VM         │
│   BEK → Key Vault, KEK optionnelle (wrap BEK)           │
├────────────────────────────────────────────────────────┤
│ Confidential Disk Encryption                            │
│   AMD SEV-SNP / Intel TDX pour workloads sensibles      │
└────────────────────────────────────────────────────────┘

DEMO 1 — Encryption at Host + CMK (recommandé prod)

1. Activer la feature sur la sub (one-shot) :

   az feature register --namespace Microsoft.Compute --name EncryptionAtHost
   az provider register -n Microsoft.Compute
   

2. Préparer Key Vault : Key vaults > Create avec Soft-delete ACTIVÉ + Purge protection ACTIVÉE (obligatoires pour CMK).
3. Créer une clé RSA : KV > Keys > Generate/Import → type RSA, taille 2048+ (2048/3072/4096).
4. Créer un Disk Encryption Set (DES) : Disk Encryption Sets > Create → pointer vers le KV + la key. Le DES reçoit une System-assigned Managed Identity auto.
5. Donner accès au DES sur le KV : KV > Access policies (ou RBAC) → ajouter la MI du DES avec Get, WrapKey, UnwrapKey.
6. À la création de la VM : Disks blade → Encryption at host: On + Encryption type: Customer-managed key → sélectionner le DES.
7. Vérifier : VM > Disks > [disk] > Encryption → doit afficher la clé du DES.

DEMO 2 — ADE + KEK (legacy mais encore en exam)

1. KV avec Soft-delete + Purge protection ACTIVÉS + Azure Disk Encryption for volume encryption activé (KV > Properties).
2. Créer la KEK : KV > Keys > Generate/Import → type RSA, taille 2048+.
3. Update access policy du KV → ajouter le resource provider Azure Disk Encryption (PAS Microsoft.Compute) avec Get, WrapKey, UnwrapKey.
4. Activer ADE sur la VM (PowerShell) :

   Set-AzVMDiskEncryptionExtension `
     -ResourceGroupName myrg -VMName myvm `
     -DiskEncryptionKeyVaultUrl $kv.VaultUri `
     -DiskEncryptionKeyVaultId $kv.ResourceId `
     -KeyEncryptionKeyUrl $kek.Key.Kid `
     -KeyEncryptionKeyVaultId $kv.ResourceId `
     -VolumeType All
   

5. Vérifier état : Get-AzVMDiskEncryptionStatus -ResourceGroupName myrg -VMName myvm.

🚨 Pièges ADE+KEK : KEK = RSA obligatoire (pas EC). Soft-delete + Purge protection = prérequis (sans ça, refus). Le RP est Azure Disk Encryption, pas Compute.

Move VM

1. VM > Move > Move to another resource group/subscription
2. Cocher les ressources liées (NIC, Public IP, Disks)
3. Validation Azure → confirmer le nouveau RG/sub
4. Cross-region : passer par ASR (réplication) ou snapshot disks → recreate dans la region cible

Spot VM

1. Create VM > Azure Spot instance: Yes
2. Choisir Eviction type : Capacity only (Azure récupère la capacité) ou Capacity or Price (eviction aussi quand le prix dépasse ton max)
3. Eviction policy : Deallocate (garde les disks, redéploiement plus rapide) ou Delete (cleanup total)
4. Max price : -1 (paie jusqu'au tarif PAYG max) ou cap personnalisé

Trusted Launch (sur nouvelle VM)

1. Create VM > Security type: Trusted launch virtual machines
2. Secure Boot + vTPM cochés par défaut → laisser
3. Choisir une image Gen2 compatible (la plupart des images modernes le sont)

Update Manager

1. Azure Update Manager > Machines → liste tous les VMs Azure + Arc
2. One-time : sélectionner VMs → One-time update → choisir classifications + reboot setting
3. Schedule : Maintenance configurations > Create → type Guest, scope (sub/RG/VM), recurrence → puis Assign aux VMs
4. Periodic assessment : activable à grande échelle via Azure Policy

Boot diagnostics / Serial console

1. Activer Boot diag : VM > Boot diagnostics > Settings > Enable with managed storage account
2. Voir l'écran : VM > Boot diagnostics > Screenshot (pour diagnostiquer un freeze au boot)
3. Serial console : VM > Serial console → si Linux, login root ou user créé. Si Windows, cmd pour activer SAC.

VM Insights

1. Prérequis : Log Analytics workspace existant
2. VM > Insights > Enable → choisir le workspace
3. AMA déployé auto → données dispo après quelques minutes
4. Vue Map : visualiser les connexions réseau de la VM

Backup (rappel quick — détaillé dans une fiche dédiée)

• VM > Backup → créer un Recovery Services Vault, choisir policy → backup automatique
• Restore options : full VM / disk / file-level

🏢 Scenarios d'entreprise réels — pensée d'architecte

Comment ces services s'utilisent dans la vraie vie. Pour chaque scenario : contexte business → choix techniques (uniquement les services traités dans la fiche) → pièges typiques.

Scenario 1 : Migration SAP S/4HANA lift-and-shift (industriel manufacturier)

Contexte business : Groupe industriel (chimie, automobile) sort de son datacenter on-prem, migre son SAP ERP critique vers Azure. RTO < 1h, latence app↔DB < 0.7 ms exigée par l'éditeur SAP. Choix techniques : VMs Memory-optimized série M (HANA-certified, jusqu'à 12 TB RAM) + Premium SSD v2 ou Ultra Disk pour les data files HANA, Proximity Placement Group pour colocaliser app servers (D-series) et DB (M-series), Availability Set au sein du PPG, ASR vers la region pair pour DR. Architecture / pattern :

• PPG ancré sur la première VM HANA (M-series) → toutes les VMs SAP suivantes (NetWeaver app servers, ASCS) déployées dans ce PPG
• 2 zones AZ pour HANA System Replication (primary AZ1, secondary AZ2) — chacune avec son PPG
• ASR Azure-to-Azure vers region pair pour DR cross-region
• Reserved Instances 3 ans + Azure Hybrid Benefit Windows/SQL (économies jusqu'à -65%)
• Encryption at Host + DES + CMK pour compliance interne Pièges à éviter :
• Mettre HANA sur Standard SSD → SLA refusé par SAP, perfs catastrophiques. Utiliser Premium SSD v2 ou Ultra Disk uniquement
• Oublier de créer le PPG avant la première VM → impossible d'ajouter une VM existante à un PPG (forcerait à recréer)
• AS + AZ combinés → impossible, choisir un mécanisme HA. Pour SAP HANA HA inter-zones : pas d'AS, on fait du HSR cross-AZ
• ASR + Ultra Disk = compatibilité limitée historiquement → vérifier la support matrix avant de promettre du DR

Scenario 2 : Rendu 3D / encodage vidéo (studio media & post-production)

Contexte business : Studio post-prod livre des rushes 4K/8K en délais serrés. Pics massifs de rendu CGI le soir, machines idles le jour. Budget calcul = poste majeur. Choix techniques : VMSS Flexible avec Spot VMs (eviction policy Delete), familles HC/HB (HPC) ou N-series GPU selon pipeline (Arnold, V-Ray, Blender), autoscale schedule-based + queue-based. Architecture / pattern :

• VMSS Flexible mix de sizes (mix HBv3 pour CPU rendering + NVads_A10_v5 pour GPU passes)
• Autoscale : profile schedule "weekday 19h-8h min=20 max=200", default min=2
• Custom Script Extension dans extensionProfile du VMSS pour installer le render agent à chaque nouvelle instance
• Spot max price = -1 (paie jusqu'au PAYG, mais profite des baisses) + eviction policy = Delete (pas besoin de garder l'OS disk d'une instance évincée — le job repart sur une autre)
• Reserved Instance 1 an pour la VM "head node" qui coordonne la queue (jamais Spot) Pièges à éviter :
• Tout en Spot : la head node / scheduler doit être PAYG ou RI (un eviction = pipeline cassé)
• Eviction policy Deallocate sur une fleet Spot massive → stockage OS disks orphelins consommé en silence, facture qui grimpe
• Quota vCPU régional sous-estimé → autoscale bloqué à 50 alors qu'on en voulait 200. Demander increase avant la première semaine de prod
• Famille H/N souvent en pénurie capacité → si Spot eviction = Capacity only, prévoir une 2e region en fallback ou une famille alternative dans le model VMSS

Scenario 3 : Application bancaire interne hautement réglementée (banque retail)

Contexte business : Application Windows legacy (.NET Framework, IIS) traitant des données clients. RGPD + secret bancaire. Pas de cloud public exposé, DR obligatoire avec RTO 4h. Choix techniques : VMs Windows Gen2 Trusted Launch (Secure Boot + vTPM), Encryption at Host avec CMK via Disk Encryption Set, Availability Zones (3 VMs sur 3 zones) + Standard Load Balancer zone-redundant, ASR zone-to-zone puis ASR cross-region vers region pair, Azure Update Manager avec maintenance configuration mensuelle. Architecture / pattern :

• 3 VMs (1 par AZ) derrière LB Standard zone-redundant — pas d'AS, on est en multi-zone
• OS = Windows Server Datacenter Azure Edition → hotpatching (patchs sans reboot, exigence des équipes ops)
• DES + CMK dans Key Vault Premium HSM-backed (compliance crypto)
• Boot diagnostics + Serial Console activés (incident response sans réseau)
• ASR Azure-to-Azure avec recovery plan pour orchestrer le failover (DB, app, DNS)
• Hybrid Benefit + RI 3 ans pour les VMs prod Pièges à éviter :
• Croire qu'AZ remplace le backup → AZ protège contre la panne datacenter, pas contre la corruption logique ou la ransomware. Toujours coupler avec Azure Backup (RSV).
• Activer ADE alors qu'on est en 2026 → legacy, retraite 2028. Pour une nouvelle VM : Encryption at Host directement.
• Maintenance Configuration sans pre/post events → le LB continue d'envoyer du trafic vers une VM en cours de patching. Toujours scripter un drain.
• Public IP non zone-redundant sur LB → SPOF dans une zone précise. Forcer Standard SKU + zone-redundant.

Scenario 4 : Cluster HPC recherche scientifique (laboratoire pharma / R&D)

Contexte business : Labo pharma a besoin de cracker des simulations de docking moléculaire ponctuelles (campagnes 2-3 semaines, 4× par an). Reste de l'année = aucune charge. Choix techniques : VMSS Uniform (legacy mais OK pour HPC homogène) avec famille HBv4 (HPC AMD Genoa), Spot VMs avec eviction Deallocate, Proximity Placement Group pour low-latency MPI inter-nodes, image custom avec MPI/Slurm pré-installé stockée dans Azure Compute Gallery (replicated multi-region). Architecture / pattern :

• Compute Gallery avec image golden (OS Linux + Slurm + drivers InfiniBand + binaires métier)
• VMSS Uniform 100 nodes HBv4 en Spot, dans un PPG (latence InfiniBand entre nodes < 2µs)
• Head node hors VMSS, en PAYG (orchestre Slurm)
• Quand la campagne se termine : az vmss delete → 0€ jusqu'à la prochaine
• Quotas vCPU H-family demandés en avance auprès du support Pièges à éviter :
• Spot + HPC InfiniBand : eviction d'un node = job MPI mort. Toujours coupler avec checkpoint restart (Slurm requeue) au niveau applicatif
• PPG + scale-out massif : Azure peut refuser de placer la N+1ème VM si le cluster physique est plein. Soit baisser le target count, soit accepter un VMSS sans PPG (perte de latence)
• VMSS Uniform = mode legacy. Pour un nouveau projet on irait sur Flexible, sauf que Flexible ne supporte pas certaines images HPC InfiniBand de la même façon — vérifier au cas par cas
• Compute Gallery non répliqué sur la region où on déploie le VMSS → pull d'image cross-region = boot très lent sur 100 VMs

Sources : SAP HANA Azure Architecture Center, PPG SAP scenarios, Zone-to-zone DR with ASR, Azure Spot VMs