7 — Azure Storage

Service de stockage cloud massivement scalable. Tout passe par un Storage Account (SA) qui contient les services : Blob, Files, Queue, Table. Endpoints publics par défaut.

A. Storage Account

Types (kind)

Propriétés clés (à la création)

• Nom : 3-24 chars lowercase + chiffres, globalement unique (devient le DNS : <nom>.blob.core.windows.net)
• Performance : Standard (HDD/SSD mix) ou Premium (SSD)
• Replication : LRS / ZRS / GRS / GZRS / RA-GRS / RA-GZRS (voir section E)
• Access tier par défaut : Hot ou Cool (modifiable après, niveau Blob individuel)
• Networking : public, selected networks (Service Endpoint), private (Private Endpoint), disabled
• Hierarchical Namespace (HNS) : pour Data Lake Gen2 → vrais dossiers, ACLs POSIX, optimisé big data. À cocher à la création (irréversible)

Move : un SA peut être déplacé cross-RG / cross-sub. Pas cross-region direct → recréer dans la nouvelle region.

B. Blob Storage

Hiérarchie

Storage Account > Container > Blob (pas de vrais dossiers — ce sont des prefixes dans le nom). Avec HNS activé : vrais dossiers + ACLs.

Types de blobs

Access Tiers (Block Blob uniquement)

Niveau par blob (Hot/Cool/Cold) ou par SA (default tier). Archive = blob doit être rehydraté (Hot/Cool) avant d'être lu (rehydratation = 1-15h). Frais de early deletion si suppression avant la min retention.

Lifecycle Management

• Règles JSON pour automatiser : déplacement entre tiers, suppression de blobs/snapshots/versions selon âge ou tags.
• Filterset par préfixe (ex container1/) ou index tag (ex department=finance).
• ⚠️ Append blobs ne supportent pas les access tiers → seulement règle delete.

Conditions disponibles :

• daysAfterModificationGreaterThan : depuis dernière modif (uniquement baseBlob)
• daysAfterCreationGreaterThan : depuis création (uniquement snapshot / version)
• daysAfterLastAccessTimeGreaterThan : depuis dernier accès (uniquement baseBlob) — nécessite Last-Access Time Tracking activé

🚨 Lifecycle policy — scope d'application (piège ARM template) : Une règle a 3 scopes possibles sous actions :

• baseBlob : agit sur le blob actuel (version courante). Conditions = daysAfterModification ou daysAfterLastAccessTime.
• snapshot : agit sur les snapshots du blob. Condition = daysAfterCreation.
• version : agit sur les previous versions (si versioning activé). Condition = daysAfterCreation.

Piège exam : si le template ARM met tierToCool sous snapshot avec daysAfterCreationGreaterThan: 90, ça ne touche PAS le blob courant — juste les snapshots de plus de 90j. Bien lire le scope avant de répondre.

filters.prefixMatch : array de prefixes (ex ["container1/"]) → la règle ne cible que ce(s) container(s)/prefixe(s). Les autres containers du SA = pas affectés.

Last-Access Time Tracking :

• Activer sur le SA : Lifecycle management > Enable last-access time tracking (ou via API/CLI).
• Coût : tracking lui-même est gratuit, mais Azure met à jour le lastAccessTime au max 1× / 24h pour limiter l'impact transactionnel.
• Une fois activé, on peut écrire des règles type "tier to Cool si pas accédé depuis 30 jours" plutôt que basé sur la modif.

Blob Index Tags

Métadonnées clé-valeur attachées à un blob pour le classifier, filtrer, retrouver.

