Google ACE: Gestione dei costi, prestazioni e ottimizzazione della capacità — Guida allo studio

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Fa parte della Google Associate Cloud Engineer — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

La gestione dei costi e l’ottimizzazione delle prestazioni e della capacità su Google Cloud richiedono visibilità continua, decisioni di right-sizing e una governance che allinei l’utilizzo delle risorse con gli obiettivi di business. Una pratica efficace combina controlli finanziari (budget, allocazione), leve tecniche (autoscaling, prenotazioni, policy di ciclo di vita), scelte architetturali (località dei dati, replica) e feedback operativo (telemetria, test di carico). Questa sezione descrive in dettaglio strumenti chiave, trade-off e modalità di fallimento per ambiti quali calcolo, storage, elaborazione dati, networking, database, quote e ingegneria delle prestazioni.

Visibilità dei costi, budget e allocazione

Report di fatturazione ed esportazioni:
- Utilizzare i Cloud Billing Report per un’analisi rapida dei trend e dei dettagli per SKU; abilitare l’esportazione dei dati di Cloud Billing verso BigQuery per ottenere dati di costo e utilizzo dettagliati e interrogabili. Questo supporta previsioni giornaliere/mensili, rilevamento delle anomalie e rollup multi-progetto con SQL standard.
- L’esportazione della tabella dei prezzi aiuta a riconciliare i prezzi di listino con i costi e i crediti per SKU.
- Modalità di fallimento: L’utilizzo delle sole viste della console limita la granularità; non esportare i dati su BigQuery impedisce la modellazione storica e un accurato showback/chargeback.
Budget e avvisi:
- Creare budget con ambito limitato a account di fatturazione, progetti, cartelle, servizi o filtri per etichette/tag; configurare avvisi di soglia (es. 50/90/100%) sul costo effettivo e previsto. Considerare canali di notifica tramite Pub/Sub per attivare azioni automatizzate (es. mettere in pausa gli ambienti non di produzione).
- Trade-off: Arresti automatici aggressivi riducono la spesa ma possono danneggiare l’affidabilità se applicati ai percorsi di produzione.
Etichette e tag per l’allocazione:
- Applicare etichette alle risorse e tag di Resource Manager in modo coerente (env, app, owner, cost-center). I tag supportano le policy dell’organizzazione e compaiono nei filtri di fatturazione per un’allocazione robusta.
- Governance: Applicare policy per etichette/tag utilizzando Organization Policy, template di deployment e controlli CI/CD.
- Modalità di fallimento: Chiavi incoerenti o etichette mancanti compromettono i modelli di allocazione; i tag ereditati non vengono applicati a tutti i tipi di risorsa se gli strumenti non sono coerenti.
Modelli di allocazione dei costi:
- Lo showback/chargeback utilizza tipicamente una gerarchia: progetto → servizio/SKU → etichetta/tag. I costi della piattaforma condivisa (es. load balancer, traffico in uscita dalla VPC) possono essere allocati in base a driver come il numero di richieste, i GB trasferiti o le ore-CPU misurate tramite log/metriche.
- Trade-off: I modelli semplici (divisione equa) sono facili da implementare ma possono attribuire un prezzo errato agli utenti con carichi pesanti; i modelli granulari richiedono una telemetria affidabile e un maggiore overhead.

Breve esempio (dry run in BigQuery per la stima dei costi):

bq query –use_legacy_sql=false –dry_run ‘SELECT … FROM proj.ds.tbl WHERE dt >= “2026-08-01”’

Efficienza del calcolo e ottimizzazione del ciclo di vita

