Google PCD: Costi, governance e operazioni applicative sostenibili — Guida allo studio

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Panoramica

Costi, governance e operazioni sostenibili sono inseparabili nello sviluppo di applicazioni moderne su Google Cloud. L’obiettivo è rendere visibili e controllare le spese, progettare servizi che scalino in modo economico e applicare meccanismi di protezione (guardrail) che mantengano gli ambienti sicuri, conformi e puliti, bilanciando al contempo prestazioni e affidabilità. Questa sezione descrive in dettaglio i meccanismi pratici (fatturazione ed etichette, parametri di autoscaling, quote e policy), l’economia specifica dei carichi di lavoro (Cloud Run, GKE, piattaforme dati) e le scelte consapevoli in termini di sostenibilità che riducono gli sprechi da inattività e l’impatto di carbonio senza compromettere l’esperienza utente.

Controllo e Visibilità dei Costi

Account di fatturazione, etichette, allocazione dei costi, budget, avvisi e visibilità
- Utilizzare un account di fatturazione dedicato per ogni unità di business o fonte di finanziamento per isolare la proprietà e abilitare permessi granulari. Esportare i dati di fatturazione su BigQuery per analisi dettagliate, previsioni e chargeback.
- Le etichette (label) sono coppie chiave-valore associate alle risorse per l’attribuzione dei costi. Standardizzare le chiavi delle etichette (team, app, env, cost-center) e imporle tramite policy dell’organizzazione e controlli CI. Nota: le etichette non sono retroattive; le risorse senza etichetta alterano i report.
- Utilizzare budget e avvisi a livello di account di fatturazione e di progetto. Combinare soglie (es. 50, 90, 100 percento) e trigger basati su previsioni. Indirizzare le notifiche di budget a Pub/Sub e inoltrarle a strumenti di Chat/Ops. I budget generano avvisi; non impongono limiti.
- Per le piattaforme condivise (es. GKE, BigQuery), utilizzare etichette per namespace o per job e associarle a log e dati di utilizzo per abilitare lo showback/chargeback.

Esempio: aggiungere etichette gcloud compute instances update web-01 –labels=team=payments,app=checkout,env=prod

Quote, limiti, previsione dei consumi e governance della capacità
- Le quote proteggono i servizi e limitano i costi incontrollati. Rivedere regolarmente le quote dei servizi, dimensionarle correttamente per ogni progetto e richiederne l’aumento prima dei lanci. Implementare controlli pre-deployment che confrontino l’utilizzo di picco previsto con le quote disponibili.
- Prevedere la spesa utilizzando l’esportazione della fatturazione (Billing export) e la telemetria sull’utilizzo dei prodotti (metriche di Cloud Monitoring, metriche basate su log). Modellare scenari (QPS previsto, dati scansionati) e validarli in pre-produzione.
- Modalità di fallimento: raggiungere la quota durante un incidente o il lancio di un prodotto porta a throttling (429/403), interruzioni parziali o degrado silenzioso delle prestazioni. Quote sovradimensionate aumentano il raggio d’impatto (blast radius) di job difettosi.

Esempio: elencare le quote di Compute Engine gcloud services quota list
–service=compute.googleapis.com
–consumer=projects/$PROJECT_ID

Elasticità ed Economia del Compute

Right-sizing, autoscaling, fatturazione basata sulle richieste, utilizzo impegnato e capacità spot
- Dimensionare correttamente (right-size) vCPU e memoria utilizzando gli insight di Cloud Monitoring e Recommender; convalidare con test di carico. Le sotto-allocazioni causano picchi di latenza e throttling di CPU/OOM; le sovra-allocazioni sprecano budget.
- L’autoscaling converte il sovradimensionamento simile a capex in opex elastico. Utilizzare HPA/VPA per GKE e l’autoscaling per richiesta per i servizi serverless (Cloud Run) per far corrispondere la capacità alla domanda.
- La fatturazione basata sulle richieste (Cloud Run, Cloud Functions, GKE Autopilot) allinea i costi all’utilizzo e riduce l’inattività. Attenzione agli overhead per richiesta e ai cold start; regolare le istanze minime dove appropriato.
- L’utilizzo impegnato (committed use) è per la baseline di stato stazionario. Utilizzare CUD basati sulle risorse per Compute Engine e CUD flessibili per i prodotti gestiti/serverless idonei. Non impegnare eccessivamente (overcommit) carichi di lavoro volatili.
- La capacità Spot riduce i costi di calcolo per i job interrompibili e tolleranti ai guasti. Implementare sempre gestori di terminazione controllata (graceful termination); mantenere la ridondanza e un checkpointing rapido. Aspettarsi la terminazione in qualsiasi momento con un breve preavviso.
Compromessi tra concorrenza e istanze minime in Cloud Run
- La concorrenza controlla quante richieste una singola istanza può servire simultaneamente.
  - Una concorrenza più elevata migliora l’utilizzo e l’efficienza dei costi, ma può aumentare la latenza di coda (tail latency) a causa del blocco head-of-line all’interno del container.
  - Una concorrenza pari a 1 isola le richieste (utile per codice CPU-bound o non thread-safe) ma spesso aumenta il numero di istanze e i costi.
