Szenario: Umstellen von Verwaltungsgruppen zur konzeptionellen Azure-Zielzonenarchitektur

Dieser Artikel beschreibt Überlegungen und Anleitungen zur Migration und Umstellung Ihrer bestehenden Umgebung auf die konzeptionelle Azure-Zielzonenarchitektur. Dieses Szenario gilt für einzelne oder mehrere Verwaltungsgruppen.

In diesem Szenario wird davon ausgegangen, dass der oder die Kund*in bereits Azure nutzt. Es ist eine Verwaltungsgruppenhierarchie mit mehreren Abonnements vorhanden, die einige Anwendungen oder Dienste innerhalb der Plattform hosten. Die aktuelle Implementierung beschränkt jedoch die Skalierbarkeit und das mögliche Wachstum einer Cloud First-Strategie.

Im Rahmen dieser Expansion ist geplant, von lokalen Rechenzentren auf Azure umzusteigen. Während der Migration werden Anwendungen oder Dienste modernisiert und nach Möglichkeit auf cloudnative Technologien umgestellt. Beispielsweise können Azure SQL-Datenbank und Azure Kubernetes Service (AKS) dazu genutzt werden. Es ist bekannt, dass die Umstellung viel Zeit und Anstrengung in Anspruch wird, daher ist eine Lift & Shift-Strategie geplant. Zunächst erfordert dieser Plan hybride Konnektivität über Dienste wie Azure VPN Gateway oder Azure ExpressRoute.

Der oder Kund*in möchte die vorhandene Umgebung in die konzeptionelle Azure-Zielzonenarchitektur verschieben. Diese Architektur unterstützt die Cloud First-Strategie und verfügt über eine robuste Plattform, die skaliert wird, während die lokalen Rechenzentren außer Betrieb genommen werden.

Aktueller Status

In diesem Szenario sieht die aktuelle Azure-Umgebung wie folgt aus:

• Eine oder mehrere Verwaltungsgruppen.
• Eine Verwaltungsgruppenhierarchie, die auf Organisationsstruktur oder Geografie basiert.
• Ein Azure-Abonnement für jede Anwendungsumgebung, z. B. Entwicklung, Test oder Produktion (dev/test/prod).
• Keine einheitliche Ressourcenverteilung. Plattform- und Workloadressourcen für eine einzige Umgebung werden im gleichen Azure-Abonnement bereitgestellt.
• Richtlinienzuweisungen mit Überprüfungseffekten und Verweigerungseffekten, die auf Verwaltungsgruppen- und Abonnementebene zugewiesen sind.
• Rollenzuweisungen für rollenbasierte Zugriffssteuerung für jedes Abonnement und jede Ressourcengruppe.
• Ein virtuelles Hub-Netzwerk, wie z. B. Azure VPN Gateway oder Azure ExpressRoute für hybride Konnektivität.
• Ein virtuelles Netzwerk für jede Anwendungsumgebung.
• Anwendungen, die auf der Grundlage ihrer Umgebungsklassifizierung (z. B. Entwicklung, Test oder Produktion) im jeweiligen Abonnement bereitgestellt werden.
• Ein zentrales IT-Team, das die Umgebung steuert und betreibt.

Das folgende Diagramm zeigt den aktuellen Zustand dieses Szenarios.

Übergang zur konzeptionellen Architektur der Azure-Zielzone

Überprüfen Sie vor der Implementierung dieses Ansatzes die konzeptionelle Azure-Zielzonenarchitektur, die Entwurfsprinzipien für Azure-Zielzonen und Entwurfsbereiche für Azure-Zielzonen.

Für den Wechsel vom aktuellen Zustand dieses Szenarios zu einer konzeptionellen Azure-Zielzonenarchitektur sollten Sie den folgenden Ansatz verwenden:

1. Stellen Sie den Beschleuniger für Azure-Zielzonen parallel zur aktuellen Umgebung im selben Microsoft Entra ID-Mandanten bereit. Diese Methode bietet einen reibungslosen und schrittweisen Übergang zur neuen Zielzonenarchitektur mit minimalen Unterbrechungen für aktive Workloads.

   Durch diese Bereitstellung wird eine neue Verwaltungsgruppenstruktur erstellt. Diese Struktur ist an den Entwurfsprinzipien und Empfehlungen für Azure-Zielzonen ausgerichtet. Außerdem wird sichergestellt, dass die vorhandene Umgebung von diesen Änderungen nicht betroffen ist.

   Weitere Informationen finden Sie unter Umgang mit einer Entwicklungs-/Test-/Produktions-Workload-Zielzone.

2. (Optional) Arbeiten Sie mit Anwendungs- oder Serviceteams zusammen, um die Workloads, die in den ursprünglichen Abonnements bereitgestellt wurden, in neue Azure-Abonnements zu migrieren. Weitere Informationen finden Sie unter Übertragen einer vorhandenen Azure-Umgebung in die konzeptionelle Azure-Zielzonenarchitektur. Sie können Workloads in der neu eingerichteten Verwaltungsgruppenhierarchie der konzeptionellen Azure-Zielzonenarchitektur in der richtigen Verwaltungsgruppe platzieren, wie z. B. unternehmenseigen oder online in der folgenden Abbildung.

   Details zu den Auswirkungen auf Ressourcen bei der Migration finden Sie unter Richtlinien.

   Schließlich können Sie das bestehende Azure-Abonnement kündigen und es in die außer Betrieb gesetzte Verwaltungsgruppe aufnehmen.

   Hinweis

   Sie müssen nicht unbedingt die bestehenden Anwendungen oder Dienste in neue Zielzonen oder Azure-Abonnements migrieren.

3. Erstellen Sie neue Azure-Abonnements zur Bereitstellung von Zielzonen, die Migrationsprojekte von lokalen Standorten unterstützen. Platzieren Sie diese in der richtigen Verwaltungsgruppe, z. B. unternehmenseigen oder online in der folgenden Abbildung.

   Weitere Informationen finden Sie unter Vorbereiten Ihrer Zielzone für die Migration.

Die folgende Abbildung zeigt den Status dieses Szenarios während der Migration.

Zusammenfassung

In diesem Szenario hat der oder die Kund*in Expansions- und Skalierungspläne innerhalb von Azure verwirklicht, indem er oder sie die konzeptionelle Azure-Zielzonenarchitektur parallel zur bestehenden Umgebung eingesetzt hat.