Cloud Monitoring & Cost Management

GCP Fundamentals

Chapter 9 · Cloud Monitoring & Cost Management

AWS Fundamentals Chapter 9 covered CloudWatch's real memory-and-disk-space collection gap and Budgets' alert-only behavior. Azure Fundamentals Chapter 9 covered Azure Monitor's own richer four-layer model and Budgets' identically alert-only behavior, paired with Action Groups for real automated response. GCP's own story confirms the same recurring pattern a third time — and then genuinely goes one step further on the automation side.

Cloud Monitoring: Automatic Metrics vs. the Ops Agent

Cloud Monitoring automatically collects real system metrics for Compute Engine VMs — CPU utilization and disk usage, with no setup required. But detailed system metrics, application metrics, third-party application metrics (Apache, Nginx, MongoDB, PostgreSQL, and others), and any custom instrumentation all require installing the real Ops Agent on the VM first.

The Same Real Gap, a Third Time

This completes the exact same recurring finding across all three providers in this arc: memory and deeper metrics are never collected automatically by default — AWS CloudWatch needed the CloudWatch Agent, Azure Monitor needed the Azure Monitor Agent, and now GCP Cloud Monitoring needs the Ops Agent. Three genuinely independent platforms, the same real architectural choice each time.

Alerting Policies

An alerting policy triggers when a chosen metric crosses a defined threshold (e.g. CPU above 80%), routing notifications to email, Slack, PagerDuty, or other channels, and creates a real, persistent incident record for tracking and troubleshooting — a distinctly named concept GCP uses explicitly, where AWS and Azure both lean more on the underlying alarm/alert object itself. Alerting policies can be configured via the console, API, CLI, or Terraform, and many Google Cloud services come with pre-configured alerting recommendations already available.

Cloud Billing Budgets: Alerts, Not a Spending Cap

A standard Cloud Billing budget is alerts-only by default. Google's own real documentation states plainly that an alerts-only budget "doesn't automatically cap Google Cloud... usage or spending" — it exists purely to inform, triggering email notifications at real, configurable thresholds (the real default set is 50%, 90%, and 100% of the budget) as actual or forecasted spend crosses them.

The Same Real Finding, a Third Time

This is now a fully confirmed three-way pattern: AWS Budgets alerts but never stops spending; Azure Budgets' own documentation states resources "aren't affected" and consumption "isn't stopped"; GCP's own alerts-only budget explicitly does not cap usage either. No major provider's own default budget mechanism actually enforces a spending ceiling.

Budgets can also publish real Pub/Sub notifications at each threshold — a downstream Cloud Function (Chapter 7) can subscribe to that topic to automate a real response, such as programmatically disabling billing on a project, echoing Azure's own Action Group-attached-to-a-budget pattern, but built from GCP's own Pub/Sub-plus-function pieces rather than one native attachment point.

A Genuine Step Further: Spend Cap Budgets

More Built-In Than Either Sibling Natively Offers

GCP also offers a real, separate spend cap budget type (currently in preview) for supported services — one that can actually pause a service once its threshold is reached, rather than only notifying. Lifting the cap afterward still requires manual intervention, but this genuinely goes further out of the box than AWS's typical SNS-plus-Lambda assembly or Azure's Action Group attachment, both of which still require the team to build the automated response themselves.

Three Monitoring & Budget Models, Compared

Property	AWS	Azure	GCP
Memory metrics by default	No — needs CloudWatch Agent	No — needs Azure Monitor Agent	No — needs Ops Agent
Default budget behavior	Alerts only	Alerts only	Alerts only
Built-in automated stop option	None native — build via SNS + Lambda	None native — attach an Action Group	Spend cap budgets (preview) can pause a service directly

Hands-On Exercises

Exercise 1

A team notices their Cloud Monitoring dashboard shows no memory-usage data for their Compute Engine VMs, despite CPU and disk usage showing up correctly. Explain, in your own words, why this is happening, and what real step fixes it.

📄 View solution

Exercise 2

A team sets a standard, alerts-only Cloud Billing budget of $1,000/month, and is surprised when their actual spend reaches $1,500 with no service interruption. Explain, in your own words, why this happened, and what real alternative budget type would have actually stopped spending.

📄 View solution

Exercise 3

A team wants their Cloud Billing budget to automatically disable billing on a project once spend hits 100%, without using GCP's own preview spend-cap feature. Explain, in your own words, what real combination of services they would need to build this themselves.

📄 View solution

Chapter 9 Quick Reference

Cloud Monitoring — automatic CPU/disk metrics; memory, detailed, and third-party metrics need the Ops Agent (completing a real three-way "memory needs an agent" pattern with AWS and Azure)
Alerting policies create a named incident record and route to email/Slack/PagerDuty
Cloud Billing budgets are alerts-only by default (50/90/100% thresholds) — confirmed the same real behavior as AWS Budgets and Azure Budgets, none of which stop spending by default
Pub/Sub-triggered budget notifications can drive a real Cloud Function to programmatically respond
Real, distinguishing extra: a preview spend cap budget type that can actually pause a service — more built-in than AWS's or Azure's own native options