Why this matters
A Google Cloud commitment discount is a trade: you promise to pay for a minimum amount of resource or spend for one or three years, and Google Cloud bills that usage at a lower rate. The bill arrives whether you run the workloads or not. That makes the purchase decision a capacity planning problem, not a shopping problem.
Google Cloud sells resource-based commitments for things like Compute Engine vCPU and memory, and spend-based commitments for certain services. Resource-based commitments are usually tied to a project and region. Spend-based commitments are usually set at the billing account level. The console states the scope before you pay. Read that line twice.
The risk is not missing a small discount. The risk is buying for a peak month, then watching the workload move to another region or shrink after a cleanup. You keep paying the commitment. The goal is to cover the floor of steady usage and leave the rest on-demand.
Before you start
Pull at least 60 days of billing data, and 90 if you have seasonality. Use Cloud Billing reports for a first look and a BigQuery billing export for the real work. You want hourly usage by project, region, SKU, and resource. A monthly total hides the shape of the load.
Split usage into baseline and burst. Baseline is the capacity you run every hour of a normal week. Burst is the batch job, the test cluster, the month-end spike. Commitments should follow the baseline. If a workload runs eight hours a day, a full-time commitment will sit idle for most of the day.
Check what is eligible. Not every Google Cloud service or machine series takes the same commitment. A new machine family may not match an old resource-based commitment. A spend-based commitment may not cover every SKU in the service. Ask your account team or read the service page for the exact terms. Then write down the term, region, project scope, and start date you are considering.
Get finance and engineering in the same room. Engineering knows the roadmap: a migration or a move to another region. Finance knows the budget cycle. If a team plans to leave a region in nine months, a three-year commitment in that region is a bad trade. No discount fixes that.
How to do it
The method is to size from history, buy a floor, and add more later. Do not try to get the perfect number in one purchase. Google Cloud lets you add commitments, so you can raise coverage as the baseline proves stable.
Use the same source data for sizing and for the post-purchase check. If you size from a dashboard and check from a different report, you will argue about the result. Keep a short record of the assumptions: term, scope, expected changes, and owner.
- Export billing data to BigQuery. Turn on the Cloud Billing export to BigQuery for the accounts you are reviewing. Build a table of hourly usage with project, region, SKU, and cost. Use at least 60 days so one bad week does not set the floor.
- Map steady usage by scope. Group hourly usage by project, region, and commitment family. Find the level that usage stays above in normal weeks. That level is your floor. Keep one-off projects out of it.
- Choose resource-based or spend-based. Use resource-based commitments for stable Compute Engine shapes you can name. Use spend-based commitments when the service mix is stable but the exact SKUs move. Check the console for the scope each one covers.
- Set the commitment below the floor. Take the floor and subtract room for planned changes and normal drift. If you expect a migration or a cleanup, subtract more. It is cheaper to buy a second commitment later than to carry an unused first one.
- Model the term with real history. Run the last 60 to 90 days through the commitment rate and the on-demand rate. Compare the total bill for a one-year term and a three-year term. Include the quiet months as well as the busy ones.
- Buy in small batches. Start with one commitment that covers the most certain part of the baseline. Add another after a month or two of stable usage. Stagger start dates so renewals do not all land in the same week.
- Tag and alert before the first invoice. Label the workloads that the commitment is meant to cover. Set budget alerts and a monthly review on the Committed use discounts page. Put the renewal date on the finance calendar.
- Review scope after any platform change. When you change machine families or move a project to another region, re-run the coverage check. A commitment does not follow the workload. It stays where you bought it.
How to check it worked
After the first full billing cycle, open Cloud Billing reports and the CUD analysis view. Check coverage and utilization. Coverage tells you how much eligible usage the commitment touched. Utilization tells you how much of the commitment you actually used. High coverage with low utilization means you bought the wrong shape or scope.
Query the BigQuery export for the commitment line items. Confirm the discount appears on the expected projects and regions. If the discount shows up in a project you did not plan for, the scope is wider than you thought. If it does not show up at all, the resources may not be eligible.
Compare the invoice to the model. Look at the effective rate for the committed resources, not the total bill. A lower total bill can hide a commitment that is only half used while other on-demand usage grew. Check the utilization trend for three months before you buy more.
Ask the teams if anything changed, such as a migration or a batch job that moved to another region. Then update the commitment plan. The check is not a one-time task. It is a monthly habit.
Mistakes to avoid
Buying for the peak. The busiest hour of the quarter is not a baseline. If you commit to peak, you pay for capacity that sits idle most of the month.
Ignoring scope. A resource-based commitment in one project and region will not cover a workload that moves. A spend-based commitment may not cover every service you assume. Read the scope line before you click buy.
Choosing a three-year term for a young workload. The extra discount is not worth a lock-in if the architecture is still moving. A one-year term costs more per hour but keeps the exit open.
Forgetting renewals and stacking commitments without a map. Keep a simple register: term, start, end, scope, owner. Review it with finance every quarter. If you want an outside read, the Cloud cost audit from Cloudverg is a fixed price of $4,500 for a two-week review that includes a commitment plan, one option among others.
Frequently asked questions
What is the difference between resource-based and spend-based commitments in Google Cloud?
Resource-based commitments cover Compute Engine resources such as vCPU and memory, and they are scoped to a project and region in most cases. Spend-based commitments cover eligible spend for a service and are usually set at the billing account level. Check the console wording for the exact scope before you buy.
Can I cancel or change a Google Cloud commitment?
No. A commitment is a fixed bill for its term. You cannot cancel it or move it to another region. You can buy additional commitments, but you cannot shrink the one you already have.
How much should I commit to Google Cloud?
Commit to the floor of steady usage, not the average or the peak. Leave room for planned migrations and cleanup. Start small and add commitments as the baseline proves stable.