Stockage Azure end-to-end — Cosmos DB, SQL Database, Data Lake AZ-305

📍 Article principal du cluster : Azure Solutions Architect Expert AZ-305 — guide complet 2026

Ce tutoriel fait partie du cluster certification AZ-305. Pour la vue d’ensemble, lisez d’abord le pilier.

Introduction

Le domaine 2 « Design data storage solutions » teste votre capacité à choisir le bon service de stockage Azure selon le type de données, le volume, la latence cible, le coût et les contraintes de conformité. Azure expose une dizaine d’options de stockage très différentes : Cosmos DB pour le NoSQL globalement distribué, Azure SQL Database pour le relationnel managé, PostgreSQL/MySQL Flexible Server pour les bases open-source, Storage Account pour Blobs/Files/Queues/Tables, Data Lake Gen2 pour l’analytics. Ce tutoriel construit chaque pattern de stockage avec des configurations production-grade.

Prérequis

• Compte Azure et CLI configurés
• Tutoriel identity-governance terminé
• 40 minutes

Étape 1 — Créer un Storage Account avec lifecycle

Le Storage Account est le compte unifié qui héberge Blobs, Files, Queues et Tables. Pour optimiser les coûts, on configure des lifecycle policies qui déplacent automatiquement les données entre tiers Hot/Cool/Cold/Archive selon l’âge.

az group create --name rg-data --location westeurope

az storage account create \
  --name stdataaz305prod \
  --resource-group rg-data \
  --location westeurope \
  --sku Standard_GRS \
  --kind StorageV2 \
  --access-tier Hot \
  --min-tls-version TLS1_2 \
  --allow-blob-public-access false \
  --enable-hierarchical-namespace true

# Lifecycle policy: Hot 30j → Cool 90j → Archive 365j → delete 7 ans
cat > /tmp/lifecycle.json <<'EOF'
{
  "rules": [{
    "name": "tiered-archive",
    "enabled": true,
    "type": "Lifecycle",
    "definition": {
      "filters": {"blobTypes": ["blockBlob"]},
      "actions": {
        "baseBlob": {
          "tierToCool": {"daysAfterModificationGreaterThan": 30},
          "tierToArchive": {"daysAfterModificationGreaterThan": 90},
          "delete": {"daysAfterModificationGreaterThan": 2555}
        }
      }
    }
  }]
}
EOF

az storage account management-policy create \
  --account-name stdataaz305prod \
  --resource-group rg-data \
  --policy @/tmp/lifecycle.json

Le `–enable-hierarchical-namespace true` active Data Lake Gen2 sur le compte — utile pour analytics. La SKU `Standard_GRS` (Geo-Redundant Storage) réplique les données dans une seconde région automatiquement, indispensable pour les workloads conformité (BCEAO, OHADA).

Étape 2 — Cosmos DB avec API SQL et géo-réplication

Cosmos DB est la base NoSQL global de référence. Cinq APIs supportées : SQL (la plus populaire, JSON), MongoDB, Cassandra, Gremlin, Table. Le choix d’API dépend de votre code existant — pour un nouveau projet, privilégiez SQL.

az cosmosdb create \
  --name cosmos-az305-prod \
  --resource-group rg-data \
  --kind GlobalDocumentDB \
  --default-consistency-level "Session" \
  --locations regionName=westeurope failoverPriority=0 isZoneRedundant=true \
  --locations regionName=northeurope failoverPriority=1 isZoneRedundant=false \
  --enable-multiple-write-locations false

# Créer une database et un container
az cosmosdb sql database create \
  --account-name cosmos-az305-prod \
  --resource-group rg-data \
  --name appdb

az cosmosdb sql container create \
  --account-name cosmos-az305-prod \
  --resource-group rg-data \
  --database-name appdb \
  --name orders \
  --partition-key-path "/customerId" \
  --throughput 400

La consistency level `Session` est le défaut recommandé — bon compromis entre latence et garanties. La `–enable-multiple-write-locations false` indique active-passive — le primary write est en West Europe, North Europe est read-only failover. Pour active-active multi-write, mettre `true` mais coûte le double en RUs.

Étape 3 — Comprendre les 5 niveaux de consistency Cosmos DB

Question récurrente AZ-305 : quel niveau de consistency pour quel use case. Strong = lectures voient toujours la dernière write — latence élevée, débit réduit. BoundedStaleness = lectures peuvent retarder de N opérations ou X secondes maximum — bon compromis pour banking. Session (défaut) = un client voit ses propres writes immédiatement, mais peut voir d’anciennes versions des writes d’autres clients. ConsistentPrefix = lectures voient les writes dans l’ordre, mais avec délai. Eventual = lectures peuvent voir n’importe quelle version, latence et coût les plus faibles.

