8 — Data Platforms

Choisir la bonne base de données Azure → relationnel (Azure SQL DB, SQL MI, SQL on VM), NoSQL multi-modèle (Cosmos DB), open-source (PostgreSQL, MySQL Flexible) selon modèle SQL/ACID vs NoSQL/BASE, contrôle, latence et multi-région.

A. Vocabulaire DB cloud

A.1 SQL relationnel vs NoSQL

A.2 ACID vs BASE

• ACID (Azure SQL) : transfert 100€ A→B = les 2 ops réussissent OU aucune. Jamais d'état intermédiaire incohérent.
• BASE (Cosmos) : post publié, followers Paris voient instantanément, Tokyo 200ms après. Cohérence finale.

A.3 Request Units (RU/s) — l'unité de coût Cosmos

• RU/s = la "monnaie" de Cosmos : chaque op coûte des RU (read ≈ 1 RU, write ≈ 5 RU).
• Tu paies les RU/s réservées (provisioned) ou consommées (serverless).

A.4 Partition Key (Cosmos)

Attribut qui détermine sur quelle partition physique un document est stocké. Choix critique et figé à la création.

Bonne PK = haute cardinalité (millions valeurs distinctes) + distribution équitable + souvent dans WHERE. Mauvaise PK = peu de valeurs (/status avec 5 valeurs) → hot partition.

A.5 DTU vs vCore (Azure SQL pricing)

• DTU = bundle CPU+memory+IO en unités opaques. Simple, hérité (legacy).
• vCore = CPU/RAM/storage indépendants, plus de control, supporte Azure Hybrid Benefit.

B. Azure SQL — Famille (vue d'ensemble)

Décision rapide

• Cloud-first / nouvelles apps → SQL DB
• Migration SQL Server on-prem rapide + compat features instance-level → SQL MI
• Compat 100% + control OS / agents tiers / version SQL spécifique → SQL VM

C. Azure SQL Database (PaaS)

C.1 C'est quoi

PaaS relationnel managé (single DB ou elastic pool), ~99% compat SQL Server, HA managé, scaling fin → cible apps modernes cloud-first.

C.2 Compute models

• Provisioned : capacité fixe, payé 24/7 — prod prévisible
• Serverless : auto-pause après inactivité, billing par seconde — dev/test sporadique

C.3 Tiers vCore (3 modèles archi)

🎯 Mémo 305 :

• "Production HA" (sans précision) → BC (l'exam considère GP comme "HA avec disruption")
• "DB > 4 TB" ou "read scale-out massif" → Hyperscale
• "Budget restreint, RTO 30s OK" → GP

C.4 DTU vs vCore

C.5 Features scalabilité (awareness)

• Elastic Pools : partage capacité entre N DBs (SaaS multi-tenant, ~10× moins cher que N DBs peak séparées).
• Read Scale-out : BC + Hyperscale exposent un replica readable via ApplicationIntent=ReadOnly dans conn string. Offload reads.
• Sharding : N DBs + shard map (customerId % 10) pour scale horizontal. Détail dev = DP-300.

C.6 Pièges 305

• 🚨 Hyperscale = SQL DB only (pas MI).
• 🚨 DTU model = pas d'Azure Hybrid Benefit (vCore only).
• 🚨 Elastic Pool oversize : tous tenants peak simultanément → throttling pool.
• 🚨 Read Scale-out sans ApplicationIntent=ReadOnly → reads tapent sur primary.

🚨 SQL DB — in-memory OLTP support par tier :

• Premium (DTU) et Business Critical (vCore) : FULL support in-memory OLTP + memory-optimized tables persistantes + clustered columnstore indexes.
• General Purpose : ❌ pas d'in-memory OLTP. Mnémo : Premium DTU = BC vCore = full in-memory. GP = none. Hyperscale = partiel.

D. Azure SQL Managed Instance (MI)

D.1 C'est quoi

PaaS instance complète SQL Server (quasi 100% compat) — cible migrations SQL Server on-prem rapides sans refactor.

D.2 Features uniques vs SQL DB

• SQL Agent intégré (jobs)
• CLR (.NET assemblies)
• Cross-database queries
• Linked servers
• DTC (transactions distribuées)
• Service Broker

D.3 Networking

• Toujours dans un VNet (subnet dédié, délégué Microsoft.Sql/managedInstances).
• Public endpoint optionnel, recommandé privé only.

D.4 Tiers

D.5 Pièges 305

• 🚨 SQL MI = pas de Hyperscale (GP/BC only). Cap GP classique 16 TB / Next-gen GP 32 TB / BC 16 TB → scénario >32 TB → forcément SQL DB Hyperscale (128 TB).
• 🚨 Subnet dédié non partageable + délégation obligatoire.
• 🚨 Déploiement long (4-6h création, 1-6h scale).

E. SQL Server on Azure VM (IaaS)

E.1 Quand l'utiliser

• Compat 100% SQL Server (toutes features incl. agents tiers).
• Control complet OS, version SQL spécifique.
• Workloads >100 TB ou non-supportés en PaaS (legacy ETL, drivers exotiques).
• Azure Hybrid Benefit (BYOL) pour réutiliser licences on-prem (jusqu'à ~85% d'économie en combinant licences Win/SQL + tarifs réservés ; le gain réel dépend du tier/édition, à calculer via le Pricing Calculator).

E.2 HA / DR (à ta charge)

• HA via Always On AG manuel (multi-VMs + WSFC + AD + Internal LB pour le listener) — voir fiche 11.
• DR via ASR ou Always On AG cross-region.

E.3 Pièges 305

• 🚨 SQL VM = IaaS : patch OS, HA, backups → à toi. PaaS (DB/MI) gère tout.
• 🚨 Azure Hybrid Benefit = essentiel pour rentabilité SQL VM.
• 🚨 SQL IaaS Agent Extension = à installer/enregistrer pour features Azure (backup, monitoring, AHB tracking).

🚨 SQL Server on Azure VM — tempdb placement :

• Mettre tempdb sur le disque éphémère D:\ (ephemeral local SSD) → perf I/O optimal (latence µs), data perdue au reboot (OK car tempdb se recrée auto au démarrage SQL).
• Storage Account / Premium SSD persistents pour tempdb = surcoût + latence inutile. ⚠️ Distractor exam : "tempdb sur Premium SSD persistant" = mauvaise pratique, choisir ephemeral D:\.

F. Azure DB for MySQL / PostgreSQL — Flexible Server

F.1 C'est quoi

PaaS managé MySQL / PostgreSQL avec Flexible Server (successeur Single Server legacy) — zone-redundant HA + maintenance window custom + VNet injection.

F.2 Flexible Server vs Single Server (legacy)

F.3 Tiers Flexible Server

F.4 Scale vertical vs horizontal (PostgreSQL) — awareness

• Flexible Server = PG managé single-node, scale vertical (monter compute/storage du nœud) + read replicas. Cible : prod PG classique.
• Azure Cosmos DB for PostgreSQL (ex-Citus / Hyperscale) = PG distribué horizontalement (sharding via extension Citus) : coordinator node + worker nodes, scale out multi-nœuds. Use case : multi-tenant SaaS gros volume, real-time analytics, IoT / time-series — charges qui dépassent un Flexible Server vertical.
• 🎯 "PostgreSQL qui dépasse un single-node, scale-out distribué massif" → Cosmos DB for PostgreSQL ; sinon Flexible Server.
• ⚠️ Note actuelle (juin 2026) : MS Learn signale Cosmos DB for PostgreSQL en retraite (non recommandé pour nouveaux projets) → le remplaçant pour le scale-out PG est la feature Elastic Clusters d'Azure Database for PostgreSQL Flexible Server (même techno Citus). À l'exam, le nom Cosmos DB for PostgreSQL reste le distracteur "PG distribué Citus" attendu.

F.5 Pièges 305

• 🚨 Burstable = pas de HA. Question prod HA → GP ou Memory Optimized.
• 🚨 Single Server legacy → migrer vers Flexible Server.
• 🚨 Flexible Server = scale vertical (single-node) ; Cosmos DB for PostgreSQL = scale horizontal distribué (Citus). Ne pas confondre.
• 🚨 Distractors exam : "Burstable HA" = faux | "Single Server custom maintenance" = faux.

G. Cosmos DB (NoSQL)

G.1 C'est quoi

NoSQL multi-modèle, multi-region, low-latency (<10ms P99). Cœur "Design data storage" AZ-305 — schema-less + scale horizontal natif + SLA 99.999%. Gross feature: multi-region write.

G.2 Hiérarchie

Account (région primaire + N régions) → Database → Container (collection/table/graph) → Item (document/row/vertex)

G.3 APIs (façades)

🎯 Question type 305 : "Migrer app MongoDB existante avec wire protocol Mongo intact" → Cosmos DB for MongoDB API.

G.4 Throughput modes (RU/s)

Throughput scope : Database-level (RU partagées, max 25 containers) vs Container-level (RU dédiées, recommandé prod).

G.5 Partitioning

• PK = haute cardinalité + distribution équitable + souvent dans WHERE.
• Limite 20 GB / partition logique.

G.6 Consistency Levels (5)

🎯 Mémo : Strong = cher + lent multi-region. Session suffit 99% des cas prod.

G.7 Multi-Region & Replication

G.8 Backup

• Periodic (default) : 2/jour, restore via ticket
• Continuous PITR : 7j gratuit / 30j payant, self-service portail

G.9 Quand l'utiliser

• NoSQL global low-latency schema-less (<10ms P99).
• Multi-region writes nécessaires (apps mondiales, edge).
• Charges write-heavy / IoT / catalogue / sessions / social.
• PAS : relationnel + ACID + joins → SQL DB | cache key-value → Redis | big data analytical → Synapse/Databricks.

H. Caching — Redis

📚 Azure Cache for Redis & Azure Managed Redis = traités dans la fiche 5 - App Integration Services (section M).

Rappel court : caching key-value in-memory pour sessions, offload DB, rate limiting, distributed lock. Azure Cache for Redis en sunset 2026-2028 → nouveaux projets = Azure Managed Redis (Redis Enterprise multi-threaded, modules natifs, active geo-rep, zone-redundant par défaut).

I. Rappel HA/DR & Backup (détail → fiche 11)

Vite fait, le détail est dans la fiche 11 :

• HA SQL DB intra-region : GP (~30s reattach storage) / BC Always On AG 4 replicas (<10s) / Hyperscale (page servers). Option Zone-Redundant (+30% coût, SLA 99.995%).
• DR cross-region SQL DB / MI : Auto-Failover Group (listener DNS stable + failover auto + multi-DB atomique) ou Active Geo-Replication (manuel, SQL DB only).
• Backup SQL : PITR 1-35j + LTR W/M/Y jusqu'à 10 ans + Geo-redundant default (GRS).
• MySQL/PG Flex backup : LRS / ZRS / GRS pour DR régional + Read Replica cross-region pour DR manuel.
• Cosmos DB : Continuous Backup PITR 7d/30d + Multi-region writes pour HA globale.
• Redis : Zone-redundant intra-region (Standard+) + Active geo-rep (Enterprise / Managed Redis) pour DR.

J. Decision Trees AZ-305

Par type de data

Tu as quel type de data ?
├─ Relationnel + ACID + joins                          → Azure SQL
│   ├─ Cloud-first, nouvelles apps                     → SQL Database
│   │   ├─ Mission-critical low-latency                → Business Critical
│   │   ├─ Volume >4 TB ou scale reads massif          → Hyperscale
│   │   └─ Standard prod                               → General Purpose
│   ├─ Migration SQL Server avec Agent/CLR/cross-DB   → SQL Managed Instance
│   └─ Compat 100% + control OS / agents tiers         → SQL on Azure VM (+ AHB)
│
├─ MySQL / PostgreSQL                                  → MySQL/PG Flexible Server
│   ├─ Prod HA                                         → GP ou Memory Optimized
│   └─ Dev/test                                        → Burstable
│
├─ NoSQL global, schema-less, low-latency              → Cosmos DB
│   ├─ Documents JSON natifs                           → NoSQL API
│   ├─ Migrer MongoDB                                  → MongoDB API
│   ├─ Migrer Cassandra                                → Cassandra API
│   ├─ Graphes (social, fraud)                         → Gremlin API
│   └─ App PG distribuée massive                       → PostgreSQL API (Citus)
│
├─ Cache key-value RAM (sessions, offload DB)          → Azure Managed Redis 
│                                                       (ou Cache for Redis legacy si déjà déployé)
│
├─ Fichiers / blobs                                    → Storage Account (fiche 7)
└─ Big data analytical                                 → Synapse / Databricks (fiche 10)

Par tier SQL DB

Quel tier Azure SQL DB ?
├─ Production "HA" sans précision                      → Business Critical (réponse 305 par défaut)
├─ Mission-critical + read replicas inclus             → Business Critical
├─ Volume >4 TB ou jusqu'à 128 TB                      → Hyperscale
├─ Scale reads massif (30 read replicas)               → Hyperscale
├─ Budget restreint + RTO 30s OK                       → General Purpose
└─ Dev/test sporadique avec auto-pause                 → Serverless

Par consistency Cosmos

Use case ?
├─ Compteurs critiques, finance                        → Strong
├─ Tolère retard borné                                 → Bounded Staleness
├─ Read-your-own-writes (default, le + courant)        → Session 
├─ Order matter, pas de gaps                           → Consistent Prefix
└─ Likes counter, no fresh required                    → Eventual

K. Decision Matrix consolidée

L. Scénarios 305 → solution

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

Scénario 1 : SaaS B2B — plateforme RH multi-tenant 400 clients

Contexte business : Éditeur SaaS RH, 400 entreprises clientes, 1 base par client (isolation contractuelle). Charges très inégales : quelques gros tenants actifs, la majorité dormante. Budget contraint. Choix architectural : Azure SQL Database — Elastic Pool (1 base par tenant), tier GP zone-redundant, + Auto-Failover Group pour le DR cross-region. L'elastic pool fait partager le compute entre 400 bases au lieu de payer 400 bases à pleine puissance. Architecture / pattern :

• 1 base par client, regroupées dans 2-3 elastic pools qui partagent le compute
• LTR (semaine/mois/an) pour la rétention RH ; PITR 1-35j pour les erreurs humaines
• Un gros tenant "premium" peut sortir du pool vers une base dédiée (modèle hybride) Trade-offs assumés :
• Gain : coût/tenant minimal (compute mutualisé ~10x moins cher que 400 bases séparées) + isolation par base + restauration par tenant
• Perte : risque "voisin bruyant" si tous les tenants pointent en même temps ; routage tenant→base à gérer côté app Pièges à éviter :
• Pool sous-dimensionné → throttling si les pics se cumulent (la paie de fin de mois pour tous les clients en même temps)
• Mettre les tenants sur des serveurs différents : impossible de les mettre dans un même pool (pool = même serveur logique)
• Restaurer une base multitenant vers du single-tenant n'est pas supporté nativement (outil split/merge requis) 📐 Réf. Architecture Center — Multitenant SaaS database tenancy patterns : le modèle database-per-tenant + elastic pool est le pattern recommandé pour concilier isolation et coût ; au-delà du seuil de densité, basculer vers sharded multitenant. Lien

Scénario 2 : E-commerce mondial — catalogue & panier multi-région

Contexte business : Marketplace sur 4 continents, pics Black Friday, latence <50ms partout. Beaucoup d'écritures (paniers, sessions) depuis chaque région. Schéma produit variable selon la catégorie. Choix architectural : Azure Cosmos DB for NoSQL en multi-region writes (écriture locale dans chaque région), Autoscale par container, consistency Session par défaut, Continuous backup PITR. Architecture / pattern :

• Container orders, PK /customerId (haute cardinalité, on relit ses propres écritures sur le panier)
• Container catalog répliqué en lecture dans toutes les régions clientes
• Autoscale 10-100% pour absorber Black Friday sans surpayer 24/7
• Le stock critique est géré à part (SQL DB ou Cosmos en Strong sur un container isolé) Trade-offs assumés :
• Gain : écriture locale = latence minimale par région + élasticité + SLA multi-région élevé
• Perte : le multi-write impose de gérer les conflits (LWW ou custom) et un comportement eventual côté app ; coût RU plus élevé qu'en mono-région Pièges à éviter :
• Strong consistency en multi-write : très cher et lent cross-région — Session suffit pour le panier
• Mal choisir la PK : /customerId (réparti), pas /status ni /region (hot partition, erreurs 429 même à faible charge)
• Compter sur l'eventual pour "ne jamais survendre" : isoler le stock en Strong ou dans une SQL DB transactionnelle 📐 Réf. WAF — Architecture best practices for Azure Cosmos DB (Performance Efficiency) : multi-region writes recommandé uniquement si clients géo-distribués et app tolérant la résolution de conflits + eventual consistency. Lien

Scénario 3 : Fintech — moteur de trading low-latency HA

Contexte business : Plateforme de trading. Transactions ACID strictes, latence <2ms par requête, rapports analytiques lourds en parallèle sans ralentir l'OLTP, reprise en quelques secondes, zéro perte de données validées. Choix architectural : Azure SQL Database — Business Critical zone-redundant (Always On, 4 nœuds), Read Scale-out pour les rapports, Auto-Failover Group pour le DR régional. BC choisi car c'est le tier le plus rapide et le plus résilient (SSD local, replica HA). Architecture / pattern :

• BC = stockage SSD local, latence <2ms, replica secondaire lisible inclus gratuitement
• Rapports envoyés au replica via ApplicationIntent=ReadOnly → ils ne touchent pas le primary
• Zone-redundant (SLA 99.995%, RPO=0) pour survivre à la perte d'une zone
• Auto-Failover Group : listener DNS stable, bascule atomique, pas besoin de changer la conn string Trade-offs assumés :
• Gain : HA quasi transparente (<10s, vs ~30s en GP) + read replica gratuit + RPO zéro en zone-redundant
• Perte : BC ~2.7x le prix de GP (+ surcoût zone-redundancy) ; Hyperscale indisponible en BC Pièges à éviter :
• Prendre GP "pour économiser" alors que l'énoncé dit "HA sans interruption" → l'exam attend BC
• Rapports sans ApplicationIntent=ReadOnly → ils tapent le primary et dégradent l'OLTP
• Confondre Auto-Failover Group (DR cross-région) et zone-redundancy (HA intra-région) : deux couches distinctes 📐 Réf. WAF — Architecture best practices for Azure SQL Database (Reliability) : « Use the Business Critical tier for critical workloads because it offers the highest reliability guarantees » + redondance via failover groups & zone-redundancy. Lien

DEMO

Demo Portail — Create Cosmos DB account + container

💡 Serverless vs Provisioned : Provisioned = réserves RU/s (manual / autoscale), payé 24/7, charge prévisible. Serverless = pay-per-RU, max ~5k RU/s + 1 TB, pas multi-region writes, idéal dev/test.

1. Azure Cosmos DB > Create > Azure Cosmos DB for NoSQL (ou MongoDB / Cassandra / Gremlin / Table)
2. Basics tab :
   • Resource Group + Account Name : mycosmos (FQDN globalement unique)
   • Location : East US
   • Capacity mode : Provisioned throughput ou Serverless
   • Apply Free Tier Discount : Apply (1000 RU/s gratuites si dispo)
3. Global Distribution tab :
   • Geo-Redundancy : Enable (read replica paired region)
   • Multi-region Writes : Enable
   • Availability Zones : Enable
4. Networking tab : All networks / Selected networks / Private endpoint
5. Backup Policy tab : Continuous (7 days) gratuit (PITR self-service) ou Continuous 30j / Periodic
6. Encryption tab : Service-managed key ou Customer-managed key (KV)
7. Review + create (5-10 min)
8. Après création — créer DB + container :
   • mycosmos > Data Explorer > New Container
   • Database id : mydb
   • Container id : orders
   • Partition key : /customerId (haute cardinalité, figé)
   • Throughput : Manual / Autoscale (max RU/s) / Serverless
9. mycosmos > Replicate data globally : cliquer regions sur la carte + drag Failover priorities → Save
10. Data Explorer : New Item (JSON) + New SQL Query (SELECT * FROM c WHERE c.customerId="C-001")

Demo — Cosmos Continuous Backup (PITR)

• À la création : Backup policy: Continuous (7 days or 30 days)
• Restore : Cosmos DB > Point in time restore → timestamp + nouveau account destination

Demo Portail — Cosmos Entra ID auth

1. Cosmos DB > Access Control (IAM) > + Add role assignment
2. Rôle : Cosmos DB Built-in Data Contributor → assigner à user / Managed Identity
3. (Optionnel) Cosmos DB > Settings > Features : activer Disable local auth (Entra-only)
4. Côté app : utiliser DefaultAzureCredential (MSAL) au lieu des keys

Demo Portail — Create Azure SQL DB + Entra ID auth (avec VM/SSMS)

Étape 1 — Créer VM jump avec SSMS

1. Virtual machines > + Create > Azure virtual machine
2. Basics :
   • Resource Group : rg-sqldemo
   • Virtual machine name : vm-ssms
   • Image : Windows Server 2022 Datacenter (ou marketplace avec SSMS)
   • Public inbound : Allow RDP (3389)
3. Networking : créer vnet-sqldemo + subnet snet-vm
4. Review + create → RDP, installer SSMS (aka.ms/ssmsfullsetup)

Étape 2 — Créer SQL Server + SQL Database

1. SQL databases > + Create
2. Basics tab :
   • Resource Group : rg-sqldemo
   • Database name : mydb
   • Server → Create new :
     • Server name : mysrv-demo
     • Authentication method : Use both SQL and Microsoft Entra authentication (ou Entra-only)
     • Set Microsoft Entra admin : sélectionner user/group Entra
   • Want to use SQL elastic pool? : No
   • Compute + storage > Configure database :
     • Service tier : General Purpose / Business Critical / Hyperscale
     • Compute tier : Provisioned ou Serverless (auto-pause)
     • Hardware : Standard-series Gen5 + vCores + Storage
3. Networking tab :
   • Connectivity method : Public endpoint (selected networks) ou Private endpoint
   • Allow Azure services and resources to access this server : No
   • Add current client IP address : Yes (optionnel)
4. Security tab : Microsoft Defender for SQL (recommandé) + Transparent data encryption ON (default)
5. Additional settings : Use existing data = None / Backup / Sample (AdventureWorksLT)
6. Review + create

Étape 3 — Autoriser le VNet de la VM

1. mysrv-demo > Security > Networking
2. Public network access : Selected networks
3. Virtual networks > + Add existing virtual network :
   • VNet vnet-sqldemo, Subnet snet-vm → Enable (Service Endpoint Microsoft.Sql)
4. Save

Étape 4 — Activer Entra ID auth (si pas fait à la création)

1. mysrv-demo > Settings > Microsoft Entra ID
2. Set admin → user/group DB Admins → Save
3. (Optionnel) Microsoft Entra authentication only : On → Save

Étape 5 — Se connecter via SSMS depuis la VM

1. RDP vm-ssms → ouvrir SSMS
2. Connect > Database Engine :
   • Server name : mysrv-demo.database.windows.net
   • Authentication : Microsoft Entra MFA
   • Database (Options) : mydb

Étape 6 — Créer un contained user (SQL DDL)

💡 Explication : EXTERNAL PROVIDER = principal Entra. Le user dans la DB est mappé par nom (pas de password). db_datareader/writer = rôles SQL built-in pour CRUD sans droits admin/DDL.

CREATE USER [my-app] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [my-app];
ALTER ROLE db_datawriter ADD MEMBER [my-app];

Étape 7 — Côté app .NET (Managed Identity, zéro password)

var credential = new DefaultAzureCredential();
var sqlConn = new SqlConnection("Server=mysrv-demo.database.windows.net;Database=mydb;");
sqlConn.AccessToken = (await credential.GetTokenAsync(
    new TokenRequestContext(new[] { "https://database.windows.net/.default" }))).Token;