Google Cloud Pricing Models Explained: On-Demand, Committed, Sustained, and Spot
A pricing model is the method Google Cloud uses to calculate your charges for a particular service. Some services charge per second of compute time. Others charge per request, per gigabyte stored, or per terabyte of data processed. This page explains every major pricing model, compares them side by side, and helps you decide which one fits your workload.
If you are new to Google Cloud billing concepts (projects, billing accounts, invoices), read the billing fundamentals page first. This page focuses on how you are charged, not how billing is structured.
Simple explanation of Google Cloud pricing models
On-demand is like paying per minute with no contract. SUDs are like an automatic loyalty discount your carrier applies when you use enough minutes each month. CUDs are like signing a 1 or 3-year contract for a lower monthly rate. Spot VMs are like standby tickets: massively cheaper, but you might get bumped.
Google Cloud has several pricing models. Here is the short version:
- On-demand: pay per second (or per request, per GB, etc.) with no commitment. The default for almost every service.
- Sustained use discounts (SUDs): automatic savings that apply when an eligible VM runs for a large portion of a billing month. No action required.
- Committed use discounts (CUDs): deeper savings in exchange for committing to a minimum level of resources for 1 or 3 years.
- Spot VMs: the cheapest compute option (60–91% off), but GCP can reclaim the VM at any time.
- Usage-based service pricing: services like Cloud Run, Cloud Storage, and BigQuery do not use VM discount models. They charge by request, storage volume, data processed, or a combination.
The discount models (SUDs, CUDs, Spot) apply mainly to Compute Engine VMs. Managed and serverless services have their own pricing structures, covered later on this page.
How Google Cloud pricing works
Three concepts are related but distinct:
- Pricing is the rate Google charges per unit of a resource. For example, a per-second CPU rate or a per-GB storage rate.
- Billing is the process of tracking usage, applying discounts, generating invoices, and collecting payment. See GCP billing fundamentals for details.
- Cost optimisation is the practice of reducing your bill through architecture decisions, discount commitments, and resource management. See the FinOps principles guide for that broader topic.
Why pricing models differ by service
Compute Engine VMs reserve dedicated CPU and memory for as long as they run, so they are priced per second of runtime. Serverless services like Cloud Run only consume resources while handling a request, so they charge per request and per unit of compute time used. Cloud Storage charges for bytes stored and operations performed. BigQuery charges for the volume of data your queries scan.
Two cost factors apply across almost every service:
- Region: the same VM or storage bucket costs more in some regions than others.
- Network egress: sending data out of GCP to the internet is charged per GB. Ingress is free. See network egress costs explained for the full breakdown.
Google Cloud also provides a permanent Always Free tier with monthly allowances for many services. Usage within those limits incurs no charge. Usage above the limits is billed at standard rates.
Pricing model comparison table
| Model | How you are charged | Best for | Main trade-off | Typical services |
|---|---|---|---|---|
| On-demand | Per-second runtime, no commitment | New workloads, dev/test, unpredictable usage | Highest per-unit cost | Compute Engine, GKE nodes, Cloud SQL |
| Sustained use discounts | Automatic reduction on eligible VMs running most of a month | VMs you have not committed to yet | Savings cap at ~30%; not all families eligible | Compute Engine (N1, N2, N2D, C2, C2D, M1) |
| Committed use discounts | Fixed commitment for 1 or 3 years; pay whether or not you use it | Stable, predictable baseline workloads | You pay the committed amount regardless of actual use | Compute Engine, Cloud SQL, GKE, some other services |
| Spot VMs | Per-second runtime at 60–91% off | Batch processing, ML training, CI/CD builds | GCP can reclaim the VM at any time | Compute Engine, GKE node pools |
| Usage-based (serverless) | Per request + per unit of CPU/memory time used | Variable or spiky traffic, event-driven workloads | Cost scales directly with traffic volume | Cloud Run, Cloud Functions |
| Usage-based (storage/data) | Per GB stored + per operation + egress | Any workload with storage or data transfer needs | Cost driven by volume and access pattern | Cloud Storage, Firestore, Bigtable |
| On-demand query (BigQuery) | Per TB of data scanned by queries | Exploratory analytics, variable query volume | Costs are unpredictable if queries scan large tables | BigQuery |
| Capacity-based (BigQuery) | Reserved processing slots at a flat rate | High-volume, predictable analytics workloads | You pay for slots whether or not queries run | BigQuery Editions |
On-demand pricing
On-demand is the default pricing model for Compute Engine, Cloud SQL, and most services that provision dedicated resources. You pay per second of usage (with a one-minute minimum for VMs) and can stop at any time with no penalty.
Example: an n2-standard-4 VM (4 vCPUs, 16 GB memory) in
us-central1 costs approximately $0.19/hour on-demand. Running it
24/7 for a full month works out to roughly $140/month. The same VM in a more
expensive region costs more. These figures are approximate, so always check the
current pricing page or the
GCP Pricing Calculator
for your specific configuration.
On-demand pricing is the right starting point when you are experimenting, building a prototype, or running a workload whose resource needs are not yet predictable.
Sustained use discounts (SUDs)
Sustained use discounts are automatic. GCP tracks how long each eligible VM runs during a billing month and applies increasing discounts as runtime grows:
- A VM running more than 25% of the month receives its first discount tier.
- At 50% of the month, a higher tier applies.
- At full-month runtime (100%), the discount reaches approximately 30% off the on-demand rate.
You do not need to enable SUDs or opt in. If your VM is in an eligible machine family, the discount appears on your invoice automatically. There is nothing to purchase, configure, or monitor.
Which VMs qualify
SUDs apply to the N1, N2, N2D, C2, C2D, and M1 machine families. They do not apply to E2, T2D, Tau, or Spot VMs.
When SUDs help and when they do not
SUDs are valuable for VMs that run for weeks or months but where you have not yet committed to a CUD. They are not a replacement for CUDs on stable workloads. SUDs cap at around 30% off, while CUDs can save roughly double that. SUDs also do not apply to non-VM services such as Cloud Run or Cloud Storage.
Committed use discounts (CUDs)
Committed use discounts require you to commit to a minimum level of resources, typically vCPUs and memory, for 1 or 3 years. In return, you receive a significantly larger discount than SUDs:
- 1-year commitment: approximately 37% off on-demand pricing
- 3-year commitment: approximately 52–57% off on-demand pricing
The commitment is to a resource pool (a quantity of vCPUs and memory in a region), not to a specific VM instance. You can resize, delete, and recreate VMs and still benefit from the discount as long as total usage meets or exceeds the committed amount.
Resource-based vs spend-based CUDs
Google Cloud offers two CUD structures:
- Resource-based CUDs commit to specific vCPU and memory quantities for a machine family in a region. These give the deepest discounts and are best when you know exactly which machine family you will use.
- Spend-based (flexible) CUDs commit to a dollar amount of spend per hour across eligible services. They offer slightly lower discounts but more flexibility, letting you shift between machine families or even between Compute Engine and some other services. Spend-based CUDs are available for services beyond just Compute Engine, including Cloud SQL and GKE.
A common strategy is to buy CUDs sized to your stable baseline (the compute you know will run all year) and let SUDs or on-demand pricing cover any variable usage above that. This way you get the deepest discount on what you are certain about and avoid paying for committed capacity you do not use.
When to buy CUDs
CUDs are for predictable baseline usage. If you know a set of VMs will run for at least a year, a 1-year CUD immediately saves more than SUDs alone. See the Compute Engine cost optimisation guide for more detail on layering discounts.
Spot VMs
Spot VMs use spare Google Cloud capacity at discounts of 60–91% off the on-demand price. The trade-off is preemptibility: GCP can reclaim a Spot VM at any time with only a 30-second warning (SIGTERM).
Best-fit workloads
- Batch data processing
- ML model training with checkpointing
- CI/CD build and test pipelines
- Video rendering and transcoding
- Any job that can save progress and resume after interruption
Who should not use Spot VMs
Do not use Spot VMs for web servers, databases, or any service that must stay available. A preemption causes immediate downtime for workloads that cannot tolerate interruption. The discount is meaningless if it causes an outage.
For a deeper look at Spot VM patterns, including checkpointing examples, see the Spot VMs for cost savings guide.
Usage-based pricing for managed and serverless services
Many Google Cloud services do not use VM-style pricing at all. Instead, they charge based on the specific resource you consume: requests, compute seconds, bytes stored, data scanned, or data transferred. The sections below cover the most common services.
Cloud Run
Cloud Run charges for three things:
- Requests: charged per million requests
- CPU time: charged per vCPU-second while your container is processing a request
- Memory: charged per GiB-second while your container is processing a request
In the default CPU allocation mode, idle containers cost nothing. This makes Cloud Run cost-effective for spiky or low-traffic services. Setting minimum instances above zero reintroduces idle billing. The Always Free tier includes 2 million requests, 180,000 vCPU-seconds, and 360,000 GiB-seconds of memory per month, plus 1 GiB of outbound data transfer from North America.
To model your specific workload, use the free Cloud Run Cost Calculator. For deeper optimisation strategies, see Cloud Run cost optimisation.
Cloud Run functions (Cloud Functions)
Cloud Run functions use the same per-invocation and per-compute model as Cloud Run. You are charged per invocation, plus CPU and memory time billed per 100 ms of execution. The first 2 million invocations per month are free. The main cost driver is a combination of invocation volume and per-invocation duration.
Cloud Storage
Cloud Storage charges for three dimensions independently:
- Storage volume: a per-GB monthly rate that varies by storage class (Standard, Nearline, Coldline, Archive). Colder classes are cheaper per GB but have minimum retention periods and higher retrieval costs.
- Operations: Class A operations (writes, lists) and Class B operations (reads) are charged per 10,000 operations. High-frequency small-object workloads can accumulate meaningful operation costs.
- Network egress: data transferred out of Cloud Storage to the internet or to another region is charged per GB.
Cloud SQL
Cloud SQL bills continuously for vCPUs and memory while an instance is in the RUNNING state, plus a per-GB monthly rate for storage. Unlike serverless services, a Cloud SQL instance does not scale to zero automatically. A running instance with no queries still incurs compute charges. Stop instances in dev environments when not in use.
BigQuery
BigQuery has two query pricing models:
- On-demand: charges per TB of data scanned by your queries (first 1 TB/month free). Good for exploratory and variable-volume analytics. The LIMIT clause does not reduce bytes scanned. Use partition filters and column selection to control costs.
- Capacity (Editions): you reserve processing slots (units of compute capacity) at a flat rate. Suited for teams with predictable, high-volume query workloads where per-TB pricing becomes expensive.
Storage is charged separately at per-GB monthly rates, with a lower rate for long-term tables (those not modified in 90 days). For a thorough guide, see BigQuery pricing explained and BigQuery cost optimisation.
When to use each pricing model
| Scenario | Recommended model | Why |
|---|---|---|
| New or uncertain workload | On-demand | No commitment; measure real usage before optimising |
| Stable production VMs running 24/7 | CUDs (1-year or 3-year) | Predictable baseline benefits most from deep commitment discounts |
| Long-running VMs, no commitment yet | On-demand with automatic SUDs | SUDs apply automatically while you evaluate whether to commit |
| Fault-tolerant batch jobs or ML training | Spot VMs | Steep discount; design for interruption |
| Spiky web or API traffic | Cloud Run (usage-based) | Pay only during requests; scales to zero |
| Exploratory analytics | BigQuery on-demand | Pay per query; first 1 TB/month is free |
| High-volume daily analytics | BigQuery capacity (Editions) | Flat rate avoids per-TB cost spikes |
| Storage-heavy workload with infrequent access | Cloud Storage Nearline/Coldline/Archive | Lower per-GB rate; accept minimum retention and higher retrieval cost |
Many real architectures combine multiple models. A common pattern is CUDs for baseline VMs, Spot for batch processing, Cloud Run for API services, and BigQuery on-demand for analytics. Start with on-demand, then layer in discounts and commitments as usage patterns become clear. The estimating cloud costs guide walks through how to model this for a real workload.
Common mistakes that increase GCP bills
Leaving dev resources running. A dev VM running 24/7 costs roughly $140/month. Running it only during business hours (8 hours/day, weekdays) drops that to approximately $28/month. Use scheduled start/stop policies and billing alerts to catch idle resources.
Forgetting network egress. Architects size compute and storage carefully but forget that sending data out of GCP to the internet costs roughly $0.08–0.12 per GB. A data-heavy service can have egress costs that match or exceed its compute costs. See network egress costs for how to avoid surprises.
Assuming LIMIT reduces BigQuery cost. BigQuery bills for bytes scanned, not rows returned. Adding
LIMIT 100to a query does not reduce your bill. Use partition filters and select only the columns you need.Running stable workloads on on-demand pricing indefinitely. If a VM will run for at least a year, a 1-year CUD saves roughly 37% with no architecture changes. Many teams leave money on the table by never purchasing commitments for production workloads they know are long-lived.
Misunderstanding the free tier. The Always Free tier is a fixed monthly allowance, not a spending cap. Once you exceed the limit, standard pricing applies automatically with no warning unless you have set up billing budgets and alerts.
Confusing billing with pricing. Pricing is the per-unit rate. Billing is the process of tracking usage, applying discounts, and generating invoices. Understanding how billing works helps you read your invoice and know which discounts were applied.
On-demand vs SUD vs CUD vs Spot: direct comparison
| Factor | On-demand | SUD | CUD (1-year) | CUD (3-year) | Spot |
|---|---|---|---|---|---|
| Discount | 0% | Up to ~30% | ~37% | ~52–57% | 60–91% |
| Commitment | None | None (automatic) | 1 year | 3 years | None |
| Can be interrupted? | No | No | No | No | Yes, 30s warning |
| Configuration needed | None | None | Purchase commitment | Purchase commitment | Set provisioning model to Spot |
| Best for | Dev, test, uncertain usage | Medium-term VMs | Stable 1+ year workloads | Stable 3+ year workloads | Batch, ML, fault-tolerant jobs |
A production environment might use CUDs for baseline VMs, Spot VMs for nightly batch processing, and on-demand for burst capacity during peak events. You do not have to pick just one.
Frequently asked questions
What is the difference between on-demand, sustained use discounts, committed use discounts, and Spot?
On-demand charges the full per-second rate with no commitment. Sustained use discounts (SUDs) are automatic reductions (up to approximately 30% off) that GCP applies when an eligible VM runs for a large portion of a billing month. Committed use discounts (CUDs) require a 1-year or 3-year commitment to a minimum level of resources and offer deeper savings of roughly 37% (1-year) to 57% (3-year). Spot VMs use spare capacity at 60-91% off but can be reclaimed by GCP at any time with only 30 seconds notice. Choose on-demand for experimentation, SUDs for medium-term VMs you have not committed to yet, CUDs for predictable baseline workloads, and Spot for fault-tolerant batch work.
Is Google Cloud always pay-as-you-go?
Most Google Cloud services use pay-as-you-go pricing, meaning you only pay for what you consume. However, committed use discounts require an upfront time commitment (1 or 3 years) and you pay the committed amount whether or not you use it. Some services, like BigQuery capacity pricing, also let you reserve fixed processing slots at a flat rate. The free tier provides a permanent monthly allowance for many services, but exceeding those limits triggers standard pay-as-you-go charges automatically.
When should I choose committed use discounts instead of relying on sustained use discounts?
Choose CUDs when you have workloads that will run steadily for at least a year. SUDs max out at around 30% off, while a 1-year CUD saves roughly 37% and a 3-year CUD saves roughly 57%. If your baseline compute usage is predictable (for example, production VMs that run 24/7) CUDs give meaningfully deeper savings. Many teams use CUDs for the stable baseline and let SUDs cover any additional VMs that run long enough to qualify.
Does the free tier mean my project is free?
Not necessarily. The Always Free tier provides a fixed monthly allowance for specific services, such as 2 million Cloud Run requests or 1 TB of BigQuery query processing. If your usage stays within those limits, there is no charge for those services. But the free tier does not cover all services, does not cover network egress beyond small allowances, and any usage above the free tier limit is billed at standard rates. It is easy to exceed limits without realising, especially for storage and egress. Always set a billing budget and alerts.
What costs surprise beginners most in GCP?
Network egress is the most common surprise: sending data out of GCP to the internet costs roughly $0.08-0.12 per GB, and this adds up fast for data-heavy applications. Other surprises include idle resources still incurring charges (a stopped Cloud SQL instance still bills for storage), BigQuery scanning full columns regardless of LIMIT clauses, and accidentally exceeding free tier limits. Setting up billing budgets and alerts before deploying anything is the single best way to avoid bill shock.