Scénario : Transition d’un abonnement unique sans groupes d’administration vers l’architecture de référence de la zone d’atterrissage Azure

Cet article décrit les considérations et instructions relatives à la migration et à la transition de votre environnement Azure vers l’architecture de référence de la zone d’atterrissage Azure. Ce scénario couvre un seul abonnement sans groupe d’administration.

Dans ce scénario, le client utilise déjà Azure et héberge déjà quelques applications ou services au sein de la plateforme. Mais leur implémentation actuelle limite leur scalabilité et leur croissance liées à leur première stratégie cloud .

Dans le cadre de cette expansion, ils prévoient de migrer hors de leurs centres de données locaux et vers Azure. Au cours de la migration, ils commencent par moderniser et transformer leurs applications ou services afin d’utiliser les technologies natives du cloud lorsque cela est possible. Par exemple, ils peuvent utiliser Azure SQL Database et Azure Kubernetes Service (AKS). Ils savent qu’il faut beaucoup de temps et d’effort, de sorte qu’ils prévoient de soulever et de se déplacer pour commencer. Au départ, ce plan nécessite une connectivité hybride via des services tels que la passerelle VPN Azure ou Azure ExpressRoute.

Le client souhaite passer de son approche existante à une architecture à l’échelle de l’entreprise. Cette architecture prend en charge sa première stratégie cloud et dispose d’une plateforme robuste qui s’adapte à mesure que le client élimine ses centres de données locaux.

État actuel

Dans ce scénario, l’état actuel de l’environnement Azure du client se compose des éléments suivants :

• Un seul abonnement Azure.
• Aucun groupe d’administration personnalisé.
• Distribution de ressources nonuniformes. Les ressources de plateforme et de charge de travail sont déployées dans le même abonnement Azure.
• Utilisation minimale d’Azure Policy. Les affectations de stratégie, telles que les effets d’audit et les effets de refus, sont effectuées pour chaque groupe de ressources, avec des exceptions.
• Groupes de ressources traités comme des unités de gestion et d’échelle.
• Attributions de rôles de contrôle d’accès en fonction du rôle pour chaque groupe de ressources.
• Un seul réseau virtuel.
  • Aucune connectivité hybride via des services tels que la passerelle VPN Azure ou Azure ExpressRoute.
  • Un nouveau sous-réseau est créé pour chaque application.
• Plusieurs applications autonomes dans chaque groupe de ressources app-xx-rg. Les applications sont contrôlées et exploitées par différentes équipes d’application ou de service.

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

Transition vers l’architecture de référence de la zone d’atterrissage Azure

Avant d’implémenter cette approche, passez en revue l’architecture de référence des zones d’atterrissage Azure et les zones de conception de zone d’atterrissage Azure.

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

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

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

2. (Facultatif) Collaborez avec les équipes d’application ou de service pour migrer les charges de travail déployées dans l’abonnement d’origine vers de nouveaux abonnements Azure. Pour plus d’informations, consultez Transition d’environnements Azure existants vers l’architecture de référence de la zone d’atterrissage Azure. Vous pouvez placer des charges de travail dans la hiérarchie de gestion de l'architecture de référence de la zone de destination Azure récemment déployée sous le groupe de gestion approprié, tel que corporate ou online dans le diagramme suivant.

   Pour plus d’informations sur l’effet sur les ressources lors de la migration, consultez Stratégies.

   Finalement, vous pouvez annuler l’abonnement Azure existant et le placer dans le groupe d’administration désactivé.

   Note

   Vous n’avez pas nécessairement besoin 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 qui peuvent prendre en charge les projets de migration à partir d’un site local. Placez-les sous le groupe d’administration 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 sur la migration.

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

Résumé

Dans ce scénario, le client a accompli ses plans d’expansion et de mise à l’échelle dans Azure en déployant l’architecture de référence de zone d’atterrissage Azure en parallèle avec son environnement existant.