5 — App Integration Services

Faire communiquer des composants découplés → messaging (Queue Storage, Service Bus), eventing (Event Grid, Event Hub, IoT Hub), workflows (Logic Apps) et gestion d'API (APIM) : choisir selon commande vs notification, débit et ordre.

A. Messaging vs Eventing

Règle : "data flowing TO an action" → Messaging. "Notification OF an action" → Eventing.

B. Vocabulaire messaging — base

• Producer : envoie messages. Consumer : lit/traite.
• Compete consumer (queue) : 1 message = 1 consumer (N workers se partagent). Use case : load balancing tasks.
• Pub/Sub (topic) : 1 message = N consumers (chacun reçoit une copie). Use case : notifier plusieurs systèmes du même event.
• Topic = channel. Subscription = abonnement avec filtre. Chaque sub reçoit une copie filtrée.
• FIFO : ordre exact d'envoi. Sessions = FIFO par clé (orderId) → ordre strict par entité, parallèle entre entités.
• DLQ (Dead Letter Queue) : messages qui échouent N fois → atterrissent en DLQ pour inspection/replay.
• Transactions : envoyer/recevoir plusieurs messages atomiquement (tout ou rien).
• At-least-once : message arrive au moins 1 fois (peut arriver 2-3× en cas de retry). → Idempotence côté consumer obligatoire.
• Duplicate detection (Service Bus) : broker rejette doublons via MessageId dans une fenêtre.
• Load leveling : queue absorbe pics (5k/s in → 100/s out → 0 crash).
• Décorrélation : producer/consumer pas besoin d'être up en même temps.
• Buffer async : tier web rend la main <200ms, queue + worker fait le job long en background.

C. Azure Queue Storage

🎯 Présentation

Messaging simple intégré au Storage Account, compete consumer pattern. Solution low-cost pour découpler producer/consumer sans features enterprise.

🏗️ Architecture

• Queue hébergée dans un Storage Account (pas de namespace séparé)
• Compete consumer : 1 message = 1 consumer (N workers se partagent la charge)
• Accès via REST API ou SDK Azure Storage
• Pas de topics/subscriptions — file unique

🎚️ Tiers / SKU

✅ Quand l'utiliser

• Buffer simple (resize images, archive logs)
• Load leveling pour pic (Black Friday checkout)
• Notifications email différées
• Queue jobs longue durée (rapports CSV)

🚨 Pièges

• Pas de FIFO strict garanti → si requis, basculer Service Bus + sessions
• Pas de DLQ native → gestion erreurs côté code consumer
• Pas de pub/sub ni de filtres broker-side → topic = Service Bus
• Pas de duplicate detection → consumer doit être idempotent (at-least-once)
• Limite message 64 KB : payload plus gros → stocker en Blob + envoyer référence

D. Azure Service Bus

🎯 Présentation

Enterprise messaging broker avec FIFO, sessions, transactions, pub/sub, DLQ natif. Cœur des architectures messaging fiables Azure.

🏗️ Architecture

• Namespace : container régional (Basic / Standard / Premium)
• Queue : FIFO compete consumer
• Topic : pub/sub vers N subscriptions
• Subscription : filtre (SQL/Correlation/Boolean) + endpoint
• DLQ : messages morts (auto par sub/queue)

🎚️ Tiers / SKU

✅ Quand l'utiliser

• Besoin de FIFO strict (sessions par clé : orderId)
• Transactions atomiques (pop + push multi-queues)
• DLQ native + replay admin
• Pub/Sub avec filtres broker-side (SQL/Correlation)
• Scheduled messages, auto-forwarding, duplicate detection

Features clés (cas concret)

🚨 Pièges

• Basic = pas de topics → migration douloureuse si besoin pub/sub plus tard
• Geo-DR Premium : réplique structure (queues/subs/filters) mais PAS les messages en attente
• Throughput limité pour streaming massif → Event Hub si > ~1M msg/s
• Sessions = FIFO par clé, pas global → bien choisir la session key
• Transactions limitées à un namespace (pas cross-namespace)
• 🚨 Sessions vs Partitioning (Premium) : Sessions = FIFO strict par sessionId (ex: OrderCreated > Paid > Shipped ordonné par orderId). Partitioning = juste sharding pour throughput, AUCUNE garantie FIFO. "Ordre garanti par entité" → Sessions (pas Partitioning). Les 2 peuvent coexister mais le FIFO vient uniquement de Sessions.