• Max 10 tags par blob, key 128 chars / value 256 chars.
• Indexés au niveau du SA → recherche cross-container possible (Find blobs by tags).
• Utilisables dans lifecycle policies, SAS (limiter l'accès aux blobs ayant un tag spécifique via filter expression).
• Modifiables après upload (différent des metadata classiques qui sont aussi possibles, mais non indexées).
• Supportés : GPv2 + Premium Block Blob, avec HNS = non supporté (utiliser tags via APIs spécifiques).
• RBAC : nécessite Storage Blob Data Owner ou Tag Contributor data role.

Object Replication (Block Blob)

• Réplication async vers un autre SA (même ou autre region/sub/tenant).
• Prérequis sur source ET destination : Versioning + Change Feed activés.
• Types de SA supportés : GPv2 ou Premium Block Blob (source ET destination). ❌ GPv1, ❌ BlobStorage legacy.
• Policy avec rules : quels blobs (prefix), copy filter, copy mode (now / sync everything).
• ❌ Pas de réplication des blobs en Archive (les rehydrater d'abord).

🚨 Object Replication vs GRS — choix de la region cible (piège exam) :

• GRS / GZRS : Azure impose le regional pair (ex SEA → East Asia). Tu ne choisis pas la region secondaire.
• Object Replication : tu choisis librement la region/sub/tenant cible.

⚠️ Piège exam : "compliance impose réplication SEA → Australia Central" → Object Replication (GRS forcerait East Asia, le regional pair). Versioning seul = juste un prérequis, pas le mécanisme de copie.

Immutable Blob Storage (WORM)

Empêche modif/suppression des blobs pendant une période → compliance (SEC 17a-4, GDPR…).

• Scope : container OU version-level (nécessite versioning activé)
• Supporté : GPv2, Premium Block Blob

Autres features Blob à connaître

• Soft delete :
  • Blob soft delete : récup blobs supprimés (1-365 j, default 7)
  • Container soft delete : récup container supprimé (1-365 j)
• Versioning : snapshot auto à chaque modif (préalable pour Object Replication, version-level immutability)
• Change feed : log append-only de tous les changements (audit, replication)
• Point-in-time restore : rollback blob à un instant T (nécessite versioning + change feed + soft-delete)
• Snapshots : copie point-in-time manuelle d'un blob
• Static website : Static website blade → enable → upload dans $web container, endpoint dédié (<sa>.z??.web.core.windows.net)
• Anonymous public access : 🚨 Désactivé par défaut sur les nouveaux SA (depuis nov 2023). Doit être explicitement activé au niveau du SA pour pouvoir l'activer au niveau du container.

C. Access Control

4 méthodes d'authentification

SAS — 3 types

Stored Access Policy : attachée à un container/share/queue/table → définit permissions + dates. Un Service SAS peut s'y référer → si on supprime/modifie la policy, tous les SAS associés sont invalidés. Sans policy, un SAS reste valide jusqu'à sa date d'expiration.

⚠️ Max 5 stored access policies par container/share/queue/table simultanément. Au-delà → erreur HTTP 400 (Bad Request).

Roles RBAC clés (data plane, sur le SA ou container)

• Storage Blob Data Owner : full + ACLs (HNS)
• Storage Blob Data Contributor : R/W/D
• Storage Blob Data Reader : R only
• Storage File Data SMB Share Contributor / Elevated Contributor / Reader : pour Files SMB
• Storage Queue Data Contributor / Reader / Sender / Processor

Distinction : Contributor (control plane, gère le SA mais pas l'accès aux data) vs Storage Blob Data Contributor (data plane, accès aux blobs).

Storage networking (firewall)

SA > Networking > Public network access :

• Disabled : seul Private Endpoint
• Enabled from selected virtual networks and IPs : whitelist VNets (Service Endpoint) + IP/CIDR
• Enabled from all networks : ouvert (default historique, à éviter)

Voir fiche 5 pour Service Endpoint vs Private Endpoint.

D. Redundancy

Options

💡 Choix DR cost-effective + read-access secondaire :

• GRS seul = pas de read access en secondaire → si tu veux lire la copie secondaire (ex: app continue en read-only pendant outage primaire), il faut un suffixe RA.
• RA-GRS ⭐ = le moins cher parmi ceux qui offrent read-access secondaire. Réplication async cross-region + endpoint <sa>-secondary.blob.core.windows.net.
• RA-GZRS = même idée mais avec ZRS au primaire (donc HA intra-region en plus). Plus cher que RA-GRS.
• Si la question demande "DR + read-access secondaire + cost-effective" → RA-GRS, pas RA-GZRS.

Premium Block Blob et Premium File Shares = LRS / ZRS uniquement (pas de geo).

Failover

• Customer-initiated failover : tu déclenches le failover vers la region secondaire si MS n'a pas réagi.
• Après failover : la sub passe en LRS dans la region secondaire (perd la geo-redundancy → reconfigurer après).
• RPO ~15 min typique (asynchrone).

Conversion entre redundancies

• LRS ↔ ZRS, GRS ↔ GZRS, etc. : la plupart directement dans le portail (Redundancy blade).
• Certaines transitions nécessitent un ticket support (anciennement, c'était plus le cas — vérifier).

🚨 Live migration vers ZRS — contraintes (piège exam) :

• SA supportés : GPv2 / FileStorage / BlockBlobStorage uniquement. ❌ GPv1, ❌ BlobStorage legacy.
• Source : LRS ou GRS uniquement. ❌ RA-GRS direct → switcher vers LRS/GRS d'abord (l'étape intermédiaire retire le endpoint secondary read-only).
• LRS ↔ ZRS dans la même region = ticket Azure Support (live migration), pas dans le portail seul.

⚠️ Mauvaises réponses fréquentes : "GPv1 supporte ZRS" (faux), "RA-GRS → RA-GZRS direct" (faux, switcher d'abord vers GRS).

Redondance ≠ Backup. Si tu supprimes un blob, il est supprimé partout. Pour récupérer : soft-delete + versioning + Azure Backup (RSV).

E. Encryption

💡 Encryption Scopes (Blob only) — détail : sous-niveau d'encryption avec clés indépendantes par container ou par blob (override du chiffrement du SA). Créés au niveau du SA (Storage Account > Encryption > Encryption scopes > Add), puis :

• Assignation default par container (à la création du container) → tous les nouveaux blobs héritent.
• Assignation override par blob individuel (à l'upload via header x-ms-encryption-scope).

Supporte PMK ou CMK indépendamment de la config SA, + Infrastructure encryption activable par scope. Désactivable ensuite, mais les blobs déjà chiffrés conservent leur scope d'origine.

Use case : multi-tenancy (1 container par tenant avec sa propre clé CMK) ou compliance granulaire.

Transport

• Secure transfer required = HTTPS only (activé par défaut). Refuse HTTP + SMB 2.1.
• Min TLS version : configurable (TLS 1.2 minimum recommandé).

F. Azure Files

Partages de fichiers managés (vs Files Sync = solution hybride). Protocoles : SMB ou NFS.

Tiers

SMB vs NFS

Identity-based auth (SMB uniquement)

3 méthodes, une seule active à la fois par SA :

Le storage account doit être joint au domaine (AD/Entra DS) ou avoir Entra Kerberos activé. Permissions share-level via RBAC (Storage File Data SMB Share Contributor…) + permissions NTFS classiques sur les fichiers (gérables depuis n'importe quel client joint).

⭐ Setup AD DS auth pour Azure Files — ordre des 4 étapes (piège drag-and-drop) :

1. Sync on-prem AD vers Entra ID (Entra Connect Sync ou Cloud Sync) — prérequis hybrid identity.
2. Enable AD DS authentication sur le SA (Storage Account > File shares > Active Directory: Configure).
3. Assign share + directory permissions : RBAC share-level (Storage File Data SMB Share Contributor) + NTFS ACLs file-level.
4. Mount file share depuis client domain-joined avec AD creds.

Azure File Sync

Étend un serveur de fichiers Windows on-prem vers Azure → centralisation cloud + accès local rapide.

Composants :

• Storage Sync Service : ressource Azure régionale
• Sync Group : 1 share Azure (cloud endpoint) + 1+ serveurs Windows (server endpoints)
• Agent installé sur chaque serveur Windows à enregistrer

Règles :

• 1 Sync Group = 1 cloud endpoint (1 share Azure) → pour ajouter un 2e share, créer un autre sync group
• 1 Sync Group = N server endpoints (multi-serveurs)
• 1 server = enregistré sur 1 seul Storage Sync Service
• 🚨 1 server = max 1 server endpoint dans le MÊME sync group → impossible d'ajouter F:\folder1 ET F:\folder2 du même serveur dans le même group (même si les chemins ne se recouvrent pas). Pour ça, créer un autre sync group.

Ordre exact de déploiement (piège exam, séquence tutorialdojo) :

1. Deploy Storage Sync Service (ressource Azure)
2. Deploy Azure File Sync agent sur le serveur Windows
3. Register le serveur avec le Storage Sync Service
4. Set up sync group + cloud endpoint (1 share Azure)
5. Create server endpoint (path local sur le serveur)

Mnémo : Service → Agent → Register → Group → Endpoint. Ne pas inverser register/sync group : on ne peut pas créer un server endpoint sans avoir register le server avant.

Cloud Tiering (optionnel) :

• Date policy : tier les fichiers non accédés depuis X jours
• Volume free space policy : garder X% libre sur le serveur
• Les fichiers tierés gardent leur entrée dans l'arbo (reparse point), réhydratés à la demande

Sync ↔ inverse : changements on-prem → cloud rapides, cloud → on-prem peuvent prendre jusqu'à 24h (forcer via PowerShell Invoke-AzStorageSyncChangeDetection).

Azure NetApp Files (ANF)

Service de file shares haute performance (NetApp natif sur Azure), pour workloads critiques que Azure Files ne peut pas absorber : SAP HANA, HPC, EDA, VDI massif, DBs.

Différences clés vs Azure Files :

• Performance bien supérieure (sub-ms latency, jusqu'à plusieurs GiB/s).
• Protocoles : NFSv3, NFSv4.1, SMB, dual-protocol.
• Pas dans un Storage Account → ressource séparée avec hiérarchie propre.
• Délégation de subnet obligatoire : un subnet dédié (Microsoft.NetApp/volumes) dans le VNet.

Hiérarchie :

NetApp Account (région)
  └─ Capacity Pool (4 TiB min, 500 TiB max — service level fixé ici)
        └─ Volume(s) (le share consommé par les clients)

Service Levels (par capacity pool) :

Possibilité de changer dynamiquement le service level (déplacer le volume vers un autre capacity pool). 24h min entre 2 changements descendants. Cool Access disponible (tiering vers stockage moins cher pour blocs froids).

Pour AZ-104 : retenir l'existence + la hiérarchie + subnet délégué. Pas de questions très détaillées attendues.

G. Data Transfer Tools

DEMO — chemins portail

Créer un Storage Account

1. Storage accounts > Create
2. Choisir : kind (GPv2), perf (Standard/Premium), replication (LRS/ZRS/GRS/GZRS)
3. Onglet Advanced : HNS si Data Lake, secure transfer, min TLS, blob anonymous, Shared Key access (Disabled recommandé)
4. Networking : public/selected/disabled, Service Endpoint, Private Endpoint
5. Encryption : PMK ou CMK (KV + MI)
6. Data protection : soft-delete blob/container/share, versioning, change feed, immutability default

Blob — opérations courantes

1. SA > Containers > + Container (private/public access level)
2. Upload : drag-and-drop ou AzCopy. Choisir tier au upload (Hot/Cool/Cold).
3. Change tier : clic droit blob > Change tier
4. Default tier du SA : Configuration > Blob access tier (default)
5. Snapshot/version : clic droit > Create snapshot

SAS Token

1. SA > Shared access signature (Account SAS)
2. Cocher services + permissions + dates + IP + protocoles
3. Generate SAS and connection string → copier (perdu si pas sauvegardé)
4. Pour User Delegation SAS : depuis Storage Browser/AzCopy avec login Entra → généré sans access key

Stored Access Policy (Service SAS revocable)

1. Container > Access policy > + Add policy
2. Définir nom, dates, permissions
3. Lors de la création d'un Service SAS : sélectionner cette policy → SAS héritera des permissions/dates

RBAC pour data access

1. SA > Access Control (IAM) > Add role assignment
2. Choisir un rôle Data (Storage Blob Data Contributor, etc.) — pas Contributor qui ne donne pas accès aux data !
3. Assigner à user/group/MI

Lifecycle policy

1. SA > Data management > Lifecycle management > Add a rule
2. Conditions sur âge (modification, last-access via tracking), filterset (prefix / index tag)
3. Actions : tier to cool/cold/archive, delete blob, delete snapshot/version

Object Replication

1. Source SA : activer Versioning + Change Feed (Data protection)
2. Destination SA : activer Versioning
3. Source SA > Object replication > Create replication rules → choisir destination, prefix, copy options
4. Vérifier la copie après quelques minutes

Immutable Storage

1. Container-level : Container > Access policy > Immutable blob storage > Add policy (Time-based ou Legal Hold)
2. Version-level : créer le SA avec Enable version-level immutability support (irréversible) puis policy au niveau blob ou version

Failover de redondance

1. SA > Geo-replication → vérifier que LastSyncTime est récent
2. Initiate failover → la region secondaire devient primary, redondance passe en LRS
3. Reconfigurer la redundancy si besoin (Redundancy > Geo-redundant)

Encryption Storage — CMK + Key Vault (DEMO)

1. Préparer Key Vault : Key vaults > Create avec Soft-delete ACTIVÉ + Purge protection ACTIVÉE (obligatoires pour CMK).
2. Créer une clé RSA : KV > Keys > Generate/Import → type RSA, taille 2048+ (2048/3072/4096). Activer rotation auto (optionnel).
3. Activer Managed Identity sur le SA : SA > Identity > System assigned > On (ou User-assigned MI séparée).
4. Donner accès à la MI du SA sur le KV : KV > Access policies (ou RBAC) → ajouter la MI avec Get, WrapKey, UnwrapKey.
5. Activer CMK sur le SA : SA > Encryption → Customer-managed keys → sélectionner le KV + la key (version "auto" recommandée pour suivre la rotation, ou version fixe).
6. Vérifier : SA > Encryption affiche le statut "Customer-managed key" + URL de la key.

💡 Infrastructure encryption (double encryption service + infra) : à cocher à la création du SA, irréversible.

Encryption Scope (Blob only) — DEMO

1. Créer un Encryption Scope : SA > Encryption > Encryption scopes > Add → choisir PMK ou CMK (avec KV+key), Infrastructure encryption optionnelle.
2. Assigner par container (default) : Containers > [container] > Edit → Encryption scope = myscope. Tous les nouveaux blobs héritent.
3. Assigner par blob (override) : à l'upload via CLI/SDK avec --encryption-scope myscope (ou header x-ms-encryption-scope).
4. Désactiver un scope : SA > Encryption scopes > [scope] > Disable. Les blobs déjà chiffrés gardent leur scope d'origine, mais nouveaux uploads refusés sur ce scope.

Azure Files — créer + monter

1. SA > File shares > + File share (tier, quota)
2. Onglet Connect → script PowerShell (Windows) ou mount (Linux) avec storage key OU Entra
3. Pour identity-based : SA > File shares > Active Directory: Configure → choisir AD DS / Entra DS / Entra Kerberos

Azure File Sync

1. Storage Sync Services > Create (région)
2. Install agent + register server : installer l'agent Azure File Sync sur le serveur Windows → register au Storage Sync Service (l'install puis le register sont 2 étapes distinctes en exam)
3. Sync group : créer le sync group + pointer vers le share Azure (cloud endpoint)
4. Add server endpoint au sync group : path local + cloud tiering rules
5. Vérifier le sync (Storage Sync Services > Sync group > Server endpoint)

🏢 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 : Plateforme de streaming média (broadcaster TV / VOD)

Contexte business : Broadcaster gère 5 PB de contenus vidéo. Les nouveautés sont vues massivement le premier mois, puis le trafic chute. Le catalogue legacy reste accessible mais peu vu. Réglementation : 7 ans de conservation des masters. Choix techniques : Storage Account GPv2 + Premium Block Blob pour les manifests/segments HLS chauds, lifecycle management automatisant Hot → Cool → Cold → Archive, RA-GZRS pour les masters critiques, Last-Access Time Tracking activé. Architecture / pattern :

• Container live-streaming/ en Premium Block Blob (latence sub-ms pour les segments HLS de live TV)
• Container vod-catalog/ GPv2 Hot par défaut, lifecycle : Hot → Cool à 30j, Cool → Cold à 90j, Cold → Archive à 365j (basé sur daysAfterLastAccessTime)
• Container masters/ en RA-GZRS Cool + Immutable Storage time-based 7 ans (compliance contractuelle avec les ayants droit)
• CDN devant les blobs Hot pour absorber les pics
• Object Replication vers SA secondaire dans une autre region pour le DR éditorial Pièges à éviter :
• Premium Block Blob ne supporte pas les tiers Hot/Cool/Archive — y mettre du contenu rarement vu = facture x10 vs GPv2 Cool
• Lifecycle policy avec daysAfterLastAccessTime sans avoir activé Last-Access Time Tracking → la condition n'est jamais évaluée, rien ne tier
• Archive sans prévoir la rehydration (1-15h) → impossible de servir un contenu archive en mode "lecture immédiate"
• Object Replication impose Versioning + Change Feed activés des deux côtés et ne réplique pas les blobs en Archive (rehydrater d'abord)

Scenario 2 : Migration de file servers Windows on-prem multi-sites (groupe industriel multi-pays)

Contexte business : Groupe industriel avec 25 filiales mondiales. Chaque site a un file server Windows local (DFS) avec PDF/CAO/Excel partagés. DSI veut centraliser sans casser l'expérience utilisateur (latence locale). Choix techniques : Azure Files SMB (tier Transaction Optimized) + Azure File Sync sur chaque file server local, identité on-prem AD DS synchronisée vers Entra ID, cloud tiering activé. Architecture / pattern :

• 1 SA GPv2 par share métier (1 share = max 100 TB en standard, partition logique propre)
• File Sync Group par share avec cloud endpoint + N server endpoints (1 par filiale)
• Cloud tiering policy : "garder 20% libre + tier fichiers non accédés > 30j"
• AD DS auth activée sur le SA → permissions NTFS héritées des anciens shares
• GRS sur les SA (DR cross-region cost-effective, pas besoin de read-access secondaire en runtime)
• Backup Azure des shares via RSV (rétention 7 ans) Pièges à éviter :
• Mettre tous les shares dans 1 seul SA → quota d'IOPS partagé sur le SA, contention entre filiales
• 1 server = max 1 server endpoint dans le même sync group : impossible de sync F:\projects ET F:\archives du même serveur dans le même group → créer 2 sync groups
• Cloud tiering trop agressif (5% libre) → rappel constant des fichiers à la première ouverture, expérience utilisateur dégradée
• AD DS auth nécessite line-of-sight au DC depuis le client — VPN/ExpressRoute obligatoire entre le site distant et le DC

Scenario 3 : Archive de compliance financière (banque / asset manager)

Contexte business : Asset manager soumis à SEC 17a-4 et FINRA 4511 doit conserver emails, ordres de marché, communications client en WORM pendant 7 ans, non altérable. Audit annuel. Choix techniques : Storage Account GPv2 + Immutable Blob Storage (time-based retention locked) + Archive tier + GZRS + Infrastructure encryption activée à la création + CMK via Key Vault. Architecture / pattern :

• SA dédié salegalarchive-prod (séparé du reste pour scope d'audit clair)
• Versioning + Soft delete (containers + blobs) + Change Feed activés (audit trail)
• Container avec Time-based retention policy LOCKED 7 ans → personne ne peut shorten ou delete (même un Storage Account Owner)
• Lifecycle : Hot 30j → Cool 90j → Archive (daysAfterCreation) — pas Last-Access (les masters ne sont pas accédés en routine)
• Legal Hold ajouté à la demande sur des sous-folders pendant les contentieux
• GZRS (HA intra + DR inter-region) + Infrastructure encryption (double couche, irréversible)
• Shared Key access désactivé, accès uniquement RBAC Entra + User Delegation SAS Pièges à éviter :
• Time-based retention Unlocked : un admin peut shorten la période → ne satisfait pas SEC 17a-4 (qui exige WORM strict). Toujours Lock la policy après validation.
• Archive tier coûte cher à lire (rehydration + transactions) → ne pas mettre en Archive ce qui sera audité tous les mois
• Oublier Infrastructure encryption à la création = irréversible, faut recréer le SA pour l'avoir
• GRS au lieu de GZRS : LRS au primaire = single-DC, ne survit pas à une panne zone. Pour compliance : GZRS minimum.

Scenario 4 : Backend HPC / SAP HANA partagé (industrie pharma, ERP)

Contexte business : Workload SAP HANA scale-out a besoin d'un /hana/shared accessible par tous les nodes HANA, latence sub-ms, throughput plusieurs GiB/s. Azure Files standard est trop lent. Choix techniques : Azure NetApp Files (capacity pool Ultra ou Flexible), protocole NFSv4.1, subnet délégué Microsoft.NetApp/volumes, snapshot policies natives. Architecture / pattern :

• NetApp Account dans la même region que les VMs HANA, dans le même VNet (subnet délégué dédié)
• Capacity Pool 4 TiB Ultra (128 MiB/s par TiB) pour /hana/data et /hana/log, pool Premium séparé pour /hana/shared
• Volumes NFSv4.1 mounts depuis chaque VM HANA
• Snapshots ANF déclenchés via Azure Backup / scripts pour des restores instantanés
• Pas dans un Storage Account → ressource séparée, billing différent (capacité provisionnée, pas pay-per-GB consommé) Pièges à éviter :
• Oublier la délégation de subnet au provider Microsoft.NetApp/volumes → la création du volume échoue avec erreur cryptique
• Mettre un capacity pool Standard pour HANA → throughput insuffisant, SAP refusera le support
• Tenter d'utiliser Azure Files Premium pour HANA → non certifié SAP. Azure Files Premium = très bon pour fileshares généraux, pas pour /hana/data
• Service level change downgrade (Ultra → Standard) : 24h min entre 2 descentes — verrouille les opérations rapides

Sources : Azure Blob lifecycle management, Hybrid file services architecture, Immutable storage overview, Azure NetApp Files for SAP HANA