Gestire la conformità delle macchine virtuali

Questo articolo descrive come gestire la conformità delle macchine virtuali senza interrompere le procedure DevOps. Usare Azure VM Image Builder e Azure Compute Gallery per ridurre i rischi associati alle immagini di sistema. La soluzione è costituita dal processo di pubblicazione delle immagini gold e dal processo di rilevamento della conformità delle macchine virtuali.

Architecture

Scaricare un file di Visio di questa architettura.

Flusso di dati

Le sezioni seguenti descrivono i due processi in questa soluzione.

Pubblicazione di immagini d'oro

Il flusso di dati seguente corrisponde al diagramma precedente:

1. Ogni mese, il processo di pubblicazione di immagini d'oro acquisisce un'immagine di base da Microsoft Marketplace. Un'immagine d'oro è la versione pubblicata di un'immagine del Marketplace.

2. Image Builder per macchine virtuali di Azure personalizza l'immagine.

3. Il processo di tatuaggio dell'immagine tiene traccia delle informazioni sulla versione dell'immagine, ad esempio la data di origine e pubblicazione.

4. I test automatizzati convalidano l'immagine.

5. Se l'immagine non supera i test, torna al passaggio di personalizzazione per le correzioni.

6. Il processo pubblica l'immagine finalizzata.

7. La Compute Gallery rende disponibile l'immagine macchina ai team di DevOps.

Rilevamento della conformità delle macchine virtuali

Scaricare un file di Visio di questa architettura.

Il flusso di dati seguente corrisponde al diagramma precedente:

1. Il processo di rilevamento della conformità delle macchine virtuali usa Criteri di Azure per assegnare definizioni di criteri alle macchine virtuali e valutare la conformità delle macchine virtuali.

2. Criteri di Azure pubblica i dati di conformità per le macchine virtuali e per altre risorse di Azure nel dashboard di Criteri di Azure.

Components

• Image Builder per macchine virtuali di Azure è un servizio gestito per la personalizzazione di immagini di sistema. Compila immagini usate dai team DevOps. In questa architettura, VM Image Builder acquisisce dal Marketplace immagini di base mensili, applica modifiche di hardening e installa gli agenti. La creazione dell'immagine in questo processo è la golden image.

• Compute Gallery è un servizio di Azure per l'archiviazione e l'organizzazione di immagini VM personalizzate. Centralizza la gestione delle immagini e controlla l'accesso ai team interni e ai tenant esterni autorizzati. In questa architettura, la Compute Gallery archivia le immagini master che i team DevOps devono usare. Criteri di Azure impone che i team DevOps eselezionino le macchine virtuali solo dalle immagini in questa raccolta.

• Criteri di Azure è un servizio di governance di Azure che fornisce definizioni di criteri. È possibile usare queste definizioni per applicare gli standard dell'organizzazione e valutare la conformità su larga scala. Il dashboard di Criteri di Azure visualizza i risultati delle valutazioni di Criteri di Azure e mantiene informati sullo stato di conformità delle risorse. In questa architettura, Azure Policy assegna definizioni dei criteri alle macchine virtuali, le valuta per la conformità, pubblica i risultati nel dashboard di Azure Policy e limita i team DevOps all'uso solo di immagini della raccolta di calcolo.

• La funzionalità di configurazione delle macchine di Azure Policy consente di controllare o assegnare in modo dinamico le configurazioni ai computer tramite codice. Le configurazioni in genere includono le impostazioni dell'ambiente o del sistema operativo. In questa architettura, la configurazione della macchina di Azure controlla le impostazioni di configurazione stabilite dalla personalizzazione dell'immagine e contrassegna le macchine virtuali come non conformi nel dashboard dei criteri di Azure quando si verifica un cambiamento nella configurazione.

Alternatives

• È possibile usare uno strumento non Microsoft per gestire la conformità. In genere è necessario installare un agente nella macchina virtuale di destinazione e potrebbe essere necessario pagare una tariffa di licenza.