Right-sizing e tipi di macchina personalizzati:
- Utilizzare la Recommender API/console per effettuare il right-sizing delle VM in base ai percentili di utilizzo di CPU/memoria. Preferire i tipi di macchina personalizzati per esigenze stabili che non rientrano nei tipi predefiniti (es. 2 vCPU/10 GB di RAM) per evitare di pagare per la capacità inutilizzata.
- Modalità di fallimento: Il ridimensionamento di servizi sensibili alla latenza o con picchi di carico (bursty) può causare throttling. Convalidare con test di carico e prevedere un margine di buffer.
Committed Use Discount (CUD):
- Acquistare CUD basati sulle risorse (vCPU, memoria, GPU) con ambito regionale per periodi di 1 o 3 anni tramite console o CLI. Ideali per una capacità di base stabile; sovrapporre l’autoscaling per gestire i picchi.
- Trade-off: Gli impegni (commitment) riducono il prezzo unitario ma sono inflessibili. Un impegno eccessivo (overcommitting) blocca la spesa; un impegno insufficiente (undercommitting) fa perdere gli sconti.
Spot VM:
- Utilizzare le Spot VM per carichi di lavoro fault-tolerant e interrompibili (batch, CI, livelli stateless). Implementare il checkpointing e la gestione della preemption (preavviso di 30 secondi tramite metadati/Pub/Sub).
- Modalità di fallimento: La capacità può scomparire in qualsiasi momento; non collocare mai servizi stateful o critici per il quorum esclusivamente su Spot VM.
Autoscaling, pianificazione e ciclo di vita:
- I Managed Instance Group (MIG) con autoscaling (basato su CPU, load balancer o metriche personalizzate di Cloud Monitoring) gestiscono il carico variabile. Regolare i controlli di cool-down e scale-in per prevenire oscillazioni; allineare il ritardo iniziale dell’health check con la prontezza dell’applicazione (readiness).
- Pianificazione: Arrestare o sospendere le VM di sviluppo/test al di fuori dell’orario di lavoro; utilizzare Instance Schedules o automazioni con Cloud Scheduler e Cloud Functions per minimizzare i costi di inattività.
- Ciclo di vita e manutenzione: Abilitare il riavvio automatico e la migrazione per manutenzione dell’host (host maintenance migrate) per l’alta disponibilità; tenere presente che la migrazione live potrebbe non essere applicabile con GPU o SSD locali.
- Pulizia delle risorse inattive: Recuperare dischi permanenti non collegati, snapshot obsoleti e IP statici non utilizzati usando Recommender.
- Modalità di fallimento: Ritardi brevi negli health check o segnali di readiness mancanti causano un overprovisioning; uno scale-in troppo aggressivo interrompe le connessioni; disabilitare l’autoriparazione (autohealing) nasconde i nodi che presentano errori.

Brevi esempi:

gcloud compute commitments create base-36mo –region=us-central1 –plan=36-month –resources=vcpu=64,memory=240Gi
gcloud compute instances add-labels vm-1 –labels=env=prod,app=api,cost-center=cc123

Economia dello storage e dell’elaborazione dati

Classi di archiviazione e ciclo di vita di Cloud Storage:
- Scegliere le classi in base al pattern di accesso: Standard (dati ad accesso frequente), Nearline (min. ≥30 giorni), Coldline (min. ≥90 giorni), Archive (min. ≥365 giorni). Applicare regole del ciclo di vita per passare a classi inferiori ed eliminare i dati secondo una pianificazione.
- Compromessi sul recupero: Le classi a costo inferiore impongono tariffe di recupero per GB e costi per la durata minima di archiviazione; letture frequenti su Coldline/Archive annullano i risparmi. Pianificare i flussi di lavoro di ripristino tenendo conto dei picchi di costo in lettura.
- Governance: Usare policy di conservazione e blocchi degli oggetti per la conformità; abilitare i pagamenti a carico del richiedente (requester-pays) per i set di dati condivisi per evitare sorprese di fatturazione tra team.
Esempio di policy del ciclo di vita (tiering e successiva eliminazione):
- Definire le azioni SetStorageClass e Delete basate sull’età per automatizzare le transizioni e la pulizia dei dati obsoleti.
Controlli dei costi di BigQuery:
- Le query on-demand vengono addebitate per byte elaborati; minimizzare i costi con il partition pruning e il clustering. Partizionare per data di ingestione o colonna di data; creare cluster su un massimo di quattro colonne con alta cardinalità/selettività.
- Utilizzare esecuzioni di prova (dry run) per stimare i costi, viste materializzate per le aggregazioni ad accesso frequente e decoratori di tabella per restringere le finestre temporali.
- Le prenotazioni (slot) offrono prestazioni e spesa prevedibili; utilizzare assegnazioni per progetto/cartella e considerare i commitment flessibili per picchi di breve durata.
- Scenari di fallimento: Scansioni non partizionate, SELECT * in tabelle molto larghe o un clustering mal ordinato generano un’enorme quantità di byte scansionati; le tabelle intermedie effimere possono far lievitare lo spazio di archiviazione se non vengono fatte scadere.

