Région, zone de disponibilité, edge location : une hiérarchie à trois niveaux
L'infrastructure des grands fournisseurs cloud est organisée selon une hiérarchie géographique à trois niveaux, chacun répondant à un besoin différent : la latence, la conformité, ou la tolérance aux pannes.
Région
Une région est une zone géographique délimitée (par exemple « France Centre » ou « USA Est ») regroupant plusieurs centres de données. Choisir une région détermine où vos données sont physiquement stockées — un critère central pour les contraintes réglementaires et de latence avec vos utilisateurs.
Zone de disponibilité (AZ)
Une zone de disponibilité est un ou plusieurs centres de données isolés à l'intérieur d'une région, avec sa propre alimentation électrique, son propre refroidissement et son propre réseau physique, mais reliée aux autres AZ de la région par un réseau à très faible latence. Cette isolation physique est ce qui permet de tolérer la panne d'une AZ sans interrompre le service.
Edge location (point de présence)
Une edge location est un point de présence plus petit qu'une région complète, positionné au plus près des utilisateurs finaux pour réduire la latence — typiquement utilisé pour la diffusion de contenu (CDN) ou certains traitements en périphérie de réseau. Une edge location ne remplace pas une région : elle sert un objectif de proximité, pas de tolérance aux pannes.
Région = où vos données vivent. Zone de disponibilité = comment vous survivez à la panne d'un centre de données. Edge location = comment vous réduisez la latence avec l'utilisateur final. Trois problèmes différents, trois réponses différentes.
La logique de la redondance à l'intérieur d'une région
Répartir une charge de travail sur plusieurs zones de disponibilité au sein d'une même région est la première ligne de défense contre l'indisponibilité — et généralement la plus simple à mettre en œuvre, car la latence entre AZ d'une même région reste suffisamment faible pour de la réplication synchrone.
Réplication automatique des données
Les services de stockage « zone-redondants » répliquent automatiquement les données sur plusieurs zones de disponibilité, de sorte que la panne d'une seule zone n'affecte pas la disponibilité des données. Ce mécanisme est proposé nativement par la plupart des services managés des trois grands fournisseurs.
Répartition de charge entre zones
Pour les charges de calcul, déployer des instances dans plusieurs AZ derrière un répartiteur de charge permet de continuer à servir le trafic même si une zone devient indisponible — à condition que la capacité restante dans les autres zones suffise à absorber la charge, un point souvent négligé lors du dimensionnement initial.
Un coût marginal généralement faible
Contrairement à une idée reçue, répartir une charge de travail standard sur plusieurs zones de disponibilité d'une même région n'implique généralement pas de surcoût de licence ou d'infrastructure majeur — le principal changement porte sur la conception de l'architecture (réplication, répartition de charge), pas sur une facturation spécifique liée au nombre de zones utilisées.
Multi-AZ et multi-région protègent contre des risques différents
Comme pour la distinction entre hybride et multicloud, il s'agit ici de deux réponses à des risques différents, pas de deux niveaux d'un même spectre.
Multi-AZ protège contre la panne d'un centre de données
Une architecture multi-AZ survit à la défaillance d'une zone de disponibilité — panne électrique, incident matériel, problème réseau localisé. C'est le niveau de résilience de base recommandé pour la quasi-totalité des charges de travail en production, avec un coût et une complexité de mise en œuvre relativement faibles.
Multi-région protège contre un sinistre régional ou un besoin de proximité
Une architecture multi-région survit à un événement qui affecte une région entière (catastrophe naturelle majeure, panne réseau à l'échelle régionale), et permet en plus de rapprocher le service de utilisateurs répartis dans plusieurs zones géographiques. En contrepartie, elle implique une complexité significativement plus élevée : synchronisation des données entre régions, cohérence applicative, coûts de transfert de données.
Passer directement au multi-région sans avoir d'abord une architecture multi-AZ solide n'apporte pas la résilience attendue : la complexité du multi-région se justifie seulement une fois le niveau multi-AZ correctement maîtrisé.
Ce qu'un SLA garantit vraiment
Les fournisseurs cloud publient des engagements de disponibilité contractuels (SLA) exprimés en pourcentage — mais l'écart entre deux pourcentages proches représente des différences bien plus importantes qu'il n'y paraît.
La logique des « neuf »
Un SLA de 99,9 % (« trois neuf ») tolère environ 8h45 d'indisponibilité par an. Un SLA de 99,99 % (« quatre neuf ») tolère environ 52 minutes par an. Un SLA de 99,999 % (« cinq neuf ») tolère environ 5 minutes par an. Chaque « neuf » supplémentaire représente une réduction d'un facteur 10 du temps d'indisponibilité toléré — et généralement une complexité et un coût d'architecture nettement plus élevés pour l'atteindre.
Un SLA composite se dégrade vite
Une architecture qui enchaîne plusieurs services, chacun avec son propre SLA, hérite d'une disponibilité globale inférieure au plus faible des SLA individuels si les services ne sont pas conçus pour tolérer la panne des uns et des autres indépendamment. Un service à 99,99 % combiné à un autre à 99,9 % ne garantit pas 99,9 % à l'ensemble : le résultat réel dépend de la façon dont ils sont architecturés ensemble.
Les trois grands fournisseurs proposent des SLA financièrement garantis de l'ordre de 99,9 % pour une instance unique, et jusqu'à 99,99 % pour une paire d'instances réparties sur deux zones de disponibilité — des seuils comparables d'un fournisseur à l'autre, la différence se jouant surtout sur l'architecture mise en œuvre par le client.
RTO, RPO et les grands schémas de reprise après sinistre
Au-delà du pourcentage de disponibilité, deux métriques pilotent concrètement une stratégie de résilience : le RTO et le RPO. Elles se définissent en amont, en fonction du coût réel d'une interruption pour votre activité — pas après coup.
RTO et RPO : deux métriques, deux questions différentes
Le RTO (Recovery Time Objective) répond à la question « combien de temps peut-on tolérer avant que le service soit rétabli ? ». Le RPO (Recovery Point Objective) répond à une question différente : « combien de données peut-on se permettre de perdre, mesuré en temps depuis la dernière sauvegarde ou réplication ? ». Un RTO court et un RPO proche de zéro coûtent tous les deux plus cher à atteindre.
Les 4 grands schémas de reprise après sinistre
Du moins coûteux au plus résilient, quatre approches structurent la plupart des stratégies de reprise après sinistre en environnement cloud.
- Sauvegarde et restauration : les données sont sauvegardées régulièrement, l'infrastructure est reconstruite en cas de sinistre. RTO et RPO les plus longs, coût le plus faible.
- Site de secours minimal (« pilot light ») : une version réduite de l'infrastructure tourne en permanence dans une région secondaire, prête à être mise à l'échelle en cas de besoin.
- Site de secours actif (« warm standby ») : une version fonctionnelle mais réduite de l'application tourne en continu dans une région secondaire, prête à absorber le trafic complet rapidement.
- Multi-site actif-actif : l'application tourne simultanément à pleine capacité dans plusieurs régions, avec bascule quasi instantanée. RTO et RPO les plus courts, coût et complexité les plus élevés.
Comment choisir entre ces 4 schémas
Le bon choix dépend directement du coût réel d'une interruption pour l'activité concernée. Un site e-commerce dont chaque minute d'indisponibilité se traduit par une perte de chiffre d'affaires mesurable justifie un investissement en multi-site actif-actif. Un outil de reporting interne, consulté quelques fois par jour, se contente très bien d'une sauvegarde-restauration classique. Le piège le plus fréquent consiste à appliquer le même niveau d'exigence à l'ensemble du système d'information, sans hiérarchiser les systèmes par criticité réelle.
Les pièges les plus courants en matière de résilience
Trois erreurs reviennent régulièrement dans les analyses d'incidents liés à une architecture insuffisamment résiliente.
Déploiement mono-AZ pour des charges critiques
Déployer une charge de travail de production sur une seule zone de disponibilité reste l'une des causes les plus fréquentes d'indisponibilité évitable — souvent par simplicité initiale, sans revoir l'architecture une fois le service devenu critique pour l'activité.
Un plan de reprise jamais testé en conditions réelles
Un schéma de reprise après sinistre documenté mais jamais testé donne un faux sentiment de sécurité. Un test de bascule réel, planifié régulièrement, révèle presque toujours des écarts entre le plan théorique et la réalité opérationnelle — configuration oubliée, dépendance non anticipée, procédure incomplète.
Des objectifs RTO/RPO jamais formalisés
Sans RTO et RPO explicitement définis en amont pour chaque système, il devient impossible de choisir objectivement le bon schéma de reprise après sinistre — le risque est de sur-investir sur des systèmes secondaires et de sous-investir sur des systèmes réellement critiques.
Un pourcentage de disponibilité élevé affiché par le fournisseur ne compense pas une architecture cliente mal conçue. Le SLA du fournisseur porte sur son infrastructure, pas sur la résilience de la façon dont vous l'utilisez.
L'infrastructure des 3 grands fournisseurs, en ordre de grandeur
Ces chiffres évoluent en continu à mesure que les fournisseurs ouvrent de nouvelles régions — à considérer comme des ordres de grandeur plutôt que des valeurs figées, à vérifier sur la documentation officielle de chaque fournisseur pour un chiffre exact au moment de la lecture.
- Azure : plus de 60 régions, chacune comptant généralement au moins trois zones de disponibilité — la couverture géographique la plus large des trois grands fournisseurs.
- AWS : une quarantaine de régions actives, pour plus d'une centaine de zones de disponibilité au total, chaque région comptant au minimum trois AZ physiquement séparées.
- Google Cloud : plus de 40 régions et environ 130 zones, avec un maillage réseau mondial propre à Google reliant l'ensemble.
Toutes les régions d'un même fournisseur ne proposent pas systématiquement l'intégralité du catalogue de services, ni le même nombre de zones de disponibilité. Vérifier la disponibilité des services et le nombre d'AZ pour la région ciblée avant de concevoir une architecture fait partie des vérifications de base, souvent négligée en phase de conception initiale.
Un concept central des domaines « architecture » des certifications d'entrée
Régions, zones de disponibilité et haute disponibilité figurent systématiquement dans le domaine consacré à l'architecture des certifications cloud d'entrée — Azure Fundamentals, Google Cloud Digital Leader et AWS Cloud Practitioner testent tous les trois la capacité à choisir la bonne configuration régionale pour un scénario donné.
Pour aller plus loin
Questions fréquentes
Quelle est la différence entre une région et une zone de disponibilité ?
Une région est une zone géographique regroupant plusieurs centres de données. Une zone de disponibilité (AZ) est un ou plusieurs centres de données isolés à l'intérieur de cette région, avec sa propre alimentation et son propre réseau physique, mais relié aux autres AZ par un réseau à très faible latence.
Combien de zones de disponibilité par région, en général ?
Les trois grands fournisseurs visent généralement un minimum de trois zones de disponibilité par région, ce qui permet de tolérer la perte d'une zone tout en conservant une majorité de zones fonctionnelles.
Faut-il toujours viser une architecture multi-région ?
Non. Le multi-région ajoute une complexité et un coût significatifs, justifiés uniquement par un besoin réel de résilience face à un sinistre régional ou de proximité avec des utilisateurs répartis mondialement. Pour la plupart des charges de travail, une architecture multi-AZ bien conçue suffit largement.
Qu'est-ce qui différencie une edge location d'une région ?
Une edge location est un point de présence plus petit, positionné pour réduire la latence avec les utilisateurs finaux (diffusion de contenu, traitement en périphérie), sans offrir la même profondeur de services qu'une région complète. Elle répond à un objectif de proximité, pas de tolérance aux pannes.
Un SLA de 99,99 % garantit-il qu'aucune panne ne se produira ?
Non. Un SLA garantit un engagement contractuel de disponibilité sur une période donnée, généralement assorti d'une compensation financière en cas de non-respect — pas une garantie d'absence totale de panne. Une indisponibilité ponctuelle reste compatible avec le respect du SLA, tant que le cumul annuel reste sous le seuil contractuel.
Quelle est la différence entre RTO et RPO ?
Le RTO (Recovery Time Objective) mesure le temps toléré avant rétablissement du service. Le RPO (Recovery Point Objective) mesure la quantité de données qu'on peut se permettre de perdre, en temps depuis la dernière sauvegarde. Ce sont deux dimensions indépendantes d'une stratégie de résilience.
Quel schéma de reprise après sinistre choisir ?
Cela dépend du RTO et du RPO définis pour le système concerné, mis en balance avec le budget disponible. La sauvegarde-restauration convient pour des systèmes tolérant plusieurs heures d'indisponibilité ; le multi-site actif-actif se justifie uniquement pour des systèmes où chaque minute d'interruption a un impact business majeur.
Pourquoi tester régulièrement un plan de reprise après sinistre ?
Parce qu'un plan documenté mais jamais testé donne un faux sentiment de sécurité. L'environnement change en continu (nouveaux services, nouvelles dépendances), et seul un test de bascule réel révèle les écarts entre la théorie et la réalité opérationnelle du moment.
Les chiffres de régions et zones de disponibilité évoluent-ils souvent ?
Oui, les trois grands fournisseurs ouvrent régulièrement de nouvelles régions. Les chiffres cités dans ce guide sont des ordres de grandeur à un instant donné — pour un chiffre exact, la documentation officielle de chaque fournisseur reste la source de référence.
Faut-il connaître ces concepts pour une certification cloud ?
Oui, régions, zones de disponibilité et haute disponibilité font partie des concepts fondamentaux testés dans les certifications d'entrée Azure Fundamentals, Google Cloud Digital Leader et AWS Cloud Practitioner, généralement dans le domaine consacré à l'architecture.