Domande frequenti sulla landing zone di Azure

Questo articolo risponde alle domande frequenti sull'architettura delle zone di destinazione Azure.

Per domande frequenti sull'implementazione dell'architettura Azure landing zone, vedere Domande frequenti sull'implementazione su scala aziendale.

Che cos'è l'acceleratore del portale della zona di destinazione Azure?

L'acceleratore del portale della zona di destinazione Azure è un'esperienza di distribuzione basata sul portale Azure. Distribuisce un'implementazione con parere basata sull'architettura di riferimento della zona di destinazione Azure.

Quali sono gli acceleratori e le implementazioni consigliati per Azure zone di destinazione?

Microsoft sviluppa e gestisce attivamente gli acceleratori e le implementazioni della piattaforma e delle applicazioni in linea con i principi di progettazione e le linee guida delle aree di progettazione della destinazione Azure.

Esaminare la guida Distribuire le zone di atterraggio di Azure per ulteriori informazioni sulle zone di atterraggio della piattaforma e delle applicazioni consigliate.

Per informazioni su come personalizzare la distribuzione delle zone di destinazione Azure in base alle esigenze, vedere Tailor l'architettura della zona di destinazione Azure per soddisfare i requisiti

Che cos'è l'architettura di riferimento della zona di destinazione Azure?

L'architettura di riferimento della zona di atterraggio di Azure rappresenta le decisioni sulla scalabilità e sulla maturità. Si basa su lezioni apprese e feedback dai clienti che hanno adottato Azure come parte del proprio digital estate. Questa architettura concettuale può aiutare l'organizzazione a definire una direzione per la progettazione e l'implementazione di una zona di destinazione.

Che cos'è una zona di destinazione in Azure nel contesto dell'architettura della zona di destinazione Azure?

Da un punto di vista della zona di destinazione di Azure, le landing zone sono singole sottoscrizioni Azure.

Cosa significa la governance basata su criteri e come funziona?

La governance basata su criteri è uno dei principi chiave di progettazione dell'architettura su scala aziendale.

La governance basata su criteri significa usare Criteri di Azure per ridurre il tempo necessario per le attività operative comuni e ripetute nel tenant Azure. Usare molti degli effetti Criteri di Azure, ad esempio Append, Deny, DeployIfNotExists e Modify, per impedire la conformità limitando le risorse non conformi (come definito dalla definizione dei criteri) da creare o aggiornare o distribuendo risorse o modificando le impostazioni di una richiesta di creazione o aggiornamento delle risorse per renderle conformi. Alcuni effetti, ad esempio Audit, Disablede AuditIfNotExists, non impediscono o esegono azioni, ma controllano e segnalano solo la mancata conformità.

Ecco alcuni esempi di governance basata su criteri:

• Deny effetto: impedisce la creazione o l'aggiornamento delle subnet in modo che non abbiano gruppi di sicurezza di rete associati.

• DeployIfNotExists effetto: Viene creata una nuova sottoscrizione (landing zone) e inserita in un gruppo di gestione all'interno della distribuzione della landing zone di Azure. Criteri di Azure assicura che Microsoft Defender per il cloud sia abilitato nella sottoscrizione. Configura anche le impostazioni di diagnostica per il log attività per inviare i log all'area di lavoro Log Analytics nella sottoscrizione di gestione.

  Anziché ripetere il codice o le attività manuali quando viene creata una nuova sottoscrizione, la definizione dei DeployIfNotExists criteri distribuisce e li configura automaticamente.

Cosa accade se non è possibile o non è ancora possibile usare i criteri DeployIfNotExists (DINE) ?

È disponibile una pagina dedicata che illustra le varie fasi e le opzioni per "disabilitare" i criteri DINE o per adottarli gradualmente utilizzando il nostro approccio a tre fasi all'interno del tuo ambiente.

Vedi la guida all'adozione di barriere guidate dalle politiche

È consigliabile usare Criteri di Azure per distribuire i carichi di lavoro?

In breve, no. Usare Criteri di Azure per controllare, gestire e mantenere conformi i carichi di lavoro e le zone di destinazione. Non è progettato per distribuire interi carichi di lavoro e altri strumenti. Usare il portale di Azure o le offerte di infrastruttura come codice (modelli arm, Bicep, Terraform) per distribuire e gestire il carico di lavoro e ottenere l'autonomia necessaria.

Che cos'è Cloud Adoption Framework zone di destinazione per Terraform (aztfmod)?

