Google Cloud / Advanced: Governance, Reliability, and Architecture / Lesson 15
Cost Engineering and Governance
Connect consumption, allocation, limits, commitments, and service objectives without turning an estimate into a guaranteed bill.
On this page
Lesson goals
- Track useful-work unit cost and unallocated spend.
- Review scaling, retention, and network cost assumptions.
- Define budget and enforcement scope with accountable owners.
Optimize useful outcomes, not just resource counts
Cost engineering relates resource consumption to useful outcomes under reliability and performance requirements. Reducing instances can lower one dimension while increasing retries, latency, failures, or operational work. Define a unit such as successful report or processed event, and preserve its eligibility and quality rule before comparing unit costs.
The first program divides invented accounting units by good completed work. It is not a Google price or a financial forecast. Include failed/retried work in consumed resources while keeping the denominator honest. A metric that counts every retry as a useful result can make an inefficient system appear cheaper.
from decimal import Decimal
synthetic_cost_units = Decimal("60")
good_completed_events = 3000
assert good_completed_events > 0
print(f"units_per_good_event={synthetic_cost_units / good_completed_events:.4f}")
units_per_good_event=0.0200
The model gives0.0200 accounting units per good event and quotes no service rate.
Allocation metadata needs reconciliation
Use an agreed mapping from projects, labels/tags, services, and shared platforms to owners and products. Labels and tags have distinct service and policy behavior; do not assume identical coverage in every billing export. Keep unattributed and shared amounts visible, and reconcile allocations to the source totals for a defined billing period and credit/tax treatment.
Billing exports and dashboards have schema, timing, and access contracts. A query over incomplete recent data can understate current consumption. Forecasting needs explicit assumptions about demand, usage mix, discounts, and change events. Do not substitute one week’s average for a complete monthly commitment or declare a pricing model permanent.
Resource controls protect particular dimensions
Review autoscaling, concurrency, connection pools, storage growth, logs, data transfer, and retry amplification together. Quotas and service limits are technical dimensions, not one universal spend ceiling. A limit can protect a database while causing rejected work upstream, so choose overload and degradation policy deliberately rather than promising unlimited demand absorption.
Rightsizing should preserve peak and failure headroom, not merely average CPU. Commitments can make sense for justified predictable usage but create utilization and contractual exposure. Compare current documented terms in an authorized real estimate; the course offers no discount, savings, or free-tier promise.
Enforcement must name what remains outside it
Current Google documentation distinguishes alerts-only budgets and eligible-service spend-cap budgets. A design must state the selected type, project/account scope, services, exclusions, reporting/enforcement behavior, and owner. Do not claim all budgets shut everything down or, conversely, that no supported budget can enforce anything. Review current eligibility and operational consequences.
The second offline program separates invented covered and uncovered items. It is a coverage review, not an implementation of Google’s cap feature or eligibility list. A control that pauses one service can also interrupt a dependent application while other charges continue. Define a safe authorized response and how service is restored.
items = {"covered-model-service": 40, "other-model-service": 15}
covered = {"covered-model-service"}
inside = sum(amount for name, amount in items.items() if name in covered)
outside = sum(amount for name, amount in items.items() if name not in covered)
print(f"inside_model_scope={inside} outside_model_scope={outside}")
inside_model_scope=40 outside_model_scope=15
The model leaves fifteen units outside its declared scope; these names are not actual eligibility claims.
A governance cycle links data to an approved action
Define review cadence, anomaly ownership, expected business drivers, approval authority, and evidence that a change preserved service objectives. A cost spike can be an incident, useful growth, a billing adjustment, or a delayed export; diagnose before stopping resources. Cleanup must respect data retention, backups, legal/organizational requirements, and recovery ownership.
Keep a dated assumption register and compare estimates with actual outcomes in authorized operations. A model is improved by reconciliation, not by hiding differences. All examples here use invented local records and perform no billing query, purchase, commitment, shutdown, cleanup, or cloud change.
Common errors and fixes
Lower average CPU is treated as proof of safe rightsizing.
- Why it happens
- Peak, failure, and latency requirements were omitted.
- How to fix it
- Review workload distributions and recovery headroom.
- Prevent it next time
- Validate service objectives after authorized changes.
A cap covers one dimension but is reported as total-cost protection.
- Why it happens
- Scope and uncovered services were hidden.
- How to fix it
- Name coverage, exclusions, and operational effects.
- Prevent it next time
- Reconcile outside-scope spend explicitly.
A monthly forecast is copied without its date and usage assumptions.
- Why it happens
- A scenario was mistaken for a permanent price.
- How to fix it
- Record current terms and scenario inputs.
- Prevent it next time
- Compare forecast and observed usage under an owned review.
Check your understanding
1. A team cuts telemetry retention to reduce cost. What must the review include beyond the storage estimate?
Show worked solution
Check incident diagnosis, audit obligations, data classification, access, export dependencies, recovery requirements, and what evidence will no longer exist. Define an approved retention policy and verify the application’s operating needs. A lower bill in one dimension can create unacceptable investigation or compliance gaps; the cost decision needs the full operational contract.
2. Why is cost per good completed event often more informative than cost per incoming request?
Show worked solution
Retries, rejected work, and failed requests consume resources without necessarily delivering the intended outcome. Counting all arrivals as useful output can hide inefficiency. Define good completion and its denominator consistently, include all relevant consumed resources, and inspect quality/latency alongside unit cost. The metric still depends on the business question rather than being a universal score.
Key takeaways
- Cost models need explicit consumption, allocation, and service-quality assumptions.
- Limits and budgets have scope and operational consequences.
- No local model is a price quote, purchase, or enforcement test.