E. Azure Event Grid

🎯 Présentation

Service eventing pub/sub pour events discrets (state changes) avec latence ms. Réagir aux changements (Azure resources, apps custom, partenaires SaaS) sans poller.

🏗️ Architecture

• Event source : Storage, Resource Mgr, IoT Hub, custom, partner SaaS
• Topic : channel
• Event : payload <1 MB
• Event handler : Functions, Logic Apps, Webhook, Event Hub, Queue, Service Bus
• Event filter : subject, type, advanced filter
• At-least-once (retries exponentiels 24h), DLQ sur Storage Account
• Push (default) ou Pull (Namespace mode)

🎚️ Tiers / SKU (Modes)

✅ Quand l'utiliser

• Réagir à un changement Azure (blob uploaded, RG deleted) → System Topics
• App émet ses propres events vers N consommateurs → Custom Topics
• SaaS multi-tenant avec ~10k+ clients à notifier → Domains
• IoT MQTT broker managé / pull delivery → Namespaces

🚨 Pièges

• Payload limit 1 MB → gros volumes data = Event Hub, pas Event Grid
• Pas de filter SQL avancé broker-side (subject/type only, ou advanced filter) — pour SQL filter complet → Service Bus Topic
• At-least-once → handler doit être idempotent
• DLQ doit être configuré explicitement (Storage Account) sinon events perdus après 24h retries
• Push delivery → endpoint cible doit être public OU dans VNet (Premium)

F. Azure Event Hubs

🎯 Présentation

Plateforme de streaming massif (millions events/sec) pour telemetry, logs, IoT, click-stream. Équivalent Kafka managé sur Azure.

🏗️ Architecture

• Namespace : container régional
• Event Hub : équivalent Kafka topic
• Partitions : 1-32 Standard, 100 par event hub Premium (200/PU au namespace), 1024 Dedicated (parallel consumption)
• Consumer group : vue indépendante du stream (1 = 1 reader avec curseur)
• TU/PU/CU : capacity units (Standard/Premium/Dedicated)
• Capture auto-archive vers Blob/ADLS (Avro/Parquet)
• Schema Registry, Kafka protocol compat, Geo-DR async

🎚️ Tiers / SKU

✅ Quand l'utiliser

• Streaming big data : telemetry IoT, logs apps, click-stream
• Kafka workloads sur Azure sans gérer cluster (Standard min)
• Ingest pour Stream Analytics / Synapse / Databricks
• VNet integration → Premium min

• 10 GB/s soutenu ou HSM-grade isolation → Dedicated

🚨 Pièges

• Basic : 1 consumer group seulement → impossible d'avoir plusieurs apps consommatrices
• Partition count immuable après création (Standard) → choisir large dès le début
• Pas de pub/sub broker-side filter → filtering côté consumer
• Retention Standard max 7j → archivage long terme = Capture vers Blob/ADLS
• Sur-dimensionné pour faible volume (100 msg/j) → préférer Service Bus

G. Azure IoT Hub

G.1 C'est quoi

Service managé pour devices IoT avec communication bidirectionnelle (devices ↔ cloud). C'est l'équivalent IoT-spécifique d'Event Hub mais avec des features devices natives.

G.2 IoT Hub vs Event Hub (le seul piège 305)

🎯 "Devices doivent recevoir des commandes / updates de config" → IoT Hub. 🎯 "Telemetry massive unidirectionnelle → analytics" → Event Hub.

H. SignalR Service + Notification Hubs (light awareness)

H.1 Azure SignalR Service

Service managé pour real-time bidirectional (WebSocket / Server-Sent Events / Long Polling) sans gérer scale ni connection management.

Use cases AZ-305 :