Le zone di destinazione Cloud Adoption Framework open source project (OSS) (note anche come aztfmod) sono un progetto guidato dalla community di proprietà e gestito al di fuori del team principale delle zone di destinazione Azure e dell'organizzazione Azure GitHub. Se l'organizzazione sceglie di usare questo progetto OSS, è necessario considerare il supporto disponibile perché questo è basato sul lavoro della community attraverso GitHub.

Cosa accade se nelle zone di destinazione sono già presenti risorse e successivamente si assegna una definizione di Criteri di Azure che le include nell'ambito?

Esaminare le sezioni della documentazione seguenti:

• Transizione degli ambienti Azure esistenti all'architettura di riferimento della landing zone Azure - sezione "Criteri"
• Guida introduttiva: Creare un'assegnazione di criteri per identificare le risorse non conformi - Sezione "Identificare le risorse non conformi"

È necessaria una zona di destinazione dedicata o separata per l'intelligenza artificiale?

No, non è necessaria una zona di destinazione di intelligenza artificiale separata. È invece possibile usare l'architettura della zona di destinazione Azure esistente per distribuire i carichi di lavoro di intelligenza artificiale. Consulta le linee guida e la spiegazione in AI nelle zone di sbarco di Azure.

Come si gestiscono le zone di destinazione del carico di lavoro "sviluppo/test/produzione" nell'architettura della zona di destinazione Azure?

Per altre informazioni, vedere Gestire gli ambienti di sviluppo di applicazioni in Azure zone di destinazione.

Perché viene chiesto di specificare Azure aree durante la distribuzione dell'architettura di riferimento della zona di destinazione Azure e per cosa vengono usate?

Quando si distribuisce l'architettura della zona di destinazione di Azure usando l'esperienza basata sul portale dell'architettura di riferimento di Azure, selezionare una regione di Azure in cui eseguire la distribuzione. La prima scheda, Percorso di distribuzione, determina dove vengono archiviati i dati di distribuzione. Per ulteriori informazioni, vedere Distribuzioni di tenant con modelli di Resource Manager. Alcune parti di una zona di destinazione vengono distribuite a livello globale, ma i relativi metadati di distribuzione vengono rilevati in un archivio metadati a livello di area. I metadati relativi alla distribuzione vengono archiviati nell'area selezionata nella scheda Percorso di distribuzione .

Il selettore di area nella scheda Deployment viene usato anche per selezionare l'area Azure in cui archiviare le risorse specifiche dell'area, ad esempio un'area di lavoro Log Analytics, se necessario.

Se si distribuisce una topologia di rete nella scheda Topologia di rete e connettività, è necessario selezionare un'area Azure in cui distribuire le risorse di rete. Questa area può essere diversa dall'area selezionata nella scheda Percorso di distribuzione .

Per altre informazioni sulle aree usate dalle risorse della zona di destinazione, vedere Aree della zona di destinazione.

Come possiamo abilitare più regioni Azure quando usiamo l'architettura della zona di atterraggio Azure?

Per informazioni su come aggiungere nuove aree a una zona di destinazione o come spostare le risorse della zona di destinazione in un'area diversa, vedere Aree di destinazione.

È consigliabile creare una nuova sottoscrizione Azure ogni volta o riutilizzare Azure sottoscrizioni?

Che cos'è il riutilizzo della sottoscrizione?

Il riutilizzo della sottoscrizione è il processo di riemissione di una sottoscrizione esistente a un nuovo proprietario. Deve essere presente un processo per reimpostare la sottoscrizione a uno stato pulito noto e per poi riassegnarla a un nuovo proprietario.

Perché è consigliabile riutilizzare le sottoscrizioni?

In generale, è consigliabile che i clienti adottino il principio di progettazione della democratizzazione delle sottoscrizioni. Tuttavia, esistono circostanze specifiche in cui il riutilizzo della sottoscrizione non è possibile o consigliato.

È consigliabile prendere in considerazione il riutilizzo della sottoscrizione se si soddisfa una delle circostanze seguenti:

• Si dispone di un Contratto Enterprise (EA) e si prevede di creare più di 5.000 sottoscrizioni su un singolo account proprietario dell'account EA (account di fatturazione), incluse le sottoscrizioni eliminate.
• Se si dispone di un Contratto del cliente Microsoft (MCA) o di un Contratto Microsoft Partner (MPA) e si prevede di avere più di 5.000 sottoscrizioni attive. Per ulteriori informazioni sui limiti delle sottoscrizioni, vedere Account di fatturazione e ambiti nel portale di Azure.
• Sei un cliente con pagamento in base al consumo.
• Si utilizza una sponsorizzazione di Microsoft Azure.
• In genere crei:
  1. Lab temporaneo o ambienti sandbox
  2. Ambienti demo per i modelli di verifica (POC) o i prodotti minimi validi (MVP), inclusi fornitori di software indipendenti (ISV) per l'accesso demo/versione di valutazione dei clienti
  3. Ambienti di training, ad esempio ambienti di apprendimento di MSPs/Trainer

Come si riutilizzano le sottoscrizioni?

Se si corrisponde a uno degli scenari o considerazioni precedenti, potrebbe essere necessario prendere in considerazione la possibilità di riutilizzare le sottoscrizioni non usate o rimosse esistenti e di riassegnarle a un nuovo proprietario e scopo.

Pulire la sottoscrizione precedente

È prima necessario pulire la sottoscrizione precedente per il riutilizzo. È necessario eseguire le azioni seguenti in una sottoscrizione prima che sia pronta per il riutilizzo:

• Rimuovere gruppi di risorse e risorse contenute.
• Rimuovere le assegnazioni di ruolo, incluse quelle di Privileged Identity Management (PIM), all'ambito della sottoscrizione.
• Rimuovere definizioni di Controllo di accesso personalizzate basate su ruoli (RBAC) nell'ambito della sottoscrizione.
• Rimuovere definizioni di criteri, iniziative, assegnazioni ed esenzioni nell'ambito della sottoscrizione.
• Rimuovere le implementazioni nell'ambito della sottoscrizione.
• Rimuovere i tag nell'ambito della sottoscrizione.
• Rimuovere tutti i blocchi delle risorse nell'ambito della sottoscrizione.
• Rimuovi tutti i budget Gestione dei costi Microsoft nel contesto della sottoscrizione.
• Reimpostare i piani di Microsoft Defender per il cloud ai livelli gratuiti, a meno che i requisiti dell'organizzazione non impostino questi log sui livelli a pagamento. Questi requisiti vengono in genere applicati tramite Criteri di Azure.
• Rimuovere i log delle attività della sottoscrizione (impostazioni di diagnostica) inoltrandoli ad Aree di lavoro di Log Analytics, Event Hub, Account di archiviazione o altre destinazioni supportate, a meno che i requisiti organizzativi non richiedano l'inoltro di questi log mentre la sottoscrizione è attiva.
• Rimuovere qualsiasi assegnazione di Azure Lighthouse a livello di sottoscrizione.
• Rimuovere tutte le risorse nascoste dalla sottoscrizione.

Riassegnare la sottoscrizione

È possibile riassegnare la sottoscrizione dopo aver pulito la sottoscrizione. Ecco alcune attività comuni che è possibile eseguire come parte del processo di riassegnazione:

• Aggiungere nuovi tag e impostarne i valori nella sottoscrizione.
• Aggiungere nuove assegnazioni di ruolo o assegnazioni di ruolo di Gestione delle Identità Privilegiate (PIM), nell'ambito della sottoscrizione per i nuovi proprietari. In genere, queste assegnazioni vengono effettuate ai gruppi di Microsoft Entra anziché ai singoli.
• Inserire la sottoscrizione nel gruppo di gestione desiderato in base ai requisiti di governance.
• Creare nuovi budget Gestione dei costi Microsoft e impostare avvisi su nuovi proprietari quando vengono soddisfatte le soglie.
• Impostare i piani di Microsoft Defender per il cloud ai livelli desiderati. È consigliabile applicare questa impostazione tramite Criteri di Azure una volta inserita nel gruppo di gestione corretto.
• Configurare l'inoltro dei log attività della sottoscrizione (impostazioni di diagnostica) alle Aree di lavoro di Log Analytics, Hub eventi, Account di archiviazione o altre destinazioni supportate. È consigliabile applicare questa impostazione tramite Criteri di Azure una volta inserita nel gruppo di gestione corretto.

Che cos'è una zona di destinazione sovrana e come è correlata all'architettura della zona di destinazione Azure?

La zona di destinazione sovrana è un componente di Microsoft Cloud sovrano destinato ai clienti del settore pubblico che necessitano di controlli avanzati di sovranità. Come versione personalizzata dell'architettura di riferimento della zona di destinazione Azure, la zona di destinazione sovrana allinea le funzionalità Azure, ad esempio residenza dei servizi, chiavi gestite dal cliente, collegamento privato di Azure e confidential computing. Grazie a questo allineamento, la zona di destinazione sovrana crea un'architettura cloud in cui i dati e i carichi di lavoro offrono crittografia e protezione dalle minacce per impostazione predefinita.

Per altre informazioni sulla zona di destinazione sovrana, vedere Zona di destinazione sovrana (SLZ).