Question type d’examen : « Une application de paiement mobile money exige que toute requête lecture voie la dernière transaction confirmée ». Réponse : Strong consistency (ou BoundedStaleness avec staleness=0). Une application de catalogue produits où un délai de propagation de 5 secondes est acceptable : Eventual ou Session.

Étape 4 — Azure SQL Database avec failover groups

Azure SQL Database est le SGBD relationnel managé Microsoft. Pour la haute disponibilité multi-region, on utilise les failover groups qui orchestrent la bascule automatique entre primary et secondary.

SERVER_PRIMARY="sql-az305-prod-we"
SERVER_SECONDARY="sql-az305-prod-ne"
ADMIN_USER="sqladmin"
ADMIN_PASS=$(openssl rand -base64 24)

az sql server create \
  --name $SERVER_PRIMARY \
  --resource-group rg-data \
  --location westeurope \
  --admin-user $ADMIN_USER \
  --admin-password "$ADMIN_PASS"

az sql server create \
  --name $SERVER_SECONDARY \
  --resource-group rg-data \
  --location northeurope \
  --admin-user $ADMIN_USER \
  --admin-password "$ADMIN_PASS"

az sql db create \
  --name appdb \
  --server $SERVER_PRIMARY \
  --resource-group rg-data \
  --service-objective S2 \
  --backup-storage-redundancy Geo

# Failover group
az sql failover-group create \
  --name fg-az305-prod \
  --partner-server $SERVER_SECONDARY \
  --resource-group rg-data \
  --server $SERVER_PRIMARY \
  --add-db appdb \
  --failover-policy Automatic \
  --grace-period 1

Le `–grace-period 1` (en heures) définit combien de temps Azure attend avant un failover automatique en cas de panne du primary. Plus court = bascule rapide mais risque de faux positifs ; plus long = stabilité mais downtime plus long en cas d’incident réel.

Étape 5 — TDE et Customer-Managed Keys avec Key Vault

Transparent Data Encryption (TDE) chiffre les données SQL at-rest. Activé par défaut, mais avec une clé gérée par Microsoft. Pour la conformité BCEAO/PCI-DSS, on bascule sur Customer-Managed Keys (CMK) hébergées dans Azure Key Vault.

az keyvault create \
  --name kv-az305-prod \
  --resource-group rg-data \
  --location westeurope \
  --enable-purge-protection true \
  --enable-soft-delete true \
  --retention-days 90

# Créer la clé
az keyvault key create \
  --vault-name kv-az305-prod \
  --name tde-key \
  --kty RSA \
  --size 2048

# Donner le accès au SQL Server
SERVER_IDENTITY=$(az sql server show \
  --name $SERVER_PRIMARY \
  --resource-group rg-data \
  --query identity.principalId -o tsv)

az keyvault set-policy \
  --name kv-az305-prod \
  --object-id $SERVER_IDENTITY \
  --key-permissions get wrapKey unwrapKey

Avec cette configuration, vous gardez le contrôle de la clé de chiffrement. Si vous supprimez la clé Key Vault, votre base devient inaccessible — c’est précisément ce que demandent les régulateurs : preuve que vous pouvez révoquer l’accès.

Étape 6 — PostgreSQL Flexible Server

Pour les applications open-source qui demandent PostgreSQL, Azure Database for PostgreSQL Flexible Server est l’option recommandée en 2026. Plus performante que Single Server (deprecated 2025), avec haute disponibilité Same-Zone ou Zone-Redundant.

az postgres flexible-server create \
  --name pg-az305-prod \
  --resource-group rg-data \
  --location westeurope \
  --tier GeneralPurpose \
  --sku-name Standard_D2ds_v5 \
  --storage-size 256 \
  --version 16 \
  --high-availability ZoneRedundant \
  --backup-retention 35 \
  --geo-redundant-backup Enabled \
  --admin-user pgadmin \
  --admin-password "$(openssl rand -base64 24)"

La haute disponibilité ZoneRedundant déploie un secondary dans une zone de disponibilité différente (résilience contre panne datacenter). `–geo-redundant-backup Enabled` réplique les backups dans la paired region. `–backup-retention 35` jours est le maximum supporté.

Étape 7 — Data Lake Gen2 et Synapse Analytics

Pour les workloads analytics massifs (centaines de Go à des Po), Data Lake Gen2 + Synapse est l’architecture de référence. ADLS Gen2 stocke les données dans un Storage Account avec hierarchical namespace ; Synapse exécute les queries SQL ou Spark dessus.

# ADLS est déjà activé sur le storage account de l'étape 1
# Créer un workspace Synapse
az synapse workspace create \
  --name syn-az305-prod \
  --resource-group rg-data \
  --location westeurope \
  --storage-account stdataaz305prod \
  --file-system synapsefs \
  --sql-admin-login-user synadmin \
  --sql-admin-login-password "$(openssl rand -base64 24)"

# Note: Synapse coute cher (computes serverless dedicated SQL pool ~1 USD/heure DWU100c)
# A utiliser uniquement quand justifie

Synapse en serverless mode est facturé à la requête (5 USD/Tbo scanné). Excellent pour analytics ponctuels. Pour des workloads continus, le dedicated SQL pool est plus prévisible côté budget.

Étape 8 — Database Migration Service pour migration legacy

Pour migrer une base on-premise vers Azure (cas typique d’une banque ouest-africaine qui passe au cloud), Azure Database Migration Service automatise les phases de schema migration et data sync.

# DMS demande un VNet pour la connectivité
az network vnet create \
  --resource-group rg-data \
  --name vnet-dms \
  --address-prefix 10.50.0.0/16 \
  --subnet-name subnet-dms \
  --subnet-prefix 10.50.1.0/24

az dms create \
  --name dms-az305-prod \
  --resource-group rg-data \
  --location westeurope \
  --sku-name Premium_4vCores \
  --vnet vnet-dms \
  --subnet subnet-dms

DMS supporte les migrations SQL Server → Azure SQL, MySQL → Azure MySQL, MongoDB → Cosmos MongoDB API, et plus. Le mode online minimise le downtime à quelques minutes — critical pour une migration banking en production.

Comprendre la différence Azure SQL Database vs Managed Instance vs SQL Server VM

Trois saveurs SQL sur Azure, souvent confondues. Azure SQL Database est totalement managé, scaling vertical/horizontal automatique, paie par vCore ou DTU. Limitation : pas toutes les fonctionnalités SQL Server enterprise (CLR, SQL Agent local, etc.). Azure SQL Managed Instance est un compromis — managé mais avec quasi 100 % de compatibilité SQL Server enterprise. Plus cher, démarrage plus lent (4-6 heures pour création), idéal pour migrations lift-and-shift d’applications legacy. SQL Server on Azure VM est self-managed — vous gérez patches, backup, tuning. Maximum compatibilité et contrôle, minimum d’avantages cloud.

Question type AZ-305 : « Une banque migre une application legacy qui utilise SQL Server Agent et CLR custom assemblies, quelle option Azure ? ». Réponse : Managed Instance, car SQL Database ne supporte ni Agent ni CLR. Erreur classique : choisir SQL Database par défaut.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Pour les fintechs et néobanques de Dakar et Abidjan, le combo Azure SQL Database + Cosmos DB + Storage Account avec GRS couvre 90 % des besoins. Le coût démarre à environ 80-150 USD/mois pour une base SQL S2 + Cosmos DB 400 RUs + 1 Storage Account, ce qui est très accessible. La géo-réplication entre West Europe (primary) et North Europe (DR) répond aux exigences de continuité d’activité PSI-RC. Pour les workloads volumineux (data lake analytics > 1 To), le Synapse serverless est extrêmement économique — vous payez uniquement les requêtes exécutées.

Tutoriels frères

• Identity, governance et monitoring Azure
• Disaster recovery avec Azure Site Recovery et Backup (à venir)

Pour aller plus loin

• 🔝 Retour au pilier : AZ-305 — guide complet
• Cosmos DB : learn.microsoft.com/fr-fr/azure/cosmos-db
• Azure SQL Database : learn.microsoft.com/fr-fr/azure/azure-sql
• Storage Account lifecycle : learn.microsoft.com/fr-fr/azure/storage/blobs/lifecycle-management-overview

FAQ

Cosmos DB SQL ou MongoDB API ?
SQL si vous démarrez un nouveau projet — meilleure intégration Azure et fonctionnalités plus riches. MongoDB si vous migrez une application MongoDB existante.

Quand utiliser Azure SQL Hyperscale ?
Hyperscale est le service tier d’Azure SQL pour bases > 4 To, avec scalabilité jusqu’à 100 To et lectures parallélisées. Justifié pour data warehouses ou bases applicatives massives.

Mots-clés secondaires : cosmos db consistency level, azure sql failover group, customer-managed key tde, postgresql flexible server, data lake gen2, synapse analytics, dms migration azure