• È possibile usare estensioni di script personalizzate per installare software nelle macchine virtuali o configurare le macchine virtuali dopo la distribuzione. Ogni macchina virtuale o set di scalabilità di macchine virtuali supporta una sola estensione di script personalizzata.

Dettagli dello scenario

Le normative di conformità, gli standard di sicurezza e i livelli di rischio accettabili variano a seconda delle organizzazioni e delle aree geografiche.

I diversi standard possono essere più difficili da seguire in ambienti cloud di scalabilità dinamica rispetto ai sistemi locali. Quando i team usano le procedure DevOps, spesso comportano un minor numero di restrizioni per chi può creare risorse di Azure come le macchine virtuali. Questa flessibilità complica le attività di conformità.

Le assegnazioni di Criteri di Azure e controllo degli accessi in base al ruolo consentono alle aziende di applicare standard alle risorse di Azure. Tuttavia, per le macchine virtuali, questi controlli si applicano solo al piano di controllo o alla route alla macchina virtuale. Le immagini di sistema eseguite nella macchina virtuale rappresentano una minaccia per la sicurezza. Alcune aziende impediscono agli sviluppatori di accedere alle macchine virtuali, riducendo così l'agilità e rende difficile seguire le procedure DevOps.

Questa soluzione usa VM Image Builder, Raccolta di immagini e Azure Policy per gestire la conformità delle macchine virtuali in Azure. Tiene traccia della conformità, riduce al minimo i rischi derivanti dalle immagini di sistema eseguite nelle macchine virtuali e supporta le procedure DevOps.

Potenziali casi d'uso

Usare questa soluzione se l'organizzazione usa macchine virtuali ed è necessario:

• Fornire immagini d'oro ai team DevOps.

• Testare e convalidare le immagini prima di renderle disponibili per i team DevOps.

• Tenere traccia dell'immagine usata da ogni team DevOps.

• Applicare gli standard aziendali senza perdita di produttività.

• Assicurarsi che i team DevOps utilizzino le versioni più recenti delle immagini.

• Gestire la conformità dei server per animali domestici, che sono server a elevato utilizzo di manutenzione e server bovini, che sono facilmente sostituibili.

Approach

Le sezioni seguenti forniscono una descrizione dettagliata dell'approccio della soluzione.

Identificare animali domestici e bestiame

I team DevOps usano un'analogia animale domestico e bovino per definire modelli di servizio. Per tenere traccia della conformità di una macchina virtuale, determinare prima di tutto se si tratta di un animale domestico o di un server bovino:

• I server animali domestici richiedono un'attenzione significativa e non sono facili da sostituire. Il recupero di un server per animali domestici richiede molto tempo e risorse finanziarie. Ad esempio, un pet server potrebbe essere un server che esegue SAP. Oltre al software sul server, altre considerazioni possono determinare il modello di servizio. I server di produzione in tempo reale e quasi in tempo reale possono anche essere animali domestici quando si ha una bassa tolleranza di errore.

• I server bovini fanno parte di un gruppo identico e sono facili da sostituire. Ad esempio, le macchine virtuali eseguite in un set di scalabilità di macchine virtuali sono bovini. I server dell'ambiente di test sono un altro esempio di bestiame quando soddisfano le condizioni seguenti:

  • Si usa una procedura automatizzata per creare i server da zero.
  • Dopo aver eseguito i test, dismettere i server.

Un ambiente può contenere solo server animali domestici o solo server bovini. Al contrario, un insieme di macchine virtuali in un ambiente potrebbe essere trattato come "pets". Un diverso insieme di VM nello stesso ambiente potrebbe essere considerato come macchine sacrificabili.

Le considerazioni sulla conformità variano per gli ambienti animali domestici e bovini:

