Les régions

Introduction

Microsoft Azure répartit son infrastructure dans plusieurs régions géographiques à travers le monde. Chaque région regroupe des centres de données dans lesquels sont hébergées les ressources utilisées pour exécuter les applications et stocker les données. Lors de la création de nombreuses ressources Azure, il est donc nécessaire de choisir leur région de déploiement. Ce choix permet notamment de rapprocher les applications de leurs utilisateurs pour réduire la latence et de répondre aux contraintes de localisation des données. Il influence également la disponibilité des services, leur tarification et les possibilités de résilience de l’application. Selon les besoins, une application peut être déployée dans une seule région ou répartie entre plusieurs régions afin de renforcer sa continuité de service.

Les géographies

Dans Azure, une géographie est un périmètre géographique qui regroupe une ou plusieurs régions et qui constitue une frontière de résidence des données. Elle peut correspondre à un pays, comme la France ou le Canada, ou à un ensemble plus large, comme l’Europe. Chaque région appartient à une seule géographie. Voici un exemple :

Géographie Azure	Régions appartenant à cette géographie
France	France Central, France South
Canada	Canada Central, Canada East
Europe	North Europe (Irlande), West Europe (Pays-Bas)

Une géographie Azure ne correspond donc pas nécessairement à un continent : les régions situées sur le continent européen peuvent appartenir à des géographies Azure différentes, comme France, Allemagne ou Europe.

Cartographie des régions

Dans le monde, en septembre 2026, il existe plus de 70 régions réparties sur différents continents. Une région comporte plusieurs Datacenters, et l'ensemble de ces régions contiennent plus de 400 Datacenters. Un Datacenter contient des serveurs pour héberger les applications, des serveurs de stockage, des capacités réseau, etc. Les Datacenters sont reliés entre eux par des câbles de fibre optique.

Toutes les régions et tous les services ne sont pas accessibles à chaque abonnement.

Régions sur le continent Européen

Qui peut utiliser les régions à accès restreint ? Les clients qui répondent aux critères d’éligibilité définis par Microsoft pour la région concernée. Leur utilisation nécessite une demande d’accès et une approbation de Microsoft, notamment pour répondre à des besoins spécifiques de résidence des données ou de reprise après sinistre.

Régions sur le continent Nord Américain

Pour en savoir plus sur les régions

Une carte est disponible de manière interactive ici. Aussi, vous trouverez la liste des régions disponibles ici.

Les paires régionales

Dans Azure, une paire régionale (region pair) est une association définie par Microsoft entre deux régions, généralement situées dans la même géographie. Certains services utilisent cette association pour assurer la géoréplication des données et contribuer à la reprise après sinistre. Par exemple, les régions France Central et France South forment une paire régionale, de même que North Europe et West Europe.

Ce jumelage des régions apporte les avantages suivants :

La géoréplication : certains services, comme Azure Storage avec l’option GRS, répliquent les données vers la région jumelée.
Les mises à jour décalées : Microsoft s’efforce d’échelonner les mises à jour de l’infrastructure entre les deux régions.
La priorisation de la restauration : en cas de panne majeure touchant une géographie, une région de chaque paire est prioritaire pour la remise en service.

Attention : Le jumelage ne rend pas automatiquement une application hautement disponible. La réplication et le déploiement dans une autre région et le basculement doivent être prévus selon les capacités des services utilisés.

Enfin, toutes les régions ne sont pas jumelées, et une architecture multi-régions peut utiliser des régions qui ne forment pas une paire.

Utilité des régions

Les régions Azure permettent de choisir où déployer les ressources d’un logiciel. Ce choix influence les performances, la localisation des données et la continuité de service.

Critère	Description
Rapprocher les applications de leurs utilisateurs	Une région proche des utilisateurs contribue à réduire la latence, c’est-à-dire le délai des échanges réseau. Pour une application utilisée sur plusieurs continents, un déploiement dans plusieurs régions peut améliorer les temps de réponse.
Répondre aux exigences de localisation des données	Une organisation peut devoir conserver certaines données dans un périmètre géographique déterminé. Le choix des régions contribue à respecter cette exigence, mais il faut également vérifier les engagements de chaque service concernant le stockage et la réplication des données.
Préparer la reprise après un incident majeur	Utiliser plusieurs régions permet de prévoir une solution de secours si l’une d’elles devient indisponible. Cette protection nécessite de concevoir la réplication des données et le basculement des traitements : déployer des ressources dans deux régions ne suffit pas à assurer automatiquement la continuité de l’application.

Le choix d’une région doit aussi tenir compte des services disponibles, des possibilités de redondance entre zones de disponibilité et des coûts. La région la plus proche constitue donc un point de départ, à confronter aux besoins des logiciels à déployer.

Les zones de disponibilité

Dans Azure, une zone de disponibilité (Availability Zone) regroupe plusieurs Datacenters au sein d’une même région. De manière générale, une région Azure prenant en charge les zones de disponibilité en possède au moins trois. Les zones sont physiquement séparées et disposent d’infrastructures indépendantes pour l’alimentation électrique, le refroidissement et le réseau de communication. Cette séparation a l'avantage de limiter les conséquences lorsqu'une panne survient à l’intérieur d’une région. Elles ne protègent pas contre l’indisponibilité complète de cette région : ce scénario nécessite une stratégie de reprise, éventuellement dans une autre région. Ainsi, en répartissant une application entre plusieurs zones de disponibilité, on peut maintenir son fonctionnement, même lorsqu'une zone devient indisponible. Les zones sont reliées par un réseau à très faible latence, facilitant les échanges et la réplication des données.

Azure distingue deux modes de déploiement :

Mode	Fonctionnement	Responsabilité
Ressource zonale	La ressource est déployée dans une zone choisie.	Nécessite de prévoir des ressources dans d’autres zones et d'organiser le basculement.
Ressource redondante interzone	Le service répartit ou réplique la ressource entre plusieurs zones.	Azure gère la répartition et le basculement selon les capacités du service.

Certains services utilisent automatiquement plusieurs zones ; d’autres nécessitent une configuration particulière. Choisir une région disposant de zones ne suffit donc pas à rendre l’application résiliente. Par exemple, une application peut utiliser plusieurs machines virtuelles réparties entre les zones, un répartiteur de charge et une base de données configurée avec une redondance interzone. La disponibilité doit être prévue pour l’ensemble de ces éléments.

Le schéma ci-dessous illustre l’organisation d’une région Azure disposant de zones de disponibilité. Il présente également une ressource déployée sans choix de zone. Dans ce cas, Azure détermine alors son emplacement. Ce mode de déploiement ne signifie pas que la ressource est hébergée hors des zones de disponibilité et ne garantit pas, à lui seul, sa résilience à la panne d’une zone.

Impact sur le SLA

Les zones de disponibilité peuvent permettre de bénéficier d’un SLA (Service Level Agreement) plus élevé, à condition de déployer les ressources selon les exigences du service. Il n’existe pas de SLA unique applicable à toutes les zones Azure.

Configuration	Engagement de disponibilité
Au moins deux VM dans un même ensemble de disponibilité (Availability Set)	99,95 %
Au moins deux VM réparties dans au moins deux zones de disponibilité d’une même région	99,99 %

Important : - Placer une seule VM dans une zone ne suffit donc pas à obtenir le SLA de 99,99 %. Le bénéfice vient de la redondance entre plusieurs zones.

Pour la configuration multizone, l’engagement porte sur la connectivité d’au moins une instance, et non sur la disponibilité permanente de chacune des VM. Enfin, le SLA des ressources ne constitue pas automatiquement celui de l’application : celle-ci dépend aussi de sa base de données, du réseau, de ses autres services et des mécanismes de basculement. L’architecture complète doit permettre de continuer à fonctionner malgré la perte d’une zone.

Les impacts financiers

L’utilisation des zones de disponibilité peut augmenter les coûts, principalement en raison des ressources nécessaires à la redondance. Il n’existe pas de supplément forfaitaire commun à tous les services Azure : l’impact dépend du service et de sa configuration.

Poste	Impact financier possible
Instances supplémentaires	Plusieurs VM ou instances applicatives entraînent davantage de coûts de calcul, de disques et éventuellement de licences.
Réplication des données	Le stockage redondant interzone (ZRS) peut coûter davantage que le stockage localement redondant (LRS).
Offre du service	La redondance interzone peut nécessiter un niveau de service particulier ou un nombre minimal d’instances.
Répartition du trafic	Un répartiteur de charge et les traitements associés peuvent ajouter des frais.

Le surcoût du stockage ZRS dépend notamment des volumes stockés et des opérations effectuées. Les transferts de données entre zones de disponibilité d’une même région ne sont actuellement pas facturés par Azure, que les adresses IP soient privées ou publiques. Cela n’annule pas les frais propres aux services réseau utilisés.

Par exemple, passer d’une VM à deux VM identiques réparties dans deux zones double le coût de calcul de ces VM à durée d’exécution égale. En revanche, répartir deux VM déjà nécessaires entre deux zones ne double pas à nouveau ce coût. L’intérêt économique consiste à comparer le surcoût de la redondance au coût potentiel d’une interruption : perte de ventes, arrêt de production ou indisponibilité pour les utilisateurs.