- Le istanze minime riducono i cold start e livellano la latenza al costo di una spesa di base. Utilizzare solo dove gli SLO lo richiedono e convalidare il valore minimo con i pattern di domanda.

Esempio: Configurazione di Cloud Run (service.yaml)

undefined

Richieste e limiti di risorse in GKE, comportamento del Cluster Autoscaler e pulizia delle risorse inattive
- Le richieste (requests) determinano la pianificazione (scheduling); i limiti (limits) limitano l’utilizzo di picco. Impostare le richieste vicino al fabbisogno stazionario osservato e i limiti leggermente al di sopra per consentire brevi picchi. Limiti troppo bassi causano throttling della CPU; limiti di memoria troppo bassi causano OOMKilled. Richieste molto al di sopra della realtà bloccano la capacità e impediscono lo scheduling.
- Il Cluster Autoscaler scala i node pool in base ai pod non pianificabili (richieste aggregate insufficienti). Rispetta i PodDisruptionBudgets e non può espellere (evict) alcuni pod (ad es. con storage locale o PDB restrittivi), il che può impedire lo scale-down. Anche i DaemonSet e i taint/affinità dei nodi possono bloccare l’efficienza della scalabilità.
- L’Horizontal Pod Autoscaler (HPA) lega la scalabilità a CPU/memoria o a metriche personalizzate; il Vertical Pod Autoscaler (VPA) dimensiona correttamente le richieste nel tempo. Coordinare HPA e VPA per evitare oscillazioni; utilizzare VPA nelle modalità recommend o auto a seconda dei casi.
- Pulizia delle risorse inattive: eliminare load balancer, dischi permanenti, snapshot e IP statici non utilizzati. Utilizzare le raccomandazioni di Active Assist e “janitor” automatizzati per rilevare e rimuovere gli asset inattivi.

Esempio: Deployment GKE con richieste/limiti

undefined

Governance dei costi per dati, analytics e rete

Classi di archiviazione, controlli del ciclo di vita, scaling dei database e progettazione dell’egress di rete
- Scegliere le classi di Cloud Storage in base al pattern di accesso: Standard per i dati ad accesso frequente (hot); Nearline, Coldline o Archive per i dati ad accesso meno frequente (colder). Prestare attenzione ai tempi minimi di recupero e di cancellazione anticipata per i livelli di archiviazione meno utilizzati.
- Le regole del ciclo di vita automatizzano le transizioni e le cancellazioni. Utilizzare la configurazione dual-region per la resilienza dove la latenza multi-regione è accettabile; collocare le risorse di calcolo e i dati nella stessa posizione per ridurre l’egress e la latenza.
- Scaling dei database:
  - Cloud SQL: scalare verticalmente con cautela; utilizzare repliche di lettura (read replicas) per le letture; autoscaling dello spazio di archiviazione; usare piani di esecuzione delle query e pooling delle connessioni. Un throughput di scrittura elevato potrebbe richiedere lo sharding o la migrazione a Spanner/Bigtable.
  - Spanner: scaling orizzontale tramite l’aggiunta di nodi; configurazioni multi-regione per la disponibilità e le letture globali; progettare schemi e chiavi per un carico bilanciato.
  - Bigtable: progettare le chiavi di riga (row keys) per evitare hotspot; scalare i nodi del cluster e lo storage separatamente.
- Egress di rete: evitare il traffico tra regioni diverse; posizionare client e dati nella stessa regione, dove possibile. Utilizzare Cloud CDN per contenuti su scala Internet, Cloud Interconnect/Peering per ambienti ibridi e Private Google Access o Private Service Connect per accedere privatamente alle API di Google. Il traffico non necessario tra zone o regioni diverse aumenta i costi e la latenza.

Esempio: ciclo di vita di Cloud Storage

undefined

