Microsoft AZ-305: Haute disponibilité, reprise après sinistre et continuité des activités — Guide d'étude

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Fait partie du Microsoft Azure Solutions Architect Expert AZ-305 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Microsoft, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La haute disponibilité (HA), la reprise après sinistre (DR) et la continuité d’activité (BC) dans Azure nécessitent une conception délibérée à travers les couches de calcul, de données et de réseau. La résilience commence par des objectifs clairs de temps de récupération (RTO) et de point de récupération (RPO), puis combine les capacités de la plateforme — Availability Zones, routage mondial, réplication des données, sauvegarde et orchestration du basculement — en une stratégie testée et automatisée. Azure fournit une isolation des pannes par zone et par région, une distribution mondiale basée sur le DNS et l’anycast, une durabilité des données multirégionale et une sauvegarde/restauration pilotée par des politiques pour atteindre des objectifs stricts tout en maîtrisant les coûts et la complexité opérationnelle.

Architecture pilotée par RTO/RPO et résilience zonale/mondiale

La conception commence avec le RTO et le RPO. Le RTO dicte la rapidité avec laquelle le service doit reprendre après une panne ; le RPO dicte la perte de données maximale acceptable. Atteindre un RTO faible nécessite un basculement automatisé et une capacité pré-provisionnée ; atteindre un RPO faible nécessite une réplication synchrone ou quasi-synchrone et des points de récupération cohérents et fréquents.

Les Availability Zones sont des domaines de panne de centres de données indépendants au sein d’une région. Les services zonaux (par exemple, les Virtual Machines, les disques managés, les adresses IP publiques Standard) sont rattachés à une seule zone. Les services redondants interzones (par exemple, les frontends redondants interzones d’Azure Load Balancer Standard, les offres de stockage redondant interzone et les niveaux redondants interzones d’Azure SQL) s’étendent automatiquement sur plusieurs zones. Un modèle résilient typique déploie des VM zonales dans au moins deux zones, les place dans un seul réseau virtuel et expose un frontal d’équilibrage de charge redondant interzone. Cela élimine la défaillance d’une seule zone comme cause d’interruption de service.

À la périphérie mondiale (global edge), choisissez entre une distribution de charge basée sur le DNS et une distribution par proxy anycast :

Azure Traffic Manager est basé sur le DNS. Il dirige les clients vers des points de terminaison en utilisant des méthodes de routage : Performance (latence la plus faible), Pondéré (tests A/B et transferts de trafic progressifs), Priorité (basculement actif/passif), Géographique (servir les utilisateurs depuis des points de terminaison conformes au niveau régional), MultiValue (retourne plusieurs enregistrements IPv4/IPv6 sains pour les clients simples) et Subnet (mapper des plages d’adresses IP de clients à des points de terminaison spécifiques). Comme il est basé sur le DNS, Traffic Manager n’accélère pas le contenu et ne sert pas de proxy pour le trafic ; les clients se connectent directement au point de terminaison choisi et respectent le comportement de mise en cache DNS local.
Azure Front Door (Standard/Premium) est un proxy inverse HTTP/HTTPS anycast mondial avec routage intelligent, déchargement TLS et un pare-feu d’applications web (WAF) intégré. Les règles de routage effectuent une correspondance sur le domaine, le chemin, la méthode et les en-têtes, puis acheminent le trafic vers des groupes d’origines ; les actions du moteur de règles peuvent réécrire les URL/en-têtes et forcer des redirections. Les sondes d’intégrité (health probes) évaluent en continu l’état des origines sur un chemin et un protocole configurables ; les origines défaillantes sont retirées de la rotation. Les groupes d’origines prennent en charge la distribution par priorité (actif/passif) et pondérée entre les régions. Les politiques WAF s’attachent au point de terminaison ou à la route, avec des ensembles de règles managées, des règles personnalisées et une limitation de débit pour atténuer les menaces OWASP et les clients abusifs. Utilisez Front Door lorsque vous avez besoin d’un équilibrage de charge mondial avec accélération, sécurité en périphérie et basculement sensible à l’application ; combinez-le avec Traffic Manager uniquement lorsque vous avez besoin de points de terminaison non-HTTP ou d’un contrôle au niveau du DNS.

