Cost Optimization and FinOps

Introduction — Why Cost Economics Matters for the PCA

The Professional Cloud Architect (PCA) exam routinely surfaces scenarios in which the cheapest correct architecture is the right answer. The blueprint expects you to balance technical fit against the Total Cost of Ownership (TCO) of a Google Cloud workload — across compute, storage, networking, data, and the human cost of operating it. This study note walks through the cost mental models, pricing instruments, billing telemetry, and FinOps operating practices the exam tests.

The exam rarely asks "what is the cheapest VM" in isolation. Instead it weaves cost into design questions: pick the storage class, pick the discount instrument, pick the billing export schema, pick the right alerting threshold. You are graded on whether you can defend a design decision in dollars, not just in features.

Capex vs Opex — The Cloud Mindset Shift

On-premises infrastructure is Capital Expenditure (Capex): you raise a large lump-sum budget, purchase servers, depreciate them across 3–5 years, and shoulder the residual risk of over- or under-provisioning. Google Cloud reverses the model into Operational Expenditure (Opex): each second of vCPU, each GiB of egress, and each query slot is metered and billed in arrears.

Why the shift changes architecture

Capex thinking encourages peak-load sizing because once the hardware is bought, idle capacity is "free". Opex thinking encourages autoscaling and stateless services because every idle minute is a line item. A PCA candidate must spot the legacy assumptions in a scenario — "we sized for Black Friday" — and replace them with managed-instance-group autoscaling, Cloud Run scale-to-zero, or BigQuery on-demand slots.

Financial reporting implications

Capex spend hits the balance sheet and depreciates over years; Opex spend hits the P&L immediately. A CFO migrating to cloud may demand to recreate the capex feel using 3-year Committed Use Discounts (CUDs), which give a fixed monthly commitment resembling a depreciation schedule. PCA scenarios mentioning "predictable monthly cost" or "finance team prefers fixed budgets" are signalling CUDs.

Hybrid TCO comparison

Use the Google Cloud Pricing Calculator and Migration Center TCO Assessment to compare a fully-loaded on-prem run-rate (power, cooling, real estate, refresh cycles, staff) against a 3-year cloud projection. The PCA exam expects you to remember that on-prem TCO is rarely just the hardware sticker price.

Plain-Language Explanation: (Plain English Explanation)

Cost economics on GCP becomes intuitive when you map it onto everyday financial decisions.

Analogy 1 — Buying vs Renting a House (Capex vs Opex)

Capex is buying a house: a huge down-payment, a 30-year mortgage, you own the asset, but you eat the costs of an empty bedroom for ever. Opex is renting an Airbnb by the night: you only pay when you sleep there, you can change cities tomorrow, and the landlord (Google) handles plumbing. Committed Use Discounts sit in between — like signing a 1-year or 3-year lease at a discount in exchange for a stay-or-pay guarantee.

Analogy 2 — Electricity Utility Billing (Metered Opex)

Google Cloud bills like a power utility: you don't buy a generator, you let the kWh meter run. Sustained Use Discounts (SUDs) are the loyalty kick-back the utility gives you for keeping the lights on past 25% of the month — the longer you stay connected, the cheaper the marginal kWh, up to 30% off the standard rate on Compute Engine. Spot VMs are like buying electricity off the wholesale spot market — up to 91% cheaper, but the utility can cut your supply with 30 seconds' warning when demand spikes.

Analogy 3 — The Credit Card Statement (Billing Export)

Your Cloud Billing export to BigQuery is the itemised credit card statement. Every line shows who swiped (project), at which shop (service / SKU), for which family member (labels), and how much loyalty cashback applied (credits column). Budgets and alerts are the SMS notification you set when a teen burns through the family card; the Recommender API is the bank's AI suggesting you cancel the gym membership you haven't used in 90 days.

Google Cloud Pricing Models

PCA candidates must memorise the discount instruments and when each one applies.

On-demand (list price)

Pay full sticker for every second/byte/operation. No commitment, maximum flexibility. Use for prototyping, unpredictable spikes, and short-lived environments.

Sustained Use Discounts (SUDs)

Automatic monthly discount on Compute Engine and GKE on-demand vCPUs and memory that run past 25% of a billing month. Discounts grow linearly to a maximum of ~30% off list price for instances running the full month. N1 and custom machine types earn SUDs; N2/N2D/E2/T2D earn smaller automatic infrastructure discounts. SUDs require zero action — Google applies them at invoice time.

Committed Use Discounts (CUDs)

You promise spend for 1 year or 3 years, Google gives a discount.

Spot VMs (and Spot Pods on GKE)

Up to 91% off on-demand pricing for preemptible compute. Google can reclaim them with a 30-second shutdown signal. Spot replaces the older Preemptible VMs (24-hour cap) — Spot has no maximum runtime, but no SLA either. Ideal for batch, CI workers, Dataflow flex workers, and stateless web tiers with multi-region failover.

Flat-rate / reservations (data platforms)

• BigQuery Editions (Standard, Enterprise, Enterprise Plus) sell slots by autoscaling baseline + max, billed per slot-hour. Pair with 1-year or 3-year slot commitments for further discount.
• Cloud Storage Autoclass automatically downgrades objects to cheaper classes (Nearline, Coldline, Archive) without manual lifecycle rules — useful when you cannot predict access patterns.

Billing Accounts and Resource Hierarchy

The exam expects fluency in how money flows through the GCP Organization → Folder → Project tree.

Billing account types

• Self-serve (online) billing account — paid by credit card, monthly invoice.
• Invoiced billing account — net-30 terms, used by enterprises; required for >$10K monthly spend or for marketplace contractual commitments.
• Sub-accounts — used by resellers / partners to pass through charges to downstream customers.

Project-to-billing mapping

Every project must be linked to exactly one Cloud Billing Account at any moment. The link can be changed without re-creating resources, but stops resource creation if the project becomes unlinked. Use the gcloud billing projects link PROJECT_ID --billing-account=BILLING_ID command.

Chargeback and showback patterns

Most enterprises bill internal teams using one of three patterns:

1. Project-per-team — each team gets its own project, billing is mechanically attributable.
2. Label-based — shared projects with team, cost_center, environment labels; billing exports group by label.
3. Folder-based — folders represent business units; CUDs sit at the billing-account level and share across the organisation.

Billing Exports to BigQuery

Cloud Billing offers three BigQuery export streams; the exam expects you to pick the right one.

Standard usage export

Daily, summarised cost data: per-project, per-service, per-SKU, per-label totals. Schema includes cost, currency, usage.amount, credits[], labels[], project.id, sku.description. Adequate for monthly cost reporting and dashboards.

Detailed usage export

Adds resource-level rows: each resource.name (e.g. each VM, each Cloud SQL instance, each Cloud Storage bucket) gets its own row. Required when you need to chargeback by individual resource, debug why one Cloud SQL instance is more expensive than another, or build per-resource right-sizing dashboards.

Pricing export

Daily snapshot of the price list itself — every SKU's per-unit cost, geo, tier breakpoints, and commitment discount. Use it to forecast "what would the same workload cost in europe-west1 vs us-central1?" without running it.

Schema highlights you should recognise

• cost (FLOAT) — net pre-credits charge in currency.
• credits (REPEATED RECORD) — SUDs, CUDs, free-tier, and promotional rebates; sum is negative.
• usage.amount / usage.unit — the consumed quantity (e.g. byte-seconds).
• labels (REPEATED RECORD) — user-defined labels on the resource at usage time.
• export_time — when the row was written (note: full reconciliation can take up to 5 days, with some adjustments arriving as late as 30 days).

Sample chargeback query

SELECT
  project.id AS project,
  service.description AS service,
  (SELECT value FROM UNNEST(labels) WHERE key = 'cost_center') AS cost_center,
  SUM(cost) + SUM(IFNULL((SELECT SUM(amount) FROM UNNEST(credits)),0)) AS net_cost
FROM `billing_dataset.gcp_billing_export_v1_XXXX`
WHERE _PARTITIONTIME BETWEEN '2026-04-01' AND '2026-04-30'
GROUP BY project, service, cost_center;

Budgets, Alerts, and Programmatic Cost Control

Cloud Billing Budgets are the safety net that prevents a runaway autoscaler from generating a five-figure invoice.

Budget anatomy

A budget has:

1. Scope — billing account, one or more projects, one or more labels, or one or more services.
2. Amount — fixed amount, or "last period's actual + X%" for moving targets.
3. Thresholds — typically 50%, 90%, 100%, 120% of budget on actual or forecasted spend.
4. Notifications — email to billing admins, optional Pub/Sub topic for programmatic action.

Programmatic auto-shutdown pattern

When you want a hard kill switch (not just an email), wire the budget to a Pub/Sub topic, then trigger a Cloud Function or Cloud Run service that:

1. Reads the budget event payload (budgetAmount, costAmount, alertThresholdExceeded).
2. Calls the Cloud Billing API to unlink the offending project from its billing account: projects.updateBillingInfo(billingAccountName="").
3. Logs the action to Cloud Logging and pages the on-call via PagerDuty.

This is the canonical runaway lab account pattern. The PCA exam often tests it under the guise of "an intern left a GPU TPU pod running on a Friday."

Budgets caveat

Budgets are alerting, not enforcement. They do not stop resources from running on their own — only the Pub/Sub-driven automation does. Quotas (next section) are the only true preventive cap.

Quota Manager — The Preventive Cost Cap

Quotas are the only mechanism that prevents resource creation rather than just alerting on its cost.

Quota types

• Rate quotas — API requests per minute (e.g. Compute API at 1,500 req/min/project).
• Allocation quotas — total resources in flight (e.g. CPUs per region, T4 GPUs per region, persistent disk total GiB).

Cloud Quotas (Quota Adjuster)

The Cloud Quotas API (formerly the Service Usage quota endpoint) lets you both raise and lower quotas programmatically. PCA-savvy teams lower GPU and IP-address quotas in dev/sandbox projects to a hard ceiling — even if a runaway script tries to spin 500 GPUs, only 4 will succeed.

Quota override pattern

Use gcloud alpha services quota update or the Cloud Quotas console to override:

gcloud quotas update \
  --service=compute.googleapis.com \
  --consumer=projects/lab-sandbox \
  --quota-id=NVIDIA_T4_GPUS-per-region \
  --override=4 \
  --location=us-central1

When paired with budgets, quotas form a defence-in-depth: quota stops the resource creation, budget stops the running spend.

Cost Allocation — Labels and Resource Manager Tags

Labels and tags are how you slice the billing data, but they serve different purposes.

Labels

Key-value strings attached to most resources (VMs, disks, buckets, Cloud SQL, BigQuery datasets). Up to 64 labels per resource, key max 63 chars, value max 63 chars. Labels propagate to the billing export as a labels[] repeated field — this is what chargeback queries pivot on.

Resource Manager Tags

A separate construct, sitting at the organisation/folder/project level. Tags are used by IAM Conditions and Org Policies for access control — for example, "only resources tagged env=prod can attach a public IP." Tags also flow to the billing export as tags[], so they double as a cost dimension.

Allocation strategy

A PCA-grade label taxonomy looks like:

• cost_center — the chargeback bucket (e.g. cc-12345).
• environment — prod / staging / dev.
• team — engineering owner.
• application — logical app or service.
• data_classification — public / internal / restricted.

Enforce labels via Org Policy gcp.resourceLocations + custom constraint or Terraform pre-commit checks. Unlabelled resources are unbillable — they pollute the chargeback into an "unattributed" bucket that finance teams dislike.

Recommender API — Automated Cost Savings

The Recommender API is Google's machine-learning-driven cost optimisation engine, surfaced in the Active Assist tab of the console.

Cost recommenders to memorise

Integration with FinOps automation

Programmatic clients can pull recommendations via gcloud recommender recommendations list and feed them into a Cloud Workflows pipeline that auto-applies low-risk actions (e.g. deleting unattached disks over 30 days old). The PCA exam loves scenarios where the answer is "use Recommender API" rather than "build a custom script."

Carbon Footprint and Sustainability Cost

Sustainability is increasingly a cost concern — regulated industries report Scope 3 emissions, and some regions price carbon differently.

Cloud Carbon Footprint product

Cloud Carbon Footprint exports gross location-based and net market-based emissions per project and service to BigQuery. Schema fields:

• carbon_emissions_kgCO2e — gross emissions for the usage period.
• carbon_model_version — methodology version (the GHG Protocol-aligned model).
• region / service — same dimensions as billing export, enabling joins.

Region selection trade-off

Picking a low-carbon region (e.g. europe-north1 Finland, us-west1 Oregon, northamerica-northeast1 Montréal) can reduce reported emissions by up to 90% versus high-carbon regions. But latency and data-sovereignty constraints often dominate region choice — a PCA scenario may require you to justify a slightly more expensive low-carbon region for an ESG-driven customer.

Sustainability levers

• Schedule batch and training workloads in regions/times with high renewable mix (the Carbon Aware scheduling pattern).
• Prefer Spot VMs — preempting idle capacity is more energy efficient than reserving it.
• Right-size with Recommender — fewer wasted cycles directly cuts both cost and carbon.

FinOps Foundation Framework on GCP

The FinOps Foundation defines three iterative phases. Each maps onto specific GCP services.

Phase 1 — Inform (visibility)

Goal: everyone can see what they spend. GCP tooling:

• Cloud Billing Reports in the console (cost trends, top services, top SKUs).
• Billing export to BigQuery + Looker Studio dashboards.
• Labels and tags policy rolled out organisation-wide.
• Carbon Footprint export for sustainability KPIs.

Phase 2 — Optimize (eliminate waste, buy discounts)

Goal: cut waste, lock in commitments. GCP tooling:

• Recommender API for idle/right-size opportunities.
• CUD analysis report to size 1yr vs 3yr commitments.
• Storage Autoclass + Lifecycle Policies to demote cold data.
• BigQuery slot reservation tuning vs on-demand pricing.

Phase 3 — Operate (govern continuously)

Goal: cost discipline becomes a habit. GCP tooling:

• Budgets + Pub/Sub auto-shutdown for runaway protection.
• Cloud Quotas as preventive caps in non-prod.
• Org Policy enforcing labels and forbidding expensive SKUs in dev (e.g. block A100 GPUs in sandbox folder).
• Cloud Billing API integrations into FinOps SaaS tools (Apptio Cloudability, Vantage, CloudHealth).

The PCA exam may name the phase explicitly ("the team is in the Inform phase, what do they need next?") and expect you to suggest dashboards, labelling, or BigQuery exports as appropriate.

Cloud Billing API and FinOps Automation

The Cloud Billing API is the programmatic spine of FinOps automation.

Key endpoints

• billingAccounts.list / get — discover the billing accounts you can access.
• billingAccounts.projects.list — enumerate projects under a billing account.
• projects.updateBillingInfo — link/unlink projects (the auto-shutdown lever).
• services.list and services.skus.list — enumerate the price list itself (also exposed as the pricing export).
• billingAccounts.budgets (Cloud Billing Budgets API) — create/update budgets programmatically.

IAM bindings to remember

• roles/billing.admin — full control of a billing account.
• roles/billing.user — link projects to a billing account.
• roles/billing.viewer — read invoices and reports.
• roles/billing.costsManager — manage budgets, view costs, but not change billing-account-level settings.

The principle of least privilege here is critical: most engineers should get costsManager, not admin. Granting billing.admin accidentally lets someone unlink production projects.

Putting It All Together — Reference Cost Architecture

A production-grade GCP cost architecture combines every layer above:

1. Organisation hierarchy with folders per business unit, each linked to one billing account.
2. Label taxonomy enforced by Org Policy and Terraform CI.
3. Resource-based 3yr CUDs for the steady-state production baseline; on-demand + Spot for spiky and batch workloads.
4. Detailed billing export to a finops-warehouse BigQuery dataset, partitioned by _PARTITIONTIME.
5. Looker Studio dashboards on the export for per-team chargeback, refreshed daily with a 5-day grace window.
6. Budgets per project at 50%/90%/100%/120% of forecast, with the 100% threshold wired to a Pub/Sub-triggered Cloud Function that unlinks runaway sandboxes.
7. Cloud Quotas preventive caps on GPU, public IP, and Cloud SQL CPU in dev/sandbox folders.
8. Recommender API scanned weekly via a Cloud Workflows pipeline that auto-applies idle-disk deletions and emails right-sizing candidates.
9. Carbon Footprint export joined to billing export for sustainability KPIs.
10. Monthly close at day +5 and final reconciliation at day +30 to absorb late credits.

This is the canonical PCA-grade architecture; you should be able to draw it on a whiteboard and defend each box.

FAQ — Capex/Opex and Cost Optimization on GCP

Q1. When should I pick a 1-year CUD vs a 3-year CUD?

Use a 1-year CUD when the workload is steady but the underlying technology may evolve (e.g. you expect to migrate from N1 to N2 within a year). Use a 3-year CUD for foundational production workloads that you are committed to running on the same family for the long haul — the additional ~20 percentage-point discount over 1-year usually pays for itself within 18 months.

Q2. Are Sustained Use Discounts compatible with Committed Use Discounts?

CUDs are applied first to your usage; remaining on-demand usage then earns SUDs. You never "double dip" — but you also never lose money by having both. SUDs only apply to the residual on-demand portion above your committed amount.

Q3. What's the difference between Preemptible VMs and Spot VMs?

Preemptible VMs (legacy) have a hard 24-hour runtime cap and a fixed discount. Spot VMs (the replacement, generally available since 2021) have no runtime cap but variable pricing — discounts up to 91% that fluctuate with demand. Both can be preempted with a 30-second SIGTERM. New designs should use Spot; Preemptible is retained only for backward compatibility.

Q4. Can a budget actually stop a workload from running?

Not by itself. Budgets only notify (email + Pub/Sub). To enforce a hard stop you must wire the Pub/Sub topic to a Cloud Function that calls projects.updateBillingInfo(billingAccountName="") — unlinking the project from billing prevents new resource creation and stops most resources after a short grace period. Quotas are the only mechanism that prevents resource creation upfront.

Q5. How do I attribute costs to a team that shares a project with three other teams?

Use labels (team=engineering-platform, cost_center=cc-12345) on every resource the team owns, then query the billing export with a GROUP BY (SELECT value FROM UNNEST(labels) WHERE key='team'). If labels are unreliable, split into one project per team — project boundaries are the only billing dimension with zero ambiguity.

Q6. Is the Recommender API free?

Yes — both the recommender insights and the API calls to retrieve them are free. You only pay for the actions you take (e.g. snapshotting a disk before deletion). PCA scenarios that mention "no additional cost to detect savings opportunities" are pointing at Recommender.

Q7. How fresh is the BigQuery billing export?

Standard export latency is a few hours for in-flight rows, but full reconciliation can take up to 5 days for most credits and up to 30 days for some long-tail adjustments. Always quote prior-period costs with at least a 5-day grace window, and run monthly close at day +30 for audit-grade numbers.

Final Architect Tip

Cost optimisation on GCP is not a one-time project — it is a continuous practice with three feedback loops: daily (budgets and alerts), weekly (Recommender review), and quarterly (CUD/slot commitment renegotiation). The PCA exam rewards candidates who weave these loops into the design from day one, rather than bolting them on after a surprise invoice. When in doubt, choose the architecture that is both technically correct and generates the smallest line item in the billing export — that's almost always the intended answer.