Condividi tramite

Considerazioni e raccomandazioni sulle sottoscrizioni

  • Articolo

Le sottoscrizioni sono un'unità di gestione, fatturazione e scalabilità in Azure. Svolgono un ruolo fondamentale quando si progetta per l'adozione di Azure su larga scala. Questo articolo illustra come acquisire i requisiti della sottoscrizione e progettare le sottoscrizioni di destinazione in base a fattori critici che variano a seconda di:

  • Tipi di ambiente
  • Modelli di proprietà e governance
  • Strutture organizzative
  • Portfolio di applicazioni
  • Aree

Suggerimento

Per altre informazioni sulle sottoscrizioni, vedere il video di YouTube: Zone di destinazione di Azure - Quante sottoscrizioni è consigliabile usare in Azure?

Nota

Se si usano Contratto Enterprise, Contratto del cliente Microsoft (Enterprise) o Contratto Microsoft Partner (CSP), esaminare i limiti delle sottoscrizioni negli account di fatturazione e negli ambiti nel portale di Azure.

Considerazioni sulla sottoscrizione

Le sezioni seguenti contengono considerazioni utili per pianificare e creare sottoscrizioni per Azure.

Considerazioni sulla progettazione dell'organizzazione e della governance

  • Le sottoscrizioni vengono usate come limiti per le assegnazioni di Criteri di Azure.

    Ad esempio, i carichi di lavoro protetti, come quelli conformi allo standard PCI (Payment Card Industry), richiedono in genere altri criteri per ottenere la conformità. Invece di usare un gruppo di gestione per raccogliere i carichi di lavoro che richiedono la conformità a PCI, è possibile ottenere lo stesso isolamento con una sottoscrizione, senza la necessità di avere troppi gruppi di gestione con poche sottoscrizioni.

    Se è necessario raggruppare più sottoscrizioni dello stesso archetipo di carico di lavoro, crearle in un gruppo di gestione.

  • Le sottoscrizioni fungono da unità di scala in modo che i carichi di lavoro dei componenti possano essere ridimensionati entro i limiti delle sottoscrizioni della piattaforma. Assicurarsi di considerare i limiti delle risorse della sottoscrizione durante la progettazione dei carichi di lavoro.

  • Le sottoscrizioni specificano un limite di gestione per governance e isolamento, che consente una netta separazione delle problematiche.

  • Creare sottoscrizioni di piattaforma separate per la gestione (monitoraggio), la connettività e l'identità quando sono necessarie.

    • Stabilire una sottoscrizione di gestione dedicata nel gruppo di gestione della piattaforma per supportare funzionalità di gestione globali come le aree di lavoro Log di Monitoraggio di Azure e i runbook Automazione di Azure.

    • Stabilire una sottoscrizione di identità dedicata nel gruppo di gestione della piattaforma per ospitare i controller di dominio di Windows Server Active Directory, se necessario.

    • Stabilire una sottoscrizione di connettività dedicata nel gruppo di gestione della piattaforma per ospitare un hub di azure rete WAN virtuale, DNS (Domain Name System) privato, un circuito Azure ExpressRoute e altre risorse di rete. Una sottoscrizione dedicata garantisce che tutte le risorse di rete di base siano fatturate insieme e isolate da altri carichi di lavoro.

    • Usare le sottoscrizioni come unità di gestione democratizzata in linea con le esigenze e le priorità aziendali.

  • Usare processi manuali per limitare i tenant di Microsoft Entra solo alle sottoscrizioni per la registrazione del Contratto Enterprise. Quando si usa un processo manuale, non è possibile creare sottoscrizioni di Microsoft Developer Network (MSDN) nell'ambito del gruppo di gestione radice.

    Per il supporto, inviare un ticket di supporto tecnico di Azure.

    Per informazioni sui trasferimenti di sottoscrizioni tra le offerte di fatturazione di Azure, vedere Sottoscrizione di Azure e hub di trasferimento delle prenotazioni.

Considerazioni su più aree

Importante

Le sottoscrizioni non sono associate a un'area specifica e possono essere considerate sottoscrizioni globali. Sono costrutti logici per fornire controlli di fatturazione, governance, sicurezza e identità per le risorse di Azure contenute all'interno di esse. Pertanto, non è necessaria una sottoscrizione separata per ogni area.

  • È possibile adottare un approccio multiregione a livello di singolo carico di lavoro per il ridimensionamento o il ripristino di emergenza geografico o a livello globale (carichi di lavoro diversi in aree diverse).

  • Una singola sottoscrizione può contenere risorse provenienti da aree diverse, a seconda dei requisiti e dell'architettura.

  • In un contesto di ripristino di emergenza geografico è possibile usare la stessa sottoscrizione per contenere risorse da aree primarie e secondarie perché fanno parte logicamente dello stesso carico di lavoro.

  • È possibile distribuire ambienti diversi per lo stesso carico di lavoro in aree diverse per ottimizzare i costi e la disponibilità delle risorse.

  • In una sottoscrizione che contiene risorse da più aree, è possibile usare i gruppi di risorse per organizzare e contenere risorse in base all'area.

Considerazioni sulla progettazione di quote e capacità

Le aree di Azure possono avere un numero limitato di risorse. Di conseguenza, è necessario tenere traccia della capacità disponibile e degli SKU per le adozione di Azure con diverse risorse.

  • Considerare i limiti e le quote all'interno della piattaforma di Azure per ogni servizio richiesto dai carichi di lavoro,

  • Considerare la disponibilità degli SKU richiesti nelle aree di Azure selezionate. Le nuove funzionalità, ad esempio, potrebbero essere disponibili solo in determinate aree geografiche. La disponibilità di determinati SKU per determinate risorse, ad esempio macchine virtuali, può variare da un'area a un'altra.

  • Si consideri che le quote di sottoscrizione non sono garanzie di capacità e vengono applicate in base all'area.

    Per le prenotazioni di capacità delle macchine virtuali, vedere Prenotazione della capacità su richiesta.

  • Valutare la possibilità di riutilizzare le sottoscrizioni inutilizzate o rimosse. Per altre informazioni, vedere Creare o riutilizzare sottoscrizioni di Azure.

Considerazioni sulla progettazione di restrizioni per il trasferimento di tenant

Ogni sottoscrizione di Azure è collegata a un singolo tenant di Microsoft Entra, che funge da provider di identità (IdP) per la sottoscrizione di Azure. Usare il tenant di Microsoft Entra per autenticare utenti, servizi e dispositivi.

Quando un utente dispone delle autorizzazioni necessarie, può modificare il tenant di Microsoft Entra collegato alla sottoscrizione di Azure. Per altre informazioni, vedi:

Nota

Non è possibile trasferire un tenant Microsoft Entra diverso per le sottoscrizioni di Azure Cloud Solution Provider (CSP).

Per le zone di destinazione di Azure, è possibile impostare i requisiti per impedire agli utenti di trasferire le sottoscrizioni al tenant di Microsoft Entra dell'organizzazione. Per altre informazioni, vedere Gestire i criteri di sottoscrizione di Azure.

Configurare i criteri di sottoscrizione fornendo un elenco di utenti esentati. Gli utenti esentati possono ignorare le restrizioni impostate nei criteri.

Importante

Un elenco di utenti esentati non è un Criteri di Azure.

  • Valutare se consentire agli utenti che dispongono di sottoscrizioni di Visual Studio o MSDN Azure di trasferire la propria sottoscrizione da o verso il tenant di Microsoft Entra.

  • Solo gli utenti con il ruolo Microsoft Entra Global Amministrazione istrator possono configurare le impostazioni di trasferimento del tenant. Questi utenti devono avere accesso con privilegi elevati per modificare i criteri.

    • È possibile specificare solo singoli account utente come utenti esentati, non come gruppi di Microsoft Entra.

  • Tutti gli utenti con accesso ad Azure possono visualizzare i criteri definiti per il tenant di Microsoft Entra.

    • Gli utenti non possono visualizzare l'elenco degli utenti esentati.

    • Gli utenti possono visualizzare gli amministratori globali all'interno del tenant di Microsoft Entra.

  • Le sottoscrizioni di Azure trasferite in un tenant di Microsoft Entra vengono inserite nel gruppo di gestione predefinito per tale tenant.

  • Se l'organizzazione approva, il team dell'applicazione può definire un processo per consentire il trasferimento delle sottoscrizioni di Azure da o verso un tenant di Microsoft Entra.

Considerazioni sulla progettazione della gestione dei costi

Ogni grande organizzazione aziendale ha la sfida di gestire la trasparenza dei costi. Questa sezione illustra gli aspetti chiave per ottenere la trasparenza dei costi in ambienti di Azure di grandi dimensioni.

  • Potrebbe essere necessario condividere modelli di chargeback, ad esempio ambiente del servizio app e servizio Azure Kubernetes (servizio Azure Kubernetes) per ottenere una densità più elevata. I modelli di chargeback possono influire sulle risorse PaaS (Shared Platform as a Service).

  • Usare una pianificazione di arresto per i carichi di lavoro non di produzione per ottimizzare i costi.

  • Usare Azure Advisor per ottenere consigli per ottimizzare i costi.

  • Stabilire un modello di chargeback per una migliore distribuzione dei costi nell'organizzazione.

  • Implementare i criteri in modo che gli utenti non possano distribuire risorse non autorizzate nell'ambiente dell'organizzazione.

  • Stabilire una pianificazione e una cadenza regolari per esaminare i costi e i diritti delle risorse per i carichi di lavoro.

Raccomandazioni per le sottoscrizioni

Le sezioni seguenti contengono raccomandazioni che consentono di pianificare e creare sottoscrizioni per Azure.

Raccomandazioni per l'organizzazione e la governance

  • Considerare le sottoscrizioni come un'unità di gestione allineata alle esigenze e alle priorità aziendali.

  • Informare i proprietari delle sottoscrizioni dei ruoli e delle responsabilità.

    • Eseguire una verifica di accesso trimestrale o annuale per Microsoft Entra Privileged Identity Management (PIM) per assicurarsi che i privilegi non vengano moltiplicati quando gli utenti si spostano all'interno dell'organizzazione.

    • Assumere la proprietà completa della spesa e delle risorse del budget.

    • Garantire la conformità dei criteri e, se necessario, apportare le correzioni necessarie.

  • Quando si identificano i requisiti per le nuove sottoscrizioni, fare riferimento ai principi seguenti:

    • Limiti di dimensionamento: le sottoscrizioni vengono usate come unità di dimensionamento in modo che i carichi di lavoro dei componenti siano dimensionati nei limiti della sottoscrizione della piattaforma. Carichi di lavoro specializzati di grandi dimensioni, come il calcolo ad alte prestazioni, IoT e SAP, devono usare sottoscrizioni separate per evitare l'esecuzione in questi limiti.

    • Limite di gestione: le sottoscrizioni forniscono un limite di gestione per la governance e l'isolamento, che consente una netta separazione delle problematiche. Diversi ambienti, ad esempio gli ambienti di sviluppo, test e produzione, vengono spesso rimossi dal punto di vista della gestione.

    • Limite dei criteri: le sottoscrizioni vengono usate come limite per le assegnazioni di Criteri di Azure. Ad esempio, carichi di lavoro sicuri come carichi di lavoro PCI richiedono in genere altri criteri per ottenere la conformità. L'altro sovraccarico non viene considerato se si usa una sottoscrizione separata. In termini di criteri, gli ambienti di sviluppo hanno requisiti meno severi rispetto agli ambienti di produzione.

    • Topologia di rete di destinazione: non è possibile condividere reti virtuali tra sottoscrizioni, ma è possibile connetterle con tecnologie diverse, ad esempio il peering di reti virtuali o ExpressRoute. Quando si decide se è necessaria una nuova sottoscrizione, considerare quali carichi di lavoro devono comunicare tra loro.

  • Raggruppare le sottoscrizioni in gruppi di gestione che siano allineati alla struttura del gruppo di gestione e ai requisiti dei criteri. Sottoscrizioni di gruppo per assicurarsi che le sottoscrizioni con lo stesso set di criteri e le assegnazioni di ruolo di Azure provengano dallo stesso gruppo di gestione.

  • Stabilire una sottoscrizione di gestione dedicata nel Platform gruppo di gestione per supportare funzionalità di gestione globali come le aree di lavoro Log di Monitoraggio di Azure e i runbook di Automazione.

  • Stabilire una sottoscrizione di identità dedicata nel Platform gruppo di gestione per ospitare i controller di dominio di Active Directory di Windows Server quando necessario.

  • Stabilire una sottoscrizione di connettività dedicata nel Platform gruppo di gestione per ospitare un hub rete WAN virtuale, DNS privato, circuito ExpressRoute e altre risorse di rete. Una sottoscrizione dedicata garantisce che tutte le risorse di rete di base siano fatturate insieme e isolate da altri carichi di lavoro.

  • Evitare un modello di sottoscrizione rigida. Scegliere invece un set di criteri flessibili per raggruppare le sottoscrizioni all'interno dell'organizzazione. La flessibilità garantisce che, quando la struttura dell'organizzazione e la composizione del carico di lavoro cambiano, è possibile creare nuovi gruppi di sottoscrizione invece di usare un set fisso di sottoscrizioni esistenti. Non è detto che lo stesso modello vada bene per tutte le sottoscrizioni e quello che funziona per una business unit potrebbe non funzionare per un'altra. Alcune applicazioni potrebbero coesistere all'interno della stessa sottoscrizione della zona di destinazione, mentre altre potrebbero richiedere una sottoscrizione propria.

    Per altre informazioni, vedere Gestire le zone di destinazione del carico di lavoro sviluppo/test/produzione.

