8 — App Service

PaaS Azure pour héberger WebApp / API / Mobile back-end / Functions sans gérer l'OS ni le serveur web. Tu fournis le code (ou container), Azure gère le runtime, l'OS, les patches, la HA.

A. Présentation

Types d'apps hébergées

Hiérarchie

Resource Group (région X)
  └─ App Service Plan (région X — capacité compute, SKU)
        └─ App Service (Web App, API, etc.)
              └─ Deployment slots (option, selon SKU)

Plan + apps = même région. Plusieurs apps peuvent partager un seul plan (mutualisation des coûts). Linux et Windows = plans séparés (un plan ne peut pas mixer les deux).

B. App Service Plans (SKUs)

Tiers (à connaître pour AZ-104)

Slots = uniquement à partir de Standard. Basic = pas de slots. Le tier influence : CPU/RAM, slots dispo, scale-out max, prix. Scale-up/down (changer de SKU) = possible à chaud sans downtime applicatif (juste un swap derrière).

App Service Environment (ASE) v3

• App Service hébergé dans ton VNet → 100% isolé (single-tenant), inbound + outbound contrôlés.
• Requis pour SKU Isolated v2.
• Use case : compliance stricte, workloads internes accessibles uniquement via VNet.
• ⚠️ Cher : facturé même sans app dedans.

Static Web Apps (service séparé)

Service dédié pour sites statiques (HTML/JS/SPA Vue/React/Angular/Svelte/Blazor + Hugo/Gatsby) + APIs serverless intégrées.

Caractéristiques :

• Hébergement statique global (CDN intégré, certs SSL auto).
• GitHub Actions / Azure DevOps auto-config à la création (CI/CD natif).
• APIs via Azure Functions (Node, .NET, Python) intégrées dans la même app.
• Staging environments : preview à chaque PR (pull request).
• Authentication : intégration Entra ID, GitHub, Twitter via config simple.

SKUs :

Fichier staticwebapp.config.json : routes, auth rules, fallback, custom headers.

Pour AZ-104 : retenir l'existence + différence avec App Service (SWA = statique + API serverless intégré, App Service = full backend).

C. Deployment

Sources possibles

• Code : zip, GitHub, Azure Repos, Bitbucket, local Git, FTP/FTPS
• Container : ACR, Docker Hub, registres tiers (image pull au démarrage)
• Static Web Apps : déploiement direct depuis GitHub Actions / Azure Pipelines

Méthodes de déploiement

Deployment Center = blade unifiée pour toutes les sources. Configure le pipeline CI/CD auto si Git/GitHub.

Deployment Slots (Standard+)

Environnements parallèles (staging, dev, etc.) — chacun a sa propre URL <app>-<slot>.azurewebsites.net.

Avantages :

• Test avant prod : déploie sur staging, teste, puis swap.
• Swap atomique : pas de downtime, pré-warm de l'instance avant rotation DNS.
• Rollback instantané : si la prod casse, swap inverse.
• Traffic routing : split du trafic % entre slots (canary, A/B).

Slot settings (sticky) :

• App settings & connection strings sont par défaut swapés avec le code.
• On peut les marquer comme slot setting (sticky) → restent dans leur slot lors du swap (utile pour les chaînes de connexion DB de prod vs staging).

Slots disponibles : Standard = 5 (incluant prod), Premium v3 = 20, Isolated v2 = 20.

D. Configuration

App Settings & Connection Strings

• App Settings : variables d'environnement injectées dans l'app au boot.
• Connection Strings : pour DB, formaté pour différents providers (SQL, MySQL, etc.).
• Stockés chiffrés côté Azure.
• Référence Key Vault : @Microsoft.KeyVault(SecretUri=https://...) → l'app résout le secret au runtime via la Managed Identity de l'app.
• Slot setting checkbox : sticky lors du swap (voir section C).

Custom domain

1. Acheter le domaine chez un Registrar (ou Azure App Service Domains).
2. App > Custom domains > Add → instructions pour ajouter records DNS :
   • CNAME : www → <app>.azurewebsites.net
   • TXT + A : pour apex (@)
3. Verify → custom domain attaché.
4. Ajouter un certificat SSL (App Service Managed Cert gratuit, ou via KV).

Backup (Standard+)

• Snapshot app + config vers un Storage Account.
• Manuel ou planifié (frequency, retention).
• Restore : new app ou overwrite.
• ⚠️ Pas pour les data DB → utilise les backups DB séparés.

Diagnostic logging (App > Monitoring > App Service logs)

4 catégories distinctes :

Severity levels (du moins au plus verbeux) :

Error  →  Warning  →  Information  →  Verbose

→ Choisir un niveau capture ce niveau ET tous les plus critiques :

• Error → Error uniquement
• Warning ⭐ → Warning + Error
• Information → Information + Warning + Error
• Verbose → tout (très bruyant, à éviter en prod)

🚨 Piège exam classique : "capturer logs de severity Warning ou plus" → choisir level Warning (pas Information qui en capturerait trop, ni Error qui en raterait). Pour stockage longue durée : Application Logging (Blob), pas FileSystem.

E. Networking

Inbound (qui peut joindre l'app)

Outbound (où l'app peut sortir)

VNet Integration (regional)

• L'app peut joindre les ressources d'un VNet (privé) via un subnet délégué (Microsoft.Web/serverFarms).
• Same region entre App Service Plan et VNet → recommandé.
• Permet d'atteindre :
  • VMs / DBs avec Private Endpoint dans le VNet
  • Ressources peerées (autres VNets)
  • On-prem via VPN Gateway / ExpressRoute (si le VNet y est connecté)
• Subnet dédié (un subnet = un App Service Plan).
• Standard tier+.

Hybrid Connections (Azure Relay)

• Outbound vers une ressource précise (host:port) via Azure Relay + Hybrid Connection Manager (HCM) sur le réseau cible.
• Trafic sortant TCP via 443 uniquement (pas de UDP).
• Use case : accès à une DB on-prem sans VPN, accès à un système legacy hors Azure.
• Pas de routage VNet — c'est un tunnel app-to-host.

À retenir piège AZ-104 :

• Inbound = restreindre qui appelle l'app (Access restrictions / Private Endpoint).
• Outbound = par où l'app appelle (VNet Integration / Hybrid Connections). Ce sont deux features distinctes, gérées séparément.

F. Scaling

Scale Up (vertical)

• Changer le SKU du plan (B1 → S1 → P1v3 → …) → plus de CPU/RAM par instance.
• Pas de downtime applicatif (rolling).
• App Service Plan > Scale up.

Scale Out (horizontal)

• Ajouter / retirer des instances du plan (la même app tourne sur N VMs derrière un load balancer interne).
• Limites par tier :
  • Basic : 3 instances max (manual)
  • Standard : 10 (autoscale dispo)
  • Premium v3 : 30 (autoscale)
  • Isolated v2 : 100 (autoscale)
• App Service Plan > Scale out.

Autoscale (Standard+)

• Manual : nombre fixe d'instances.
• Custom autoscale : règles métriques (CPU, mémoire, HTTP queue, custom Application Insights metric).
  • Scale-out + Scale-in rules (avec cooldown).
  • Min / Max / Default instances.
  • Multiples profiles : par date/horaire (ex: weekend min=1, semaine min=4).
• Backend = Azure Monitor (mêmes mécanismes que les VMSS).

Auto-scale ≠ infinité d'instances — limité par le SKU + quotas sub.

G. Security

App Service Authentication ("Easy Auth")

• Auth gérée avant que la requête atteigne l'app (sidecar middleware).
• Providers supportés : Microsoft Entra ID, Microsoft account, Facebook, Google, X, Apple, OpenID Connect custom.
• 2 modes :
  • Require authentication : refuse l'accès anonyme → redirige vers le provider.
  • Allow unauthenticated : laisse passer + injecte les claims si auth.
• Plus rapide que coder l'auth dans l'app, fonctionne sans modif de code.

Managed Identity

• System-Assigned ou User-Assigned (voir fiche 1).
• Permet à l'app d'appeler d'autres services Azure (KV, Storage, SQL DB) sans secret.
• Utilisable pour résoudre les secrets Key Vault dans les App Settings.

TLS / SSL custom domains

• App Service Managed Certificate : gratuit, auto-renouvelé, pour custom domains. Limites : pas de wildcard (ou limité), pas de domaines apex sans CNAME.
• Bring your own cert : upload .pfx ou import depuis Key Vault.
• TLS minimum version configurable (TLS 1.2 par défaut, 1.3 dispo).
• HTTPS Only : redirige tout HTTP → HTTPS (à activer).

WAF

• Pas dans App Service directement → mettre Application Gateway WAF v2 ou Front Door WAF Premium devant l'app.
• Restreindre l'app à n'accepter que le trafic du WAF via Access restrictions (Service Tag AzureFrontDoor.Backend ou IPs de l'AppGW).

DEMO — chemins portail

Créer une Web App

1. App Services > Create > Web App
2. Choisir : runtime (Node, .NET, Python, Java, PHP) ou container, OS (Linux/Windows)
3. Plan : créer un nouveau ou réutiliser existant (mais même région, même OS)
4. SKU : ex S1 pour avoir slots
5. Onglet Deployment : configurer GitHub Actions direct (optionnel)
6. Onglet Networking : VNet Integration + Private Endpoint (option)

Deployment via Deployment Center

1. Web App > Deployment Center
2. Choisir source : GitHub / Azure Repos / Local Git / External Git / Container
3. Authoriser Azure → choisir repo + branche → save
4. Pipeline créé auto, build à chaque push

Deployment Slots

1. Web App > Deployment slots > Add Slot (nom : staging, dev…)
2. Cloner depuis le slot prod si besoin (settings + code)
3. Slot apparaît comme une "sub-app" → le déployer indépendamment via son propre Deployment Center
4. Swap : Deployment slots > Swap → choisir source/target → preview swap (vérif app settings) → confirmer
5. Slot settings sticky : Configuration > [setting] > Deployment slot setting checkbox

Custom domain + SSL

1. Custom domains > + Add custom domain → entrer le domaine
2. Azure donne les records DNS (CNAME / TXT / A) à ajouter chez le Registrar
3. Validate → domaine ajouté
4. Certificat : Certificates > + Create → App Service Managed Certificate (free) → bind au custom domain

VNet Integration

1. Web App > Networking > VNet integration > Add VNet
2. Choisir VNet + subnet dédié (vide, ou créer un nouveau subnet /27 minimum, délégué à Microsoft.Web/serverFarms)
3. App peut maintenant atteindre les ressources du VNet (DB privée, VM, etc.)

Private Endpoint

1. Web App > Networking > Private endpoints > + Add
2. Choisir VNet/subnet
3. Cocher "Integrate with private DNS zone" (zone privatelink.azurewebsites.net)
4. L'endpoint public peut être désactivé (Networking > Public access: Disabled)

Hybrid Connections

1. App > Networking > Hybrid connections > + Add (Standard+ requis)
2. Définir endpoint name, host:port cible, namespace Relay
3. Télécharger l'HCM (Hybrid Connection Manager) → installer sur le réseau cible (on-prem ou autre cloud)
4. HCM se connecte à Azure Relay en outbound 443 → tunnel établi

Autoscale

1. App Service Plan > Scale out > Custom autoscale
2. Default profile : min/max/default instances
3. Scale-out rule : ex CPU > 70% pendant 10min → +1 instance, cooldown 5min
4. Scale-in rule : ex CPU < 30% pendant 10min → -1 instance, cooldown 10min
5. Profile additionnel par horaire (weekend min=1, semaine min=4)

Easy Auth (Entra ID)

1. Web App > Authentication > + Add identity provider > Microsoft
2. Choisir : créer une nouvelle App Registration, ou utiliser existante
3. Choisir behavior si non auth : Require authentication ou Allow + inject claims
4. Save → app redirige vers login Entra à la prochaine visite anonyme

Managed Identity + Key Vault reference

1. Web App > Identity > System assigned > On
2. Donner à cette MI le rôle Key Vault Secrets User sur le KV cible
3. Dans Configuration > Application settings, ajouter :
   • Nom : MyDbPassword
   • Valeur : @Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/MyDbPassword/)
4. L'app récupère le secret au démarrage (refresh périodique)

🏢 Scenarios d'entreprise réels — pensée d'architecte

Comment ces services s'utilisent dans la vraie vie. Pour chaque scenario : contexte business → choix techniques (uniquement les services traités dans la fiche) → pièges typiques.

Scenario 1 : SaaS B2B multi-tenant (éditeur RH / facturation)

Contexte business : Éditeur SaaS RH, ~80 clients PME, déploiements hebdo, zero-downtime exigé (les RH ne tolèrent pas une coupure le matin du 1er du mois = jour de paie). Pic d'usage prévisible (fin de mois). Choix techniques : App Service Plan Premium v3 (P1v3 → P2v3), deployment slots (prod + staging + canary), autoscale schedule-based + metric-based, VNet Integration vers SQL Database privée, Managed Identity + Key Vault references. Architecture / pattern :

• 1 plan P1v3 par tenant-tier (Standard / Enterprise) — apps des Enterprise sur leur propre plan pour isolation perf
• 2 slots actifs : staging (déploiement + smoke tests) + prod. Swap manuel après validation QA
• 3e slot canary à 10% du traffic pendant 24h via traffic routing avant swap final (catch des bugs visibles uniquement sous charge réelle)
• App settings DB connection string marquée slot setting (sticky) → staging tape la DB de staging, jamais la prod après swap
• Autoscale : schedule "1er-5 du mois min=6", default min=2 ; metric "HTTP queue > 100 → +1 instance"
• VNet Integration vers SQL DB en Private Endpoint, public access SQL = Disabled
• Easy Auth Entra ID multi-tenant pour les clients M365 Pièges à éviter :
• Oublier de marquer la connection string DB comme slot setting → au swap, staging tape la prod live, désastre garanti
• Mettre N apps dans le même App Service Plan sans surveiller la RAM cumulée → un memory leak d'une app fait tomber les voisines (même process worker pool partagé)
• Slot swap sans pré-warm correct → première requête après swap = cold start visible client. Activer WEBSITE_SWAP_WARMUP_PING_PATH sur un endpoint de health
• Basic tier choisi pour économiser : pas de slots, pas d'autoscale. La promesse "zero-downtime deploy" devient mensongère.

Scenario 2 : Site corporate global + landing pages campagnes marketing

Contexte business : Grand groupe consumer (cosmétique, retail) veut un site institutionnel mondial + landing pages éphémères pour campagnes pubs (lancements produit, Black Friday). Pas de backend lourd, mais une API de formulaires (newsletters, contact). Choix techniques : Static Web Apps Standard pour le site + landing pages + APIs intégrées (Azure Functions Node), Easy Auth Entra ID pour la zone admin. Architecture / pattern :

• 1 SWA Standard par marque (groupe en a 5) avec custom domain SSL auto
• GitHub Actions auto-configurés à la création : push sur main = déploie en prod, push sur feature/* = preview environment unique (preview à chaque PR)
• API Functions dans le même repo (/api) → packagées et déployées avec le front (1 deploy = front + back cohérents)
• staticwebapp.config.json : routes, fallback SPA, header CSP, auth sur /admin/*
• CDN global natif (inclus dans SWA), bandwidth Standard tier 100 GB/mois inclus puis facturé Pièges à éviter :
• Free tier en prod → pas de SLA, pas de custom auth, limite 100 GB bandwidth/mois → un buzz et le site est down faute de quota. Standard mandatory.
• Confondre SWA et App Service : SWA = statique + Functions seulement, pas de backend Node/Python "server" classique. Si le besoin évolue vers du SSR lourd → App Service ou Container Apps.
• API Functions dans SWA = limité aux runtimes Functions supportés et timeout court. Pour un backend complexe → "Bring Your Own Functions" (BYOF, lier un Function App externe).
• Pas de Private Endpoint en Free → si la conformité interne l'exige, c'est Standard obligatoire.

Scenario 3 : ERP / app interne très sensible (banque privée, assurance vie)

Contexte business : Banque privée porte une app interne (gestion patrimoine clients) historiquement on-prem. PCI-DSS-like + secret bancaire. Aucun accès depuis Internet, audit annuel sur l'isolation réseau. Choix techniques : App Service Environment v3 (ASE) SKU Isolated v2, ILB (Internal Load Balancer), pas de public endpoint, VNet Integration vers backends, Access restrictions Service Tag/IP, Easy Auth Entra avec MFA + Conditional Access. Architecture / pattern :

• ASE v3 dans un VNet hub-and-spoke connecté à l'on-prem via ExpressRoute
• ILB ASE = l'app n'a aucun endpoint public, accessible uniquement via le VNet (employés via VPN/ExpressRoute, partenaires via Front Door Premium → Private Link → ASE)
• Slots Premium (20 dispos) pour staging + canary
• WAF en amont : Application Gateway WAF v2 dans le même VNet, ou Front Door Premium WAF
• App Service Auth Entra → enforce MFA via Conditional Access
• TLS 1.3 min, HTTPS only, App Service Managed Cert ou cert KV Pièges à éviter :
• Croire qu'ASE est "comme App Service mais sécurisé" → c'est cher (~1000$/mois fixe vide), pas adapté pour des charges légères. Pour <5 apps moyennes : Premium v3 + Private Endpoint suffit souvent
• Private Endpoint sur l'app production seulement : ⚠️ slots ne supportent pas Private Endpoint → le staging reste public si on n'utilise pas un ASE
• Ouvrir public access "temporairement pour tester" et oublier de refermer → faille d'audit majeure
• ASE = ressource régionale unique. Pour DR multi-region : 2 ASE actifs/passifs derrière Front Door, double facture

Scenario 4 : API publique forte volumétrie (marketplace, plateforme partenaires)

Contexte business : Marketplace e-commerce expose une API publique (catalogue, commandes) à 1000+ partenaires intégrateurs. Latence < 200ms p95, scale élastique selon les promos, plusieurs versions d'API en parallèle. Choix techniques : App Service Plan Premium v3 (P2v3 → P3v3), deployment slots par version d'API (v1, v2), autoscale metric sur HTTP queue + CPU, VNet Integration vers Cosmos DB privée, Hybrid Connections vers un legacy on-prem (système commandes). Architecture / pattern :

• 2 apps dans le même plan : api-prod (v2 active) + api-legacy (v1 maintenue pour partenaires non migrés)
• Slot staging sur api-prod pour les déploiements zero-downtime
• Autoscale : CPU > 65% sur 5min → +2 instances (cooldown 5min), CPU < 30% sur 15min → -1 instance (cooldown 10min). Plafond max=15 instances (P3v3 supporte 30, on garde une marge sub).
• Hybrid Connection vers le système commandes legacy (host:port 443) — pas de VPN à monter, juste l'HCM installé on-prem
• Access restrictions : Front Door Service Tag AzureFrontDoor.Backend + clé secrète header (l'app refuse tout trafic qui ne vient pas du Front Door WAF)
• Application Insights + diagnostic logging Blob (severity Warning → capture warnings + errors, pas verbose) Pièges à éviter :
• Autoscale agressif sans cooldown → "scale flapping" (in/out toutes les minutes), facture qui explose et perfs irrégulières
• Hybrid Connections pour du throughput massif → c'est un tunnel TCP via Relay, pas conçu pour des Gbps. Au-delà de quelques MB/s, prévoir VPN ou ExpressRoute.
• App Service Plan Basic pour tenir le pic Black Friday → max 3 instances, pas d'autoscale. Migrer en Standard/P-v3 avant, pas pendant.
• Logs en FileSystem uniquement → désactivés auto après 12h, on perd les traces post-incident. Toujours coupler Blob persistant.

Sources : Azure App Service Plans, Deployment slots, App Service Environment v3, Multi-region HA App Service