Google ACE: Cost Management, Performance and Capacity Optimization — Study Guide

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

Part of the Google Associate Cloud Engineer — Study Guide. Practice with verified answers in the Google exam hub, or take timed practice tests on ExamRoll.io.

Overview

Cost management and performance/capacity optimization on Google Cloud require continuous visibility, right-sizing decisions, and governance that aligns resource utilization with business goals. Effective practice blends financial controls (budgets, allocation), technical levers (autoscaling, reservations, lifecycle policies), architectural choices (data locality, replication), and operational feedback (telemetry, load tests). This section details key tools, trade-offs, and failure modes across compute, storage, data processing, networking, databases, quotas, and performance engineering.

Cost Visibility, Budgets, and Allocation

• Billing reports and exports:

  • Use Cloud Billing Reports for quick trend and SKU breakdowns; enable Cloud Billing data export to BigQuery for detailed, queryable cost-and-usage data. This supports daily/monthly forecasts, anomaly detection, and multi-project rollups with standard SQL.
  • Pricing table export helps reconcile list prices with SKU costs and credits.
  • Failure modes: Using only console views limits granularity; not exporting to BigQuery blocks historical modeling and accurate showback/chargeback.

• Budgets and alerts:

  • Create budgets scoped to billing accounts, projects, folders, services, or label/tag filters; configure threshold alerts (e.g., 50/90/100%) on actual and forecasted cost. Consider notification channels via Pub/Sub to trigger automated actions (e.g., pausing non-prod).
  • Trade-off: Aggressive automated shutdowns reduce spend but can harm reliability if applied to production paths.

• Labels and tags for allocation:

  • Apply resource labels and Resource Manager tags consistently (env, app, owner, cost-center). Tags support org policies and appear in billing filters for robust allocation.
  • Governance: Enforce label/tag policies using Organization Policy, deployment templates, and CI/CD checks.
  • Failure modes: Inconsistent keys or missing labels break allocation models; inherited tags not applied to all resource types if tooling is inconsistent.

• Cost allocation models:

  • Showback/chargeback typically use a hierarchy: project → service/SKU → label/tag. Shared platform costs (e.g., load balancers, VPC egress) can be allocated by drivers such as requests, GB transferred, or CPU-hours measured via logs/metrics.
  • Trade-off: Simple models (equal split) are easy to run but can misprice heavy users; granular models require reliable telemetry and more overhead.

Short example (BigQuery dry run for cost estimation):

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

Compute Efficiency and Lifecycle Optimization

• Rightsizing and custom machine types:

  • Use the Recommender API/console to rightsize VMs based on CPU/memory usage percentiles. Prefer custom machine types for steady, sub-flavor needs (e.g., 2 vCPU/10 GB RAM) to avoid paying for unused capacity.
  • Failure modes: Downsizing latency-sensitive or bursty services can cause throttling. Validate with load tests and buffer headroom.

• Committed Use Discounts (CUDs):

  • Purchase resource-based CUDs (vCPU, memory, GPUs) at regional scope for 1- or 3-year terms via console or CLI. Best for stable baseline capacity; overlay autoscaling for bursts.
  • Trade-offs: Commitments reduce unit price but are inflexible. Overcommitting locks in spend; undercommitting forfeits discounts.

• Spot VMs:

  • Use Spot VMs for fault-tolerant, interruptible workloads (batch, CI, stateless tiers). Implement checkpointing and preemption handling (30-second notice via metadata/Pub/Sub).
  • Failure modes: Capacity can disappear any time; never place stateful or quorum-critical services solely on Spot.

• Autoscaling, scheduling, and lifecycle:

  • Managed instance groups (MIGs) with autoscaling (CPU, load balancer, or custom Cloud Monitoring metrics) handle variable load. Tune cool-down and scale-in controls to prevent oscillation; align health check initial delay with app readiness.
  • Scheduling: Stop or suspend dev/test VMs off-hours; use Instance Schedules or automation with Cloud Scheduler and Cloud Functions to minimize idle cost.
  • Lifecycle and maintenance: Enable automatic restart and host maintenance migrate for high availability; be aware that live migration may not apply with GPUs or local SSDs.
  • Idle cleanup: Reclaim unattached persistent disks, stale snapshots, and unused static IPs using Recommender.
  • Failure modes: Short health check delays or missing readiness signals cause overprovisioning; too-aggressive scale-in drops connections; disabling autohealing hides failing nodes.