Raccomandazioni su più aree

  • Creare sottoscrizioni aggiuntive per ogni area solo se sono presenti requisiti di governance e gestione specifici dell'area, ad esempio la sovranità dei dati o la scalabilità oltre i limiti di quota.

  • Se il ridimensionamento non è un problema per un ambiente di ripristino di emergenza geografico che si estende su più aree, usare la stessa sottoscrizione per le risorse dell'area primaria e secondaria. Alcuni servizi di Azure, a seconda della strategia di continuità aziendale e ripristino di emergenza (BCDR) e degli strumenti adottano, potrebbero dover usare la stessa sottoscrizione. In uno scenario attivo-attivo, in cui le distribuzioni sono gestite in modo indipendente o hanno cicli di vita diversi, è consigliabile usare sottoscrizioni diverse.

  • L'area in cui si crea un gruppo di risorse e l'area delle risorse contenute deve corrispondere in modo che non influiscano sulla resilienza e sull'affidabilità.

  • Un singolo gruppo di risorse non deve contenere risorse di aree diverse. Questo approccio può causare problemi con la gestione delle risorse e la disponibilità.

Raccomandazioni sulle quote e sulla capacità

  • Usare le sottoscrizioni come unità di scala e aumentare le risorse e le sottoscrizioni in base alle esigenze. Il carico di lavoro può quindi usare le risorse necessarie per aumentare il numero di istanze senza raggiungere i limiti delle sottoscrizioni nella piattaforma Azure.

  • Usare le prenotazioni di capacità per gestire la capacità in alcune aree. Il carico di lavoro può quindi avere la capacità necessaria per le risorse a domanda elevata in un'area specifica.

  • Stabilire un dashboard con visualizzazioni personalizzate per monitorare i livelli di capacità usati e configurare avvisi se la capacità si avvicina ai livelli critici, ad esempio il 90% dell'utilizzo della CPU.

  • Generare richieste di supporto per gli aumenti di quota nel provisioning della sottoscrizione, ad esempio il totale di core delle VM disponibili in una sottoscrizione. Assicurarsi che i limiti di quota siano impostati prima che i carichi di lavoro superino i limiti predefiniti.

  • Assicurarsi che i servizi e le funzionalità necessari siano disponibili all'interno delle aree di distribuzione scelte.

Raccomandazioni sull'automazione

  • Creare un processo di vendita di abbonamenti per automatizzare la creazione di sottoscrizioni per i team delle applicazioni tramite un flusso di lavoro di richiesta. Per altre informazioni, vedere Distribuzione automatica delle sottoscrizioni.

Raccomandazioni sulle restrizioni per il trasferimento di tenant

  • Configurare le impostazioni seguenti per impedire agli utenti di trasferire le sottoscrizioni di Azure verso o dal tenant di Microsoft Entra:

    • Impostare Sottoscrizione lasciando la directory Microsoft Entra su Permit no one.

    • Impostare Sottoscrizione immettendo la directory Microsoft Entra su Permit no one.

  • Configurare un elenco limitato di utenti esentati.

    • Includere membri di un team operativo della piattaforma Azure.

    • Includere account di emergenza nell'elenco degli utenti esentati.

Passaggio successivo

Adottare protezioni guidate da criteri