Au niveau de la couche 4, Azure Load Balancer fournit une distribution de charge à très faible latence pour TCP/UDP. Le Standard Load Balancer prend en charge les frontends zonaux et redondants interzones, les ports HA, les règles de trafic sortant et un comportement sécurisé par défaut (configuration explicite du NSG et du pool backend). Les sondes d’intégrité (TCP/HTTP) déterminent l’état du backend ; une défaillance retire les instances de la rotation. Le Basic Load Balancer n’a pas de prise en charge des zones, de fonctionnalités avancées, ni de SLA — évitez-le pour la production. Le Cross-region Load Balancer ajoute un frontal anycast mondial qui équilibre la charge entre les Standard Load Balancers régionaux, permettant des conceptions multirégionales actives/actives pour les charges de travail non-HTTP et offrant un basculement régional rapide basé sur l’état de santé.

Mise en pratique : Atteindre des objectifs de récupération spécifiques

Associez chaque niveau à son mécanisme de continuité, en vous basant sur les RTO/RPO et les domaines de défaillance :

Disponibilité intra-région : Utilisez les Availability Zones. Déployez des ressources de calcul zonales sur au moins deux zones ; utilisez des frontends redondants entre les zones (Standard Load Balancer, Application Gateway v2 avec redondance de zone, ou Front Door en périphérie). Activez la redondance de zone pour SQL là où elle est prise en charge et utilisez GZRS pour le stockage qui nécessite une résilience à la fois zonale et régionale.
Reprise d’activité (DR) inter-régions : Pour les niveaux avec état (stateful), privilégiez la géo-réplication native (groupes de basculement automatique SQL, comptes multi-régions Cosmos DB, stockage GRS/GZRS) pour un RPO faible. Pour les IaaS avec état ou les charges de travail sans réplication native, utilisez Azure Site Recovery avec des stratégies de réplication et des plans de récupération bien ajustés. Pour les ressources de calcul éphémères, réhydratez à partir d’images ou de VM Scale Sets, en utilisant l’Infrastructure as Code.
Routage et basculement global : Pour le HTTP/S, Azure Front Door fournit un basculement piloté par des sondes d’intégrité, sensible à l’application, et une protection WAF. Pour les protocoles non-HTTP ou mixtes, ajoutez Traffic Manager (DNS) ou Cross-region Load Balancer (anycast L4) selon le cas. Utilisez le routage par priorité pour des objectifs RTO actif/passif stricts ; utilisez le routage pondéré pour les déploiements progressifs et le routage par performance pour les expériences utilisateur à plus faible latence.
Sauvegardes comme dernière ligne de défense : Même avec la réplication, maintenez Azure Backup avec des stratégies de rétention conformes, activez la suppression réversible (soft delete) pour protéger contre les purges, et configurez la restauration inter-régions pour les coffres utilisant un stockage géo-redondant. Les sauvegardes protègent contre la corruption logique, les ransomwares et les erreurs humaines — des risques que la réplication peut propager.

Les tests ne sont pas négociables. Planifiez des basculements de test ASR réguliers, effectuez des exercices de test des sondes d’intégrité de Front Door/Traffic Manager, validez le comportement des groupes de basculement SQL sous charge, et exécutez des simulations de basculement de stockage dans un environnement de test (sandbox). Instrumentez les mesures de RTO et automatisez la restauration (rollback/failback) avec des runbooks. Documentez et répétez les runbooks opérationnels afin que les intervenants d’astreinte puissent les exécuter de manière cohérente sous pression.

Scénario de problème pratique

Le groupe Expedia doit moderniser sa plateforme mondiale de réservation de voyages pour atteindre un RTO ≤ 15 minutes et un RPO ≤ 5 minutes pour les réservations principales, tout en supportant des pics de trafic 10 fois supérieurs lors des grands événements de voyage. La plateforme dessert des clients web et mobiles dans le monde entier avec des charges de travail mixtes HTTP et non-HTTP.

Construire la résilience zonale dans une région primaire

Déployez des microservices sans état (stateless) en tant que VM Scale Sets zonaux sur deux Availability Zones ou plus avec des frontends redondants entre les zones de type Standard Load Balancer. Cela élimine le risque de défaillance d’une seule zone et assure un trafic intra-région à faible latence.
Utilisez Azure SQL Database avec des groupes de basculement automatique et la redondance de zone activée. Les groupes de basculement automatique fournissent un basculement de base de données coordonné et un écouteur (listener) stable, respectant le RTO de 15 minutes avec une charge opérationnelle minimale.
Stockez les artefacts de session et les images dans des comptes de stockage GZRS pour combiner la durabilité zonale avec une protection régionale asynchrone. Cela permet d’atteindre le RPO de 5 minutes lorsqu’il est associé à l’idempotence côté application.

