Comprendre Azure Storage : services, comptes et coûts

Azure Storage regroupe les services cloud de Microsoft pour les objets, les fichiers partagés, les messages et les données structurées non relationnelles. Azure propose aussi des disques managés pour les machines virtuelles. Le choix dépend de la manière dont une application lit et écrit les données, au-delà du seul espace nécessaire.

Si vous avez recherché « Windows Azure Storage », vous utilisez une ancienne appellation. Microsoft a renommé Windows Azure en Microsoft Azure en avril 2014 (annonce en anglais). Ces services fonctionnent avec Linux et d'autres plateformes, ainsi qu'avec Windows.

Ce guide s'adresse aux développeurs et aux équipes informatiques qui choisissent un service de stockage ou réévaluent une installation. Commencez par le mode d'accès, puis examinez l'emplacement, la résilience, les autorisations, les performances et le coût de sortie des données. Les liens vers la documentation Microsoft ci-dessous renvoient aux sources en anglais.

Quel service de stockage Azure choisir ?

Un partage de fichiers, un conteneur d'objets et un disque virtuel répondent à des besoins différents. Déplacer les mêmes données entre ces services peut demander de modifier l'application. Ce tableau permet de préciser le choix avant de comparer les configurations.

Service	Modèle de données	Premier usage à évaluer
Azure Blob Storage	Objets dans des conteneurs	Images, exports, médias et fichiers applicatifs
Azure Files	Système de fichiers partagé	Applications nécessitant un accès SMB ou NFS
Disques managés Azure	Stockage bloc pour les machines virtuelles Azure	Systèmes d'exploitation et volumes de données des VM
Azure Data Lake Storage	Fonctions analytiques fondées sur Blob Storage	Pipelines utilisant un espace de noms hiérarchique
Azure Queue Storage	Messages	Tâches en attente de traitement par une application
Azure Table Storage	Entités non relationnelles	Enregistrements structurés accessibles par clé

Azure Blob Storage pour les données non structurées

Azure Blob Storage conserve des objets texte et binaires. Un compte de stockage contient des conteneurs, qui contiennent des blobs. Les applications y accèdent couramment par API ou SDK, avec des bibliothèques clientes pour .NET, Java, Python et JavaScript, entre autres. Vérifiez l'interface attendue avant de supposer qu'un conteneur peut remplacer un dossier monté.

Azure Files pour les dossiers partagés

Azure Files fournit des partages managés via Server Message Block (SMB) ou Network File System (NFS). Les partages conservent une hiérarchie de dossiers. Confirmez le protocole, les clients pris en charge, l'authentification et les fonctions SMB ou le comportement NFS nécessaires à l'application. Notre guide des systèmes de fichiers cloud explique les différences entre accès fichier, bloc et objet.

Les disques Azure pour les machines virtuelles

Les disques managés fournissent du stockage bloc persistant aux VM Azure. Les options comprennent Ultra Disk, Premium SSD v2, Premium SSD, Standard SSD et Standard HDD. Choisissez le type et la taille selon la charge et les limites de la VM. Le disque temporaire d'une VM présente d'autres garanties de persistance : n'y conservez pas l'unique copie de fichiers importants.

Azure Data Lake Storage pour l'analyse

Azure Data Lake Storage Gen2 ajoute des fonctions analytiques à Blob Storage, dont un espace de noms hiérarchique pour les répertoires et fichiers. Ce n'est pas un type distinct de compte de stockage généraliste. Vérifiez la compatibilité des fonctions avant d'activer cet espace de noms pour un pipeline d'analyse, notamment de données massives.

Files d'attente et tables pour les données applicatives

Queue Storage assure la messagerie asynchrone entre composants applicatifs. Ce service est distinct des files Service Bus, qui proposent d'autres fonctions. Comparez les deux services de messagerie si l'ordre des messages ou la détection des doublons compte.

Table Storage stocke des entités aux propriétés flexibles, organisées par clés de partition et de ligne. Ce modèle accueille des jeux de données flexibles, mais les clés doivent correspondre aux requêtes prévues. Ce n'est pas une base relationnelle avec des jointures SQL. Azure Cosmos DB for Table est une offre distincte : vérifiez le service auquel renvoie un tutoriel ou un paramètre de connexion.

Un message Storage Queue peut atteindre 64 Kio. Une file peut contenir des millions de messages dans les limites de capacité du compte. Pour un contenu plus volumineux, prévoyez un message qui référence les données stockées ailleurs plutôt que d'y inclure le fichier entier.

Comprendre les comptes avant de créer les ressources

Un compte de stockage à usage général v2 prend en charge Blob, Queue, Table et les ressources Azure Files classiques. Les comptes Premium répondent à des usages précis, sans améliorer tous les services à la fois. Les disques managés sont des ressources distinctes. Le nom du compte comprend 3 à 24 lettres minuscules et chiffres, et doit être unique dans Azure.

Azure Files dispose aussi d'un modèle de gestion plus récent. La ressource Microsoft.FileShares permet de créer des partages sans compte de stockage. Au moment de la vérification, cette option prend en charge les partages NFS sur SSD avec le modèle provisionné v2. SMB et les autres configurations nécessitent toujours un modèle compatible.

Précisez l'interface nécessaire avant de suivre un tutoriel. Pour une bibliothèque d'images de site web, testez l'envoi et la récupération d'objets. Pour déplacer un dossier applicatif partagé, testez les autorisations, le verrouillage et l'accès des clients. Un compte facile à créer peut malgré tout être inadapté à l'application.

Choisir ensemble l'emplacement et la redondance

La région détermine où fonctionne le service et influence ses connexions aux utilisateurs et aux autres ressources. Partez de l'emplacement de l'application et des exigences documentées de résidence des données. Notre article sur l'emplacement des données cloud apporte du contexte à cette discussion.

Azure Storage peut répliquer les données selon plusieurs configurations de redondance. Leur disponibilité varie selon le service, la région et les fonctions du compte.

Option	Emplacement des copies
LRS	Dans un même centre de données physique de la région principale
ZRS	Dans au moins trois zones de disponibilité de la région principale
GRS	Redondance locale et réplication vers une région secondaire
GZRS	Redondance entre zones et réplication vers une région secondaire

La réplication géographique est asynchrone : la région secondaire peut donc avoir du retard sur les dernières écritures. Les variantes avec accès en lecture permettent de lire depuis le point de terminaison secondaire, sans y autoriser les écritures ordinaires. Consultez les consignes de basculement de Microsoft et définissez le comportement de l'application en cas de panne.

Plusieurs copies contribuent à la résilience, mais la haute disponibilité et le retour à un état antérieur demandent des démarches distinctes. Déterminez l'état antérieur à retrouver, les personnes autorisées à lancer la restauration et sa durée acceptable. Un test de restauration documenté permet de vérifier que les protections retenues produisent le résultat attendu.

Protéger les données Azure Storage avec des accès limités

Privilégier les identités aux clés intégrées dans le code

Microsoft recommande l'autorisation via Microsoft Entra ID pour Blob, Queue et Table lorsque c'est possible, notamment les identités managées des applications. Accordez les droits sur les données au périmètre adapté le plus restreint. Pour déléguer un accès, examinez les signatures d'accès partagé (SAS) disponibles, leurs autorisations et leur expiration. L'authentification des partages de fichiers demande un examen propre au protocole.

Vérifier séparément le chiffrement et l'accès réseau

Azure Storage chiffre les données au repos en AES 256 bits, avec des clés gérées par Microsoft par défaut et des options de clés gérées par le client selon le service. Le chiffrement côté service ne garantit pas que seul l'utilisateur final puisse déchiffrer les données.

Pour l'accès REST, le paramètre de transfert sécurisé obligatoire refuse HTTP et exige HTTPS. Il est activé par défaut sur les nouveaux comptes. Les connexions SMB et NFS ont leurs propres exigences de sécurité du transport. Examinez-les avec l'exposition des points d'accès et les autorisations.

Avant la production, demandez à une autre personne que le responsable de la configuration de tester une requête autorisée et une requête refusée. Consignez qui peut modifier les droits ou supprimer des ressources. Ces vérifications opérationnelles complètent vos mesures de sécurité cloud.

Adapter le niveau Blob Storage aux besoins de récupération

Pour les blobs de blocs compatibles, les niveaux Hot, Cool, Cold et Archive répartissent différemment les coûts de stockage et d'accès. Cool, Cold et Archive prévoient respectivement 30, 90 et 180 jours de durée minimale facturable. Il s'agit de règles tarifaires, pas de verrouillages de conservation : une suppression ou un déplacement anticipé peut entraîner des frais.

Archive est hors ligne. Il faut réhydrater un blob archivé avant de lire son contenu, ce qui peut prendre des heures. N'y placez pas une copie nécessaire à la restauration sans vérifier que ce délai respecte votre objectif de reprise.

Le niveau Smart peut déplacer automatiquement les blobs de blocs compatibles entre Hot, Cool et Cold selon les accès. Il ne les déplace pas vers Archive. Vérifiez les comptes et redondances compatibles, les règles de taille des objets et les frais de suivi avant de l'activer.

Choisissez un niveau en fonction de la prochaine lecture probable, pas seulement de la précédente. Un ancien fichier peut devenir urgent lors d'une enquête ou d'une restauration. Précisez quelles données peuvent attendre, lesquelles doivent rester accessibles immédiatement et qui approuve un changement de politique.

Estimer le coût complet d'exploitation

La page tarifaire d'Azure Blob Storage distingue capacité, opérations, récupération et transferts applicables. La région, la redondance et le niveau d'accès influencent l'estimation. Files et les disques managés ont leurs propres modèles tarifaires.

