Scenario: Één abonnement zonder beheergroepen overdragen naar de referentiearchitectuur van de Azure-landingszone

In dit artikel worden overwegingen en instructies beschreven voor het migreren en overstappen van uw Azure-omgeving naar de referentiearchitectuur van de Azure-landingszone. In dit scenario wordt één abonnement zonder beheergroepen behandeld.

In dit scenario maakt de klant al gebruik van Azure en host deze al enkele toepassingen of services binnen het platform. Maar hun huidige implementatie beperkt hun schaalbaarheid en groei met betrekking tot hun eerste cloudstrategie .

Als onderdeel van deze uitbreiding zijn ze van plan om hun on-premises datacenters te migreren naar Azure. Tijdens de migratie geven ze prioriteit aan het moderniseren en transformeren van hun toepassingen of diensten om, waar mogelijk, gebruik te maken van cloud-native technologieën. Ze kunnen bijvoorbeeld Azure SQL Database en Azure Kubernetes Service (AKS) gebruiken. Ze weten dat het veel tijd en moeite kost, dus ze zijn van plan om op te tillen en te verschuiven om te beginnen. In eerste instantie vereist dit plan hybride connectiviteit via services zoals Azure VPN Gateway of Azure ExpressRoute.

De klant wil overstappen van hun bestaande benadering naar een architectuur op ondernemingsniveau. Deze architectuur ondersteunt hun eerste cloudstrategie en heeft een robuust platform dat wordt geschaald naarmate de klant hun on-premises datacenters elimineert.

Huidige status

In dit scenario bestaat de huidige status van de Azure-omgeving van de klant uit:

• Eén Azure-abonnement.
• Geen aangepaste beheergroepen.
• Niet-uniforme resourceverdeling. Platform- en workloadresources worden geïmplementeerd in hetzelfde Azure-abonnement.
• Minimaal gebruik van Azure Policy. Beleidstoewijzingen, zoals controle-effecten en weigeringseffecten, worden uitgevoerd voor elke resourcegroep, met uitzonderingen.
• Resourcegroepen die beschouwd worden als beheereenheden en schaaleenheden.
• Roltoewijzingen voor op rollen gebaseerd toegangsbeheer voor elke resourcegroep.
• Eén virtueel netwerk.
  • Geen hybride connectiviteit via services zoals Azure VPN Gateway of Azure ExpressRoute.
  • Er wordt een nieuw subnet gemaakt voor elke toepassing.
• Meerdere zelfstandige toepassingen in elk van de app-xx-rg resourcegroepen. Toepassingen worden beheerd en aangestuurd door verschillende toepassings- of serviceteams.

In het volgende diagram ziet u de huidige status van dit scenario.

Overgang naar de referentiearchitectuur van de Azure-landingszone

Voordat u deze benadering implementeert, bekijkt u de referentiearchitectuur van de Azure-landingszone en ontwerpgebieden van de Azure-landingszone.

Als u wilt overstappen van de huidige status van dit scenario naar een referentiearchitectuur voor een Azure-landingszone, gebruikt u deze benadering:

1. Implementeer de Azure-landingszone in dezelfde Microsoft Entra ID-tenant parallel met de huidige omgeving. Deze methode biedt een soepele en gefaseerde overgang naar de nieuwe landingszonearchitectuur met minimale onderbreking van actieve workloads.

   Met deze implementatie maakt u een nieuwe structuur voor beheergroepen. Deze structuur is afgestemd op ontwerpprincipes en aanbevelingen voor Azure-landingszones. Het zorgt er ook voor dat deze wijzigingen geen invloed hebben op de bestaande omgeving.

2. (Optioneel) Werk samen met toepassings- of serviceteams om de workloads te migreren die in het oorspronkelijke abonnement zijn geïmplementeerd in nieuwe Azure-abonnementen. Zie Bestaande Azure-omgevingen overschakelen naar de referentiearchitectuur van de Azure-landingszone voor meer informatie. In het volgende diagram kunt u workloads plaatsen in de zojuist geïmplementeerde referentiearchitectuurhiërarchie van de Azure-landingszone onder de juiste beheergroep, zoals corporate of online.

   Zie Beleid voor meer informatie over het effect op resources tijdens de migratie.

   Uiteindelijk kunt u het bestaande Azure-abonnement opzeggen en in de buiten gebruik gestelde beheergroep plaatsen.

   Opmerking

   U hoeft de bestaande toepassingen of services niet per se te migreren naar nieuwe landingszones of Azure-abonnementen.

3. Maak nieuwe Azure-abonnementen om landingszones te bieden die migratieprojecten van on-premises kunnen ondersteunen. Plaats ze onder de juiste beheergroep, zoals zakelijk of online , in het volgende diagram.

   Zie Uw landingszone voorbereiden voor migratierichtlijnen voor meer informatie.

In het volgende diagram ziet u de status van dit scenario tijdens de migratie.

Samenvatting

In dit scenario heeft de klant hun uitbreidings- en schaalplannen binnen Azure uitgevoerd door de referentiearchitectuur van de Azure-landingszone parallel aan hun bestaande omgeving te implementeren.