Controlli delle query di BigQuery, conservazione dei dati e costi di utilizzo per l’analytics
- Controllare i byte analizzati: filtrare sempre per chiavi di partizione/cluster; evitare SELECT *; utilizzare viste materializzate e caching dei risultati per query ripetute; usare aggregazioni approssimate quando possibile.
- Limitare il costo delle scansioni con l’opzione maximum bytes billed e impostare la priorità del job su batch per lavori non urgenti, al fine di ridurre interferenze e costi.
- Scegliere il modello di pricing: on-demand per carichi di lavoro sporadici; prenotazioni (slot) con commitment per carichi di lavoro costanti e ad alto volume. Utilizzare prenotazioni e assegnazioni separate per isolare i team.
- Conservazione dei dati: impostare la scadenza di set di dati/tabelle e partizioni per la governance; implementare l’archiviazione a livelli (tiered storage) o l’esportazione per l’archiviazione a lungo termine.
- Modalità di fallimento: tabelle di grandi dimensioni non partizionate fanno esplodere i costi; query senza filtri di partizione analizzano intere tabelle; scadenze troppo aggressive cancellano dati necessari; un’eccessiva contesa per gli slot (slot contention) degrada gli SLA.

Esempio: limitare il costo di una query

undefined

Governance Organizzativa e Igiene degli Ambienti

Policy dell’organizzazione, nomenclatura delle risorse, tagging e separazione dei progetti
- Utilizzare le policy dell’organizzazione per imporre dei guardrail: limitare le location delle risorse, non consentire IP esterni, richiedere CMEK, limitare i servizi consentiti, controllare il peering VPC e imporre l’uso di OS Login dove necessario. Applicare a livello di organizzazione o cartella, con eccezioni modellate tramite la gerarchia.
- Standardizzare la nomenclatura delle risorse per codificare ambiente, progetto, app e regione (es. app-env-region-suffix). Imporre la regola tramite controlli CI o policy-as-code.
- Distinguere tra:
  - Etichette (Labels): attribuzione per fatturazione/operazioni.
  - Tag (di prima classe): da associare alle risorse e utilizzare nelle condizioni IAM e nel targeting delle policy dell’organizzazione.
  - Tag di rete: per le regole firewall su Compute Engine.
- Separazione dei progetti: isolare gli ambienti (prod, staging, dev) e i carichi di lavoro sensibili. Utilizzare Shared VPC per una rete centralizzata e progetti di servizio con privilegi minimi (least-privilege). Questo riduce il raggio d’impatto e semplifica la gestione di IAM.
Ciclo di vita dell’ambiente, ambienti di test effimeri e automazione della pulizia
- Eseguire il provisioning degli ambienti tramite IaC (Terraform) e abilitare ambienti effimeri per ogni PR. Impostare etichette TTL e lo smantellamento automatico dopo il merge o un periodo di inattività.
- Utilizzare Cloud Scheduler insieme a job di Cloud Run o a Functions per individuare ed eliminare le risorse obsolete in base a etichetta/età. Esportare l’inventario tramite Cloud Asset Inventory per alimentare gli audit.
- Modalità di fallimento: le sandbox abbandonate generano costi; la mancanza di TTL o etichette impedisce la pulizia; una pulizia troppo aggressiva può eliminare risorse attive—aggiungere allowlist e periodi di tolleranza.
Architettura attenta alla sostenibilità e bilanciamento di costi, prestazioni e affidabilità
- Preferire servizi gestiti e serverless per ridurre i tempi di inattività (idle) e migliorare l’utilizzo delle risorse.
- Scegliere regioni con minore intensità di carbonio, ove conforme alle policy; pianificare i carichi di lavoro batch durante i periodi con maggiore disponibilità di energia a zero emissioni di carbonio, quando possibile.
- Ottimizzare la data gravity e la cache per ridurre il consumo energetico della rete. Ottimizzare l’autoscaling e la concorrenza per ridurre il sottoutilizzo. Usare il profiling per rimuovere percorsi di codice inefficienti che causano un eccesso di calcolo o I/O.
- Bilanciamento: aggiungere istanze o repliche minime solo dove richiesto dagli SLO; valutare la latenza di coda rispetto alla concorrenza e la ridondanza rispetto all’uso di istanze Spot. Convalidare con test di carico basati sugli SLO e modelli di costo/prestazioni.

Scenario Pratico

NimbusMarket, un’azienda di e-commerce, registra picchi di traffico durante le vendite flash e una spesa crescente per l’analytics. Le API per i clienti girano su Cloud Run, i worker di background su GKE e l’analisi dei prodotti su BigQuery. La direzione chiede una riduzione dei costi del 25% senza compromettere l’SLO del 99,9% per le API.

Approccio:

Stabilire visibilità dei costi e guardrail
- Creare budget con avvisi di previsione al 60%, 90% e 100% per l’account di fatturazione, con notifiche Pub/Sub instradate al personale di reperibilità.
- Standardizzare le etichette (team, app, env, cost-center) e imporle tramite CI sui piani Terraform; aggiungere una policy dell’organizzazione che limiti le location delle risorse alle regioni approvate. Logica: I budget forniscono un preavviso; le etichette permettono di generare report per team; le policy prevengono l’uso accidentale di regioni con egress elevato e migliorano la conformità.
Ottimizzare Cloud Run per una scalabilità economica
- Impostare containerConcurrency a 40 per l’API stateless dopo che il profiling ha confermato un tempo CPU medio di 30 ms e I/O non bloccante. Configurare minScale=2 per evitare cold start durante le ore di normale attività; impostare una policy pianificata per ridurre minScale a 0 durante la notte. Logica: Una concorrenza più alta migliora l’utilizzo e riduce il numero di istanze; un numero minimo di istanze stabili preserva gli SLO con un costo di base limitato che viene eliminato fuori orario.
Eseguire il right-sizing dei carichi di lavoro GKE e abilitare un autoscaling efficiente
- Applicare richieste (requests) di 500m CPU/512Mi e limiti (limits) di 1 CPU/768Mi ai pod dei worker sulla base del profiling. Abilitare l’HPA sulla profondità della coda e sulla latenza di elaborazione, e il VPA in modalità “recommend” per affinare iterativamente le richieste. Verificare che i PodDisruptionBudgets consentano lo scale-down. Abilitare il Cluster Autoscaler sul pool con più nodi di dimensioni inferiori. Logica: Richieste accurate guidano uno scheduling e un autoscaling efficaci; l’HPA allinea la capacità al backlog; il VPA evita deviazioni (drift); più nodi piccoli riducono la capacità inutilizzata e accelerano gli eventi di scalabilità.
Adottare la capacità Spot per l’elaborazione batch tollerante ai guasti
- Spostare la generazione di miniature delle immagini su un node pool basato su istanze Spot con checkpointing. Implementare hook preStop per completare il lavoro in corso e un controller per ripianificare i job interrotti. Logica: La generazione di miniature è idempotente e flessibile in termini di tempo, rendendola ideale per ottenere risparmi con le istanze Spot con un impatto minimo sull’esperienza utente.
Ridurre i costi di scansione per l’analytics e isolare i carichi di lavoro
- Partizionare e clusterizzare la tabella degli eventi per event_date e customer_id. Aggiungere una scadenza della tabella per gli eventi grezzi dopo 180 giorni. Assegnare gli analisti di marketing a una reservation BigQuery separata con un limite di slot (slot cap); imporre maximum_bytes_billed nelle loro query pianificate. Convertire i report notturni in priorità batch. Logica: Il partizionamento e la clusterizzazione limitano i byte scansionati per query; la scadenza impone la governance; le reservation isolano i “noisy neighbor”; la priorità batch riduce la contesa e i costi per i job non urgenti.
Ottimizzare il ciclo di vita dello storage e l’egress
- Archiviare le immagini dei prodotti in una location dual-region vicina ai clienti; spostare le immagini non modificate da 30 giorni in Coldline tramite regole del ciclo di vita; servirle tramite Cloud CDN. Collocare i servizi Cloud Run nella stessa regione di Cloud SQL e abilitare Private Service Connect per le API di Google. Logica: La CDN riduce l’egress e la latenza; il ciclo di vita sposta i contenuti “freddi” su storage più economico; la co-locazione minimizza l’egress e migliora le prestazioni.
Implementare l’automazione della pulizia e i controlli di sostenibilità
- Taggare gli ambienti effimeri con ttl-hours ed eseguire un job notturno di Cloud Run che elimina le risorse scadute. Utilizzare i report di Carbon Footprint per valutare lo spostamento dei job batch in una regione a minore intensità di carbonio e pianificarli durante le ore a minore impatto. Logica: La pulizia automatizzata previene le fughe di costi; la pianificazione consapevole delle emissioni di carbonio riduce l’impatto ambientale senza influire sugli SLO.
Convalidare con test di carico consapevoli degli SLO e modelli di costo
- Eseguire test di carico che riproducono i pattern delle vendite flash; verificare la latenza p95 e gli error budget. Confrontare i costi prima e dopo utilizzando le dashboard basate sull’esportazione della fatturazione. Logica: Conferma che l’ottimizzazione soddisfa gli obiettivi di affidabilità, fornendo al contempo risparmi misurabili e allineati agli obiettivi.

Eseguendo questi passaggi, NimbusMarket allinea la spesa alla domanda, previene gli sprechi dovuti all’inattività e impone la governance, ottenendo i risparmi prefissati pur mantenendo l’SLO del 99,9% per le API e migliorando la propria posizione in termini di sostenibilità.

← Test · Tutti i domini

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →