Régions de zone d’atterrissage
Cet article décrit comment les zones d’atterrissage utilisent les régions Azure. L’architecture de la zone d’atterrissage Azure est indépendante de la région, mais vous devez spécifier les régions Azure pour déployer votre architecture de zone d’atterrissage Azure. Les conseils suivants décrivent comment ajouter une région à une zone d’atterrissage existante et fournissent également des considérations à prendre en compte lorsque vous migrez votre patrimoine Azure vers une autre région.
Dans certaines situations, vous devez déployer des applications dans plusieurs régions Azure pour prendre en charge vos exigences professionnelles en matière de haute disponibilité et récupération d’urgence. Il se peut que vous n’ayez pas un besoin immédiat d’applications multirégionales, mais vous devez concevoir votre plateforme de zone d’atterrissage Azure pour prendre en charge plusieurs régions, en particulier pour les services de connectivité, d’identité et de gestion. Assurez-vous de pouvoir activer et prendre en charge rapidement des zones d’atterrissage d’applications multirégionales.
Pour plus d’informations, consultez Sélectionner des régions Azure.
Zones d’atterrissage et régions Azure
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 la zone d’atterrissage Azure. Ces ressources ne sont pas déployées dans une région particulière, mais à l’échelle globale. 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 :
- Un espace de travail de journaux Azure Monitor, y compris les solutions sélectionnées
- Un compte Azure 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, y compris un hub Virtual WAN
- Réseaux virtuels Azure
- Passerelle VPN
- Passerelle Azure ExpressRoute
- Pare-feu Azure
- Plans Azure DDoS Protection
- Zones DNS privées Azure, y compris les zones pour Azure Private Link
- Groupes de ressources, pour contenir les ressources précédentes
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 après avoir terminé le déploiement initial de votre architecture de zone d’atterrissage Azure. Par exemple, si vous utilisez Azure Site Recovery pour activer la récupération d’urgence pour vos machines virtuelles, vous voudrez peut-être les répliquer dans une autre région Azure. Pour ajouter des régions Azure à votre architecture de zone d’atterrissage Azure, tenez compte des recommandations suivants :
| Zone | Recommandation |
|---|---|
| Groupes d’administration | Aucune action requise. Les groupes d’administration ne sont pas liés à une région. Vous ne devez pas créer une structure de groupe d’administration basée sur les régions. |
| Abonnements | Les abonnements ne sont pas liés à une région. |
| Azure Policy | Apportez des modifications dans Azure Policy 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 ». Mettez à jour ces attributions pour autoriser les déploiements de ressources vers la nouvelle région que vous voulez activer. |
| Contrôle d’accès en fonction du rôle (RBAC) | 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 d’utiliser un seul espace de travail de journaux Azure Monitor pour toutes les régions ou de créer plusieurs espaces de travail pour couvrir diverses régions géographiques. Chaque approche présente des avantages et des inconvénients, notamment des frais possibles de mise en réseau inter-régions. Pour en savoir plus, reportez-vous à Concevoir une architecture d'espace de travail Log Analytics. |
| Mise en réseau | Si vous déployez 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 (Domain Name System), vous pouvez également déployer des redirecteurs, si vous les utilisez, 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 Azure DNS sont des ressources globales et ne sont pas liées à une seule région Azure, elles ne nécessitent donc aucune action. |
| Identité | Si vous avez déployé Active Directory Domain Services ou Microsoft Entra Domain Services dans votre abonnement ou 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 vos régions et services prennent en charge les zones de disponibilité.
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-and-spoke traditionnelle
Conseil
Consultez une architecture hub-and-spoke traditionnelle.
Décidez si vous avez besoin d’un nouvel abonnement de zone d’atterrissage de plateforme. Nous recommandons à la plupart des clients d’utiliser leurs abonnements Connectivité existants, même lorsqu’ils utilisent plusieurs régions.
Dans l’abonnement, créez un groupe de ressources dans la nouvelle région cible.
Créez un réseau virtuel hub dans la nouvelle région cible.
Le cas échéant, déployez Pare-feu Azure ou des appliances virtuelles réseau (NVA) dans votre nouveau réseau virtuel hub.
Le cas échéant, déployez des passerelles de réseau virtuel pour la connectivité VPN 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.
Établissez un appairage de réseau virtuel entre le nouveau réseau virtuel hub et les autres réseaux virtuels hub.
Créez et configurez le routage requis, comme Serveur de routes Azure ou des itinéraires définis par l’utilisateur.
Si nécessaire, déployez des redirecteurs DNS pour la nouvelle région de destination et reliez-les à toute zone DNS privée pour activer la résolution de noms.
- Certains clients peuvent configurer la résolution de noms sur leurs contrôleurs domaine Windows Server Active Directory dans l’abonnement à la zone d’atterrissage de la plateforme d’identité.
Pour héberger vos charges de travail, vous pouvez ensuite utiliser l’appairage de réseaux virtuels pour connecter des spokes de zone d’atterrissage d’application au nouveau réseau virtuel hub de la nouvelle région.
Conseil
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
Consultez une architecture Virtual WAN.
Dans le réseau Virtual WAN existant, créez un hub virtuel dans la nouvelle région cible.
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 Virtual WAN pour acheminer le trafic via le nouveau hub virtuel sécurisé.
Le cas échéant, déployez des passerelles de réseau virtuel pour la connectivité VPN 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.
Créez et configurez tout autre routage dont vous avez besoin, par exemple des itinéraires statiques de hub virtuel.
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 utiliser l’appairage de réseaux virtuels pour connecter des spokes de zone d’atterrissage d’application au nouveau réseau virtuel hub de la nouvelle région.
Identité
Conseil
Vérifier la zone de conception de zone d’atterrissage Azure pour la gestion des identités et des accès.
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.
Créez un groupe de ressources dans la nouvelle région cible.
Créez un réseau virtuel dans la nouvelle région cible.
Établissez l’appairage de réseaux virtuels avec le nouveau réseau virtuel du hub régional dans l’abonnement de connectivité.
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
Il peut arriver que vous deviez migrer l’ensemble de votre parc 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 pays ou d’une région voisin(e) avant qu’une nouvelle région Azure ne soit lancée dans votre pays ou 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.
Remarque
Cet article fournit uniquement des informations sur la migration des composants de zone d’atterrissage de votre patrimoine. Pour plus d’informations, consultez Relocaliser les charges de travail dans le 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, car vous ne pouvez pas déplacer certaines ressources Azure d’une région à l’autre. Tenez compte des approches suivantes :
Ajouter la région de destination en tant que région supplémentaire à votre zone d’atterrissage : pour plus d’informations, consultez Ajouter une nouvelle région à une zone d’atterrissage existante.
Déployer des composants centralisés dans la région de destination : par exemple, déployez un nouvel espace de travail de journaux Azure Monitor dans votre région de destination afin que les charges de travail puissent commencer à utiliser le nouveau composant après que vous ayez migré la charge de travail.
Migrer vos charges de travail de la région source vers la région de destination : au cours du processus de migration de la charge de travail, reconfigurez les ressources pour utiliser les composants réseau, les composants d’identité, l’espace de travail de journaux Azure Monitor et d’autres ressources régionales de la région de destination.
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 : utilisez Bicep, des modèles Azure Resource Manager (modèles ARM), Terraform, des scripts ou une approche similaire pour exporter et réimporter des configurations complexes, telles que des règles pour Azure Firewall.
Automation : utilisez des scripts pour migrer les ressources Automation entre les régions.
ExpressRoute : déterminez si vous pouvez utiliser la référence SKU 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.