Scénario : Transition d'un abonnement unique sans groupe d'administration 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 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 mise en œuvre actuelle limite leur évolutivité et leur croissance liées à leur stratégie cloud first.

Dans le cadre de cette expansion, ils prévoient de migrer de leurs centres de données sur site vers Azure. Au cours de la migration, ils mènent la modernisation et la transformation de leurs applications ou services pour utiliser des technologies cloud natives lorsque cela est possible. Par exemple, il peut utiliser Azure SQL Database et Azure Kubernetes Service (AKS). Ils savent que cela demande beaucoup de temps et d’efforts, c’est pourquoi ils prévoient de se déplacer pour commencer. Initialement, ce plan nécessite une connectivité hybride via des services tels que Azure passerelle VPN ou Azure ExpressRoute.

Le client souhaite passer de son approche existante à une architecture à l’échelle de l’entreprise. Cette architecture prend en charge leur stratégie cloud first et dispose d'une plate-forme robuste qui évolue à mesure que le client élimine ses centres de données sur site.

État actuel

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

• Une seule souscription Azure.
• Aucun groupe d’administration personnalisé.
• Répartition non uniforme des ressources. 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 d’Azure Policy, telles que les effets d'audit et les effets de refus, sont effectuées pour chaque groupe de ressources, à quelques exceptions près.
• Groupes de ressources traités comme des unités de gestion et d’échelle.
• Attributions de rôles de contrôle d'accès basées sur les rôles pour chaque groupe de ressources.
• Un seul réseau virtuel.
  • Pas de connectivité hybride via des services tels que Azure passerelle VPN ou Azure ExpressRoute.
  • Un nouveau sous-réseau est créé pour chaque application.
• Plusieurs applications autonomes dans chacun des groupes 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.

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

Avant de mettre en œuvre cette approche, examinez l’architecture conceptuelle 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 des zones 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.

2. (Facultatif) Travaillez 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 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éer des abonnements Azure pour fournir des zones d’atterrissage qui peuvent prendre en charge des projets de migration localement. 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 réalisé ses plans d’expansion et de mise à l’échelle au sein d’Azure en déployant l’architecture conceptuelle de la zone d’atterrissage Azure en parallèle à son environnement existant.