Leçon 4 / 8
Leçon 04 · Microsoft Azure

Stockage Azure

Azure propose plusieurs services de stockage adaptés à des besoins différents : fichiers, objets binaires, messages, tables NoSQL. Comprendre quand utiliser chacun est essentiel pour concevoir des architectures cloud solides.

Les quatre grands types de stockage Azure

Azure organise son offre de stockage autour de quatre services principaux, regroupés sous un Storage Account (compte de stockage).

Service Type de données Cas d'usage typique
Blob Storage Objets binaires non structurés Images, vidéos, sauvegardes, logs, fichiers statiques
Azure Files Partages de fichiers SMB/NFS Remplacement d'un partage réseau on-premise, lift-and-shift
Table Storage Données NoSQL clé-valeur Catalogues, sessions utilisateur, données semi-structurées à faible coût
Queue Storage Messages en file d'attente Découplage de composants, traitement asynchrone, workflows
Règle simple pour choisir : tu stockes des fichiers ou des binaires → Blob. Tu as besoin d'un lecteur réseau partagé → Azure Files. Tu passes des messages entre services → Queue. Tu stockes des paires clé-valeur légères → Table Storage.

Le Storage Account : le conteneur de base

Avant de créer un blob ou un partage, il faut un Storage Account. C'est le niveau racine qui regroupe tous tes services de stockage et définit leur configuration globale.

Types de Storage Account

  • General Purpose v2 (GPv2) — recommandé pour la plupart des scénarios, supporte Blob, Files, Tables et Queues.
  • BlobStorage — uniquement pour les blobs, permet de choisir le niveau d'accès par défaut (Hot/Cool).
  • Premium — stockage SSD pour des latences très faibles (blobs de page, partages de fichiers haute perf).

Redondance des données

Azure réplique automatiquement tes données selon l'option choisie à la création :

  • LRS (Locally Redundant Storage) — 3 copies dans un seul datacenter. Le moins cher.
  • ZRS (Zone Redundant Storage) — 3 copies réparties dans 3 zones de disponibilité d'une même région.
  • GRS (Geo Redundant Storage) — 6 copies : 3 en région primaire (LRS) + 3 en région secondaire distante.
  • GZRS (Geo-Zone Redundant Storage) — combine ZRS en région primaire + LRS en région secondaire. Le plus résilient.
Bonne pratique : pour des données de production critiques, choisis au minimum GRS. Pour un environnement de développement ou des données reconstructibles, LRS suffit et coûte moins cher.

Azure Blob Storage

Blob Storage est le service de stockage d'objets d'Azure — l'équivalent d'Amazon S3. Il est conçu pour stocker des quantités massives de données non structurées accessibles via HTTP/HTTPS.

Organisation : containers et blobs

Un Storage Account contient des containers (équivalents de dossiers racines) qui contiennent eux-mêmes des blobs. Les containers peuvent être publics ou privés.

Types de blobs

  • Block blobs — le type par défaut. Optimisé pour uploader des fichiers en blocs parallèles. Idéal pour les images, vidéos, documents.
  • Page blobs — optimisé pour les accès aléatoires en lecture/écriture. Utilisé en interne par les disques de VMs Azure.
  • Append blobs — optimisé pour l'ajout en fin de fichier. Parfait pour les logs applicatifs.

Niveaux d'accès (tiers)

Chaque blob peut être placé dans un niveau d'accès différent selon sa fréquence d'utilisation :

  • Hot — données accédées fréquemment. Coût de stockage plus élevé, accès peu coûteux.
  • Cool — données accédées rarement, conservées au moins 30 jours. Stockage moins cher, accès plus coûteux.
  • Cold — données accédées très rarement, conservées au moins 90 jours. Encore moins cher que Cool.
  • Archive — données quasi-jamais accédées (sauvegardes long terme). Stockage très bon marché, mais la réhydratation peut prendre plusieurs heures.

Le niveau peut être défini au niveau du compte (par défaut) et surchargé blob par blob. On peut aussi configurer des lifecycle policies pour déplacer automatiquement les blobs vers des niveaux moins coûteux après un certain nombre de jours.

Azure Files

Azure Files propose des partages de fichiers managés accessibles via les protocoles SMB (Windows, Linux, macOS) et NFS (Linux). Contrairement à Blob Storage, la structure est hiérarchique, comme un vrai système de fichiers.

Connexion depuis différents OS

  • Windows — montage en lecteur réseau via la commande net use ou l'Explorateur de fichiers. Fonctionne exactement comme un partage SMB classique.
  • Linux — montage via CIFS (mount -t cifs) ou via le client Azure Files avec NFS.
  • macOS — montage via Finder (Se connecter au serveur) ou la commande mount_smbfs.

Cas d'usage principaux

  • Partager des fichiers de configuration entre plusieurs VMs ou services.
  • Migrer une application qui s'appuie sur un serveur de fichiers on-premise sans modifier le code.
  • Fournir un répertoire home partagé à des utilisateurs distants.

Accès et sécurité

