Prepare and test your skills
Prepare and test your skills
Commitment-based discount models trade a 1-year or 3-year payment promise for a lower hourly price on Google Cloud infrastructure. Committed use discounts (CUDs) (opens in a new tab) require an upfront purchase and are best for stable baseline usage, while sustained use discounts (SUDs) apply automatically to consistent Compute Engine usage with no purchase. A 3-year commitment term provides a higher discount rate than a 1-year term, and CUD savings can stack on top of negotiated enterprise discounts for additional savings. The strategy is to cover the stable baseline with CUDs and leave variable peaks to on-demand rates plus SUDs.
Resource-based committed use discounts (resource-based CUDs) provide a discount in exchange for committing to use a minimum quantity of Compute Engine resources in a specific region for 1 or 3 years. Each resource-based commitment is linked to the region and the project where it was purchased, and it can cover only resources with the matching machine configuration in that region. Resource-based CUDs are ideal for predictable and steady-state usage where location and machine type do not change.
Eligible resources for resource-based commitments are Compute Engine resources deployed with Compute Engine SKUs:
Hardware commitments earn up to 70% off for memory-optimized machine series and up to 55% off for all other machine series. Software license commitments earn up to 79% off for SUSE Linux Enterprise Server (SLES), up to 63% off for SLES for SAP, and up to 20% off for Red Hat Enterprise Linux (RHEL). Choose a resource-based commitment when baseline vCPU, memory, GPU, or license usage is stable in one region.
Spend-based committed use discounts (spend-based CUDs) provide a discount in exchange for committing to spend a minimum hourly amount on a particular product for 1 or 3 years. The spend-based commitment is purchased at the Cloud Billing account level and applies to eligible usage in any project paid for by that account, either regionally or globally depending on the product. The hourly commitment amount represents discounted spend, and the recurring commitment fee is shown in the commitment summary with the estimated savings at full utilization.
Compute flexible CUDs are the spend-based form for Compute Engine, Google Kubernetes Engine (GKE), and Cloud Run. One compute flexible commitment covers eligible spend across those three services, which makes it ideal when total spend is predictable but regions, projects, or machine types vary. For example, a single hourly spend commitment can cover N2 vCPUs in Compute Engine, GKE Standard edition, and Cloud Run instance-based billing, with the covered on-demand value distributed in proportion to eligible spend across the services. Choose a spend-based commitment when flexibility across regions and services matters more than the maximum region-locked discount.
Sustained use discounts (SUDs) are automatic credits for consistent Compute Engine and GKE usage that require no commitment purchase. The discount is earned when the same resources run continuously beyond duration thresholds within the billing period, so longer continuous use produces a larger credit. SUDs apply only to overage usage that was not already covered by a CUD, and they do not require Billing Account Administrator action or capacity planning. Choose SUDs for variable but long-running usage where committing to a fixed quantity or spend amount would create underutilization risk.
The three discount models differ by what is promised, where the discount applies, and how much flexibility is retained. All three reduce the effective on-demand rate, but only CUDs create a non-cancellable monthly fee that must be paid regardless of actual usage. The same usage portion never receives two discounts at once.
| Model | Commitment basis | Scope and flexibility |
|---|---|---|
| Resource-based CUDs | Minimum quantity of vCPUs, memory, GPUs, local SSDs, sole-tenant nodes, or licenses | Region-specific and machine-specific; highest discount for stable usage, lowest flexibility |
| Spend-based CUDs | Minimum hourly spend on an eligible product, such as compute flexible spend across Compute Engine, GKE, and Cloud Run | Billing-account level; regional or global by product; flexible across projects, regions, and eligible services |
| SUDs | No commitment; earned by continuous usage beyond thresholds | Automatic on eligible Compute Engine overage; no purchase or cancellation risk, but lower and less predictable savings |
Purchasing commitments and managing coverage controls how broadly one purchase covers usage and when the discount starts. Purchasing a spend-based commitment requires the Billing Account Administrator role on the Cloud Billing account, and the commitment cannot be cancelled or moved to a different billing account after purchase. The discount start time depends on purchase time in the local time zone: a purchase at :49 or earlier starts at the beginning of the next hour, while a purchase at :50 or later skips an hour and starts at the beginning of the hour after next.
Discount sharing determines how broadly one purchase covers usage across projects. For most Cloud Billing accounts, resource-based CUD sharing is enabled and shares each regional commitment across all projects under the same billing account. By default, all new Cloud Billing accounts created on or after June 16, 2026 have sharing enabled, so a commitment purchased in one project automatically covers matching regional usage in other projects on that account. Spend-based commitments are inherently billing-account level and cover eligible usage in any linked project.
Exam tip: Resource-based CUDs apply first to matching regional usage, compute flexible CUDs apply second to remaining eligible usage, and any leftover hourly usage is billed at on-demand rates that may earn SUDs.
Each hour, Google Cloud reconciles commitments against actual use in a fixed order:
If hourly usage exceeds the commitment, the overage is charged at on-demand rates. If hourly usage falls below the commitment, the unused portion is still billed as a commitment fee and savings are lost. Use CUD recommendations (opens in a new tab) with a coverage threshold percentage, 1-year or 3-year term selection, and usage insights such as historical days above the recommended spend and break-even days to size commitments below the observed baseline rather than at the peak.
Implementing right-sizing (opens in a new tab) and cost modeling strategies is the practice of matching infrastructure size and pricing model to actual workload demand and forecasting future spend. Right-sizing continuously adjusts virtual machine (VM) types, counts, and configurations to avoid over-provisioning costs and under-provisioning bottlenecks. Cost modeling pairs those sizing decisions with commitment discounts, preemptible capacity, and billing analytics to achieve maximum financial efficiency.
Right-sizing with utilization metrics starts with real-time visibility into how resources are actually used. Cloud Monitoring collects CPU, memory, and custom application metrics from Compute Engine, Google Kubernetes Engine (GKE), and serverless workloads, so usage patterns and inefficiencies become visible over time. Recommender analyzes that utilization data and produces intelligent recommendations for optimizing allocation, such as downsizing an oversized VM or removing an idle one. Custom metrics extend this loop by tracking workload-specific signals and configuring alerts that notify administrators when predefined thresholds are met.
Utilization data flows from monitored resources to Cloud Monitoring and then to Recommender, which returns a sizing recommendation to the operator or automation. Over-provisioned resources waste budget without improving reliability, while under-provisioned resources create bottlenecks that affect application performance and user experience. The tradeoff is resolved by treating right-sizing as continuous governance rather than a one-time choice, with monitoring, recommendation review, and reallocation repeating as demand shifts.
Machine type and idle resource recommendations translate raw utilization into specific cost actions. Active Assist is the portfolio of intelligent tools that includes Recommender insights across Compute Engine, Cloud Run, BigQuery, and Cloud SQL at no cost and without configuration. For Compute Engine, the system surfaces idle VM recommendations to identify unused instances for decommissioning and machine type recommendations to move a workload to a more cost-effective instance type or custom machine type. These recommendations help distinguish wasteful utilization that can be removed from value-driving utilization that should be retained and committed.
A disciplined right-sizing workflow evaluates each finding for both savings and blast radius before acting. First, assess the cost impact of the idle or oversized resource using billing and observability data. Then, evaluate whether decommissioning or downsizing affects availability, dependencies, or zonal distribution. Only after that review, apply the recommendation and monitor performance to confirm that the smaller footprint still meets demand.
Discount and capacity models determine the billing rate applied to a correctly sized footprint. Committed use discounts (CUDs) reduce price in exchange for committing to a minimum quantity of resources or minimum spend over a one-year or three-year period. Sustained use discounts apply automatically in Compute Engine for consistent usage beyond duration thresholds in the billing cycle, without any upfront commitment. Spot VMs provide access to unused Compute Engine capacity at a significantly lower price, but Compute Engine can preemptively stop or delete those VMs to reclaim capacity.
The three models differ by commitment, automation, and tolerance for interruption:
| Option | Pricing mechanism | Choose when |
|---|---|---|
| Committed use discounts (CUDs) | Committed quantity or spend for 1 year or 3 years; resource-based CUDs apply to a specific region, spend-based CUDs apply at the billing account level | Usage is predictable and steady and can be aggregated across projects |
| Sustained use discounts | Automatic credit after continuous usage beyond a threshold | Usage is consistent but not committed in advance |
| Spot VMs | Unused capacity at more than 80% discount versus regular VMs with preemption risk | Workloads are fault-tolerant, flexible, and batch-oriented without high-availability requirements |
Exam tip: Choose Spot VMs only for fault-tolerant workloads that tolerate preemption; choose CUDs for predictable steady usage where a 1-year or 3-year commitment is safe.
Cost modeling for infrastructure spend depends on structured billing data enriched with business context. Cloud Billing provides built-in reports on usage costs, invoices, cost breakdowns, and pricing tables, plus budgets and budget alerts that notify owners when actual spend approaches planned spend. For deeper forecasting, billing data exported to BigQuery supports custom SQL analysis by label, project, or time period to identify trends, anomalies, and optimization focus areas. The Google Cloud Pricing Calculator estimates the cost of provisioning new resources or migrating data to a new region, including regional price differences and network egress costs.
Forecasting accuracy improves when raw cost data is organized for attribution. Labels and tags are key-value pairs attached to resources that enable cost breakdowns by team, environment, or product and support chargeback and audit analysis. Custom dashboards built on BigQuery exports and Cloud Monitoring visualize key performance indicators (KPIs) and spending trends for finance and engineering stakeholders. By analyzing historical consumption alongside business requirements and traffic patterns, teams build demand models that project growth and decide when to renew CUDs or change regions using the Region Picker tradeoff between cost, latency, and sustainability.
Autoscaling sustains right-sizing dynamically by adding and removing capacity as workload fluctuates, so teams pay for needed resources only when needed. Compute Engine managed instance groups (MIGs) scale as a single entity under an autoscaling policy that defines a minimum and maximum VM count and trigger conditions, such as adding VMs when CPU utilization exceeds a threshold and removing them when it drops. Cloud Run provides built-in serverless autoscaling where instance count rises with incoming traffic and falls to reduce cost when traffic decreases. Traffic and utilization signals therefore flow from the load to the autoscaler to the compute pool, and the pool size changes only within policy bounds.
GKE autoscaling divides the same function across four cooperating controls:
Together these tools keep cluster resources aligned with application needs without manual node management. Combined with derived demand patterns, such as heavy demand only during certain hours, teams can proactively scale up in anticipation of peaks and scale down or shut down low-priority workloads off-hours, including running them on Spot VMs instead of on-demand capacity.
Network Service Tiers (opens in a new tab) is the Google Cloud control that selects the path traffic takes between the internet and Google Cloud instances. Premium Tier routes traffic on Google's premium backbone for performance, while Standard Tier routes traffic over peering, ISP, or transit networks for cost savings. Outbound data transfer pricing is different for each tier, so the tier choice directly changes both latency and egress cost for internet-facing architectures.
Premium Tier and Standard Tier differ in routing, protection, feature coverage, price, and availability guarantee. Premium Tier keeps traffic between the internet and the application within the Google Cloud network until the last mile, while Standard Tier hands traffic to peering, ISP, or transit networks closer to the user. That routing difference drives the core FinOps trade-off: Premium Tier optimizes for global performance and consistency, and Standard Tier optimizes for lower egress cost where higher latency and internet routing are acceptable.
| Tier | Routing path | SLA uptime | Feature and security posture |
|---|---|---|---|
| Premium Tier | Traffic travels within the Google Cloud network to reach users | 99.99% | Supports all Google Cloud networking features; traffic is protected on Google's backbone until the last mile |
| Standard Tier | Traffic uses peering, ISP, or transit networks to reach users | 99.9% | Supports a foundational feature set; security is comparable to other public clouds |
Standard Tier supports a foundational feature set that includes Cloud NAT, Regional external Application Load Balancer, and Regional external passthrough Network Load Balancer. Premium Tier pricing is at parity with other public cloud providers, while Standard Tier pricing is cost-effective and at parity with other cloud providers. Choose Premium Tier when global reach, low latency, full feature support, and the higher SLA justify higher egress rates, and choose Standard Tier when regional serving and lower egress rates matter more than backbone performance.
External IP address type and resource type determine whether Standard Tier can be selected at all. Google Cloud has global external IPv4 and IPv6 addresses, which are publicly routable anycast addresses, and regional external IPv4 and IPv6 addresses, which are designated for resources that fit within a single Google Cloud region. Global external IPv4 and IPv6 addresses are supported only in Premium Tier, regional external IPv4 addresses are supported in both tiers when used with eligible resources, and regional external IPv6 addresses are supported only in Premium Tier.
Tier eligibility also constrains load balancers, compute, and connectivity resources:
A regional external IP address can still be contacted from anywhere on the internet. The term regional means the Google Cloud resources must all be in a single region, and the tier choice for a regional external IP address only affects the path that network traffic from the internet takes when contacting the resource.
Tier selection for storage and caching follows special rules that affect network architecture and budget. Access to Cloud Storage buckets is considered Premium Tier by default, whether or not the bucket is used as a backend for an external Application Load Balancer. Standard Tier is an option for Cloud Storage only when a bucket is used as a backend for an external Application Load Balancer. Cloud CDN is always Premium Tier and cannot be moved to Standard Tier for savings.
Traffic between virtual machine (VM) instances that are in the same or different regions is designed to stay on Google's network regardless of tier, including when a load balancer is on the path. This behavior applies whether the traffic uses publicly or privately routable IP addresses, so tier selection controls the internet ingress and egress path rather than the internal VM-to-VM path. For cost planning, concentrate internet-heavy, cacheable, or region-local workloads on Standard Tier eligible regional resources, and reserve Premium Tier for global anycast front ends, Cloud CDN, Cloud VPN, and latency-sensitive applications where backbone routing and the 99.99% SLA outweigh egress savings.
Exam tip: Cloud CDN is always Premium Tier, and Cloud Storage defaults to Premium Tier unless the bucket is a backend for an external Application Load Balancer.
Resource-based committed use discounts (resource-based CUDs) require a 1-year or 3-year commitment to a minimum quantity of Compute Engine resources in a specific region and cover only matching machine configuration in that region, while spend-based committed use discounts (spend-based CUDs) require a minimum hourly spend at the Cloud Billing account level and cover eligible usage in any linked project regionally or globally depending on the product. Choose resource-based CUDs when baseline vCPU, memory, GPU, or license usage is stable in one region, and choose spend-based CUDs such as compute flexible CUDs when flexibility across regions, projects, and eligible services matters more than the maximum region-locked discount.
Spot VMs should be used only for fault-tolerant, flexible, and batch-oriented workloads without high-availability requirements that can tolerate preemption. Spot VMs provide access to unused Compute Engine capacity at more than 80 percent discount versus regular VMs but can be preemptively stopped or deleted, while CUDs fit predictable steady usage with a 1-year or 3-year commitment and SUDs apply automatically to consistent usage beyond duration thresholds without a purchase.
Premium Tier routes traffic within the Google Cloud network until the last mile with a 99.99 percent SLA and supports all networking features, while Standard Tier routes traffic over peering, ISP, or transit networks with a 99.9 percent SLA and lower egress cost. Choose Premium Tier when global reach, low latency, full feature support, and the higher SLA justify higher egress rates, and choose Standard Tier when regional serving and lower egress rates matter more than backbone performance.
An enterprise DevOps team is conducting a FinOps review to optimize network egress spend across multiple Google Cloud workloads without compromising technical constraints. They have identified two distinct services:
us-central1).Which Network Service Tier configuration should the DevOps team implement to achieve the lowest overall egress cost while satisfying all technical and architectural requirements?
Last updated