Een bestaande Azure-omgeving overschakelen naar de conceptuele architectuur van de Azure-landingszone

  • Artikel

Veel organisaties hebben een bestaande Azure-footprint, een of meer abonnementen en mogelijk een bestaande beheergroepstructuur. Afhankelijk van hun zakelijke vereisten en scenario's kunnen Azure-resources zijn geïmplementeerd, zoals Azure VPN Gateway of Azure ExpressRoute voor hybride connectiviteit.

Dit artikel bevat aanbevelingen om uw organisatie te helpen bij het navigeren door wijzigingen op basis van uw bestaande Azure-omgeving die overgaat naar de conceptuele architectuur van de Azure-landingszone. In dit artikel worden ook overwegingen beschreven voor het verplaatsen van resources in Azure, bijvoorbeeld het verplaatsen van een abonnement van de ene bestaande beheergroep naar een andere beheergroep. Overweeg deze aanbevelingen om u te helpen bij het evalueren en plannen van de overgang van uw bestaande Azure-omgeving.

Resources verplaatsen in Azure

U kunt enkele resources in Azure verplaatsen na het maken. Er zijn verschillende benaderingen die onderhevig zijn aan de azure RBAC-machtigingen (op rollen gebaseerd toegangsbeheer) van een gebruiker op en binnen verschillende bereiken. De volgende tabel bevat een overzicht van de resources die u kunt verplaatsen, op welk bereik en de voor- en nadelen die aan elke resource zijn gekoppeld.

Bereik Doel Pro Con
Resources in resourcegroepen. U kunt naar een nieuwe resourcegroep in hetzelfde of een ander abonnement gaan. U kunt de samenstelling van de resource in een resourcegroep wijzigen na de implementatie. Niet ondersteund door alle resourceTypes.

Sommige resourceTypes hebben specifieke beperkingen of vereisten.

resourceIds worden bijgewerkt en heeft invloed op bestaande bewakings-, waarschuwingen- en besturingsvlakbewerkingen.

Resourcegroepen worden vergrendeld tijdens de verplaatsingsperiode.

Vereist een evaluatie van beleidsregels en RBAC-bewerking vóór verplaatsing en na verplaatsing.
Abonnementen in een tenant. U kunt naar verschillende beheergroepen gaan. Geen effect op bestaande resources binnen het abonnement omdat resourceId-waarden niet worden gewijzigd. Vereist een evaluatie van beleidsregels en RBAC-bewerking vóór verplaatsing en na verplaatsing.

Bekijk de volgende voorbeelden om te bepalen welke verplaatsingsstrategie u moet gebruiken.

Abonnementen verplaatsen

Normaal gesproken verplaatst u abonnementen om ze te organiseren in beheergroepen of om abonnementen over te dragen naar een nieuwe Microsoft Entra ID-tenant. Het verplaatsen van een abonnement naar een nieuwe tenant is voornamelijk bedoeld voor het overdragen van het eigendom van facturering. Zie Beheergroepen en abonnementen verplaatsen voor meer informatie over het verplaatsen van abonnementen tussen beheergroepen in dezelfde tenant.

Vereisten voor Azure RBAC

Als u een abonnement wilt beoordelen vóór een verplaatsing, is het belangrijk dat de gebruiker over de juiste Azure RBAC beschikt. De gebruiker kan eigenaar zijn van het abonnement (directe roltoewijzing) en schrijfmachtigingen hebben voor de doelbeheergroep. Ingebouwde rollen die schrijfmachtigingen voor de doelbeheergroep ondersteunen, zijn de rol eigenaar, de rol inzender en de rol van inzender voor beheergroepen.

Als de gebruiker een overgenomen eigenaarsrolmachtiging heeft voor het abonnement van een bestaande beheergroep, kunt u het abonnement alleen verplaatsen naar de beheergroep waaraan de gebruiker de rol van eigenaar is toegewezen.

Beleidsregels

Bestaande abonnementen kunnen onderhevig zijn aan Azure-beleid dat rechtstreeks of toegewezen is aan de beheergroep waar ze zich momenteel bevinden. Het is belangrijk om het huidige beleid en de beleidsregels te evalueren die mogelijk aanwezig zijn in de nieuwe beheergroep of de hiërarchie van de beheergroep.

U kunt Azure Resource Graph gebruiken om een inventaris van bestaande resources uit te voeren en hun configuratie te vergelijken met het beleid dat op de bestemming bestaat.

Nadat u abonnementen naar een beheergroep met bestaande Azure RBAC en beleidsregels hebt verplaatst, moet u rekening houden met de volgende factoren:

  • Voor elke Azure RBAC die is overgenomen van de verplaatste abonnementen, kan het tot 30 minuten duren voordat de gebruikerstokens in de cache van de beheergroep zijn vernieuwd. Als u dit proces wilt versnellen, kunt u het token vernieuwen door u af te melden en in te loggen of een nieuw token aan te vragen.

  • Een beleid waarin het toewijzingsbereik de verplaatste abonnementen omvat, voert alleen een controle uit op de bestaande resources. Een bestaande resource in het abonnement waarvoor een:

    • DeployIfNotExists beleidseffect wordt weergegeven als niet-compatibel en wordt niet automatisch hersteld. Een gebruiker moet het herstel handmatig uitvoeren.

    • Deny beleidseffect wordt weergegeven als niet-compatibel en wordt niet geweigerd. Een gebruiker moet dit resultaat handmatig beperken.

    • Append en Modify beleidseffect wordt weergegeven als niet-compatibel en vereist dat een gebruiker dit kan beperken.

    • Audit en AuditIfNotExist beleidseffect wordt weergegeven als niet-compatibel en vereist dat een gebruiker dit kan beperken.

  • Alle nieuwe schrijfbewerkingen naar resources in het verplaatste abonnement zijn in realtime onderhevig aan het toegewezen beleid, zoals normaal.

Resources verplaatsen

Normaal gesproken verplaatst u resources wanneer u resources wilt samenvoegen in dezelfde resourcegroep als ze dezelfde levenscyclus delen. Of als u resources wilt verplaatsen naar een ander abonnement vanwege vereisten voor kosten, eigendom of Azure RBAC.

Wanneer u resources verplaatst, worden de bronresourcegroep en de doelresourcegroep vergrendeld tijdens de verplaatsingsbewerking. U kunt geen resources toevoegen, bijwerken of verwijderen in de resourcegroepen. Een verplaatsingsbewerking voor resources wijzigt de locatie van de resources niet.

Zie Resources verplaatsen naar een nieuwe resourcegroep of een nieuw abonnement voor meer informatie over het verplaatsen van resources tussen resourcegroepen en abonnementen in dezelfde tenant.

Tip

Als u het effect van regionale storingen wilt minimaliseren, raden we u aan resources in dezelfde regio als de resourcegroep te plaatsen. Zie Locatie-uitlijning van resourcegroep voor meer informatie.

Als u resources in verschillende regio's binnen dezelfde resourcegroep hebt, kunt u overwegen om uw resources te verplaatsen naar een nieuwe resourcegroep of een nieuw abonnement.

Als u wilt bepalen of uw resource ondersteuning biedt voor het verplaatsen naar een andere resourcegroep, moet u uw resources inventariseren door ze kruislings te raadplegen. Zorg ervoor dat u voldoet aan de juiste vereisten.

Voordat u resources verplaatst

Voorafgaand aan een verplaatsingsbewerking moet u controleren of de resources worden ondersteund en de vereisten en afhankelijkheden ervan beoordelen. Wanneer u bijvoorbeeld een virtueel peernetwerk verplaatst, moet u eerst peering van virtuele netwerken uitschakelen en peering opnieuw inschakelen nadat de verplaatsingsbewerking is voltooid. Plan van tevoren de afhankelijkheid uitschakelen en opnieuw inschakelen, zodat u begrijpt wat het effect is op bestaande workloads die mogelijk zijn verbonden met uw virtuele netwerken.

Nadat u resources hebt verplaatst

Wanneer u de resources verplaatst naar een nieuwe resourcegroep in hetzelfde abonnement, zijn overgenomen Azure RBAC en beleidsregels van de beheergroep of het abonnement nog steeds van toepassing. Dit geldt ook als u overstapt op een resourcegroep in een nieuw abonnement waarvoor het abonnement mogelijk onderhevig is aan andere Azure RBAC en beleidstoewijzing. U moet de naleving van resources en toegangsbeheer valideren.

Scenario's

In de volgende scenario's wordt beschreven hoe u een bestaande omgeving migreert en overgaat naar de conceptuele architectuur van de Azure-landingszone.

Reis naar de doelarchitectuur