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).

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

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

Contexte business : Un éditeur SaaS RH sert ~80 PME et déploie chaque semaine. Aucune coupure tolérée (le 1er du mois = jour de paie). Le trafic monte de façon prévisible en fin de mois. Choix architectural : un plan App Service Premium v3 (pour avoir les slots et l'autoscale), des deployment slots (prod + staging + canary) pour déployer sans coupure, et un autoscale mi-planifié mi-réactif. Base SQL jointe en privé via VNet Integration. Architecture / pattern :

• 1 plan par catégorie de client (Standard / Enterprise), les Enterprise isolés sur leur propre plan.
• 2 slots actifs : staging (tests) et prod, avec swap manuel après validation QA.
• Un 3e slot canary reçoit 10% du trafic 24h avant le swap final (détecte les bugs qui n'apparaissent que sous vraie charge).
• La connection string de la base est marquée slot setting (sticky) → staging ne tape jamais la base de prod après swap.
• Autoscale : "min 6 du 1er au 5", sinon min 2 ; +1 instance si la file HTTP dépasse 100.
• SQL en Private Endpoint, accès public désactivé. Secrets via Managed Identity + Key Vault. Trade-offs assumés :
• Gain : déploiements sans coupure et montée en charge automatique.
• Perte : Premium v3 coûte plus que Basic, et mutualiser des apps demande de surveiller la RAM. Pièges à éviter :
• Oublier de marquer la connection string en slot setting → au swap, staging tape la prod en live. Désastre.
• Empiler des apps dans un même plan sans surveiller la RAM → une fuite mémoire d'une app fait tomber les voisines.
• Swap sans pré-chauffage → 1re requête = cold start visible. Activer WEBSITE_SWAP_WARMUP_PING_PATH.
• Choisir Basic pour économiser : pas de slots, pas d'autoscale → la promesse "zéro coupure" devient fausse.

📐 Réf. WAF — Operational excellence (safe deployment) & App Service landing zone : les deployment slots + swap pré-warmé + traffic routing canary sont les pratiques Well-Architected de déploiement sûr et zero-downtime sur App Service. Lien

Scenario 2 : Site corporate global + landing pages campagnes marketing

Contexte business : Un grand groupe consumer veut un site institutionnel mondial + des landing pages éphémères pour ses campagnes (lancements, Black Friday). Pas de gros backend, juste une petite API de formulaires (newsletter, contact). Choix architectural : Static Web Apps Standard — pensé pour les sites statiques/SPA, avec CI/CD GitHub natif, CDN global inclus et petites API serverless (Azure Functions) intégrées. Architecture / pattern :

• 1 SWA Standard par marque (5 marques), custom domain et SSL automatiques.
• GitHub Actions configurés à la création : push sur main = prod, chaque PR = un environnement de preview dédié.
• L'API Functions vit dans le même repo (/api) → front et back déployés ensemble, toujours cohérents.
• staticwebapp.config.json gère les routes, le fallback SPA, le CSP et l'auth sur /admin/*.
• CDN global inclus, 100 GB/mois de bande passante inclus puis facturé. Trade-offs assumés :
• Gain : déploiement simple, CDN mondial et previews par PR sans infra à gérer.
• Perte : limité au statique + Functions, pas de vrai backend serveur ni de gros SSR. Pièges à éviter :
• Free tier en prod → pas de SLA, pas de custom auth, plafond 100 GB → un buzz et le site tombe. Standard obligatoire.
• Confondre SWA et App Service : SWA = statique + Functions, pas de backend Node/Python serveur. Pour du SSR lourd → App Service ou Container Apps.
• L'API Functions intégrée a des runtimes et timeouts limités → pour un backend complexe, lier un Function App externe (BYOF).
• Pas de Private Endpoint en Free → si la conformité l'exige, Standard obligatoire.

📐 Réf. — Azure Static Web Apps (jamstack) & WAF : SWA (CDN global, CI/CD GitHub natif, API serverless intégrée, preview par PR) est le service recommandé pour les sites statiques et SPA avec backend léger. Lien

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

Contexte business : Une banque privée migre une app interne (gestion de patrimoine) depuis l'on-prem. Secret bancaire, aucun accès Internet, audit annuel sur l'isolation réseau. Choix architectural : un App Service Environment v3 (ASE) avec Internal Load Balancer (ILB) → l'app n'a aucun endpoint public et n'est joignable que depuis le réseau privé. Authentification Entra avec MFA. Architecture / pattern :

• ASE v3 dans un VNet hub-and-spoke relié à l'on-prem par ExpressRoute.
• ILB = zéro endpoint public : employés via VPN/ExpressRoute, partenaires via Front Door Premium → Private Link.
• Slots Premium pour staging + canary.
• Un WAF en amont (App Gateway WAF v2 ou Front Door Premium WAF).
• Auth Entra avec MFA imposé par Conditional Access ; TLS 1.3, HTTPS only. Trade-offs assumés :
• Gain : isolation réseau totale, exigée par la conformité.
• Perte : l'ASE coûte cher en fixe (~1000$/mois même à vide), surdimensionné pour peu d'apps. Pièges à éviter :
• Croire que l'ASE est "App Service en plus sécurisé" : il est cher. Pour <5 apps moyennes, Premium v3 + Private Endpoint suffit souvent.
• Private Endpoint sur la prod uniquement : ⚠️ les slots ne supportent pas Private Endpoint → le staging reste public sauf en ASE.
• Ouvrir l'accès public "juste pour tester" et oublier de refermer → faille d'audit majeure.
• L'ASE est régional : pour du DR multi-région, il en faut 2 (actif/passif) derrière Front Door → double facture.

📐 Réf. — App Service Environment landing zone accelerator (WAF) : pour les workloads internes hautement réglementés, l'ASE v3 + ILB (zéro endpoint public) dans un VNet hub-spoke + WAF en amont est l'architecture de référence. Lien

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)