• La conformità dei server "pet" può essere più problematica da monitorare rispetto a quella dei server "cattle". In genere, solo i team di DevOps possono monitorare e mantenere la conformità di ambienti e server di tipo pet. Questa soluzione aumenta la visibilità dello stato di ogni animale domestico in modo che tutti gli utenti dell'organizzazione possano tenere traccia della conformità.

• Per gli ambienti bovini, aggiornare le macchine virtuali e ricompilarle da zero regolarmente per mantenere la conformità. È possibile allineare questo ciclo di aggiornamento con la cadenza di rilasci regolare dei team di DevOps.

Limitare le immagini

Non consentire ai team DevOps di usare immagini di macchine virtuali del Marketplace. Consentire solo immagini di VM pubblicate da Compute Gallery. Questa restrizione è fondamentale per la conformità delle macchine virtuali. È possibile usare criteri personalizzati in Criteri di Azure applicare questa restrizione. Per un esempio, vedere Consentire autori di immagini.

Come parte di questa soluzione, VM Image Builder dovrebbe utilizzare un'immagine del Marketplace. È fondamentale usare l'immagine più recente disponibile in Marketplace. Applicare le personalizzazioni sopra l'immagine. Le immagini del Marketplace vengono aggiornate spesso e includono configurazioni predefinite che rendono le immagini sicure per impostazione predefinita.

Personalizzare le immagini

Un'immagine d'oro è una versione personalizzata di un'immagine del Marketplace pubblicata in Compute Gallery per i team DevOps da usare. Le attività di personalizzazione sono univoche per ogni azienda. Le attività comuni includono:

• Rafforzamento della sicurezza del sistema operativo

• Distribuzione di agenti personalizzati per software non Microsoft

• Installazione dei certificati radice dell'autorità di certificazione (CA) aziendale

È possibile usare Image Builder per personalizzare le immagini modificando le impostazioni del sistema operativo ed eseguendo script e comandi personalizzati. Image Builder per macchine virtuali di Azure supporta immagini di Windows e di Linux. Per altre informazioni, vedere Criteri di conformità normativa di Azure Policy per le macchine virtuali di Azure.

Rafforzare le immagini usando Trusted Launch

Oltre alle personalizzazioni a livello di applicazione, le immagini dorate devono stabilire una catena di attendibilità basata su hardware dall'avvio al runtime. Trusted Launch fornisce le fondamenta per le macchine virtuali di seconda generazione. Configurare immagini dorate con queste funzionalità di avvio attendibile:

• Avvio protetto: Assicura che durante l'avvio vengano eseguiti solo caricatori, kernel e driver del sistema operativo firmati e attendibili. Questo approccio protegge dai bootkit e rootkit.

• Virtual Trusted Platform Module (vTPM): Emula un modulo TPM (Trusted Platform Module) hardware all'interno della macchina virtuale e fornisce una risorsa di archiviazione sicura per chiavi di crittografia, certificati e misurazioni di avvio. vTPM supporta scenari come la crittografia del disco BitLocker e l'attestazione guest crittografica.

• Monitoraggio dell'integrità dell'avvio: Misura l'intera catena di avvio e fornisce telemetria a Microsoft Defender for Cloud.

Tenere traccia dei contrassegni delle immagini

Il tatuaggio delle immagini è il processo di rilevamento di tutte le informazioni sul controllo delle versioni delle immagini usate da una macchina virtuale. Queste informazioni sono molto utili durante la risoluzione dei problemi e possono includere:

• Origine originale dell'immagine, ad esempio il nome e la versione dell'editore.

• Stringa di versione del sistema operativo per un aggiornamento sul posto.

• La versione dell'immagine personalizzata.

• La data di pubblicazione.

La quantità e il tipo di informazioni di cui si tiene traccia dipendono dal livello di conformità dell'organizzazione.

Per l'assegnazione di contrassegni alle immagini nelle VM Windows, configurare un registro personalizzato. Aggiungere tutte le informazioni necessarie nel percorso di questo registro sotto forma di coppie chiave-valore. Nelle macchine virtuali Linux, inserire i dati di marcatura delle immagini nelle variabili di ambiente o in un file. Posizionare il file nella /etc/ cartella in cui non è in conflitto con le applicazioni o il lavoro degli sviluppatori. Per utilizzare Azure Policy per tenere traccia o segnalare i dati di marcatura, archiviare ogni pezzo di dato come una coppia chiave-valore univoca. Per altre informazioni, vedere Trovare una versione dell'immagine del Marketplace.

Generare una fattura software di materiali per immagini dorate

Il tatuaggio dell'immagine registra i metadati relativi all'immagine, ad esempio la relativa origine, versione e data di pubblicazione. Un elenco di materiali software (SBOM) completa il contrassegno registrando il contenuto dell'immagine, come pacchetti del sistema operativo, agenti, librerie e patch. Questo inventario supporta la risposta alle vulnerabilità, i controlli di conformità e la trasparenza della supply chain.

Un SBOM per le immagini d'oro è utile nei modi seguenti:

• Risposta più rapida alle vulnerabilità e alle esposizioni comuni (CVE): Quando viene divulgata una vulnerabilità critica, un SBOM identifica le versioni delle immagini dorate che contengono il componente interessato.

• Conformità alle normative: Le leggi e gli standard normativi richiedono spesso SBOMs per gli artefatti software. Le immagini delle macchine virtuali fanno parte di tale catena di approvvigionamento software.

• Tracciabilità dell'audit: Quando si associano impronte digitali delle immagini con gli SBOMs, i revisori ottengono una panoramica completa di quale immagine esegue una macchina virtuale ed esattamente quali componenti software l'immagine contiene al momento della compilazione.

Generare lo SBOM durante la creazione dell'immagine

Aggiungere la generazione SBOM come passaggio nella pipeline di Image Builder della macchina virtuale subito dopo la personalizzazione e prima della convalida.

Usare lo strumento Microsoft SBOM open source per generare SBOMs in formato SPDX . Lo strumento enumera i pacchetti, gli agenti e le dipendenze del sistema operativo installati. Eseguire lo strumento sull'immagine personalizzata come passaggio di personalizzazione del VM Image Builder o come script di post-personalizzazione nella pipeline. Firmare in modo crittografico lo SBOM generato per garantire l'integrità.

Archiviare sbom insieme all'immagine. Carica la SBOM in un account di archiviazione di Azure o in un archivio artefatti collegato alla versione dell'immagine della Raccolta calcolo di Azure. Usare una convenzione di denominazione coerente che esegua il mapping di ogni file SBOM alla definizione dell'immagine, alla versione e alla data di compilazione. Mantenere lo SBOM disponibile per tutto il tempo in cui la versione dell'immagine è in uso.

Convalidare le immagini d'oro usando test automatizzati

In genere, è consigliabile aggiornare le immagini dorate ogni mese per rimanere aggiornati con gli aggiornamenti e le modifiche più recenti nelle immagini del Marketplace. A questo scopo, usare una procedura di test ricorrenti. Come parte del processo di creazione dell'immagine, usare una pipeline di Azure o un altro flusso di lavoro automatizzato per i test. Configurare la pipeline per distribuire una nuova macchina virtuale per eseguire i test prima dell'inizio di ogni mese. I test devono confermare le immagini preparate prima di pubblicarle per l'utilizzo. Automatizzare i test usando una soluzione di automazione di test o l'esecuzione di comandi o batch nella macchina virtuale.

Gli scenari di test comuni includono:

• Convalidare l'ora di avvio della macchina virtuale.

• Verificare le personalizzazioni delle immagini, ad esempio le impostazioni di configurazione del sistema operativo o le implementazioni dell'agente.

Un test non superato dovrebbe interrompere il processo. Ripetere il test dopo aver affrontato la causa radice del problema. Se i test funzionano senza problemi, l'automazione del processo di test riduce lo sforzo richiesto per mantenere uno stato sempreverde.

Pubblicare le immagini dorate

Pubblicare immagini finali in Compute Gallery come immagini gestite che i team DevOps possono usare. Contrassegnare le immagini precedenti come obsoleti. Se non è stata impostata una data di fine vita per una versione dell'immagine in Compute Gallery, è consigliabile interrompere l'immagine meno recente in base ai criteri aziendali.

Per ulteriori informazioni sui limiti che si applicano quando si usa la Raccolta di calcolo, vedere Archiviare e condividere immagini in Raccolta di calcolo.

La pubblicazione delle immagini più recenti in aree diverse è una procedura consigliata. È possibile usare Compute Gallery per gestire il ciclo di vita e la replica delle immagini nelle diverse aree di Azure.

Aggiornare le immagini Golden

Quando un'applicazione usa un'immagine, l'immagine del sistema operativo sottostante può essere difficile da aggiornare con le modifiche di conformità recenti. Requisiti aziendali rigorosi possono complicare il processo di aggiornamento della macchina virtuale sottostante. L'aggiornamento è anche complesso per le macchine virtuali critiche per l'azienda.

I server bovini sono dispensabili, in modo da poter coordinare con i team DevOps per aggiornarli in una finestra di manutenzione pianificata come attività regolare.

I server animali domestici sono più difficili da aggiornare. La sospensione di un'immagine può mettere a rischio le applicazioni. Negli scenari di scalabilità orizzontale, Azure non riesce a trovare le rispettive immagini, che genera errori.

Quando si aggiornano i server animali domestici, tenere presenti queste linee guida:

• Per le procedure consigliate, vedere la panoramica del pilastro Affidabilità nel framework Azure Well-Architected.

• Per semplificare il processo, vedere i principi negli articoli seguenti:

  • Modello degli stamp di distribuzione
  • Modello Geode
  • Modello paratia

• Contrassegnare ogni "pet server" come tale. Configurare un criterio in Criteri di Azure per tenere conto di questo tag durante gli aggiornamenti.

Applicazione di patch di emergenza per le vulnerabilità critiche

La cadenza di aggiornamento mensile dell'immagine gold è adatta per gli aggiornamenti di routine, ma le vulnerabilità di sicurezza critiche e le CVE richiedono interventi prima del ciclo pianificato successivo. Stabilire un processo di applicazione di patch di emergenza fuori banda (OOB) che viene eseguito indipendentemente dalla cadenza mensile e si attiva su richiesta. Abbonati alle notifiche di Integrità dei servizi di Azure e del Centro di risposta alla sicurezza di Microsoft per gli avvisi CVE che influiscono sulle immagini di base.

Quando un CVE critico influisce su un'immagine golden pubblicata, intervenire subito per impedire il provisioning di nuove macchine virtuali con la versione vulnerabile. Iniziare contrassegnando la versione dell'immagine interessata come esclusa dalla versione dell'immagine selezionata da Azure quando gli utenti o l'automazione richiedono la versione più recente. Nella Raccolta di Calcolo, impostare la proprietà excludeFromLatest su true in ogni versione dell'immagine interessata. Dopo questa modifica, l'automazione e gli utenti che richiedono la versione disponibile più recente non ricevono più la versione vulnerabile. Usare la descrizione dell'assegnazione dei Criteri di Azure per collegare un runbook o un wiki interno che elenchi un CVE, le versioni d'immagine interessate e le azioni correttive richieste.

Attivare una build di immagini OOB

Usare la stessa pipeline di Image Builder della macchina virtuale che produce l'immagine golden mensile, ma attivarla su richiesta:

1. Applicare la patch di sicurezza. Aggiungere la correzione critica al passaggio di personalizzazione dell'immagine come aggiornamento del sistema operativo, una modifica della configurazione o uno script che corregge la vulnerabilità specifica.

2. Eseguire la suite di test automatizzata. Non tralasciare la convalida. Gli stessi test che vengono eseguiti durante il ciclo mensile dovrebbero essere eseguiti anche per i build d'emergenza.

3. Pubblicare l'immagine aggiornata. Pubblicare la nuova versione dell'immagine nella Compute Gallery e replicarla in tutte le aree richieste. La versione interessata viene esclusa dalla selezione della versione più recente, quindi la versione con patch diventa automaticamente la versione usata dalle nuove distribuzioni.

4. Aggiornare l'immagine del tatuaggio. Registrare la natura OOB dell'aggiornamento nel tatuaggio dell'immagine e includere l'identificatore CVE, la data della patch e un flag che lo distingue da una versione mensile pianificata. Questi dati supportano i controlli di conformità.

Migliorare la visibilità

In genere, è consigliabile usare Azure Policy per gestire le attività di conformità del control plane. È anche possibile usare Criteri di Azure per eseguire le attività seguenti:

• Tenere traccia della conformità delle macchine virtuali.

• Installare gli agenti di Azure. Usare l'agente di Monitoraggio di Azure per il monitoraggio.

• Registrare i log di diagnostica.

• Migliorare la visibilità della conformità delle macchine virtuali.

Usare la configurazione del computer di Azure per controllare le modifiche di configurazione apportate durante la personalizzazione delle immagini. In caso di deviazione, il dashboard di Azure Policy elenca la VM interessata come non conforme. Azure Policy può utilizzare le informazioni di etichettatura delle immagini per tracciare quando vengono utilizzate immagini o sistemi operativi obsoleti.

Controllare i pet server per ogni applicazione. È possibile migliorare la visibilità di questi server usando i criteri di Azure che hanno l'effetto di controllo. Modificare il processo di controllo in base al livello accettabile di rischio e ai processi di gestione dei rischi interni dell'azienda.

Ogni tea di DevOps può tenere traccia dei livelli di conformità delle applicazioni nel dashboard di Criteri di Azure e intraprendere le azioni correttive appropriate. Quando si assegnano questi criteri a un gruppo di gestione o a una sottoscrizione, includere un URL alla documentazione a livello aziendale sui criteri nella descrizione dell'assegnazione. La documentazione dovrebbe elencare i passaggi che i team DevOps devono seguire per rendere le macchine virtuali conformi.

I responsabili dei rischi IT e i responsabili della sicurezza possono anche usare il dashboard di Criteri di Azure per gestire i rischi aziendali in base al livello di rischio accettabile della propria azienda.

La configurazione del computer di Azure con le opzioni di correzione applica automaticamente le azioni correttive. Tuttavia, le query frequenti o le modifiche apportate a una macchina virtuale usata per un'applicazione business critical possono influire sulle prestazioni. Pianificare con attenzione le azioni correttive per i carichi di lavoro di produzione. Assegnare a un team DevOps la proprietà della conformità delle applicazioni in tutti gli ambienti. Adotta questo approccio per server personalizzati e ambienti, che in genere sono componenti di Azure a lungo termine.

Procedure consigliate per l'igiene delle immagini d'oro

Un processo di compilazione di immagini ben strutturato impedisce errori comuni che causano incidenti di sicurezza, deviazione della configurazione e attrito operativo. Seguire queste linee guida quando si personalizzano e si mantengono immagini dorate:

• Non inserire mai segreti in immagini. Non incorporare chiavi API, stringhe di connessione, password, chiavi private dei certificati o token nell'immagine. Quando si incorporano segreti in un'immagine, vengono esposti a ogni macchina virtuale che usa l'immagine e a chiunque abbia accesso in lettura a Compute Gallery. Recuperare invece i segreti in fase di esecuzione da Azure Key Vault usando un'identità gestita.