• Chat temps-réel multi-utilisateurs
• Live dashboards (Power BI live tile)
• Notifications push web (push-to-browser)
• Collaborative apps (Google Docs-like)
• Live sports / trading scoreboard

H.2 Azure Notification Hubs

Service push notifications mobiles cross-platform : iOS (APNS), Android (FCM), Windows, Amazon Kindle, Baidu (China).

Use cases AZ-305 :

• Push notifs mobile à des millions d'users
• Targeting par tags (geo, user segment, language)
• Schedule notifs
• Multi-platform unified API

H.3 Decision rapide

• "Real-time browser, chat, dashboard" → SignalR Service
• "Push notifs mobile iOS+Android" → Notification Hubs
• "Devices IoT bidirectionnels" → IoT Hub

I. Decision Messaging/Eventing/Streaming

Comparaison rapide

Anti-patterns

J. Azure API Management (APIM)

🎯 Présentation

Gateway façade managée centralisant security, throttling, transformation, analytics, doc OpenAPI sur N backends. Évite la duplication auth/rate-limit dans chaque microservice.

🏗️ Architecture

• API : interface logique (REST/SOAP/GraphQL/WebSocket)
• Backend : où tape l'API (App Service, Function, AKS, FQDN)
• Product : bundle d'APIs avec subscription key
• Policies : XML transformations in/out flow (validate-jwt, rate-limit, cache, transform, circuit-breaker)
• Developer portal : self-service devs (OpenAPI auto)

[Clients] → [APIM Gateway] (auth/throttle/cache/log) → [Microservices privés via PE]

🎚️ Tiers / SKU (v2, 2026)

✅ Quand l'utiliser

• ≥ 2 backends exposés + besoin auth/rate-limit/monitoring centralisé
• 1 DNS/cert SSL pour N microservices, versioning d'APIs
• Mock-response (frontend dev avant backend ready)
• Backends privés via Private Endpoint + zero-trust
• Compliance VNet/AZ → Premium v2 (multi-région active-active → Premium classique v1 uniquement)

Policies clés

• Auth : validate-jwt, validate-azure-ad-token, OAuth2, mTLS
• Rate limit / quota : rate-limit-by-key, quota-by-key
• CORS / IP filter, Mock response
• Caching : cache-lookup / cache-store
• Transform : set-header, set-body, xml-to-json
• Backend : set-backend-service, circuit-breaker

🚨 Pièges

• v1 tiers (Basic/Standard/Premium classic) à éviter pour nouveaux déploiements 2026 → v2 tiers
• Consumption : pas de VNet, pas de cache, cold start → pas pour prod critique
• Developer : aucun SLA → jamais en prod
• Multi-region (active-active) = Premium classique v1 uniquement (indisponible dans les tiers v2 à ce jour) → seule exception à la règle « éviter les v1 »
• Sur-dimensionné pour 1 seul backend → préférer App Gateway L7 si pas besoin de policies APIM
• VNet injection Premium uniquement (vs PE inbound = Standard v2)

K. Azure Logic Apps

🎯 Présentation

Workflow orchestration low-code visual avec 1000+ connectors (M365, SAP, Salesforce). Automatise les processus métier sans écrire de code.

🏗️ Architecture

• Trigger : HTTP, Schedule, Event Grid, Service Bus, connector SaaS
• Actions : call API, transform, send mail, Function, conditional, loop
• Connectors : built-in (HTTP) ou Managed (1000+ : M365, SAP, Salesforce, ServiceNow)
• Designer visuel + JSON workflow (code-behind)
• Run history pour debug

🎚️ Tiers / SKU

✅ Quand l'utiliser

• Workflow low-code, intégrations SaaS (M365, SAP, Salesforce)
• Collab business owner ↔ IT (designer visuel)
• Schedule-based jobs avec connectors prêts à l'emploi
• Standard si VNet integration / perf max / multi-workflow par plan
• Pour orchestration code-first complexe haute perf → Durable Functions plutôt

Logic Apps vs Functions vs Power Automate

Logic Apps vs Durable Functions

Accès hybride on-prem (awareness) : Data Gateway vs Azure Relay

Deux façons pour un service cloud d'atteindre une ressource on-prem sans l'exposer à Internet (les 2 = agent on-prem en outbound only 443, zéro port entrant, ≈ logique App Proxy) :

• On-premises Data Gateway : pont haut niveau orienté DONNÉES pour Logic Apps + Power Platform (Power BI / Power Apps / Power Automate) + Azure Analysis Services. On l'utilise via un connecteur (SQL Server, File System, SharePoint on-prem…) ; il stocke les credentials chiffrés, gère N sources, HA par cluster de gateways. (Sous le capot, il s'appuie sur Azure Relay/Service Bus.)
• Azure Relay — Hybrid Connections : relais bas niveau générique qui expose UN endpoint TCP host:port on-prem à une app cloud. Utilisé par App Service / Functions (Hybrid Connections via le Hybrid Connection Manager) ou des apps custom. Pas lié aux connecteurs, n'importe quel protocole TCP.

🎯 Mémo 305 : "Logic App / Power BI lit une DB on-prem sans accès Internet" → On-premises Data Gateway. "App Service doit joindre 1 endpoint host:port on-prem sans VPN" → Hybrid Connections (Azure Relay). Pas d'exposition d'un LAN entier → sinon c'est du VPN/ExpressRoute (fiche 7).

L. Patterns AZ-305

Producer-Consumer (Buffer)

[Producer] → [Queue/Service Bus] → [Worker (Function/VMSS)]

Pub/Sub (Fan-out)

[Event source] → [Service Bus Topic OR Event Grid] → [N Subscribers]

Streaming Analytics

[Devices] → [Event Hub] → [Stream Analytics / Databricks] → [Power BI / SQL]

IoT bidirectionnel

[Devices IoT] ←→ [IoT Hub Standard] ←→ [Backend + Device Twin sync]
                       ↓ message routing
                  [Event Hub / Service Bus / Storage]

API Façade

[Clients] → [APIM] → [Microservices (App Service / AKS / Functions)]

Workflow Orchestration

[Trigger] → [Logic App] → actions (parallel/sequential, branches, loops)

M. Azure Cache for Redis & Azure Managed Redis (caching)

🎯 Présentation

Cache distribué in-memory managé pour sessions multi-instance, accélération DB, rate limiting, distributed lock.

🏗️ Architecture

• Cache key-value in-memory (sub-ms latency)
• Patterns : session store, output cache, data cache, pub/sub léger, rate limiting, distributed lock
• Accès via Redis protocol (SDK StackExchange.Redis, lettuce, etc.)
• Azure Managed Redis = remplaçant moderne (zone redundancy + persistence + modules + active geo-rep par défaut, 1 DB seulement, TLS XOR non-TLS)

⚠️ Retrait Cache for Redis 2026-2028 (annonce oct 2025)

Azure Cache for Redis retire tous SKUs. Remplaçant : Azure Managed Redis.

• 1 avril 2026 : new caches bloquées (Enterprise/Flash all, Basic/Std/Prem new customers)
• 31 mars 2027 : Enterprise/Flash migrés
• 1 oct 2028 : Basic/Std/Prem éteints

Nouveaux projets 2026+ → Azure Managed Redis

🎚️ Tiers / SKU

Cache for Redis (legacy) — 5 tiers :

Azure Managed Redis — différences clés : Zone redundancy by default, persistence + modules sur tous SKUs, active geo-rep native, TLS XOR non-TLS, 1 DB seulement (db 0), pas de Failover command (app gère switching).

🚨 Pièges

• Basic en prod → pas de SLA, data perdue si panne
• Geo-rep passive (Premium classique) = read-only secondary → app gère failover manuel. Active = Enterprise / Managed Redis only.
• Managed Redis : 1 DB only → refactor si app utilise multi-DB Redis
• Migration Cache→Managed : TLS mode (XOR) et multi-DB à vérifier

🌐 Caching DONNÉES (Redis) vs caching CONTENU (CDN/Front Door)

💡 Le caching AZ-305 a 2 familles : Redis = cache de DONNÉES (sessions, résultats DB, in-memory) ; CDN/Front Door = cache de CONTENU (fichiers statiques, images, JS/CSS) au bord du réseau (edge), proche des users.

