Le SKU utilizzate per fatturare i costi di archiviazione del servizio di backup e DR dipendono dal fatto che la risorsa protetta sia protetta in un vault di backup o in uno spazio di archiviazione autogestito.

Se una risorsa è protetta in un vault di backup, i costi di archiviazione verranno fatturati al progetto in cui è stato creato il vault di backup, utilizzando gli SKU del servizio Backup e DR e con i prezzi definiti nella tabella seguente.

Se una risorsa è protetta in un archivio autogestito (ad esempio un bucket Cloud Storage o uno snapshot Persistent Disk), i costi di archiviazione verranno fatturati utilizzando gli SKU corrispondenti. Per maggiori dettagli sui prezzi di Cloud Storage, vedi Prezzi di Cloud Storage. Per maggiori dettagli sui prezzi degli snapshot di Persistent Disk, vedi Prezzi degli snapshot di Cloud Persistent Disk.

Ogni progetto in Google Cloud ha un account di fatturazione che viene utilizzato per definire chi paga l'utilizzo delle risorse e delle API Google Cloud in quel progetto. Il progetto e gli SKU utilizzati per la fatturazione del servizio di Backup e DR sono determinati dal tipo di risorsa protetta.

Protezione di dischi indipendenti (Persistent Disk e Hyperdisk) in un vault di backup (include la protezione tramite Terraform e Google Cloud CLI)

I costi di gestione per i dischi (permanenti o Hyperdisk) sotto protezione attiva in un vault di backup vengono fatturati al progetto in cui si trova il disco protetto. La tabella seguente elenca gli SKU e i punti di prezzo per la protezione del disco in un vault di backup.

Protezione delle VM Compute Engine in un vault di backup (include la protezione tramite Terraform e Google Cloud CLI)

I costi di gestione per le VM sotto protezione attiva in un vault di backup vengono fatturati al progetto in cui si trova la VM protetta. La tabella seguente elenca gli SKU e i punti di prezzo per la protezione in un vault di backup.

Se una VM non è più sotto protezione attiva, ma ha dati di backup in un vault di backup, i costi di gestione verranno fatturati come descritto qui.

Protezione delle VM di Compute Engine in un'archiviazione autogestita

I costi di gestione per la protezione in uno spazio di archiviazione autogestito vengono fatturati al progetto in cui è stato attivato il servizio di Backup e DR e da cui è stata eseguita la distribuzione della console di gestione. Indipendentemente dalle zone, dalle regioni o dai progetti in cui si trovano le appliance di backup/ripristino. La tabella seguente elenca gli SKU e i punti di prezzo per la protezione nello spazio di archiviazione autogestito.

Le VM VMware Engine sono protette tramite la console di gestione del servizio di Backup e DR. I costi di gestione per le risorse sotto protezione attiva tramite la console di gestione del servizio di Backup e DR vengono fatturati al progetto in cui è stato attivato il servizio di Backup e DR e da cui è stata eseguita la distribuzione della console di gestione. Indipendentemente dalle zone, dalle regioni o dai progetti in cui si trovano le appliance di backup/ripristino.

I prezzi per il backup di VMware Engine si basano sul consumo e sul termine di impegno. Le opzioni includono sconti per impegno di utilizzo  o on demand per termini di uno e tre anni.

La seguente tabella elenca gli SKU e i prezzi per la protezione dei nodi ve1-standard-72 e dei nodi ve1-standard-72 solo archiviazione di VMware Engine in un vault di backup o in uno spazio di archiviazione autogestito.

La tabella seguente elenca gli SKU e i prezzi per la protezione dei nodi ve2 di VMware Engine in un vault di backup o in uno spazio di archiviazione autogestito.

Se una VM non è più sotto protezione attiva, ma ha dati di backup in un vault di backup, i costi di gestione verranno fatturati come descritto qui.

I database SQL Server autogestiti sono protetti tramite la console di gestione del servizio di Backup e DR. I costi di gestione per le risorse sotto protezione attiva tramite la console di gestione del servizio di Backup e DR vengono fatturati al progetto in cui è stato attivato il servizio di Backup e DR e da cui è stata eseguita la distribuzione della console di gestione. Indipendentemente dalle zone, dalle regioni o dai progetti in cui si trovano le appliance di backup/ripristino.

La tabella seguente elenca gli SKU e i punti di prezzo per la protezione in un vault di backup.

Se SQL Server non è più sotto protezione attiva, ma ha dati di backup in un vault di backup, i costi di gestione verranno fatturati come descritto qui.

La tabella seguente elenca gli SKU e i punti di prezzo per la protezione nello spazio di archiviazione autogestito.

I database Oracle autogestiti sono protetti tramite la console di gestione del servizio di backup e DR. I costi di gestione per le risorse sotto protezione attiva tramite la console di gestione del servizio di Backup e DR vengono fatturati al progetto in cui è stato attivato il servizio di Backup e DR e da cui è stata eseguita la distribuzione della console di gestione. Indipendentemente dalle zone, dalle regioni o dai progetti in cui si trovano le appliance di backup/ripristino.

I prezzi per il backup di Oracle in un vault di backup si basano sul consumo e sul termine di impegno. Le opzioni includono sconti per impegno di utilizzo o on demand per termini di uno e tre anni. La tabella seguente elenca gli SKU e i punti di prezzo per la protezione in un vault di backup.

Se Oracle non è più sotto protezione attiva, ma ha dati di backup in un vault di backup, le tariffe di gestione verranno fatturate come descritto qui.

La tabella seguente elenca gli SKU e i punti di prezzo per la protezione nello spazio di archiviazione autogestito.

I database SAP HANA autogestiti sono protetti tramite la console di gestione del servizio di backup e DR. I costi di gestione per le risorse sotto protezione attiva tramite la console di gestione del servizio di Backup e DR vengono fatturati al progetto in cui è stato attivato il servizio di Backup e DR e da cui è stata eseguita la distribuzione della console di gestione. Indipendentemente dalle zone, dalle regioni o dai progetti in cui si trovano le appliance di backup/ripristino. La tabella seguente elenca gli SKU e i punti di prezzo per la protezione nello spazio di archiviazione autogestito.

Il servizio di backup e DR supporta anche la protezione di risorse aggiuntive tramite la console di gestione del servizio di backup e DR, come elencato di seguito (ad es. file system, database MySQL ecc.). I costi di gestione per queste risorse sotto protezione attiva tramite la console di gestione del servizio di Backup e DR vengono fatturati al progetto in cui è stato attivato il servizio di Backup e DR e da cui è stata eseguita la distribuzione della console di gestione. Indipendentemente dalle zone, dalle regioni o dai progetti in cui si trovano le appliance di backup/ripristino. La tabella seguente elenca gli SKU e i punti di prezzo per la protezione nello spazio di archiviazione autogestito.

Se una risorsa non è più sotto protezione attiva (ovvero la protezione della risorsa è "inattiva") in un determinato vault di backup, ma ha ancora dati di backup in quel vault, gli addebiti di gestione verranno fatturati al progetto in cui è stato creato il vault di backup e utilizzando lo SKU e il prezzo indicati di seguito.

Tieni presente anche i seguenti scenari in cui la protezione delle risorse sarà considerata "inattiva":

• Vedi il comportamento di fatturazione associato alla disabilitazione dell'API
• Per le risorse protette tramite un'appliance di backup/ripristino:
• Se l'appliance di backup/recupero non comunica con il vault di backup per 24 ore, la protezione delle risorse del vault di backup associato verrà considerata "inattiva".

Per calcolare i costi di gestione, Backup and DR misura l'utilizzo in base alla dimensione effettiva del frontend del carico di lavoro o alla dimensione del carico di lavoro che sta gestendo. L'unità di misura è gibibyte (GiB). Un gibibyte = 1024 * 1024 * 1024 byte.

Se il carico di lavoro in gestione segnala la dimensione del volume per i dati, Backup and DR tiene conto della dimensione del volume segnalata (ad esempio, il calcolo dell'utilizzo per VMware sarà coerente con la dimensione segnalata della VM in vCenter).

Se gestisci 10 TiB di dati Oracle distribuiti su più database, i report sull'utilizzo di Backup and DR indicano 10 * 1024 GiB di utilizzo dei dati.

Nota: la misurazione dell'utilizzo di backup e DR non tiene conto della frequenza di acquisizione dei dati, di dove vengono archiviate le copie, di quante copie vengono create, della velocità di modifica dei dati, del periodo di conservazione o della quantità di spazio di archiviazione occupato dalle copie.

Misurazione dell'utilizzo per Compute Engine, quando si esegue il backup su uno spazio di archiviazione autogestito

Quando esegui il backup su uno spazio di archiviazione autogestito, Backup and DR misura l'utilizzo per i backup delle VM Compute Engine in base alla quantità di spazio di archiviazione PD collegato a una VM Compute Engine al momento del backup. Backup e DR consente di escludere i volumi PD dal backup. In questi casi, per misurare l'utilizzo vengono usati solo i volumi identificati per il backup.

Ad esempio, se due volumi PD da 1 TiB e 2 TiB sono collegati a una VM Compute Engine e configuri l'SLT di backup in modo da escludere il volume da 2 TiB, l'utilizzo della VM viene misurato come 1 TiB.

Inoltre, se la VM da 1 TiB aumenta o diminuisce, Backup and DR misura l'utilizzo in base alle dimensioni del volume al momento dell'ultimo backup.

Misurazione dell'utilizzo per Compute Engine, quando si esegue il backup in un vault di backup

Quando esegui il backup in un vault di backup, Backup and DR misura l'utilizzo per la VM di Compute Engine come descritto di seguito

• Gli addebiti di gestione si basano sulle dimensioni della VM Compute Engine al momento del backup. Ad esempio, se una VM ha un totale di 1 TiB di spazio di archiviazione collegato, gli addebiti di gestione saranno per 1 TiB indipendentemente dallo spazio di archiviazione utilizzato.
• Inoltre, se la VM da 1 TiB aumenta o diminuisce di dimensioni, Backup and DR misura l'utilizzo in base alle dimensioni della VM al momento dell'ultimo backup.

Misurazione dell'utilizzo durante il backup di dischi indipendenti (permanenti e Hyperdisk) in un vault di backup

Per i backup archiviati in un vault di backup, Backup e DR calcola l'utilizzo per dischi permanenti/Hyperdisk indipendenti come segue:

• Le tariffe di gestione sono determinate dalla dimensione del disco permanente/Hyperdisk al momento di ogni backup. Ciò significa che un disco da 1 TiB comporterà addebiti di gestione per 1 TiB, indipendentemente dall'archiviazione effettivamente utilizzata.
• Inoltre, Backup e DR ricalcolerà l'utilizzo in base alle dimensioni attuali del disco durante il backup più recente, anche se le dimensioni del disco della VM sono cambiate rispetto al backup precedente.

Misurazione dell'utilizzo per VMware Engine senza agent

Per i nodi VMware Engine ve1 e ve2

Il prezzo viene calcolato in base al numero e al tipo di nodi ESXi protetti. Un nodo ESXi è considerato protetto se una o più VM ad esso collegate sono protette dal servizio Backup and DR.

Di seguito è riportato un esempio che illustra il processo di fatturazione per VMware Engine:

• Prezzo per eseguire il backup di un singolo nodo ve1 di VMware Engine (solo backup VM) nella regione us-central1 per un mese = (prezzo di listino per il backup del nodo/ ora) X (numero di ore al giorno in cui il nodo è attivo) X (numero di giorni al mese).
• Considerando che il nodo VMware Engine è attivo per 24 ore, che ci sono 30 giorni in un mese e che il prezzo per il backup di un nodo è di 0, 46 $X 24 X 30 = 331 $.

Per i nodi ve2, il prezzo si basa sia sul numero che sul tipo (mega, large, standard, small) di nodi ESXi protetti.

I prezzi si riferiscono solo alla protezione di VMware Engine, ovvero ai backup dell'intera VM. Non include i costi di gestione del backup per eventuali backup basati su agenti, come i costi per i backup coerenti con le applicazioni per SAP HANA, SQL Server, MySQL, Postgres, agenti del file system e così via. Per stimare i costi dei backup basati su agenti, fai riferimento a Misurazione dell'utilizzo per il backup basato su agenti.

Per il nodo solo di archiviazione ve1 e ve2 di VMware Engine

Il prezzo per la protezione di un nodo di sola archiviazione VMware Engine ve1/ve2 è determinato dal numero di nodi di sola archiviazione VMware Engine ve1/ve2 aggiunti a un cluster che ha almeno uno o più nodi protetti VMware Engine ve1/ve2.

Se hai un cluster con nodi protetti VMware Engine ve1/ve2 e aggiungi nodi solo di archiviazione VMware Engine ve1/ve2 allo stesso cluster, tutti i nodi solo di archiviazione nel cluster saranno considerati protetti per impostazione predefinita e ti verrà addebitato il costo per la protezione di tutti. Non puoi escludere la protezione per i nodi di sola archiviazione ve1/ve2 di VMware Engine in un cluster che ha almeno uno o più nodi protetti ve1/ve2 di VMware Engine.

Ad esempio, supponiamo di avere un cluster esistente di 20 nodi e di proteggerne 10 utilizzando il servizio di Backup e DR. Se aggiungi 3 nodi di sola archiviazione al cluster, tutti e 3 i nodi di sola archiviazione saranno considerati protetti e ti verrà addebitato il costo per la protezione di 10 + 3 = 13 nodi ve1 VMware Engine.

Se non proteggi alcun nodo ve1/ve2 di VMware Engine su un cluster, in questo caso i nodi di sola archiviazione ve1/ve2 di VMware Engine non possono essere protetti.

Backup e DR misura l'utilizzo per il backup basato su agent in base alle dimensioni effettive del workload. Ad esempio, se un backup del database del server SQL utilizza l'agente Backup and DR e se la somma dei file di dati di un server SQL è di cinque TiB su un volume di sette TiB, l'utilizzo viene misurato come cinque TiB.

Misurazione dell'utilizzo per il backup basato su agenti dei database

Per i carichi di lavoro Oracle e SQL Server, vengono conteggiati solo i database protetti ai fini dell'utilizzo. Non tiene conto dei file di log:

• Oracle. Le dimensioni allocate dei file di database protetti vengono conteggiate nell'utilizzo. La dimensione allocata include file di dati e file di controllo.
• Microsoft SQL Server. La dimensione totale di tutti i file di database, inclusi i file .MDF, .LDF e .NDF sotto protezione, viene conteggiata nell'utilizzo.
• Protezione del database con Change Block Tracking (CBT) di Linux. Backup e DR supporta il backup efficiente di diversi database con il monitoraggio dei blocchi modificati. Questa modalità di backup si basa sul fatto che i file di log e di dati del database risiedano su volumi gestiti da Linux Logical Volume Manager (LVM). Per questa classe di workload, l'utilizzo viene misurato in base alla dimensione effettiva del database protetto, utilizzando le seguenti query:
• Db2: call get_dbsize_info(?,?,?,-1);
• MariaDB: SELECT SUM(data_length + index_length) FROM information_schema.TABLES where table_schema='';
• MySQL: SELECT SUM(data_length + index_length) FROM information_schema.TABLES where table_schema='';
• PostgreSQL: SELECT pg_database_size('$db');
• SAP ASE: sp_spaceused;
• SAP IQ: sp_iqdbsize * block_size;
• SAP HANA: select sum(TOTAL_SIZE) from sys_databases.M_VOLUME_FILES where file_type='DATA'
• SAP MaxDB: dbmcli -d $DBSID $MAXDB_KEY info DATA
• Protezione basata su dump SQL senza CBT Linux. Backup and DR supporta i backup tradizionali basati su dump SQL. In questa modalità, l'utilizzo viene misurato in base alle dimensioni del database come riportato dal database al momento del backup.

Fattori che influenzano la misurazione dell'utilizzo

Fattori che influenzano la misurazione dell'utilizzo negli scenari fuori banda:

• Volumi compressi. Quando la compressione del volume è abilitata, l'utilizzo conta i valori post-compressione. Ad esempio, se un volume di 2 TiB contiene 2,5 TiB di dati compressi in 1,8 TiB, il conteggio dell'utilizzo sarà di 1,8 TiB, non di 2,5 TiB.
• Volumi ottimizzati per Windows. Per i volumi ottimizzati per Windows, Backup and DR ripristina il volume per il backup e il conteggio dell'utilizzo sarà il valore ripristinato. Ad esempio, se un volume ottimizzato per Windows da 1 TiB contiene 800 GiB di dati, quando viene reidratato per il backup finisce per essere 1,1 TiB, l'utilizzo è 1,1 TiB.
• Dimensioni dei blocchi. Per i dischi di gestione temporanea, Backup and DR misura l'utilizzo in base alla dimensione del blocco del disco di gestione temporanea. Se la dimensione del blocco del volume di origine e la dimensione del blocco del disco di gestione temporanea corrispondono, i valori di utilizzo corrisponderanno esattamente al volume di origine. Se la dimensione del blocco utilizzata sul disco di gestione temporanea è diversa dal volume di origine, ci sarà una piccola differenza perché il calcolo dell'utilizzo viene eseguito sul disco di gestione temporanea.
• Gruppi con coerenza. Il conteggio dell'utilizzo per un gruppo di coerenza è la somma di tutte le dimensioni dei workload nel gruppo di coerenza. I carichi di lavoro vengono misurati singolarmente e sommati.

Misurazione dell'utilizzo per le copie virtuali

Backup and DR misura l'utilizzo delle copie virtuali a partire dal momento in cui viene creata una copia virtuale di un carico di lavoro. La quantità di utilizzo si basa sulle dimensioni dell'applicazione al momento dell'ultimo backup. Man mano che vengono eseguiti nuovi backup, la quantità di utilizzo viene aggiornata per riflettere le dimensioni attuali dell'applicazione. Il modo più comune per creare copie virtuali è tramite i job di montaggio. Esistono altri tipi di job, come prep-mount e reprovision, che possono creare una copia virtuale. Gli addebiti per l'utilizzo vengono ripartiti in base al tempo di utilizzo della copia virtuale (dal momento del montaggio riuscito al momento dello smontaggio, misurato in incrementi di 1 ora).

Considera l'esempio di un database SQL Server di dimensioni pari a 500 GiB. I backup di questo database comportano un addebito per l'utilizzo del backup associato a 500 GiB. Inoltre, considera che una copia virtuale di questo database viene fornita a un server di test a mezzogiorno del primo giorno del mese dal backup più recente. Il 10 del mese il database di origine si riduce a 400 GiB. Il 20 del mese, la copia virtuale viene disattivata dal server di test alle 11:00. In questo scenario, viene addebitato un costo di utilizzo della copia virtuale di 500 GiB per 12 ore il 1° e per 24 ore al giorno dal 2 al momento del backup il 10. L'addebito per l'utilizzo della copia virtuale passa a 400 GiB il 10 (al momento del backup) e continua fino al 20 del mese. L'utilizzo della copia virtuale per il giorno 20 conterà solo 11 ore di utilizzo e non l'intera giornata. La quantità di utilizzo non cambia con l'aggiunta di dati scritti nella copia virtuale.

Se i dati vengono trasferiti da un vault di backup quando l'origine e la destinazione si trovano in località Google Cloud diverse, potrebbero essere applicati costi di trasferimento dei dati tra regioni.

Attualmente, i costi per il trasferimento di dati tra regioni si applicano ai trasferimenti associati a VM VMware Engine, database Oracle, database SQL Server e dischi.

I costi di trasferimento dei dati tra regioni per le VM VMware Engine, i database Oracle e i database SQL Server verranno fatturati al progetto in cui si trova il vault di backup, utilizzando gli SKU di Backup and DR elencati di seguito.

I costi di trasferimento dei dati tra regioni per i dischi verranno fatturati al progetto di destinazione del trasferimento di dati e si applicheranno alle dimensioni dei dati trasferiti.

• Per i ripristini del disco, il progetto di destinazione è il progetto della risorsa ripristinata. La fatturazione avverrà tramite lo SKU di trasferimento dati tra regioni di Compute Engine corrispondente.

In futuro verranno applicati costi di trasferimento dei dati tra regioni per le VM Compute Engine. I clienti di Backup e DR riceveranno un preavviso prima dell'inizio degli addebiti per il trasferimento di dati tra regioni per le VM Compute Engine.

I prezzi del trasferimento di dati tra regioni basati sull'utilizzo sono indicati nella tabella seguente e vengono misurati per GiB di dati trasferiti.

Potrebbero essere applicati costi di caricamento per la creazione di backup multiregionali. Potrebbero essere applicati costi di download per il ripristino dei backup multiregionali.

Attualmente, i costi di caricamento e download si applicano ai trasferimenti associati ai dischi e alle dimensioni dei dati trasferiti.

Ulteriori dettagli:

• I costi di caricamento e download vengono fatturati agli SKU corrispondenti che hanno località geografiche contenenti la località multiregionale.
• Quando vengono applicati costi di caricamento/download per un trasferimento di dati tra località, non vengono applicati costi di trasferimento di dati tra regioni.
• Fatturazione del progetto
• I costi di caricamento vengono fatturati, tramite la SKU del servizio Backup e DR corrispondente, al progetto in cui è stato creato il vault di backup multiregionale.
• I costi di download vengono fatturati, tramite lo SKU di download del servizio Compute Engine corrispondente, al progetto di destinazione in cui sono stati ripristinati i dati.

Esempi di casi d'uso:

• "Eseguire il backup di un disco nella regione "us-central1" in un vault di backup multiregionale nella località "us"
• Si applicherebbero i costi di caricamento multiregionale.
• La fatturazione avverrebbe utilizzando lo SKU di caricamento multiregionale "Nord America" del servizio Backup e DR.
• Gli addebiti per il caricamento verrebbero fatturati al progetto in cui è stato creato il backup vault.
• Non si applicherebbero costi per il trasferimento di dati tra regioni.
• Ripristino da un backup del disco multiregionale "us" a una risorsa che si trova nella regione "us-central1".
• Si applicherebbero i costi di download multiregionali.
• La fatturazione avverrà utilizzando lo SKU Compute Engine corrispondente (vedi qui per i dettagli sui prezzi di Compute Engine)
• I costi di download verrebbero fatturati al progetto di destinazione in cui è stata creata la risorsa ripristinata.
• Non si applicherebbero costi per il trasferimento di dati tra regioni.
• Ripristino da un backup del disco multiregionale "us" a una risorsa situata nella regione "europe-west1".
• Non si applicherebbero costi di download multiregionali.
• Verranno applicati costi per il trasferimento di dati tra regioni.
• La fatturazione avverrebbe utilizzando lo SKU Compute Engine corrispondente (vedi qui per i dettagli sui prezzi di Compute Engine).
• I costi di trasferimento dei dati tra regioni verrebbero fatturati al progetto di destinazione in cui è stata creata la risorsa ripristinata.

In futuro verranno applicati addebiti per il caricamento e il download per le VM Compute Engine. I clienti di Backup e DR riceveranno un preavviso prima dell'inizio degli addebiti per il caricamento e il download delle VM Compute Engine.

Disabilitazione dell'API nel progetto contenente un vault di backup

Quando l'API del servizio di Backup e DR è disabilitata in un progetto contenente un vault di backup, il comportamento di fatturazione sarà il seguente:

• La fatturazione dello spazio di archiviazione continuerà fino alla scadenza dei backup in base alla pianificazione di scadenza definita dall'utente.
• Per le VM di Compute Engine protette nei vault di backup
• La fatturazione della gestione per la protezione attiva continuerà a essere fatturata (al progetto in cui si trova la risorsa protetta) per 30 giorni. Dopo 30 giorni consecutivi in stato disattivato, la protezione per le risorse archiviate verrà considerata inattiva.
• Nei casi in cui i dati di backup esistono in un vault di backup, ma la risorsa associata non è più sotto protezione attiva, si applicherà la fatturazione della gestione per le risorse non più sotto protezione attiva.

Disabilitazione dell'API in un progetto contenente VM Compute Engine protette in un vault di backup

Quando l'API del servizio di Backup e DR è disabilitata in un progetto contenente una risorsa protetta in un vault di backup, il comportamento di fatturazione sarà il seguente:

• La fatturazione dello spazio di archiviazione continuerà fino alla scadenza dei backup in base alla pianificazione di scadenza definita dall'utente.
• La fatturazione della gestione per la protezione attiva cesserà. Dopo 30 giorni consecutivi in stato disattivato, la protezione per le risorse archiviate verrà considerata inattiva.
• Nei casi in cui i dati di backup esistono in un vault di backup, ma la risorsa associata non è più sotto protezione attiva, si applicherà la fatturazione della gestione per le risorse non più sotto protezione attiva.

L'appliance di backup/ripristino viene eseguita come VM Compute Engine in un progetto scelto dal cliente. Le appliance del servizio di Backup e DR sono disponibili in tre diverse configurazioni, come indicato in Configurare e pianificare un deployment del servizio di Backup e DR. Per eseguire questi dispositivi si applicano i costi standard delle istanze di Compute Engine.