• Preferire la configurazione esterna rispetto ai valori fissati nel codice. Esternalizzare le impostazioni che potrebbero cambiare tra gli ambienti o prima della prossima creazione dell'immagine, ad esempio endpoint, flag di funzionalità, impostazioni regionali o livelli di log. Riservare la personalizzazione dell'immagine alle impostazioni che sono statiche e universali per tutte le implementazioni.

• Ridurre al minimo l'impronta del software. Installa solo i componenti necessari per ogni utente dell'immagine. Distribuire strumenti aggiuntivi specifici di un singolo caso d'uso o carico di lavoro dopo il provisioning usando estensioni o gestione della configurazione. Un footprint più piccolo riduce la superficie di attacco e il numero di componenti che richiedono l'applicazione di patch.

• Escludere il codice dell'applicazione e gli artefatti di distribuzione dall'immagine. Le immagini d'oro devono fornire una base del sistema operativo sicura e conforme. Distribuire separatamente il codice dell'applicazione tramite pipeline di integrazione continua e consegna continua (CI/CD). Questa separazione mantiene indipendentemente il ciclo di vita dell'immagine e il ciclo di vita dell'applicazione.

• Usare script di compilazione deterministici e ripetibili. Fissare le versioni dei pacchetti negli script di personalizzazione. Evitare comandi come apt-get upgrade o yum update che possono produrre immagini diverse in giorni di compilazione diversi.

Considerations

Queste considerazioni implementano i pilastri di Azure Well-Architected Framework, che è un set di principi guida che possono essere usati per migliorare la qualità di un carico di lavoro. Per altre informazioni, vedere Well-Architected Framework.

Reliability

L'affidabilità garantisce che l'applicazione possa soddisfare gli impegni assunti dai clienti. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'affidabilità.

Questa soluzione usa componenti gestiti che sono automaticamente resilienti a livello di area. Per altre informazioni, vedere Progettare applicazioni resilienti per Azure.

È possibile configurare il numero di repliche di ogni immagine archiviata dalla Raccolta Compute. Un numero maggiore di repliche riduce il rischio di throttling quando si effettua il provisioning di più macchine virtuali contemporaneamente. Per ulteriori informazioni, vedere Compute Gallery - Scalabilità.

Ottimizzazione dei costi

L'ottimizzazione dei costi è incentrata sui modi per ridurre le spese non necessarie e migliorare l'efficienza operativa. Per altre informazioni, vedere Elenco di controllo per la revisione della progettazione per l'ottimizzazione dei costi.

Se si usano solo i servizi Microsoft, è possibile evitare il costo aggiunto di strumenti non Microsoft come Ansible o Terraform. Tuttavia, gli addebiti di Azure possono comunque essere applicati per l'archiviazione, l'uscita, la compilazione di immagini, la replica e le risorse ibride. Altri possibili addebiti riguardano i componenti seguenti:

• I criteri di Azure e la configurazione delle macchine di Azure sono gratuiti per le risorse di Azure. Se l'azienda usa un approccio ibrido, le risorse di Azure Arc aggiungono costi aggiuntivi.

• VM Image Builder usa un singolo tipo di istanza di calcolo con 1 vCPU e 3,5 GB di RAM. Potrebbero applicarsi costi per l'archiviazione e il trasferimento dei dati.

• Compute Gallery comporta addebiti solo per l'archiviazione delle repliche e per il traffico in uscita associato alla replicazione delle immagini.

Contributors

Microsoft gestisce questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autore principale:

• Yunus Emre Alpozen | Progettista del programma

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Zona di destinazione di Azure
• Introduzione all'infrastruttura cloud
• Generatore di immagini VM
• Galleria Computazionale
• Criteri di Azure e il dashboard dei criteri
• Configurazione del computer di Azure

Risorse correlate

• Soluzioni DevTest e DevOps per l'infrastruttura distribuita come servizio (IaaS)
• DevSecOps su AKS