🎯 Réflexes : "sessions/données backend" → Redis · "contenu statique users mondiaux" → Front Door / CDN · "front global app + WAF + cache" → Front Door (fiche 6).

N. Azure App Configuration (centralized config + feature flags)

🎯 Présentation

Service managé pour centraliser config (key-values), feature flags, et références Key Vault. Élimine la config éparpillée multi-services/multi-env qui force des redéploiements.

🏗️ Architecture

• Key-value pairs avec labels env (dev/prod), hiérarchie via préfixes
• Feature flags (UI Feature Manager : % rollout, targeting groups, time windows)
• Key Vault references : secrets dans KV, référencés depuis App Config — app code lit 1 endpoint unique
• Snapshots & point-in-time (replay 7j), soft-delete (Standard+), refresh dynamique (default 30s TTL)
• Auth recommandée : Managed Identity + rôle App Configuration Data Reader

🎚️ Tiers / SKU

✅ Quand l'utiliser

• Microservices K8s : 1 App Config partagé, pas de config baker dans image
• Multi-env : labels dev/staging/prod, 1 store N envs
• A/B testing & canary : feature flag avec % filter
• Compliance kill-switch : disable feature instantanément sans redéploiement
• Combo recommandé : secrets → KV, config + feature flags → App Config (référence KV)

App Config vs Key Vault

Règle d'or : Secrets → KV. Config + feature flags → App Config. KV référencé depuis App Config (1 endpoint côté app).

🚨 Pièges

• Stocker secrets directement dans App Config → ❌ utiliser KV references
• Cache TTL SDK trop élevé → feature flag pas vu pendant 30 min
• Tier Free pas de soft-delete → store supprimé = définitif
• Pas de Private Endpoint compliance régulée → audit fail → Premium
• Pas de versionning native fin → utiliser snapshots + IaC pour traçabilité

O. Scénarios 305 → solution

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

Scénario 1 : Retail e-commerce — Découplage commandes event-driven Black Friday

Contexte business : E-commerce, pics x20 en Black Friday. Le checkout sature car il appelle l'inventaire, la facturation et la logistique de façon synchrone. Exigences : ne jamais perdre une commande, garder l'ordre par commande (OrderCreated → Paid → Shipped), et notifier 3 systèmes en parallèle. Choix architectural : Service Bus Premium (Topic + 3 subscriptions) avec sessions (sessionId = orderId) pour l'ordre par commande, duplicate detection et DLQ natives. → découple le checkout des 3 backends et absorbe les pics. Architecture / pattern :

• Le checkout publie sur le Topic → la file absorbe les pics (load leveling).
• Sessions = FIFO par orderId, en parallèle entre commandes différentes.
• Filtres SQL par subscription → fan-out côté broker vers inventory/billing/shipping.
• Workers idempotents ; DLQ inspectée + replay par l'admin. Trade-offs assumés :
• Gain : ordre garanti par commande + résilience (DLQ, dédup) + découplage.
• Perte : Premium = coût fixe > Standard ; une session = 1 seul receiver actif à la fois. Pièges à éviter :
• Confondre Sessions (FIFO par clé) et Partitioning (juste du throughput, aucun ordre) : seules les sessions garantissent le FIFO.
• Croire que la Geo-DR Premium réplique les messages en attente : elle ne réplique que la structure (queues/topics/filtres).
• Oublier l'idempotence : at-least-once → un message peut arriver 2-3×. 📐 Réf. WAF — Architecture best practices for Azure Service Bus (Reliability) : activer DLQ sur toutes les entités de prod, multiples receivers concurrents, alertes Azure Monitor sur dead-letter count et throttling ; choisir le tier avec marge (Premium pour gros payloads / débit prévisible). Lien

Scénario 2 : IoT industriel — Streaming télémétrie capteurs vers analytics temps réel

Contexte business : Usine connectée, 50 000 capteurs, ~1M events/s de télémétrie (sens unique). Besoin : ingérer ce flux massif, pouvoir le rejouer (ré-entraînement ML), et le consommer en même temps par 3 équipes (anomalie, dashboard, archivage conformité). Choix architectural : Event Hubs Standard (auto-inflate), partitions dimensionnées dès la création, 3+ consumer groups (1 par équipe), Capture auto vers ADLS pour l'archivage > 7j. Architecture / pattern :

• Producteurs → Event Hub (clé de partition = deviceId) → ordre par partition.
• 3 consumer groups indépendants : Stream Analytics (anomalie), Databricks (dashboard), Capture (archivage).
• Log durable : chaque consumer a son curseur → replay possible. Trade-offs assumés :
• Gain : débit massif + replay + plusieurs consommateurs indépendants.
• Perte : pas de filtrage côté broker (filtrer côté consumer) ; rétention Standard plafonnée à 7j (d'où Capture). Pièges à éviter :
• Nombre de partitions figé en Standard : sous-dimensionner bloque le parallélisme → voir large dès le départ.
• Event Hubs Basic = 1 seul consumer group → impossible d'avoir 3 équipes.
• Vouloir envoyer des commandes aux capteurs : Event Hubs est unidirectionnel. Pour le bidirectionnel → IoT Hub. 📐 Réf. WAF — Architecture best practices for Azure Event Hubs (Performance Efficiency) : Standard supporte jusqu'à 32 partitions et 1-7j de retention ; activer auto-inflate avec plafond TU, clés de partition hash-based pour éviter les hotspots, Capture vers Cool/Archive pour le long terme. Lien

Scénario 3 : Services financiers — API Gateway zero-trust multi-backends

Contexte business : Banque exposant 25 microservices (App Service, AKS, Functions) à des partenaires et apps mobiles. Exigences : auth centralisée (JWT/Entra), rate-limiting par client, backends 100% privés (zero-trust), zones de dispo, conformité. Choix architectural : API Management Standard v2 (private endpoint entrant + VNet integration vers backends privés). Isolation réseau complète + AZ → Premium v2. Multi-région active-active → Premium classique (v1) seulement. Architecture / pattern :

• Clients → APIM (validate-jwt, rate-limit-by-key, cache, transform) → backends via Private Endpoint.
• Standard v2 : entrée privée + sortie VNet = isolation de bout en bout.
• Policies XML mutualisées (auth/throttle/transform) au lieu d'être dupliquées dans chaque microservice. Trade-offs assumés :
• Gain : 1 point d'auth/rate-limit/observabilité pour N backends + isolation réseau + portail dev.
• Perte : sur-dimensionné pour 1 seul backend (préférer App Gateway L7) ; Premium v2 = coût + subnet dédié. Pièges à éviter :
• Croire que Basic v2 a la VNet integration : faux, ça commence à Standard v2.
• Choisir Premium v2 en croyant avoir le multi-région active-active : indisponible en v2 → c'est Premium classique (v1).
• Consumption (pas de VNet, cold start) ou Developer (aucun SLA) en prod critique. 📐 Réf. WAF — Architecture best practices for Azure API Management (Reliability) : les fonctionnalités de redondance (AZ, units multiples, multi-région, workspaces) sont en Premium classique ; Premium v2 les supporte toutes SAUF le multi-région ; le tier Developer (sans SLA) n'est pas adapté à la prod. Lien

DEMO

Demo Portail — Service Bus Topic + Subs (e-commerce)

1. Service Bus > Create → RG rg-shop, Namespace sb-shop-prod, Tier Standard → Review + Create
2. sb-shop-prod > Topics > + Topic :
   • Name : orders-events
   • Enable duplicate detection : ON
   • Duplicate detection history : 10 min
   • Create
3. Pour chaque sub (inventory, billing, shipping) : orders-events > Subscriptions > + Subscription → Max delivery count 5
4. Filter SQL sur inventory : sélectionner sub → Default rule → Filter type SQL → expression eventType = 'OrderPlaced' → Save

CLI équivalent (pour IaC) :

az servicebus topic create -g rg-shop --namespace-name sb-shop-prod -n orders-events \
  --enable-duplicate-detection true --duplicate-detection-history-time-window PT10M
az servicebus topic subscription rule create -g rg-shop --namespace-name sb-shop-prod \
  --topic-name orders-events --subscription-name inventory \
  --name OrderPlacedFilter --filter-sql-expression "eventType = 'OrderPlaced'"

Demo Portail — Event Grid Storage Blob → Function

1. Storage accounts > sashoploads > Events > + Event Subscription
2. Name : csv-uploaded-trigger, Event Schema : Event Grid Schema
3. Event Types : cocher uniquement Blob Created
4. Endpoint Type : Azure Function → sélectionner func-csv-parser > ParseCsv
5. Onglet Filters :
   • Subject Begins With : /blobServices/default/containers/uploads/
   • Subject Ends With : .csv
6. Onglet Additional Features : Max delivery attempts 30, Dead-letter Storage (optionnel)
7. Create

CLI équivalent (pour IaC) :

az eventgrid event-subscription create --name csv-uploaded-trigger \
  --source-resource-id $(az storage account show -g myrg -n sashoploads --query id -o tsv) \
  --endpoint-type azurefunction --endpoint $FUNC_ID \
  --included-event-types Microsoft.Storage.BlobCreated \
  --subject-begins-with "/blobServices/default/containers/uploads/" --subject-ends-with ".csv"

Demo Portail — Event Hub + Capture

1. Event Hubs > Create namespace → RG myrg, Namespace myns, Tier Standard, TU 1 → Review + Create
2. myns > + Event Hub :
   • Name : myhub
   • Partition Count : 4, Message Retention : 7j
   • Section Capture : ON → Time 300s, Size 300 MB, Storage mystorage, container mycontainer, format Avro
   • Create

CLI équivalent (pour IaC) :

az eventhubs eventhub update -g myrg --namespace-name myns -n myhub \
  --enable-capture true --capture-interval 300 --capture-size-limit 314572800 \
  --destination-name EventHubArchive.AzureBlockBlob \
  --storage-account /subscriptions/.../mystorage --blob-container mycontainer

📚 DEMO IoT Hub + DPS détaillée = AZ-220 (IoT Specialty), pas AZ-305.

APIM Premium v2 — policy validate-jwt + rate-limit

<inbound>
  <validate-jwt header-name="Authorization" failed-validation-httpcode="401">
    <openid-config url="https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration" />
  </validate-jwt>
  <rate-limit-by-key calls="100" renewal-period="60" counter-key="@(context.Subscription.Id)" />
</inbound>

Logic App Standard

1. Logic Apps > Create > Plan = Standard (single-tenant, VNet) ou Consumption (pay-per-exec)
2. Storage Account requis (Standard), Plan WS1/WS2/WS3, VNet injection optionnelle
3. Workflows > + Add : Stateful (durable, history) ou Stateless (latence basse)
4. Designer : Trigger + Actions
5. Run history pour debug

Demo Portal — Azure Managed Redis + Private Endpoint

1. Create resource > Azure Managed Redis
2. Basics : Name, region, Cache type (Balanced/Memory Optimized/Compute Optimized/Flash Optimized)
3. Cache size selon besoin
4. Networking : Private Endpoint + Private DNS zone privatelink.redis.azure.net
5. Advanced : TLS port (TLS XOR non-TLS), Clustering policy OSS ou Enterprise, Modules optionnels
6. High availability : Enabled (zone-redundant par défaut si région supporte AZ)
7. Review + Create → Auth via Entra ID (recommandé) ou Access keys

Demo Portal — App Config + KV reference

1. Create resource > App Configuration
2. Basics : Name, region, Pricing tier : Standard
3. Networking : Private Endpoint si compliance
4. Encryption : Microsoft-managed (default) ou CMK
5. Review + Create
6. Configuration explorer > + Create > Key-value pour ajouter clés
7. Feature manager > + Create > Feature flag : EnableNewCheckout, Enable ON/OFF, ajouter Feature filter (Targeting/Percentage/Time)
8. Key Vault reference : Configuration explorer > + Create > Key vault reference → Key + Subscription/KV/Secret
9. Access control (IAM) : rôle App Configuration Data Reader à la MI de l'app