Ajouter une reprise d’activité (DR) inter-régions avec des lectures actif/actif

Configurez les origines web/API de réservation dans deux régions jumelées derrière Azure Front Door Standard. Les sondes d’intégrité et le routage par priorité permettent un basculement rapide en fonction de l’état de l’application, tandis que l’anycast accélère le trafic utilisateur. Les stratégies WAF avec des jeux de règles managées et la limitation de débit protègent contre les attaques volumétriques et de la couche applicative, ce qui est crucial lors des pics de trafic.
Activez les écritures multi-régions de Cosmos DB pour les services d’itinéraire et de personnalisation afin de réduire la latence d’écriture pour les utilisateurs mondiaux et de fournir une disponibilité de 99,999 %. Le basculement automatique priorise la région secondaire, préservant un RTO faible sans intervention manuelle.
Utilisez des groupes de basculement automatique SQL sur les deux mêmes régions pour les réservations transactionnelles, permettant la mise à l’échelle en lecture (read-scale) sur les secondaires pour le reporting tout en assurant un basculement rapide et coordonné.

Protéger l’état et permettre la récupération après corruption

Utilisez des coffres Recovery Services pour les sauvegardes de machines virtuelles Azure (cohérentes avec l’application là où c’est pris en charge) et SQL in-VM si des composants hérités subsistent. Appliquez des stratégies de sauvegarde avec une rétention à plusieurs niveaux et activez la suppression réversible pour vous prémunir contre les suppressions accidentelles ou malveillantes.
Pour les Azure Disks hébergeant des charges de travail spécialisées, ajoutez la sauvegarde Azure Disk Backup basée sur un coffre de sauvegarde pour capturer des instantanés incrémentiels indépendamment des agents du système d’exploitation invité. Cela diversifie les options de récupération.
Activez la restauration inter-régions sur les coffres utilisant un stockage géo-redondant, permettant des restaurations du plan de données depuis la région secondaire lors de perturbations partielles du plan de contrôle.

Orchestrer la reprise d’activité (DR) et valider le RTO

Configurez Azure Site Recovery pour tous les services sans réplication native (par exemple, les services Windows hérités). Créez des plans de récupération qui séquencent la préparation de la base de données, puis de l’API, puis du web, et incluez des runbooks Azure Automation pour mettre à jour les références Key Vault, purger les caches CDN via les règles Front Door, et basculer la priorité de Traffic Manager pour les points de terminaison non-HTTP.
Planifiez des basculements de test trimestriels dans des VNets isolés en utilisant des données masquées pour vérifier les runbooks, mesurer la durée réelle du basculement et affiner les réservations de capacité. Après les tests, nettoyez les artefacts et examinez les métriques par rapport à l’objectif de RTO de 15 minutes.

Routage global pour les protocoles mixtes

Pour le HTTP/S, Front Door gère le basculement piloté par l’état de santé et la sécurité en périphérie. Pour les protocoles non-HTTP (par exemple, les intégrations TCP de partenaires), déployez un Cross-region Load Balancer avec des Standard Load Balancers régionaux comme points de terminaison enfants. Les sondes d’intégrité suppriment instantanément les régions défaillantes, maintenant la connectivité sans dépendre des TTL DNS. Là où le géorepérage (geofencing) au niveau DNS est nécessaire (points de terminaison réglementaires), superposez le routage géographique d’Azure Traffic Manager en amont des points de terminaison spécifiques à la région.

Pourquoi ces services

Les Availability Zones et les frontends redondants entre les zones éliminent les défaillances d’une seule zone avec un impact minimal sur la latence. Les groupes de basculement Azure SQL abstraient la gestion des connexions et automatisent le basculement, s’alignant sur le RTO de 15 minutes. Les écritures multi-régions de Cosmos DB répondent aux exigences de très haute disponibilité et de faible latence d’écriture à l’échelle mondiale. Les options GZRS et RA offrent une durabilité zonale plus régionale avec des compromis de RPO contrôlés. Front Door fournit une accélération globale, un basculement sensible à l’application et un WAF en périphérie. Cross-region Load Balancer et Traffic Manager couvrent les besoins de routage non-HTTP et géographiques. Azure Backup et ASR fournissent des chemins de récupération indépendants — des restaurations à un point dans le temps au basculement complet de la pile — garantissant que la plateforme peut se remettre à la fois des pannes d’infrastructure et de la corruption logique des données.

← Réseau et connectivité · Tous les domaines · Architecture de sécurité et Zero Trust →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →