1 — Core Compute Services

Les grandes familles compute Azure → VM/VMSS, App Service, ASE, Functions : choisir selon contrôle OS, coût, isolation réseau et scalabilité. (Containers → fiche 3, batch → fiche 2.)

A. Decision tree compute

Le choix entre les 4 grandes familles compute.

Quel type de workload ?
├─ Code event-driven, sporadique, sans serveur à gérer
│   └─ Serverless → Azure Functions (Flex Consumption)
│
├─ App web HTTP/S avec déploiement zip/git, sans gérer l'OS
│   ├─ Multi-tenant standard            → App Service (Premium v3)
│   ├─ Compliance stricte / VNet-only    → App Service Environment (ASE v3)
│   └─ Container web simple              → Web App for Containers / Container Apps 
│
├─ Microservices / containers complexes
│   ├─ Kubernetes managed                → AKS (fiche 3)
│   ├─ Serverless containers             → Azure Container Apps (fiche 3)
│   └─ Container unique simple           → Azure Container Instances (fiche 3)
│
├─ Control total OS / driver custom / agents tiers
│   └─ Azure Virtual Machines (IaaS)
│
└─ HPC / batch parallèle (rendu, scientifique, ML training)
    └─ Azure Batch / CycleCloud (fiche 2)

Tableau de décision rapide

🎯 Règle générale 305 : "sporadique" → Functions · "web app standard" → App Service · "microservices" → AKS / ACA · "control OS / legacy" → VMs.

B. Azure Virtual Machines

⚠️ Bases VMs (création, OS, NSG, etc.) = AZ-104. Ici juste angle design 305.

B.1 Familles de SKUs (à reconnaître)

🎯 Question 305 type : "App standard web tier" → D. "SQL Server gros workload mémoire" → E ou M. "ML training" → N (ND/NC). "HPC simulation" → fiche 2.

B.2 Security features VMs

B.3 Spot VMs

• Jusqu'à -90% sur prix on-demand.
• Azure peut évincer la VM à tout moment (30s warning).
• Use case : batch tolérants à l'interruption, dev/test, CI/CD runners, calcul scientifique avec checkpoints.

B.4 HA / Distribution

🎯 Au 305 : AZ > AS quasi-systématique en prod. AS = legacy/régions sans AZ.

B.5 VDI / Desktops distants — AVD & Windows 365 (awareness)

Le scope "Recommend a compute solution per workload requirements" peut inclure le VDI / postes distants. À reconnaître, pas à maîtriser en profondeur.

🎯 Mémo design 305 :

• "VDI flexible multi-session, contrôle coût/scale, je gère les session hosts" → AVD
• "Cloud PC simple par utilisateur, prix fixe mensuel prévisible, zéro gestion d'infra" → Windows 365

C. App Service Web Apps (PaaS)

C.1 C'est quoi

PaaS managé pour apps web HTTP/S (.NET / Java / Node / Python / PHP / Ruby / containers). MS gère OS, runtime, patching, scaling. Tu déploies juste ton code.

C.2 Tiers / Plans

🎯 Mémo 305 :

• "Prod standard sans compliance stricte" → Premium v3
• "VNet integration + zone-redundant" → Premium v3
• "Compliance PCI/HIPAA + single-tenant" → Isolated v2 (ASE v3)
• "Dev/test" → Basic ou Standard

C.3 Features clés design 305

C.4 Multi-tenant Premium v3 vs Single-tenant ASE v3

🎯 "Web app prod avec VNet privée + zone-redundant" → Premium v3 + PE + VNet Integration (suffit 99% des cas). 🎯 "PCI-DSS / HIPAA / FedRAMP isolation hardware" → ASE v3.

C.5 Pièges App Service 305

• 🚨 Slots = Standard+ (pas Basic ni Free).
• 🚨 Private Endpoint inbound = Premium v3+.
• 🚨 Zone redundancy = Premium v3+.
• 🚨 ASE v3 = dernière option sauf compliance ou >20 apps : trop cher sinon.

D. App Service Environment (ASE) v3

D.1 C'est quoi

App Service single-tenant déployé dans ton VNet : isolation hardware, compliance stricte, "zero public" via ILB (Internal Load Balancer).

D.2 Architecture rapide

