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).
• 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.

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 (pas blob) → 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.

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)

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

🏢 Scénarios d'entreprise (CAF/WAF)

Scenario 1 : Plateforme de streaming média (broadcaster TV / VOD)

Contexte business : Un broadcaster stocke 5 PB de vidéos. Une nouveauté est très regardée le 1er mois puis presque plus. Le vieux catalogue reste accessible mais peu consulté. Les masters doivent être gardés 7 ans. Choix architectural : un Storage Account GPv2 avec un container Premium Block Blob pour le contenu chaud (latence minimale), et une lifecycle policy qui descend automatiquement les données de Hot vers Cool/Cold/Archive selon l'usage. RA-GZRS pour les masters critiques. Architecture / pattern :

• live-streaming/ en Premium Block Blob : latence très basse pour les segments de live TV.
• vod-catalog/ en GPv2 Hot, puis lifecycle : Cool à 30j, Cold à 90j, Archive à 365j (selon la date de dernier accès, donc Last-Access Time Tracking activé).
• masters/ en RA-GZRS Cool + immutabilité time-based 7 ans (obligation envers les ayants droit).
• CDN devant le contenu chaud pour absorber les pics.
• Object Replication vers une autre région pour le DR. Trade-offs assumés :
• Gain : coût de stockage optimisé selon la fréquence d'accès.
• Perte : le contenu en Archive n'est pas lisible immédiatement (réhydratation requise). Pièges à éviter :
• Premium Block Blob ne gère pas les tiers Hot/Cool/Archive → y mettre du contenu rare coûte ~10x un GPv2 Cool.
• Lifecycle basé sur le dernier accès sans activer Last-Access Time Tracking → la règle ne se déclenche jamais.
• Archive sans prévoir la réhydratation (1-15h) → impossible de servir un fichier archivé en lecture immédiate.
• Object Replication exige Versioning + Change Feed des deux côtés et ne réplique pas l'Archive (réhydrater d'abord).

📐 Réf. WAF — Cost optimization (data/storage) : automatiser le déplacement Hot→Cool→Cold→Archive via lifecycle management selon le pattern d'accès est la recommandation Well-Architected d'optimisation des coûts de stockage. Lien

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

Contexte business : Un groupe a 25 filiales, chacune avec son file server Windows local (PDF, CAO, Excel partagés). La DSI veut tout centraliser dans le cloud sans dégrader la rapidité d'accès locale. Choix architectural : Azure Files (SMB) comme stockage central, avec Azure File Sync sur chaque serveur local qui garde un cache local des fichiers récents (cloud tiering). L'authentification s'appuie sur l'AD DS existant. Architecture / pattern :

• 1 Storage Account GPv2 par share métier (un share standard = max 100 TB).
• 1 Sync Group par share : un endpoint cloud + un endpoint par filiale.
• Cloud tiering : "garder 20% d'espace libre + remonter dans le cloud les fichiers non utilisés depuis 30j".
• Auth AD DS sur le SA → on garde les permissions NTFS des anciens shares.
• GRS (DR cross-région économique, pas besoin de lire le secondaire en temps normal).
• Sauvegarde des shares via Recovery Services Vault (rétention 7 ans). Trade-offs assumés :
• Gain : centralisation cloud tout en gardant la rapidité locale grâce au cache.
• Perte : dépend du lien réseau vers le DC, et le cache local limite l'espace économisé. Pièges à éviter :
• Tout mettre dans 1 seul Storage Account → les IOPS sont partagés, les filiales se gênent entre elles.
• Un serveur ne peut avoir qu'1 endpoint par Sync Group : pour sync 2 dossiers du même serveur, créer 2 Sync Groups.
• Cloud tiering trop agressif (5% libre) → les fichiers sont sans cesse re-téléchargés à l'ouverture, expérience lente.
• L'auth AD DS exige une visibilité réseau vers le DC → VPN/ExpressRoute obligatoire depuis les sites distants.

📐 Réf. — Azure File Sync (hybrid file services) & CAF storage : centraliser les file servers multi-sites dans Azure Files avec cache local via Azure File Sync + cloud tiering est le pattern hybride documenté pour les fichiers d'entreprise. Lien

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

Contexte business : Un asset manager soumis aux normes SEC 17a-4 et FINRA 4511 doit conserver emails et ordres de marché pendant 7 ans, sans pouvoir les modifier (WORM). Audit chaque année. Choix architectural : un Storage Account GPv2 dédié avec immutabilité time-based verrouillée (locked), Archive tier, redondance GZRS, Infrastructure encryption (activée à la création) et CMK. Architecture / pattern :

• SA dédié salegalarchive-prod, séparé du reste pour un périmètre d'audit clair.
• Versioning + Soft delete + Change Feed activés (piste d'audit).
• Container avec rétention time-based VERROUILLÉE 7 ans → personne ne peut raccourcir ni supprimer, même un Owner.
• Lifecycle Hot 30j → Cool 90j → Archive (selon date de création, pas le dernier accès).
• Legal Hold ajouté ponctuellement lors d'un litige.
• GZRS (HA + DR) + Infrastructure encryption (double couche, irréversible).
• Accès par Shared Key désactivé : uniquement RBAC Entra + User Delegation SAS. Trade-offs assumés :
• Gain : conformité WORM stricte et défense en profondeur.
• Perte : tout est figé/irréversible, et l'Archive coûte cher à relire. Pièges à éviter :
• Rétention Unlocked : un admin peut raccourcir la durée → ne satisfait pas SEC 17a-4. Toujours Lock après validation.
• Mettre en Archive ce qui sera audité tous les mois → réhydratation + transactions = facture qui grimpe.
• Oublier l'Infrastructure encryption à la création : irréversible, il faut recréer le SA.
• Choisir GRS au lieu de GZRS : le primaire reste en LRS (un seul datacenter), ne survit pas à une panne zone. Pour la compliance : GZRS minimum.

📐 Réf. WAF — Security (data protection) & Reliability (redundancy) : Immutable WORM + Infrastructure encryption + CMK + GZRS + Shared Key désactivé applique la défense en profondeur Well-Architected pour la conformité réglementaire des données. Lien

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)