Scénario : Transition d'un environnement d'organisation régionale vers l'architecture conceptuelle de la zone d'atterrissage Azure

Cet article décrit les considérations et les instructions pour migrer et faire la transition de votre environnement Azure vers l’architecture conceptuelle de la zone d’atterrissage Azure. Ce scénario couvre une organisation régionale avec des groupes de gestion séparés en environnements de développement, de test et de production (dev/test/prod).

Dans ce scénario, le client dispose d’une empreinte importante sur Azure. Ils ont une hiérarchie de groupes de gestion organisée par environnements dev/test/prod, puis par région. Leur mise en œuvre actuelle limite leur évolutivité et leur croissance. Ils ont des applications déployées à travers le monde. Une équipe informatique centrale gère chaque région. Dans ce scénario, les régions sont l’Amérique ; Europe, Moyen-Orient et Afrique (EMEA) ; et Asie-Pacifique (APAC).

Le client souhaite passer de son environnement existant à l’architecture conceptuelle des zones d’atterrissage Azure. Cette approche soutient leur stratégie cloud first et dispose d'une plate-forme robuste qui évolue à mesure que le client met hors service ses centres de données sur site.

État actuel

Dans ce scénario, l’état actuel de l’environnement Azure du client comprend :

• Plusieurs groupes de gestion.
• Une hiérarchie de groupes de gestion basée sur les environnements dev/test/prod au premier niveau puis basée sur la géographie au deuxième niveau.
• Une souscription Azure pour chaque zone géographique et environnement d'application, tel que dev/test/prod. Cette souscription est requise pour offrir aux développeurs un environnement détendu pour les tests et l'innovation.
• Certaines charges de travail critiques nécessitent le même modèle de gouvernance dans tous les domaines de développement/test/production, ce qui peut créer des défis de gouvernance pour le client.
• Répartition non uniforme des ressources. Les ressources de plateforme et de charge de travail pour un environnement unique sont déployées dans les mêmes abonnements Azure.
• Applications déployées dans les abonnements respectifs en fonction de leur classification de région et d'environnement, comme dev/test/prod.
• Affectations d’Azure Policy, telles que les effets d'audit et les effets de refus, attribuées au niveau du groupe d'administration et de la souscription.
• Le même ensemble de stratégies Azure appliquées à toutes les applications de la même région et du même type d’environnement.
• Attributions de rôles de contrôle d'accès basées sur les rôles pour chaque abonnement et groupe de ressources.
• Un réseau virtuel hub, tel qu’Azure passerelle VPN ou Azure ExpressRoute, pour une connectivité hybride.
• Un réseau virtuel pour chaque environnement d'application.
• Une équipe informatique centrale qui contrôle et exploite le groupe de direction respectif pour chaque région. L'équipe est confrontée à des problèmes de cohérence, de configuration et de conformité en matière de politiques, de contrôle d'accès, de configuration des ressources de la plateforme et de conformité en matière de sécurité, car certaines applications sont déployées dans plusieurs régions.

Le diagramme suivant montre l’état actuel de cet exemple de scénario.

Passage à l’architecture conceptuelle de la zone d’atterrissage Azure

Avant de mettre en œuvre cette approche, passez en revue l’architecture conceptuelle de la zone d’atterrissage Azure, les principes de conception de la zone d’atterrissage Azure et les zones de conception de la zone d’atterrissage Azure.

Pour passer de l’état actuel de ce scénario à une architecture conceptuelle de zone d’atterrissage Azure, utilisez cette approche :

1. Déployez l'accélérateur de zone d'atterrissage Azure dans le même locataire Microsoft Entra ID en parallèle avec l'environnement actuel. Cette méthode permet une transition fluide et progressive vers la nouvelle architecture de zone d'atterrissage avec une perturbation minimale des charges de travail actives.

   Ce déploiement crée une nouvelle structure de groupe d'administration. Cette structure s’aligne sur les principes et suggestions de conception des zones d’atterrissage Azure. Cela garantit également que ces changements n’affectent pas l’environnement existant.

   Pour plus d’informations, consultez Comment gérer une zone d’atterrissage de charge de travail dev/test/prod.

   Pour plus d’informations sur l’utilisation de la hiérarchie des groupes d’administration sandbox pour permettre aux développeurs de tester et d’expérimenter sans affecter les autres environnements, consultez les conseils sur les environnements sandbox de la zone d’atterrissage Azure.

   Pour plus d'informations sur la manière de minimiser les interruptions des applications et des services pendant la migration, consultez Adopter des conseils de garde-fous basés sur des stratégies.

2. (Facultatif) Travaillez avec les équipes d'application ou de service pour migrer les charges de travail déployées dans les abonnements d'origine vers de nouveaux abonnements Azure. Pour plus d’informations, consultez l’article Migrer des environnements Azure existants vers l’architecture conceptuelle de la zone d’atterrissage Azure. Vous pouvez placer les charges de travail dans la hiérarchie du groupe de gestion de l’architecture conceptuelle de la zone d’atterrissage Azure nouvellement déployée sous le groupe de gestion approprié, tel que l’entreprise ou en ligne dans le diagramme suivant.

   Pour plus de détails sur l'effet sur les ressources lors de la migration, voir Stratégies.

   Finalement, vous pouvez annuler l’abonnement Azure existant et le placer dans le groupe d’administration mis hors service.

   Remarque

   Vous n’êtes pas nécessairement obligé de migrer les applications ou services existants vers de nouvelles zones d’atterrissage ou des abonnements Azure.

3. Créez de nouveaux abonnements Azure pour fournir des zones d’atterrissage capables de prendre en charge de nouvelles applications et charges de travail. Placez-les sous le groupe de gestion approprié, tel que l'entreprise ou en ligne dans le diagramme suivant.

   Pour plus d'informations, consultez Préparer votre zone d'atterrissage pour obtenir des conseils de migration.

Le diagramme suivant montre l'état de ce scénario pendant la migration.

Résumé

Dans ce scénario, le client a établi les bases nécessaires pour prendre en charge ses plans de croissance et d’évolutivité pour ses charges de travail dans Azure en déployant l’architecture conceptuelle de la zone d’atterrissage Azure en parallèle à son environnement existant.