Breve esempio (snippet JSON del ciclo di vita di Cloud Storage):

{ “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }

Networking, database e scalabilità attenta alle quote

Traffico in uscita (egress) e impatto sull’architettura:
- Il traffico in uscita verso Internet, tra region e tramite IP esterni comporta dei costi; il traffico all’interno della stessa region su IP interni è generalmente gratuito. Scegliere il Premium Network Tier per le prestazioni o lo Standard Tier per carichi di lavoro sensibili ai costi con requisiti meno stringenti di latenza/jitter.
- Load balancer: I load balancer L7 HTTP(S) e L4 TCP/UDP hanno costi di elaborazione dati e per le regole di forwarding; i LB cross-region possono aggiungere costi di egress tra region. Consolidare i LB consente di risparmiare sui costi fissi, ma può aumentare il raggio d’impatto (blast radius).
- Ottimizzazione: Mantenere il traffico all’interno della stessa region; utilizzare bucket e servizi regionali; evitare l’hairpinning attraverso IP esterni. Mettere in cache gli asset statici sull’edge per ridurre l’egress dall’origine.
- Scenari di fallimento: L’uso accidentale di IP esterni tra servizi nella stessa VPC genera costi di egress non necessari; la replica multi-region raddoppia l’egress per i percorsi di scrittura.
Dimensionamento dei database, repliche e disponibilità:
- Cloud SQL: Dimensionare vCPU/RAM per il carico al 95° percentile; abilitare il ridimensionamento automatico dello storage; utilizzare repliche di lettura per lo scale-out in lettura; l’alta disponibilità (HA) raddoppia i costi di calcolo ma riduce l’RTO di failover. Il connection pooling evita un overhead eccessivo di connessioni.
- Spanner: La capacità viene fornita come nodi o unità di elaborazione; le configurazioni multi-region migliorano la disponibilità e la latenza in lettura, ma aumentano i costi e la latenza in scrittura; pianificare attentamente split e hotspot.
- Bigtable: Il numero di nodi determina il throughput; l’autoscaler aiuta a seguire il traffico; la replica multi-cluster aggiunge disponibilità e costi; progettare lo schema per una distribuzione uniforme delle chiavi.
- Compromessi: Le repliche migliorano il throughput in lettura e la disponibilità, ma aumentano l’amplificazione della scrittura e l’egress; la coerenza forte (strong consistency) e le scritture multi-region aggiungono latenza.
Quote, limiti di frequenza e backpressure:
- Comprendere le quote per API e la concorrenza per servizio. Implementare un backoff esponenziale con jitter per gli errori 429/5xx. Applicare il livellamento del carico basato su code con Pub/Sub e Dataflow o job di Cloud Run.
- Impostazioni di concorrenza: In Cloud Run, una concorrenza più elevata riduce i costi ma aumenta il rischio di latenza di coda (tail latency); ottimizzare l’allocazione della CPU su richiesta per un throughput costante.
- Backpressure: Utilizzare il controllo di flusso nei sottoscrittori di Pub/Sub, i circuit breaker e l’admission control per prevenire fallimenti a cascata.
- Scenari di fallimento: Ignorare le quote porta a un throttling improvviso; l’autoscaling può amplificare il carico sui sistemi a valle (downstream) senza backpressure, causando tentativi ripetuti (retry) e un aumento esponenziale dei costi.