1 — Core Compute Services (AZ-305)

A. Decision tree compute AZ-305 ⭐⭐

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 — design 305 (awareness)

⚠️ 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 ⭐

🚨 Détail encryption VMs → fiche 9 Data Protection section G.

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 Pièges VMs 305

• 🚨 Spot VMs : pas pour prod stateful (Azure évincte sans préavis long).
• 🚨 VM Series H (HPC) → fiche 2 Big Compute.
• 🚨 Détails encryption (CMK, Confidential, ADE vs Encryption at Host) → fiche 9.

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.

D.6 Pièges ASE 305

• 🚨 ASE v3 = dernière option, trop cher sauf compliance ou 20+ apps. Préférer Premium v3 + PE + VNet Integration pour 99% des cas.
• 🚨 HA intra-region = zone redundancy à activer à la création (irréversible).
• 🚨 ASE v1/v2 retirés 31 août 2024. Pas d'upgrade in-place → recréer ASE v3 + ASE Migration Feature.

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 (awareness)

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

E.4 Durable Functions — awareness 305

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 (fiche 5).

E.5 Functions vs Logic Apps

E.6 Networking (awareness)

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 ⭐⭐

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