• Subnet dédié dans ton VNet (/24 recommandé).
• Internal ASE (ILB) ou External ASE (public isolé).
• Provisioning : 2-4h.
• Multiples plans Isolated v2 dans le même ASE (mutualisation).

D.3 Multi-tenant vs ASE

• Max 200 instances Isolated v2 par ASE.

D.4 Quand l'utiliser

D.5 HA / DR

Zone redundancy (intra-region) :

• Option à la création (irréversible), min 3 instances → distribue auto sur 3 AZ.

DR cross-region :

• Pas de réplication native d'ASE.
• Pattern : 2 ASEs + Front Door + données geo-replicated.

E. Azure Functions (serverless)

E.1 C'est quoi

Compute serverless event-driven : code exécuté en réponse à un trigger, billing à l'exécution.

E.2 Hosting Plans

🎯 Choix 305 :

• "Sporadique, minimize cost" → Flex Consumption
• "Latence critique, VNet strict, long-running" → Premium
• "Plan App Service existant sous-utilisé" → Dedicated (coût marginal nul)

E.3 Triggers / Bindings

1 trigger par function. Bindings input/output = N (lire Blob + push Queue déclaré dans config, sans coder les SDK).

E.4 Durable Functions

Extension qui rend les Functions stateful : workflows long-running, reprise sur crash, attente d'événements (heures/jours).

🎯 Au 305 : "Workflow long-running orchestré code-first + reprise crash + parallèle" → Durable Functions. "Workflow low-code SaaS connectors" → Logic Apps

E.5 Functions vs Logic Apps

E.6 Networking

E.7 HA / DR

Zone redundancy :

• Flex Consumption : ✅ par défaut sur régions supportées.
• Premium / Dedicated v3 : ✅ option à la création (irréversible, min 3 instances).

Cross-region DR : 2 Function Apps + Front Door + données geo-replicated.

E.8 Pièges Functions 305

• 🚨 Slots = Premium/Dedicated uniquement.
• 🚨 Hybrid Connections = Premium/Dedicated uniquement.
• 🚨 Workflow low-code SaaS → Logic Apps, pas Functions.
• 🚨 Long-running stateful → Durable Functions.
• 🚨 Détail sécurité (keys, authLevel) = AZ-204, hors scope 305.

F. Scénarios 305 → solution

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

Scénario 1 : Assurance — App web réglementée zone-redundant (least cost vs ASE)

Contexte business : Un assureur santé migre son portail de sinistres vers Azure. Il veut : accès public filtré, lien privé vers la base SQL, et haute dispo dans la région. Le RSSI réclamait un ASE v3 par réflexe « isolation ». Choix architectural : App Service Premium v3 (zone-redundant), exposé via App Gateway + WAF, base SQL jointe en privé via Private Endpoint. → pas besoin d'ASE v3 (trop cher) ici. Architecture / pattern :

• App Service Premium v3 réparti sur 3 zones → SLA 99.99%.
• App Gateway WAF_v2 = seule porte d'entrée publique ; il joint l'app en privé (Private Endpoint).
• L'app joint SQL, Key Vault, Storage en privé (VNet Integration + Private Endpoints). Certif TLS dans Key Vault. Trade-offs assumés :
• Gain : ~10x moins cher qu'un ASE v3, déploiement en minutes (vs 2-4h), même HA 99.99%.
• Perte : hardware partagé (multi-tenant). Insuffisant si la compliance exige une isolation physique (PCI-DSS/FedRAMP strict). Pièges à éviter :
• Private Endpoint entrant + zone redundancy = Premium v3+ seulement.
• Zone redundancy = à activer à la création du plan, irréversible.
• Ne pas laisser l'app aussi accessible en public : n'autoriser que l'IP de l'App Gateway. 📐 Réf. WAF — Baseline highly available zone-redundant web application : architecture de référence WAF qui valide précisément ce pattern (App Service zone-redundant + App Gateway/WAF + Private Link vers PaaS), en privilégiant le multi-tenant zone-redondant avant d'envisager l'isolation ASE. Lien

Scénario 2 : Média — Pipeline de traitement de fichiers serverless (fan-out/fan-in)

Contexte business : Studio média : à chaque livraison, des milliers de fichiers doivent être traités en parallèle puis agrégés en un rapport. Charge sporadique (rien entre deux livraisons), objectif coût minimal, et reprise après crash sans tout relancer. Choix architectural : Azure Functions Flex Consumption + Durable Functions (pattern fan-out/fan-in), déclenché par upload Blob. Architecture / pattern :

• Flex Consumption : scale-to-zero (coût nul à l'idle), montée jusqu'à 1000 instances selon la charge.
• Durable Functions : un orchestrateur lance N tâches en parallèle (1 par fichier) puis agrège les résultats. Checkpoint auto → reprise au point d'arrêt après un crash.
• Accès privé au Storage / base de métadonnées via VNet Integration. Trade-offs assumés :
• Gain : facturé à l'usage (GB-sec), résilient aux redémarrages, pas de file d'attente à gérer à la main.
• Perte : Flex Consumption = Linux only, pas de slots, et un quota régional (cores) qui peut brider le scale avant 1000. Pièges à éviter :
• maximum-instance-count < 40 sur du HTTP → throttling sous charge.
• Le plafond 1000 est théorique : le quota régional de cores est atteint avant → le surveiller / demander une hausse.
• Ne pas recoder la coordination à la main : c'est tout l'intérêt de Durable Functions. 📐 Réf. Durable Functions — Fan-out/fan-in pattern : pattern officiel de parallélisation + agrégation avec durable execution, alternative au couple file d'attente + 2 functions. Lien

Scénario 3 : Recherche — Calcul batch tolérant aux interruptions (cost optimization Spot)

Contexte business : Labo de génomique : analyses massivement parallèles (jobs de quelques heures, découpés en milliers de tâches indépendantes). Délai flexible, priorité = réduire la facture compute. Choix architectural : VMSS Flexible avec mix Spot/dédié (Spot Priority Mix), tâches courtes et checkpointées. Architecture / pattern :

• VMSS Flexible réparti sur les zones ; Spot Priority Mix = un socle de VMs dédiées (le job avance toujours) + un complément Spot (jusqu'à -90%).
• Avant éviction, Azure prévient (~30s via Scheduled Events) → on sauvegarde l'avancement.
• Spot Placement Score pour choisir région/SKU où le Spot est le plus dispo. Trade-offs assumés :
• Gain : jusqu'à -90% sur le compute interruptible, le socle dédié garantit la progression même sans Spot.
• Perte : aucun SLA/HA sur les nœuds Spot, éviction à tout moment. Inadapté au prod stateful ou aux jobs MPI (1 VM évincée = tout le job à relancer). Pièges à éviter :
• Pas de Spot pour des tâches longues non checkpointées : une éviction = tout reperdu.
• Pas de 100% Spot pour un job critique en délai : garder un socle dédié.
• VMSS Uniform (legacy) → préférer Flexible pour le mix Spot/dédié et le cross-AZ. 📐 Réf. WAF — Architecture best practices for Azure Virtual Machines (Cost Optimization) : recommandation WAF d'utiliser Spot pour les workloads batch interruptibles et de mixer dédié/Spot via Flexible orchestration + Spot Placement Score. Lien

DEMO

Demo Portail — Function App (Flex Consumption)

1. Function App > Create > Hosting plan: Flex Consumption
2. Onglet Basics :
   • Subscription / Resource Group : rg-functions
   • Function App name : func-orders (FQDN unique)
   • Region : East US
   • Runtime stack : Node 20 (ou Python / .NET / Java)
3. Onglet Storage : Storage Account stfuncorders (requis)
4. Onglet Networking : Toggle Enable VNet integration : On → choisir VNet + subnet délégué
5. Onglet Monitoring : Application Insights : On
6. Onglet Deployment :
   • Always Ready instances : 0 (ou N pour réduire cold start)
   • Maximum instance count : 100
   • Instance memory : 2048 MB
7. Review + Create

CLI équivalent (pour IaC) :

az functionapp create -g rg-functions -n func-orders \
  --flexconsumption-location eastus --runtime node --runtime-version 20 \
  --storage-account stfuncorders --instance-memory 2048 --maximum-instance-count 100

ASE v3 (Internal)

1. App Service Environments > Create
2. Basics : name + region
3. Hosting : Virtual IP type: Internal (ILB) ou External
4. Networking : VNet existant + subnet dédié vide (/24 recommandé)
5. Create → 2-4h provisioning
6. Puis : App Service Plans > Create > Pricing: Isolated v2 dans l'ASE
7. Web App / Function App attachée au plan
8. Internal ASE → DNS privé à configurer pour résolution