Régions de zone d’atterrissage

L’architecture de zone d’atterrissage Azure elle-même est agnostique. Vous êtes cependant invité à définir des régions Azure pour déployer une architecture de zone d’atterrissage Azure. Cet article décrit comment les zones d’atterrissage utilisent les régions Azure. Il explique également comment ajouter une région à une zone d’atterrissage existante et apporte certaines considérations sur la migration de votre patrimoine Azure vers une autre région.

Pour obtenir des conseils sur le choix des régions Azure, voir Sélectionner des régions Azure.

Utilisation des régions par les zones d’atterrissage

Les zones d’atterrissage Azure sont constituées d’un ensemble de ressources et de configurations. Certains de ces éléments (comme les groupes d’administration, les stratégies et les attributions de rôles) sont stockés au niveau d’un locataire ou d’un groupe d’administration dans l’architecture de zone d’atterrissage Azure. Ainsi, ces ressources ne sont pas « déployées » dans une région donnée, mais bien globalement. Toutefois, vous devez toujours définir une région de déploiement, car Azure effectue le suivi de certaines métadonnées de ressources dans un magasin de métadonnées régional.

D’autres ressources sont déployées au niveau régional. Selon la configuration de zone d’atterrissage, vous pouvez déployer une partie ou la totalité des ressources au niveau régional :

• Espace de travail Log Analytics (y compris les solutions sélectionnées)
• Compte Automation
• Groupes de ressources (pour les autres ressources)

Si vous déployez une topologie de réseau, vous devez sélectionner une région Azure sur laquelle déployer les ressources réseau. Cette région peut être différente de celle utilisée pour les ressources répertoriées dans la liste précédente. En fonction de la topologie choisie, les ressources réseau déployées peuvent comprendre les éléments suivants :

• Azure Virtual WAN (hub Virtual WAN compris)
• Réseaux virtuels Azure
• passerelle VPN
• Passerelle ExpressRoute
• Pare-feu Azure
• Plans Azure DDoS Protection
• Zones DNS privées Azure, y compris pour Azure Private Link
• Groupes de ressources, pour contenir les ressources répertoriées ci-dessus

Remarque

Pour réduire l’effet des pannes régionales, nous vous recommandons de placer les ressources dans la même région que le groupe de ressources. Pour plus d’informations, consultez Alignement de l’emplacement du groupe de ressources.

Ajouter une région à une zone d’atterrissage existante

Vous devez envisager une stratégie sur plusieurs régions, dès le début de votre parcours dans le cloud ou en vous développant sur d’autres régions Azure une fois le déploiement initial terminé de votre architecture de zone d’atterrissage Azure. Par exemple, si vous activez la récupération d’urgence pour vos machines virtuelles à l’aide d’Azure Site Recovery, vous souhaiterez peut-être les répliquer dans une autre région Azure. Pour ajouter des régions Azure dans une architecture de zone d'atterrissage Azure, tenez compte des domaines et recommandations suivants :

Domaine	Recommandation
Groupes d’administration	Aucune action requise. Les groupes d’administration ne sont pas liés à une région et il est déconseillé de créer une structure de groupe d’administration basée sur des régions.
Abonnements	Les abonnements ne sont pas liés à une région.
Azure Policy	Apportez des modifications ici si vous avez attribué des stratégies visant à refuser le déploiement de ressources à toutes les régions en spécifiant une liste de régions Azure « autorisées ». Ces attributions doivent être mises à jour pour autoriser les déploiements de ressources vers la nouvelle région que vous souhaitez activer.
Contrôle d’accès en fonction du rôle	Aucune action requise. Le contrôle d’accès en fonction du rôle Azure n’est pas lié à une région.
Surveillance et journalisation	Décidez s’il convient d’utiliser un seul espace de travail Log Analytics ou de créer plusieurs espaces de travail pour couvrir diverses régions géographiques. Chaque approche a des avantages et des inconvénients, notamment des frais possibles de mise en réseau inter-région. Pour en savoir plus, reportez-vous à Concevoir une architecture d'espace de travail Log Analytics.
Mise en réseau	Si vous avez déployé une topologie de mise en réseau, un réseau Virtual WAN ou un réseau hub-and-spoke traditionnel, étendez la mise en réseau à la nouvelle région Azure. Créez un autre hub de mise en réseau en déployant les ressources de mise en réseau requises dans l'abonnement de connectivité existant dans la nouvelle région Azure. Azure Virtual Network Manager peut faciliter le développement et la gestion de réseaux virtuels à grande échelle dans plusieurs régions. Du point de vue du DNS, vous pouvez également déployer des redirecteurs, s’ils sont utilisés, dans la nouvelle région Azure. Utilisez des redirecteurs pour les réseaux virtuels spoke de la nouvelle région à des fins de résolution. Les zones DNS Azure sont des ressources mondiales. Elles ne sont pas liées à une seule région Azure et il n’y a rien à faire pour elles.
Identité	Si vous avez déployé Active Directory Domain Services ou Microsoft Entra Domain Services dans votre abonnement/réseau spoke d’identité, développez le service dans la nouvelle région Azure.

