Controlling Cloud Costs: CapEx vs OpEx, FinOps, Resource Hierarchy, Quotas and Budgets (Cloud Digital Leader)

Moving from on-premises infrastructure to the cloud turns most IT spending from capital expenditure (CapEx) into operational expenditure (OpEx). CapEx is money spent up front on long-lived assets: buying servers and storage arrays, building a server room, then depreciating those assets over their useful life. OpEx is ongoing spending on services as they are used, such as a monthly bill for the virtual machines and storage actually consumed.

On premises, a company has to guess its demand years ahead and buy for the peak, so capacity bought for future growth sits idle until that growth arrives. In the cloud it pays for what it uses, scales up when demand rises and scales down (and stops paying) when demand falls.

The shift has a consequence that is easy to miss: the bill becomes variable. Anyone with permission can create resources in minutes, so spend can grow quickly between reviews. Purchase approvals and depreciation schedules belong to the old model; in the cloud, finance needs continuous visibility, forecasting and governance instead. The rest of this lesson is about how Google Cloud supports that.

Total cost of ownership (TCO) is the full cost of running a workload over its life, not just the price of the hardware or the cloud resources. A fair comparison between on-premises and cloud has to count every cost on both sides.

On-premises TCO includes much more than the server quote:

• The building or colocation space, electricity and cooling
• Network equipment, physical security and insurance
• Staff time to install, maintain, patch and repair hardware
• Hardware refresh every few years, plus software licences and support contracts
• The cost of idle capacity bought for a peak that rarely arrives

Cloud TCO is the cost of the services used (compute, storage, data transfer out to the internet, managed services), plus the people who run and govern them. Because cloud cost follows consumption, an estimate that prices every VM at peak size, running around the clock, overstates the real cost: elastic, right-sized resources would not pay for that idle capacity. Discounts change the unit price; they do not change how much capacity the estimate assumes, so sizing comes first.

The principle is to compare like with like: the full lifetime cost of owning and running the hardware against the cost of the cloud capacity the workload really needs. A comparison that leaves out indirect costs on one side, or assumes the cloud cannot scale, tells the business little. TCO also has a value side that is harder to price: staff time freed from maintaining hardware can go to work that grows the business.

Google recommends that cloud costs are managed by a cross-functional team that brings together finance, technology and business staff. This practice is called FinOps (cloud financial management). In the cloud, spending decisions are spread across every engineer who creates a resource, so no single department can control costs alone: finance sees the invoice but not the usage, and engineers control usage but often do not see the bill.

The core FinOps ideas Google describes are:

• Visibility: every team can see what its own projects and services cost, close to real time.
• Accountability: the teams that create resources own their spend, rather than one central team paying for everyone.
• Central guardrails, local decisions: a central function sets policies, budgets and quotas, while teams keep the freedom to move fast inside them.
• Value, not just savings: the goal is to get the most business value per dollar, which sometimes means spending more on what earns more.

Each group sees only part of the picture on its own; cost control works when they share the same data and agree targets together.

Google Cloud's own cost management tools support this model: Cloud Billing reports and cost tables for visibility, budgets and alerts for guardrails, labels and billing export for allocation, Recommender for optimisation, and the FinOps hub in the Billing console, which brings savings opportunities and commitment use together in one view.

Controlling cloud costs takes people, process and technology working together; tools alone do not reduce a bill.

• People are the roles and owners: a FinOps lead, named budget owners in each team, executives who sponsor the effort.
• Process is the agreed way of working: a monthly review where teams compare spend with forecast, a rule that every resource gets a cost-centre label, an agreed response when a budget alert fires.
• Technology is the tooling: budgets and alerts, billing reports, billing export to BigQuery, quotas, Recommender.

The three parts depend on each other. Technology produces information, but information changes nothing unless a person is responsible for acting on it and a process says when and how they act. Equally, a well-run review meeting is of little use if the tooling cannot show which team's resources caused a change. When cost control is not working, ask which of the three is weak before adding more of the one that is already strong.

Google Cloud gives several tools for seeing and allocating cost, each answering a different question.

Some distinctions matter. Billing reports are for viewing; when cost data has to be combined with the company's own tables (for example the cloud cost of every order), billing export to BigQuery is the tool, and a manual CSV download is not automatic. Billing accounts, folders and projects cannot divide a project's costs; labels can, and reports, exports and even budgets can filter on a label once it is applied to the resources. And budgets, quotas and Spot VMs control spend in broad strokes; only Recommender points to the individual resources to change.

Cloud Monitoring dashboards and Cloud Audit Logs are not cost tools: they report performance and activity. They belong to operations and security (task 6.2 and section 5).

The resource hierarchy is the tree Google Cloud uses to organise everything a company owns, from the top down: organization node → folders → projects → resources.

Every folder, project and resource has exactly one parent (the organization node is the root), and projects (not folders) are where billing attaches. A billing account can pay for many projects, which is why billing reports can break spend down by project.

The hierarchy brings four benefits the exam guide names:

• Access control: grant a role once at the right level instead of project by project.
• Inheritance and propagation: IAM and organization policies set higher up flow down to everything below, including projects created later.
• Security and compliance: guardrails at the organization or folder level apply consistently, so a new project cannot escape them.
• Visibility and auditing: costs, assets and audit logs can be viewed per project, folder or the whole organization.

Policies set on a node in the hierarchy are inherited by everything beneath it, and inheritance only flows downward.

IAM allow policies say who can do what. A role granted on a folder applies to the folder and to every existing and future project and resource inside it, but not to other folders. A resource's effective access is the union of what is granted on it and on all its ancestors: inherited grants add up, and a grant at a lower level cannot cancel one made higher up. So if someone holds a role on both a folder and a project inside it, removing only the project grant leaves the inherited folder grant in place; the fix is to remove the grant where it was made. (Google Cloud also has separate IAM deny policies for blocking permissions explicitly; removing or narrowing the original grant is the simpler fix.)

Organization policies say what can be done with resources, whoever is acting. Examples: restrict the regions where resources can be created (resource locations), forbid external IP addresses on VMs, or block public access to storage. Set at the organization node, a policy covers every folder and project below it, including future ones, without per-project setup.

The general rule: a guardrail that must hold for the whole company is set once, as high in the hierarchy as it applies, so inheritance carries it to everything below, including resources that do not exist yet.

Quotas cap how much of a resource can be used; budgets warn about how much is being spent. The two are often confused, and they do different jobs.

Quotas (managed in Cloud Quotas) limit how much of a resource a project may use, such as the number of GPUs or CPUs in a region, or how many API requests it may make per minute. Google sets default quotas, and an administrator can request an increase or set a lower limit. Lowering a sandbox project's GPU quota stops more GPUs from being created beyond that number, which makes quotas a real ceiling on runaway consumption.

Cloud Billing budgets track spend against a target amount for a billing account, project or service, with threshold rules (for example 50%, 90% and 100%). When a threshold is crossed, budget alerts email the Billing Account Administrators and Billing Account Users by default (and Project Owners for a budget scoped to one project); other recipients can be added through Cloud Monitoring notification channels. Each threshold is based on either:

• Actual spend: fires once the money has been spent.
• Forecasted spend: fires when Google's projection for the end of the period will cross the threshold, giving an early warning.

A standard, alerts-only budget (threshold rules) does not stop spending: resources keep running and spend can pass the budget. Teams that want an automatic response connect budget notifications to Pub/Sub and trigger their own automation. Cloud Billing also offers spend cap budgets, set on a project for a few supported services such as Cloud Run and the Gemini API: when the cap is enforced, new usage of that service pauses until someone lifts it by hand. They do not cover services such as Compute Engine, so for VMs the alerts-only behaviour applies.

The two controls answer different questions: a quota answers "how much may run?", a budget answers "how much are we spending, and where is it heading?". A requirement that combines a hard ceiling with early warning needs both.

Spot VMs and Dynamic Workload Scheduler lower compute costs by trading flexibility for price or for capacity on demand.

Spot VMs are Compute Engine VMs that run on spare capacity at a deep discount. The trade-off is preemption: Compute Engine can reclaim them at any time when it needs the capacity back. They need no term commitment and no up-front payment, and unlike the older preemptible VMs they have no 24-hour maximum runtime. They suit fault-tolerant, interruptible work such as batch jobs, test runs and rendering, never a workload that must not stop.

Dynamic Workload Scheduler helps teams get scarce accelerators (GPUs and TPUs) for AI and batch work. Its Flex-start mode is for jobs that can wait: the request queues until the full set of accelerators is available, provisions them together, and bills only for the time they run, so the team does not pay to hold idle capacity while it waits. Calendar mode instead reserves accelerators for a fixed future period.

Matching the option to the job is the skill: ask whether the work can be interrupted, whether its start time is flexible, and whether its usage is steady enough to commit to.