Eseguire la transizione di un ambiente Azure esistente all'architettura concettuale della zona di destinazione di Azure

Molte organizzazioni hanno un footprint di Azure esistente, una o più sottoscrizioni e potenzialmente una struttura del gruppo di gestione esistente. A seconda dei requisiti aziendali e degli scenari, potrebbero essere distribuite risorse di Azure, ad esempio Azure Gateway VPN o Azure ExpressRoute per la connettività ibrida.

Questo articolo fornisce raccomandazioni che consentono all'organizzazione di esplorare le modifiche in base all'ambiente di Azure esistente che sta passando all'architettura concettuale della zona di destinazione di Azure. Questo articolo descrive anche le considerazioni per lo spostamento delle risorse in Azure, ad esempio lo spostamento di una sottoscrizione da un gruppo di gestione esistente a un altro gruppo di gestione. Prendere in considerazione questi consigli per valutare e pianificare la transizione dell'ambiente Azure esistente.

Spostare le risorse in Azure

È possibile spostare alcune risorse in Azure dopo la creazione. Esistono diversi approcci soggetti alle autorizzazioni di controllo degli accessi in base al ruolo (RBAC) di Azure in e in ambiti diversi. Nella tabella seguente vengono illustrate le risorse che è possibile spostare, in base all'ambito e ai vantaggi e ai svantaggi associati a ogni risorsa.

Ambito	Destinazione	Vantaggi	Svantaggi
Risorse nei gruppi di risorse.	È possibile passare a un nuovo gruppo di risorse nella stessa sottoscrizione o in una sottoscrizione diversa.	È possibile modificare la composizione delle risorse in un gruppo di risorse dopo la distribuzione.	Non supportato da tutti i tipi di risorsa. Alcuni resourceType presentano limitazioni o requisiti specifici. I ResourceId vengono aggiornati e influiscono sulle operazioni esistenti di monitoraggio, avvisi e piano di controllo. I gruppi di risorse vengono bloccati durante il periodo di spostamento. Richiede una valutazione dei criteri e dell'operazione di pre-spostamento e post-spostamento del controllo degli accessi in base al ruolo.
Sottoscrizioni in un tenant.	È possibile passare a gruppi di gestione diversi.	Nessun effetto sulle risorse esistenti all'interno della sottoscrizione perché i valori resourceId non cambiano.	Richiede una valutazione dei criteri e dell'operazione di pre-spostamento e post-spostamento del controllo degli accessi in base al ruolo.

Per determinare la strategia di spostamento da usare, prendere in considerazione gli esempi seguenti.

Spostare sottoscrizioni

In genere, si spostano le sottoscrizioni per organizzarle in gruppi di gestione o per trasferire sottoscrizioni a un nuovo tenant di Microsoft Entra ID. Lo spostamento di una sottoscrizione in un nuovo tenant è destinato principalmente al trasferimento della proprietà di fatturazione. Per altre informazioni su come spostare le sottoscrizioni tra gruppi di gestione nello stesso tenant, vedere Spostamento di gruppi di gestione e sottoscrizioni.

Requisiti del controllo degli accessi in base al ruolo di Azure

Per valutare una sottoscrizione prima di uno spostamento, è importante che l'utente disponga del controllo degli accessi in base al ruolo di Azure appropriato. L'utente potrebbe essere un proprietario della sottoscrizione (assegnazione di ruolo diretta) e disporre dell'autorizzazione di scrittura per il gruppo di gestione di destinazione. I ruoli predefiniti che supportano l'autorizzazione di scrittura per il gruppo di gestione di destinazione sono il ruolo proprietario, il ruolo collaboratore e il ruolo collaboratore del gruppo di gestione.

Se l'utente dispone di un'autorizzazione di ruolo proprietario ereditata per la sottoscrizione da un gruppo di gestione esistente, è possibile spostare solo la sottoscrizione nel gruppo di gestione in cui all'utente viene assegnato il ruolo di proprietario.

Criteri

Le sottoscrizioni esistenti potrebbero essere soggette a criteri di Azure assegnati direttamente o assegnati al gruppo di gestione in cui si trovano attualmente. È importante valutare i criteri correnti e i criteri che potrebbero esistere nel nuovo gruppo di gestione o nella gerarchia dei gruppi di gestione.

È possibile usare Azure Resource Graph per eseguire un inventario delle risorse esistenti e confrontare la configurazione con i criteri esistenti nella destinazione.

Dopo aver spostato le sottoscrizioni in un gruppo di gestione con il controllo degli accessi in base al ruolo e i criteri di Azure esistenti, tenere presenti i fattori seguenti:

• Per qualsiasi controllo degli accessi in base al ruolo di Azure ereditato nelle sottoscrizioni spostate, l'aggiornamento dei token utente nella cache dei gruppi di gestione potrebbe richiedere fino a 30 minuti. Per accelerare questo processo, è possibile aggiornare il token disconnessione e in oppure richiedere un nuovo token.

• Un criterio in cui l'ambito di assegnazione include le sottoscrizioni spostate esegue un controllo solo sulle risorse esistenti. Una risorsa esistente nella sottoscrizione soggetta a:

  • DeployIfNotExists l'effetto dei criteri viene visualizzato come non conforme e non viene corretto automaticamente. Un utente deve eseguire manualmente la correzione.

  • Deny l'effetto dei criteri viene visualizzato come non conforme e non viene rifiutato. Un utente deve attenuare manualmente questo risultato in base alle esigenze.

  • Append e Modify l'effetto dei criteri viene visualizzato come non conforme e richiede che un utente mitiga.

  • Audit e AuditIfNotExist l'effetto dei criteri viene visualizzato come non conforme e richiede che un utente mitiga.

• Tutte le nuove scritture nelle risorse nella sottoscrizione spostata sono soggette ai criteri assegnati in tempo reale come di consueto.

Spostare le risorse

In genere, si spostano le risorse quando si vogliono consolidare le risorse nello stesso gruppo di risorse se condividono lo stesso ciclo di vita. In alternativa, se si vogliono spostare le risorse in una sottoscrizione diversa a causa dei requisiti di costo, proprietà o controllo degli accessi in base al ruolo di Azure.

Quando si spostano le risorse, il gruppo di risorse di origine e il gruppo di risorse di destinazione vengono bloccati durante l'operazione di spostamento. Non è possibile aggiungere, aggiornare o eliminare risorse nei gruppi di risorse. Un'operazione di spostamento delle risorse non modifica la posizione delle risorse.

Per altre informazioni su come spostare le risorse tra gruppi di risorse e sottoscrizioni nello stesso tenant, vedere Spostare le risorse in un nuovo gruppo di risorse o sottoscrizione.

Suggerimento

Per ridurre al minimo l'effetto delle interruzioni a livello di area, è consigliabile inserire le risorse nella stessa area del gruppo di risorse. Per altre informazioni, vedere Allineamento della posizione del gruppo di risorse.

Se si dispone di risorse in aree diverse all'interno dello stesso gruppo di risorse, è consigliabile spostare le risorse in un nuovo gruppo di risorse o in una sottoscrizione.

Per determinare se la risorsa supporta lo spostamento in un altro gruppo di risorse, eseguire l'inventario delle risorse facendo riferimento incrociato. Assicurarsi di soddisfare i prerequisiti appropriati.

Prima di spostare le risorse

Prima di un'operazione di spostamento, è necessario verificare che le risorse siano supportate e valutarne i requisiti e le dipendenze. Ad esempio, quando si sposta una rete virtuale con peering, è necessario disabilitare prima il peering di rete virtuale e riabilitare il peering al termine dell'operazione di spostamento. Pianificare in anticipo la disabilitazione e riabilitare la dipendenza in modo da comprendere l'effetto sui carichi di lavoro esistenti che potrebbero essere connessi alle reti virtuali.

Dopo aver spostato le risorse

Quando si spostano le risorse in un nuovo gruppo di risorse nella stessa sottoscrizione, vengono comunque applicati tutti i criteri e il controllo degli accessi in base al ruolo di Azure ereditati dal gruppo di gestione o dalla sottoscrizione. Questo vale anche se si passa a un gruppo di risorse in una nuova sottoscrizione in cui la sottoscrizione potrebbe essere soggetta ad altre assegnazioni di criteri e controllo degli accessi in base al ruolo di Azure. È necessario convalidare la conformità delle risorse e i controlli di accesso.

Scenari

Gli scenari seguenti descrivono come eseguire la migrazione e la transizione di un ambiente esistente nell'architettura concettuale della zona di destinazione di Azure.

• Scenari di allineamento

  • Eseguire la transizione di una singola sottoscrizione senza gruppi di gestione all'architettura concettuale della zona di destinazione di Azure
  • Transizione dei gruppi di gestione all'architettura concettuale della zona di destinazione di Azure
  • Eseguire la transizione di un'organizzazione a livello di area all'architettura concettuale della zona di destinazione di Azure

• Approcci di allineamento

  • Eseguire la transizione di un ambiente duplicando un gruppo di gestione della zona di destinazione

Percorso verso l'architettura di destinazione