Short examples:

• 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

Storage and Data Processing Economics

• Cloud Storage classes and lifecycle:

  • Choose classes by access pattern: Standard (hot), Nearline (≥30-day min), Coldline (≥90-day min), Archive (≥365-day min). Apply lifecycle rules to tier down and delete on schedule.
  • Retrieval trade-offs: Lower-cost classes impose per-GB retrieval fees and minimum storage duration charges; frequent reads on Coldline/Archive erase savings. Plan restore workflows for peak read costs.
  • Governance: Use retention policies and object holds for compliance; enable requester-pays for shared datasets to avoid cross-team billing surprises.

• Lifecycle policy example (tier then delete):

  • Define Age-based SetStorageClass and Delete actions to automate transitions and cleanup of stale data.

• BigQuery cost controls:

  • On-demand queries charge per bytes processed; minimize with partition pruning and clustering. Partition by ingestion or date column; cluster up to four columns with high cardinality/selectivity.
  • Use dry runs to estimate cost, materialized views for hot aggregations, and table decorators to narrow time windows.
  • Reservations (slots) provide predictable performance and spend; use assignments per project/folder, and consider flex commitments for short spikes.
  • Failure modes: Unpartitioned scans, SELECT * in wide tables, or poorly ordered clustering generate massive scanned bytes; ephemeral intermediate tables can balloon storage if not expired.

Short example (Cloud Storage lifecycle JSON snippet):

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

Networking, Databases, and Quota-Conscious Scale

• Network egress and architecture impact:

  • Egress to the internet, between regions, and via external IPs incurs charges; same-region traffic over internal IP is generally free. Choose Premium Network Tier for performance or Standard for cost-sensitive workloads with looser latency/jitter needs.
  • Load balancers: L7 HTTP(S) and L4 TCP/UDP have data processing and forwarding rule charges; cross-region LBs may add inter-region egress. Consolidating LBs saves fixed costs but may increase blast radius.
  • Optimization: Keep traffic intra-region; use regional buckets and services; avoid hairpinning through external IPs. Cache static assets at the edge to reduce origin egress.
  • Failure modes: Accidentally using external IPs between services in the same VPC drives unnecessary egress; multi-region replication doubles egress for write paths.

• Database sizing, replicas, and availability:

  • Cloud SQL: Size vCPU/RAM to 95th-percentile load; enable storage auto-resize; use read replicas for scale-out reads; HA doubles compute cost but reduces failover RTO. Connection pooling avoids excessive connection overhead.
  • Spanner: Capacity is provisioned as nodes or processing units; multi-region configs improve availability and read latency but increase cost and write latency; plan splits and hotspots carefully.
  • Bigtable: Node count determines throughput; autoscaler helps track traffic; multi-cluster replication adds availability and cost; schema for even key distribution.
  • Trade-offs: Replicas improve read throughput and availability but increase write amplification and egress; strong consistency and multi-region writes add latency.

• Quotas, rate limits, and backpressure:

  • Understand per-API quotas and per-service concurrency. Implement exponential backoff with jitter for 429/5xx. Apply queue-based load leveling with Pub/Sub and Dataflow or Cloud Run jobs.
  • Concurrency settings: In Cloud Run, higher concurrency reduces cost but risks tail latency; tune CPU allocation on-request for steady throughput.
  • Backpressure: Use flow control in Pub/Sub subscribers, circuit breakers, and admission control to prevent cascading failures.
  • Failure modes: Ignoring quotas leads to sudden throttling; autoscaling can amplify load on downstreams without backpressure, causing retries and compounding cost.

Performance Measurement and Optimization Governance

• Measurement and load testing:

  • Establish SLIs/SLOs for latency, error rate, and saturation. Use Cloud Monitoring dashboards, uptime checks, and alerting. Instrument tracing (Cloud Trace) and profiling (Cloud Profiler) to locate hot paths and lock contention.
  • Load test with realistic traffic models, data cardinality, and think times. Validate autoscaler parameters, warm-up, and readiness gates. Include failover and chaos scenarios to observe capacity headroom and recovery time.
  • Bottleneck diagnosis: Use the USE method (Utilization, Saturation, Errors) across CPU, memory, disk, network, and downstream dependencies; correlate with logs and traces.

• Governance balancing cost, security, and reliability:

  • FinOps guardrails: Mandatory labels/tags; budgets with forecast alerts; centralized billing exports and cost review cadences. Embed Recommender findings (idle IPs/disks, rightsizing) into backlog with owner SLAs.
  • Security: Prefer private connectivity (no external IPs), VPC Service Controls for data exfiltration risks—recognize that private paths may alter egress patterns and costs. Encrypt at rest and in transit; factor KMS usage in cost models.
  • Reliability: Reserve baseline capacity via CUDs or BigQuery reservations; keep burst headroom for SLOs; perform regular game days. Document when Spot or aggressive autoscaling is unacceptable for critical paths.
  • Change management: Treat cost-affecting parameters (autoscaler caps, BigQuery reservations, LB topology) as code with review and rollback plans.

Practical Problem Scenario

Contoso Media operates a multi-region video analytics platform experiencing rising costs and occasional latency SLO breaches during traffic spikes. Leadership wants a 20% cost reduction without compromising a p95 latency SLO of 300 ms for the API and a 2-hour SLA for nightly batch completion.

1. Establish cost and performance baselines

• Action: Enable Cloud Billing export to BigQuery and create dashboards correlating SKU costs with Cloud Monitoring SLIs (latency, CPU, bytes egressed). Run bq dry runs on top 20 queries to estimate bytes scanned.
• Rationale: Baselines identify high-impact services and map spend to performance drivers, allowing targeted optimization.

2. Enforce allocation tagging and budgets

• Action: Require labels/tags (env, service, owner, cost-center) via deployment templates; set per-environment budgets with forecast alerts to a FinOps Pub/Sub topic.
• Rationale: Complete allocation data and proactive alerts enable fast ownership and corrective action before overruns.

3. Rightsize and commit baseline compute

• Action: Apply Recommender VM rightsizing to steady services; convert steady-state capacity to 1-year regional CUDs; keep 20–30% buffer on autoscaler max for spikes.
• Rationale: Rightsizing and commitments lower unit cost on predictable loads while preserving headroom for SLOs.

4. Optimize autoscaling and readiness

• Action: For MIGs, switch autoscaling signals to request-based or custom QPS/latency metrics, set cool-down to 120–180 seconds, and align health check initial delay with app warm-up. Enable scale-in controls to prevent rapid downscaling.
• Rationale: Workload-aware signals and stabilization avoid thrash and overprovisioning that inflate cost and hurt latency.

5. Reduce network egress and load balancer overhead

• Action: Remove external IP communication between services; ensure all east-west traffic uses internal load balancing; co-locate chatty services within regions; cache static assets at edge.
• Rationale: Internal paths eliminate unnecessary egress and reduce L7 processing, improving latency and cost.

6. Storage lifecycle and archival

• Action: Apply Cloud Storage lifecycle rules to move cold artifacts to Coldline at 90 days and delete at 365 days; set requester-pays on shared buckets; review minimum storage duration implications for rare-access data.
• Rationale: Tiering and retention reduce storage and retrieval costs while keeping compliance intact.

7. BigQuery query and capacity tuning

• Action: Partition large fact tables by date, cluster by high-selectivity columns; replace SELECT * with column projections; introduce materialized views for top aggregations; purchase a small reservation for peak ETL windows and use flex slots during batch spikes.
• Rationale: Partition/clustering reduce bytes scanned; capacity reservations stabilize performance and cost for critical workloads.

8. Database scale and replicas

• Action: For Cloud SQL read-heavy services, add read replicas; tune connection pooling; set storage auto-resize; test failover to validate RTO/RPO. For Bigtable, enable autoscaler and address hotspot keys.
• Rationale: Replicas offload reads and protect write paths; autoscaling keeps throughput aligned with demand without manual overprovisioning.

9. Quotas, concurrency, and backpressure

• Action: Implement exponential backoff with jitter; configure Pub/Sub subscriber flow control; set Cloud Run concurrency to balance throughput and latency; add circuit breakers at downstream boundaries.
• Rationale: Proper backpressure prevents cascading failures and runaway retries that degrade SLOs and inflate cost.

10. Continuous validation and governance

• Action: Run monthly load tests and chaos drills; track SLO/error budgets; integrate Recommender and cost anomalies into sprint planning with owners and due dates.
• Rationale: Iterative validation ensures savings persist and SLOs remain green as workloads evolve.

← Reliability · All domains

Practice these questions → · Timed practice on ExamRoll.io →

Browse Google →