Établissez trois estimations à partir des mêmes hypothèses de charge : un mois ordinaire, un mois chargé et un mois de restauration ou de migration. Incluez les éléments suivants :

• Capacité moyenne stockée et croissance prévue.
• Nombre d'objets ou de fichiers, tailles habituelles et fréquence des lectures et écritures.
• Données récupérées, transférées entre régions ou sorties du service.
• Copies, versions, journaux et autres données conservées.
• Frais éventuels de durée minimale ou de capacité provisionnée.

Cette méthode reste utile lorsque les prix unitaires changent. Un faible prix de capacité ne suffit pas à estimer le coût de lectures fréquentes ou d'un export volumineux. Conservez les hypothèses pour qu'une autre personne puisse reproduire le calcul.

Tester les performances et configurer la supervision

La capacité et les performances ont des limites distinctes. Les objectifs des comptes standard de Microsoft indiquent une capacité par défaut de 5 Pio, extensible sur demande. Le nombre de requêtes et la bande passante dépendent de la configuration et de la région. La capacité annoncée ne garantit pas un débit.

Pour les charges nécessitant un débit élevé, testez des tailles de fichiers et des accès simultanés représentatifs depuis l'emplacement réel des clients. Mesurez latence, débit, erreurs et travail applicatif accompli. Pour un traitement par lots, la durée totale peut être le résultat utile ; pour l'accès interactif aux fichiers, les délais des petites lectures peuvent compter davantage que le débit maximal.

Configurez explicitement la supervision Azure et les paramètres de diagnostic. Les journaux de ressources nécessitent des règles de collecte et de routage pour être conservés et interrogés ensuite. Choisissez les catégories, la durée de conservation et les alertes utiles, en tenant compte du coût de collecte.

Commencer par un petit déploiement réversible

Vous pouvez gérer le stockage Azure via le portail, les outils en ligne de commande, les API, les SDK et Storage Explorer. L'introduction au stockage de Microsoft renvoie aux outils et documentations disponibles. Choisissez une interface que l'équipe peut utiliser et maintenir de manière cohérente.

1. Définir la charge de travail. Consignez le protocole d'accès, le volume, les habitudes de lecture et l'indisponibilité acceptable.
2. Choisir la ressource. Vérifiez ensemble le modèle de compte, la région, la redondance et la compatibilité des fonctions.
3. Définir les accès. Attribuez les identités et autorisations, puis testez les accès autorisés et refusés.
4. Charger un échantillon représentatif. Vérifiez l'intégrité du contenu, les métadonnées et le fonctionnement de l'application.
5. Tester la restauration et le coût. Restaurez les données, mesurez la durée et comparez l'utilisation observée à l'estimation.

Conservez la copie source jusqu'à la réussite des contrôles de migration. Un envoi réussi constitue une vérification, mais ne prouve pas que les autorisations, la recherche, le comportement des répertoires ou la restauration fonctionneront comme prévu.

Exemple : séparer le stockage des fichiers et leur traitement

Prenons une équipe qui reçoit des vidéos de clients et produit des aperçus plus petits. Une architecture possible place l'original dans Blob Storage, puis envoie un message Queue Storage identifiant l'objet. Un processus de traitement récupère la vidéo, crée l'aperçu et enregistre le résultat. La file indique le travail à effectuer ; le blob conserve le contenu volumineux.

Cette architecture utilise plusieurs services Azure sans demander à un seul de tout faire. Avant de traiter de gros volumes, définissez le comportement attendu si un processus s'arrête en cours de tâche. Testez les nouvelles tentatives sans produire de résultats en double et décidez quand supprimer originaux et aperçus. Ces décisions applicatives ne se résolvent pas par la seule capacité de stockage.

Une application utilisant des dossiers partagés part d'un autre besoin. Évaluez Azure Files et le comportement de son stockage de fichiers avant de revoir l'architecture autour des objets. La performance consiste à terminer la tâche prévue dans le délai attendu : comparez donc le parcours complet, accès client et traitement compris.

Quand évaluer une autre solution

Azure mérite d'être évalué lorsque la charge dépend de ses services de VM, d'identité, d'analyse ou de messagerie. Si vous avez seulement besoin de stockage objet, comparez les fournisseurs sur ce besoin précis, en intégrant le travail nécessaire pour changer les API, les autorisations et l'exploitation.

Hivenet Object Storage prend en charge les outils compatibles S3 pour les jeux de données, les sauvegardes, les médias et les objets applicatifs. Une application utilisant les API Azure Blob demande encore une vérification de compatibilité et de migration. Le stockage objet ne remplace pas directement Azure Files, Queue Storage ou les disques de VM.

Exécutez le même échantillon de travail sur chaque service retenu. Comparez le comportement des accès, les régions disponibles, la restauration, l'assistance et le coût complet. Appuyez le choix sur des résultats que l'équipe peut démontrer, puis documentez les conditions d'une future sortie.