Google Cloud ha ripensato in modo radicale il funzionamento dei CUD spend-based, abbandonando il modello a crediti per passare a una tariffazione direttamente scontata ed estendendo al contempo la copertura a VM memory-optimized, HPC e Cloud Run. Da ieri tutti i clienti sono stati migrati al nuovo sistema. Ecco cosa cambia per i Suoi costi cloud e per le Sue dashboard FinOps.
Il vecchio rompicapo della fatturazione
Le è mai capitato di calcolare i risparmi dei CUD destreggiandosi tra costi on-demand, fee di commitment e crediti compensativi? Funzionava così il vecchio sistema CUD spend-based di Google. Ci si impegnava, ad esempio, su 100$/ora di spesa on-demand, si pagava una fee di commitment di 54$/ora (con uno sconto del 46%) e si riceveva un credito di -100$ a compensare i costi di utilizzo. I conti tornavano, ma spiegarlo ai clienti o al reparto finance era un incubo.
Il nuovo modello multiprice spazza via questa complessità. Al posto dei crediti, Google applica ora lo sconto direttamente ai prezzi degli SKU tramite i cosiddetti "consumption models". Ci si impegna sulla spesa scontata effettiva (54$/ora), si paga quell'importo e l'utilizzo viene mostrato direttamente al prezzo scontato. Niente crediti separati, niente acrobazie mentali.
Il cambiamento modifica anche profondamente il modo in cui i dati CUD compaiono negli export di BigQuery, e impone aggiornamenti a qualsiasi dashboard FinOps o sistema di cost allocation sviluppato internamente. Ci siamo passati anche noi di DoiT.
L'analisi tecnica nel dettaglio
La migrazione introduce tre cambiamenti fondamentali che i clienti devono comprendere:
Primo: la logica di calcolo del commitment è invertita. Prima ci si impegnava in base alla spesa equivalente on-demand. Ora ci si impegna sul costo orario scontato effettivo. Un commitment che copriva 185$ di utilizzo on-demand al 46% di sconto veniva descritto come "commitment da 185$/ora". Con il nuovo modello, lo stesso commitment viene descritto come "commitment da 100$/ora", ovvero l'importo che si paga effettivamente. Anche lo strumento CUD Recommendations è stato aggiornato di conseguenza. Se utilizza script di automazione che calcolano gli importi dei commitment, andranno rivisti.
Secondo: lo schema di BigQuery si arricchisce di nuovi campi. L'aggiunta più rilevante è la struct consumption_model, che contiene i campi id e description. Quando l'utilizzo è coperto da un Compute Flexible CUD triennale, il campo description riporta "Compute Flexible CUDs 3 Year" invece di apparire come una riga di credito separata. Google ha inoltre aggiunto i campi price.list_price, price.effective_price_default e cost_at_list_consumption_model per distinguere più facilmente, nelle Sue query, tra prezzi on-demand e scontati.
Terzo: gli SKU delle fee sono stati ristrutturati. I nuovi SKU di fee CUD hanno un prezzo di 1$/ora con un credito compensativo chiamato FEE_UTILIZATION_OFFSET. Quando il CUD è pienamente utilizzato, fee e offset si annullano a zero. In caso di sottoutilizzo, la quota non sfruttata comparirà come addebito. Si generano così due righe per ciascun CUD nei dati di fatturazione: una per l'utilizzo coperto a tariffe scontate, una per le eventuali eccedenze a tariffe on-demand.
FEE_UTILIZATION_OFFSET
Una copertura più ampia, opportunità di risparmio concrete
I Compute Flexible CUDs ora coprono workloads che in precedenza richiedevano tipi di commitment dedicati o non avevano alcuna possibilità di sconto.
Le VM memory-optimized ottengono finalmente la copertura Flex CUD. Le famiglie M1, M2, M3 e M4 possono ora essere coperte dai Compute Flexible CUDs, ma solo nella formula triennale, con uno sconto del 63%. Attenzione a un dettaglio importante: i commitment annuali offrono zero sconto sulle VM memory-optimized. La Sua spesa consumerà il commitment senza alcun beneficio in termini di risparmio. Se gestisce workloads memory-intensive come SAP HANA o grandi database in-memory, i commitment triennali diventano molto più interessanti.
Anche le famiglie HPC entrano in gioco. Le famiglie compute-optimized H3 e la nuova H4D sono ora idonee per i Flex CUD, con uno sconto del 17% sul triennale annuale e del 38% sul triennale. La H4D, attualmente in preview, è dotata di processori AMD EPYC Turin di 5ª generazione con 192 core, fino a 1.488 GB di memoria e networking RDMA-enabled da 200 Gbps. Hardware di altissimo livello per workloads di calcolo davvero impegnativi.
Cloud Run ottiene una copertura completa. La fatturazione request-based per i servizi Cloud Run (incluse le Cloud Run functions, in precedenza note come Cloud Functions) si qualifica ora per i Compute Flexible CUDs con uno sconto del 17% sia sull'annuale sia sul triennale. La fatturazione instance-based, i jobs e i worker pools continuano a beneficiare degli sconti del 28%/46%. Se gestisce workloads serverless su larga scala, l'impatto sulla Sua unit economics può essere significativo.
La tabella seguente riassume la nuova struttura degli sconti spend-based:
I Suoi risparmi avranno un'altra faccia
Dopo la migrazione, la colonna "Savings" della Sua dashboard FinOps mostrerà numeri sensibilmente più bassi. Se prima indicava -10,00$, ora potrebbe indicare -4,50$. Una situazione che fa scattare i campanelli d'allarme, finché non si capisce cosa sta succedendo.
Il vecchio modello mostrava un credito lordo che compensava l'intero costo on-demand. Il nuovo modello mostra il risparmio netto effettivo: la differenza tra quanto avrebbe pagato a tariffe on-demand e quanto ha effettivamente pagato a tariffa scontata. L'importo finale della fattura e il risparmio reale sono identici nei due casi. È cambiata solo la presentazione.
Nessuno di questi cambiamenti incide sulle Sue percentuali di sconto effettive. Un Compute Flexible CUD triennale Le fa sempre risparmiare il 46% sul compute generale. L'annuale, sempre il 28%. I soldi che escono dalle Sue tasche sono esattamente gli stessi prima e dopo la migrazione. Google ha cambiato il modo in cui i risparmi vengono visualizzati, non il modo in cui vengono calcolati. Mettiamolo in chiaro.
Questo richiederà anche una comunicazione mirata con CFO e stakeholder ormai abituati a vedere numeri di credito molto alti. Quando Le chiederanno perché i crediti CUD sono calati del 55%, dovrà spiegare che ora stanno guardando i risparmi reali, non più compensazioni contabili.
Le domande che mi sento ripetere
Il mio importo di commitment aumenterà se non aderisco?
No. Quando Google effettua la migrazione automatica, converte i commitment esistenti in valori equivalenti nel nuovo modello. Se aveva un commitment da 185$/ora (espresso come equivalente on-demand), diventa un commitment da 100$/ora (la Sua spesa scontata effettiva). Stessa copertura, stesso costo, etichetta diversa. Il portafoglio resta esattamente com'era; cambia solo la reportistica.
I miei CUD esistenti copriranno meno dopo la migrazione?
No, anzi: è vero il contrario. Tutti i CUD esistenti copriranno almeno ciò che coprivano prima, e molti copriranno più SKU grazie all'idoneità estesa. Se oggi ha dei Compute Flexible CUDs, inizieranno automaticamente a coprire workloads di nuova idoneità, come la fatturazione request-based di Cloud Run, le istanze H3/H4D e le VM memory-optimized. Significa un migliore utilizzo dei commitment che ha già acquistato, senza alcuna azione da parte Sua.
Quindi cosa cambia davvero?
La presentazione e la struttura dei dati. Le percentuali di sconto restano invariate. I costi dei commitment restano invariati. La copertura resta uguale o migliora. I cambiamenti riguardano:
- il modo in cui vengono espressi gli importi dei commitment;
- il modo in cui i risparmi appaiono negli export di fatturazione;
- quali SKU sono idonei alla copertura.
Tutto qui.
I CUD resource-based restano invariati
Vale la pena sottolineare cosa questa migrazione non tocca. I committed use discounts resource-based — quelli in cui ci si impegna su quantità specifiche di vCPU, memoria, GPU o Local SSD in una determinata regione e in un determinato progetto — continuano a funzionare esattamente come prima. Restano ideali per workloads prevedibili e a regime costante, con requisiti di risorse stabili.
Le differenze chiave permangono:
- i CUD resource-based sono specifici per progetto e regione (anche se è possibile abilitare la condivisione su un account di fatturazione);
- i Flex CUD spend-based si applicano automaticamente a tutto l'utilizzo idoneo all'interno di un account di fatturazione.
I commitment resource-based offrono percentuali di sconto leggermente superiori per il compute generale (fino al 55% sul triennale, contro il 46% dei Flex), ma richiedono una pianificazione delle capacità più accurata.
Alla maggior parte delle organizzazioni consiglio sempre una strategia che combini entrambi: CUD resource-based per i workloads di baseline, prevedibili, e Flex CUD per l'utilizzo variabile o distribuito, più difficile da inquadrare per regione e tipo di macchina.
Il nuovo modello CUD multiprice è il cambiamento più importante introdotto da Google Cloud sul fronte della fatturazione da anni a questa parte. La copertura estesa e un modello dati più pulito sono ottimi passi avanti. Ora il Suo compito è assicurarsi che i sistemi interni siano pronti a sfruttarli al meglio — e se vuole che noi di DoiT La aiutiamo, parliamone.