Överföra en befintlig Azure-miljö till konceptarkitekturen för Azure-landningszonen

  • Artikel

Många organisationer har ett befintligt Azure-fotavtryck, en eller flera prenumerationer och potentiellt en befintlig hanteringsgruppsstruktur. Beroende på deras affärskrav och scenarier kan de ha Azure-resurser distribuerade, till exempel Azure VPN Gateway eller Azure ExpressRoute för hybridanslutning.

Den här artikeln innehåller rekommendationer som hjälper din organisation att navigera i ändringar baserat på din befintliga Azure-miljö som övergår till den konceptuella arkitekturen i Azure-landningszonen. I den här artikeln beskrivs även överväganden för att flytta resurser i Azure, till exempel att flytta en prenumeration från en befintlig hanteringsgrupp till en annan hanteringsgrupp. Överväg de här rekommendationerna som hjälper dig att utvärdera och planera övergången för din befintliga Azure-miljö.

Flytta resurser i Azure

Du kan flytta vissa resurser i Azure när du har skapat dem. Det finns olika metoder som omfattas av en användares RBAC-behörigheter (Rollbaserad åtkomstkontroll) i Azure i och över omfång. I följande tabell beskrivs vilka resurser du kan flytta, med vilket omfång och för- och nackdelar som är associerade med varje resurs.

Omfattning Mål Pro Nackdelar
Resurser i resursgrupper. Du kan flytta till en ny resursgrupp i samma eller en annan prenumeration. Du kan ändra resurssammansättningen i en resursgrupp efter distributionen. Stöds inte av alla resourceTypes.

Vissa resourceTypes har specifika begränsningar eller krav.

resourceIds uppdateras och påverkar befintliga åtgärder för övervakning, aviseringar och kontrollplan.

Resursgrupper låses under flyttperioden.

Kräver en utvärdering av principer och RBAC-förflyttning och efterflyttning.
Prenumerationer i en klientorganisation. Du kan flytta till olika hanteringsgrupper. Ingen effekt på befintliga resurser i prenumerationen eftersom resourceId-värden inte ändras. Kräver en utvärdering av principer och RBAC-förflyttning och efterflyttning.

Tänk på följande exempel för att avgöra vilken flyttstrategi du ska använda.

Flytta prenumerationer

Vanligtvis flyttar du prenumerationer för att organisera dem i hanteringsgrupper eller för att överföra prenumerationer till en ny Microsoft Entra-ID-klientorganisation. Att flytta en prenumeration till en ny klientorganisation är främst till för att överföra faktureringsägarskapet. Mer information om hur du flyttar prenumerationer mellan hanteringsgrupper i samma klient finns i Flytta hanteringsgrupper och prenumerationer.

Krav för Azure RBAC

För att utvärdera en prenumeration före en flytt är det viktigt att användaren har rätt Azure RBAC. Användaren kan vara ägare till prenumerationen (direkt rolltilldelning) och ha skrivbehörighet för målhanteringsgruppen. Inbyggda roller som har stöd för skrivbehörighet i målhanteringsgruppen är ägarrollen, deltagarrollen och hanteringsgruppens deltagarroll.

Om användaren har en ärvd ägarrollbehörighet för prenumerationen från en befintlig hanteringsgrupp kan du bara flytta prenumerationen till den hanteringsgrupp där användaren har tilldelats ägarrollen.

Principer

Befintliga prenumerationer kan omfattas av Azure-principer som tilldelas direkt eller tilldelas i hanteringsgruppen där de för närvarande finns. Det är viktigt att utvärdera aktuella principer och de principer som kan finnas i den nya hanteringsgruppen eller hanteringsgruppshierarkin.

Du kan använda Azure Resource Graph för att utföra en inventering av befintliga resurser och jämföra deras konfiguration med de principer som finns på målet.

När du har flyttat prenumerationer till en hanteringsgrupp med befintliga Azure RBAC och principer på plats bör du tänka på följande faktorer:

  • För alla Azure RBAC som ärvs till de flyttade prenumerationerna kan det ta upp till 30 minuter att uppdatera användartoken i hanteringsgruppens cacheminne. För att påskynda den här processen kan du uppdatera token genom att logga ut och in, eller begära en ny token.

  • En princip där tilldelningsomfånget innehåller de flyttade prenumerationerna utför endast en granskning av befintliga resurser. En befintlig resurs i prenumerationen som omfattas av en:

    • DeployIfNotExists principeffekten visas som inkompatibel och åtgärdas inte automatiskt. En användare måste utföra reparationen manuellt.

    • Deny principeffekten visas som inkompatibel och avvisas inte. En användare måste åtgärda det här resultatet manuellt efter behov.

    • Append och Modify principeffekten visas som inkompatibel och kräver att en användare minimerar.

    • Audit och AuditIfNotExist principeffekten visas som inkompatibel och kräver att en användare minimerar.

  • Alla nya skrivningar till resurser i den flyttade prenumerationen omfattas av de tilldelade principerna i realtid som normalt.

Flytta resurser

Vanligtvis flyttar du resurser när du vill konsolidera resurser till samma resursgrupp om de delar samma livscykel. Eller om du vill flytta resurser till en annan prenumeration på grund av krav på kostnad, ägarskap eller Azure RBAC.

När du flyttar resurser låses källresursgruppen och målresursgruppen under flyttåtgärden. Du kan inte lägga till, uppdatera eller ta bort resurser i resursgrupperna. En resursflyttningsåtgärd ändrar inte platsen för resurserna.

Mer information om hur du flyttar resurser mellan resursgrupper och prenumerationer i samma klient finns i Flytta resurser till en ny resursgrupp eller prenumeration.

Dricks

För att minimera effekten av regionala avbrott rekommenderar vi att du placerar resurser i samma region som resursgruppen. Mer information finns i Resursgruppsplatsjustering.

Om du har resurser i olika regioner inom samma resursgrupp kan du överväga att flytta dina resurser till en ny resursgrupp eller prenumeration.

Om du vill ta reda på om din resurs har stöd för att flytta till en annan resursgrupp inventerar du dina resurser genom att korsreferera dem. Se till att du uppfyller lämpliga förutsättningar.

Innan du flyttar resurser

Innan en flyttåtgärd måste du kontrollera att resurserna stöds och utvärdera deras krav och beroenden. När du till exempel flyttar ett peer-kopplat virtuellt nätverk måste du först inaktivera peering för virtuella nätverk och återaktivera peering när flyttåtgärden har slutförts. Planera i förväg för att inaktivera och återaktivera beroendet så att du förstår effekten på befintliga arbetsbelastningar som kan vara anslutna till dina virtuella nätverk.

När du har flyttat resurser

När du flyttar resurserna till en ny resursgrupp i samma prenumeration gäller fortfarande alla ärvda Azure RBAC och principer från hanteringsgruppen eller prenumerationen. Detta gäller även om du flyttar till en resursgrupp i en ny prenumeration där prenumerationen kan omfattas av annan Azure RBAC och principtilldelning. Du måste verifiera resursefterlevnads- och åtkomstkontrollerna.

Scenarier

Följande scenarier beskriver hur du migrerar och övergår en befintlig miljö till den konceptuella arkitekturen i Azure-landningszonen.

Resa mot målarkitekturen