Remarque

Vous devez également utiliser des zones de disponibilité à haute disponibilité au sein d’une région. Vérifiez si les zones de disponibilité sont prises en charge dans vos régions choisies et pour les services que vous souhaitez utiliser.

Microsoft Cloud for Sovereignty donne des instructions pour restreindre les services et les régions. Vous pouvez utiliser ces instructions pour configurer les services et aider ainsi les clients à répondre à leurs besoins en matière de résidence des données.

Approche de haut niveau

Lorsque vous développez une zone d’atterrissage Azure dans une nouvelle région, envisagez de suivre les étapes décrites dans ces sections. Avant de commencer, vous devez déterminer une nouvelle région Azure ou plusieurs régions Azure pour l’extension.

Mise en réseau

Architecture hub et spoke traditionnelle

Conseil

Vérifier la zone de conception de zone d’atterrissage Azure pour l’architecture hub-and-spoke traditionnelle.

1. Déterminez si un nouvel abonnement de zone d’atterrissage de plateforme est nécessaire. Nous recommandons à la plupart des clients d’utiliser leurs abonnements Connectivité existants, même lorsqu’ils utilisent plusieurs régions.
2. Dans l’abonnement, créez un groupe de ressources dans la nouvelle région cible.
3. Créez un réseau virtuel hub dans la nouvelle région cible.
4. Le cas échéant, déployez Pare-feu Azure ou des appliances virtuelles réseau (NVA) dans votre nouveau réseau virtuel hub.
5. Le cas échéant, déployez des passerelles de réseau virtuel pour la connectivité VPN et/ou ExpressRoute et établissez des connexions. Veillez à ce que vos emplacements locaux et circuits ExpressRoute suivent les suggestions de résilience de Microsoft. Pour obtenir plus d’informations, consultez Conception pour une reprise d’activité avec le peering privé ExpressRoute.
6. Établissez un appairage de réseau virtuel entre le nouveau réseau virtuel hub et les autres réseaux virtuels hub.
7. Créez et configurez le routage requis, comme Serveur de routes Azure ou des itinéraires définis par l’utilisateur.
8. Si nécessaire, activez la résolution de noms en déployant des redirecteurs DNS pour la nouvelle région cible et en effectuant une liaison vers toutes les zones DNS privées.
   • Certains clients peuvent configurer la résolution de noms sur leurs contrôleurs domaine Active Directory dans l’abonnement à la zone d’atterrissage de la plateforme d’identité.

Pour héberger vos charges de travail, vous pouvez ensuite connecter des spokes de zone d’atterrissage d’application au nouveau réseau virtuel hub dans la nouvelle région à l’aide de l’appairage de réseaux virtuels.

Conseil

Azure Virtual Network Manager peut faciliter le développement et la gestion de réseaux virtuels à grande échelle dans plusieurs régions.

Architecture Virtual WAN

Conseil

Vérifier la zone de conception de zone d’atterrissage Azure pour l’l’architecture Virtual WAN.

1. Dans le réseau WAN virtuel existant, créez un hub virtuel dans la nouvelle région cible.
2. Déployez Pare-feu Azure ou les autres appliances virtuelles réseau (NVA) prises en charge dans votre nouveau hub virtuel. Configurez les stratégies de routage et intention de routage Azure Virtual WAN pour acheminer le trafic via le nouveau hub virtuel sécurisé.
3. Le cas échéant, déployez des passerelles de réseau virtuel pour la connectivité VPN et/ou ExpressRoute dans le nouvel hub virtuel et établissez des connexions. Veillez à ce que vos emplacements locaux et circuits ExpressRoute suivent les suggestions de résilience de Microsoft. Pour obtenir plus d’informations, consultez Conception pour une reprise d’activité avec le peering privé ExpressRoute.
4. Le cas échéant, créez et configurez tout autre routage dont vous avez besoin, par exemple des itinéraires statiques de hub virtuel.
5. Le cas échéant, déployez des redirecteurs DNS pour la nouvelle région cible et effectuez une liaison vers les zones DNS privées pour activer la résolution.
   • Certains clients peuvent configurer la résolution de noms sur leurs contrôleurs domaine Active Directory dans l’abonnement à la zone d’atterrissage de la plateforme d’identité.
   • Dans les déploiements Virtual WAN, cela doit se faire dans un réseau virtuel spoke connecté au hub virtuel par une connexion de réseau virtuel conformément au modèle d’extension de hub virtuel.

