Domande frequenti sulla zona di destinazione di Azure

Questo articolo risponde alle domande frequenti sull'architettura della zona di destinazione di Azure.

Per domande frequenti sull'implementazione dell'architettura della zona di destinazione di Azure, vedere Domande frequenti sull'implementazione su scala aziendale.

Che cos'è l'acceleratore di zona di destinazione di Azure?

L'acceleratore di zona di destinazione di Azure è un'esperienza di distribuzione basata sul portale di Azure. Distribuisce un'implementazione opinabile basata sull'architettura concettuale della zona di atterraggio di Azure.

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

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 per l'area di destinazione di Azure.

Per maggiori dettagli sulle piattaforme consigliate e le zone di atterraggio delle applicazioni, consultare le linee guida sulle Zone di atterraggio di Azure.

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

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

L'architettura concettuale della zona di destinazione di Azure rappresenta le decisioni relative alla scalabilità e alla 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 di Azure?

Dal punto di vista della zona di destinazione di Azure, le zone di destinazione sono singole sottoscrizioni di 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 di Azure. Usare molti degli effetti di Criteri di Azure, ad esempio Append, Deny, DeployIfNotExists, e Modify, per impedire la non conformità limitando la possibilità di creare o aggiornare risorse non conformi (come definito dalla definizione della politica) oppure 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 tua distribuzione di landing zone di Azure. I criteri di Azure garantiscono che Microsoft Defender for Cloud (noto in precedenza come Centro sicurezza di Azure) sia abilitato per la sottoscrizione. Configura anche le impostazioni di diagnostica per il registro 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.

Informazioni sulle zone di destinazione di Cloud Adoption Framework per Terraform (aztfmod)?

Le zone di atterraggio del Cloud Adoption Framework open source project (OSS) (note anche come aztfmod) sono un progetto guidato dalla comunità di proprietà e gestito all'esterno del team principale della zona di atterraggio di Azure e dell'organizzazione GitHub di Azure. Se l'organizzazione sceglie di usare questo progetto OSS, è necessario considerare il supporto disponibile perché questo è basato sull'impegno della community tramite GitHub.

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

Esaminare le sezioni della documentazione seguenti:

• Eseguire la transizione degli ambienti Azure esistenti all'architettura concettuale della zona di destinazione di 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 esistente della zona di destinazione di Azure per distribuire i carichi di lavoro di intelligenza artificiale. Vedere le indicazioni e la spiegazione in Intelligenza artificiale nelle zone di destinazione di Azure.

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

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

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

Quando si distribuisce l'architettura della zona di destinazione di Azure usando l'esperienza basata sul portale dell'acceleratore di zona di destinazione di Azure, selezionare un'area 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 Località di distribuzione viene usato anche per selezionare l'area di 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 di 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 si abilitano più aree di Azure quando si usa l'architettura della zona di destinazione di 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 di Azure ogni volta o riutilizzare le sottoscrizioni di Azure?

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.
• Si dispone di un Contratto del cliente Microsoft (MCA) o contratto Microsoft Partner e si prevede di avere più di 5.000 sottoscrizioni attive. Per maggiori informazioni sui limiti delle sottoscrizioni, vedere Account di fatturazione e ambiti nel portale di Azure.
• Sei un cliente con pagamento in base al consumo.
• Stai usando una sponsorizzazione 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 le assegnazioni di ruolo Privileged Identity Management (PIM), nell'ambito dell'abbonamento.
• Rimuovere le definizioni personalizzate di controllo degli accessi basate sui ruoli 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.
• Rimuovere tutti i budget di Gestione costi Microsoft nell'ambito della sottoscrizione.
• Reimpostare i piani di Microsoft Defender for Cloud su livelli gratuiti, a meno che i requisiti dell'organizzazione non impostino questi log sui livelli a pagamento. Questi requisiti vengono normalmente imposti tramite Azure Policy.
• Rimuovere i log di attività dell'abbonamento (impostazioni di diagnostica) inoltrati a Log Analytics Workspaces, Event Hubs, Account di archiviazione o altre destinazioni supportate, a meno che i requisiti dell'organizzazione non richiedano l'inoltro di questi log mentre l'abbonamento è attivo.
• Rimuovere tutte le deleghe di Azure Lighthouse nell'ambito della 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 Privileged Identity Management (PIM) nel contesto della sottoscrizione per i nuovi proprietari. In genere, queste assegnazioni sarebbero ai gruppi di Microsoft Entra anziché a singoli utenti.
• Inserire la sottoscrizione nel gruppo di gestione desiderato in base ai requisiti di governance.
• Creare nuovi budget di Gestione costi Microsoft e impostare avvisi per i nuovi proprietari quando vengono soddisfatte le soglie.
• Impostare i piani di Microsoft Defender for Cloud su livelli desiderati. È consigliabile imporre questa impostazione tramite Criteri di Azure una volta inseriti nel gruppo di gestione corretto.
• Configurare l'inoltro dei log delle attività in abbonamento (impostazioni di diagnostica) verso le Aree di lavoro Log Analytics, gli Hub eventi, l'account di archiviazione o altre destinazioni supportate. Dovresti applicare questa impostazione tramite Criteri di Azure una volta inseriti nel Gruppo di gestione corretto.

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

La zona di destinazione sovrana è un componente di Microsoft Cloud for Sovranità destinato ai clienti del settore pubblico che necessitano di controlli avanzati di sovranità. Come versione personalizzata dell'architettura concettuale della zona di destinazione di Azure, la zona di destinazione sovrana allinea le funzionalità di Azure, ad esempio la residenza dei servizi, le chiavi gestite dal cliente, il collegamento privato di Azure e il 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 Considerazioni sulla sovranità per le zone di destinazione di Azure.