Azure propose plusieurs mécanismes pour contrôler l'accès à un Storage Account.

Clés de compte

Chaque Storage Account dispose de deux clés d'accès (Account Keys) qui accordent un accès complet à toutes les ressources. À utiliser uniquement dans des environnements sécurisés et jamais dans du code côté client.

SAS Tokens (Shared Access Signatures)

Un SAS token est une URL signée qui délègue un accès limité à une ressource précise (un blob, un container, un service entier). On peut définir :

  • Les permissions autorisées (lecture, écriture, suppression…)
  • La plage de temps de validité (date de début et d'expiration)
  • Les adresses IP autorisées
  • Le protocole requis (HTTPS uniquement)

Microsoft Entra ID et RBAC

La méthode recommandée en entreprise est d'utiliser Microsoft Entra ID (ex Azure Active Directory) avec des rôles RBAC comme Storage Blob Data Contributor ou Storage Blob Data Reader. Cela évite de gérer des clés secrètes et s'intègre avec les identités managées des VMs et services Azure.

Créer un Storage Account et uploader un fichier avec Azure CLI

Voici le workflow complet pour créer un Storage Account, un container Blob et uploader un fichier depuis le terminal.

1. Créer un groupe de ressources et un Storage Account

# Créer un groupe de ressources
az group create \
  --name rg-stockage-demo \
  --location francecentral

# Créer un Storage Account GPv2 avec LRS
az storage account create \
  --name stmonminilabdemo \
  --resource-group rg-stockage-demo \
  --location francecentral \
  --sku Standard_LRS \
  --kind StorageV2 \
  --access-tier Hot

Le nom du Storage Account doit être unique globalement, en minuscules, entre 3 et 24 caractères, sans tirets.

2. Récupérer la clé de connexion

# Afficher les clés du Storage Account
az storage account keys list \
  --account-name stmonminilabdemo \
  --resource-group rg-stockage-demo \
  --output table

# Stocker la clé dans une variable (bash)
STORAGE_KEY=$(az storage account keys list \
  --account-name stmonminilabdemo \
  --resource-group rg-stockage-demo \
  --query "[0].value" \
  --output tsv)

3. Créer un container Blob

# Créer un container privé
az storage container create \
  --name images \
  --account-name stmonminilabdemo \
  --account-key $STORAGE_KEY

# Créer un container public (lecture anonyme autorisée)
az storage container create \
  --name assets-publics \
  --account-name stmonminilabdemo \
  --account-key $STORAGE_KEY \
  --public-access blob

4. Uploader un fichier (blob)

# Uploader un fichier local vers le container
az storage blob upload \
  --container-name images \
  --file ./photo.jpg \
  --name photo.jpg \
  --account-name stmonminilabdemo \
  --account-key $STORAGE_KEY

# Vérifier que le blob est présent
az storage blob list \
  --container-name images \
  --account-name stmonminilabdemo \
  --account-key $STORAGE_KEY \
  --output table

5. Changer le niveau d'accès d'un blob

# Passer un blob en niveau Cool (accès rare)
az storage blob set-tier \
  --container-name images \
  --name photo.jpg \
  --tier Cool \
  --account-name stmonminilabdemo \
  --account-key $STORAGE_KEY

# Passer en Archive (archivage long terme)
az storage blob set-tier \
  --container-name images \
  --name photo.jpg \
  --tier Archive \
  --account-name stmonminilabdemo \
  --account-key $STORAGE_KEY

6. Générer un SAS token pour partager un blob

# Générer un SAS token valide 1 heure, lecture seule
az storage blob generate-sas \
  --container-name images \
  --name photo.jpg \
  --permissions r \
  --expiry 2026-05-11T23:00:00Z \
  --account-name stmonminilabdemo \
  --account-key $STORAGE_KEY \
  --https-only \
  --output tsv

7. Supprimer les ressources

# Supprimer le groupe de ressources et tout ce qu'il contient
az group delete \
  --name rg-stockage-demo \
  --yes \
  --no-wait

Points clés à retenir

  • Un Storage Account est le conteneur racine de tous les services de stockage Azure. Son nom doit être unique globalement.
  • Blob Storage stocke des objets non structurés (images, vidéos, sauvegardes). Les blobs sont organisés dans des containers.
  • Les niveaux d'accès Hot, Cool, Cold et Archive permettent d'optimiser les coûts selon la fréquence d'accès aux données.
  • Azure Files propose des partages de fichiers SMB/NFS accessibles depuis Windows, Linux et macOS — idéal pour migrer des serveurs de fichiers on-premise.
  • La redondance (LRS, ZRS, GRS, GZRS) définit combien de copies de tes données Azure conserve et où. Pour la production, privilégie GRS ou GZRS.
  • Les SAS tokens permettent de déléguer un accès limité dans le temps à une ressource précise, sans partager la clé principale.
  • En entreprise, préfère Microsoft Entra ID avec RBAC plutôt que les clés de compte, pour éviter de gérer des secrets sensibles.