Pour héberger vos charges de travail, vous pouvez ensuite connecter des spokes de zone d'atterrissage d’application au nouveau hub virtuel du WAN virtuel dans la nouvelle région à l’aide de connexions de réseau virtuel.

Identité

Conseil

Vérifier la zone de conception de zone d’atterrissage Azure pour la gestion des identités et des accès.

1. Déterminez si vous avez besoin d’un nouvel abonnement de zone d’atterrissage de plateforme. Nous recommandons à la plupart des clients d’utiliser leurs abonnements Identité existants, même lorsqu’ils utilisent plusieurs régions.
2. Créez un groupe de ressources dans la nouvelle région cible.
3. Créez un réseau virtuel dans la nouvelle région cible.
4. Établissez l’appairage de réseaux virtuels avec le nouveau réseau virtuel du hub régional dans l’abonnement de connectivité.
5. Déployez des charges de travail d’identité, comme les machines virtuelles de contrôleur de domaine Active Directory, dans le nouveau réseau virtuel.
   • Vous devrez peut-être effectuer d’autres étapes de configuration sur les charges de travail une fois qu’elles seront approvisionnées, par exemple les étapes de configuration suivantes :
     • Promouvoir les machines virtuelles de contrôleur de domaine Active Directory sur le domaine Active Directory existant.
     • Créer des sites et des sous-réseaux Active Directory.
     • Configurer des paramètres du serveur DNS comme les redirecteurs conditionnels.

Migrer votre patrimoine Azure vers une nouvelle région

Parfois, vous devez migrer l’intégralité de votre patrimoine Azure vers une autre région. Imaginons que vous déployiez la zone d’atterrissage et les charges de travail dans la région Azure d’un(e) pays/région voisin(e) avant qu’une nouvelle région Azure ne soit lancée dans votre pays/région d’origine. Vous pouvez choisir de migrer toutes vos charges de travail vers la nouvelle région pour améliorer la latence de communication ou pour vous conformer aux exigences de résidence des données.

Notes

Ce document fournit uniquement des informations sur la migration des composants de zone d’atterrissage de votre patrimoine. Pour plus d’informations sur la relocalisation de votre charge de travail, consultez l’article Déplacer des charges de travail cloud.

Configuration d’une zone d’atterrissage globale

En général, vous n’avez pas à modifier la configuration d’une zone d’atterrissage déployée à l’échelle mondiale lorsque vous déplacez des régions. Vous devez toutefois vérifier les attributions de stratégie qui limitent les déploiements au niveau régional et de mettre à jour la stratégie pour autoriser les déploiements dans la nouvelle région.

Ressources de zone d’atterrissage régionale

Les ressources de zone d’atterrissage spécifiques à une région nécessitent souvent plus d’attention. En effet, certaines ressources Azure ne peuvent pas être déplacées d’une région à l’autre. Tenez compte des approches suivantes :

1. Ajouter la région de destination comme région supplémentaire de la zone d’atterrissage. Suivez les instructions fournies à la section Ajouter une région à une zone d’atterrissage existante.
2. Déployer des composants centralisés dans la région de destination. Par exemple, déployez un nouvel espace de travail Log Analytics dans la région de destination. Ainsi, les charges de travail peuvent commencer à utiliser le nouveau composant dès qu’elles sont migrées.
3. Migrer vos charges de travail de la région source vers la région de destination. Lors de la migration de la charge de travail, reconfigurez les ressources pour utiliser les composants réseau, les composants d’identité, l’espace de travail Log Analytics et d’autres ressources régionales de la région de destination.
4. Désactiver les ressources dans la région source une fois la migration terminée.

Appliquez les recommandations suivantes lorsque vous migrez des ressources de zone d’atterrissage entre deux régions :

• Utiliser l’infrastructure en tant que code : la configuration complexe (comme les règles de Pare-feu Azure) peut être exportée et réimportée à l’aide de Bicep, de modèles ARM, de Terraform, de scripts ou d’une approche similaire.
• Azure Automation : Azure Automation fournit des instructions et des scripts pour faciliter la migration interrégion de ressources Azure Automation.
• ExpressRoute : déterminez si vous pouvez utiliser ExpressRoute Local dans la région de destination. Si vos environnements locaux se trouvent dans la même région métropolitaine que votre région Azure, ExpressRoute Local peut constituer une option moins coûteuse que les autres références SKU d’ExpressRoute.

Étapes suivantes

Améliorer la gouvernance des zones d’atterrissage