For Zarthi, I’d recommend structuring your committed use discounts in two layers. First, commit to resource-based discounts to cover the steady, baseline compute across your primary regions and machine families. Second, complement that with a spend-based or flexible commitment to cover offsetting workloads that shift in region or instance type.

Start by analyzing your past 12 months of usage to find the consistent “floor” demand: for each region or project, determine the minimal vCPU/memory you always consume. Commit to about 60–80 % of that baseline via resource CUDs to avoid overcommitment. Use one-year terms initially—this gives flexibility while you validate your usage patterns; once you’re confident, gradually shift parts to three-year commitments in the most stable areas.

For workloads that occasionally spike or move across regions (e.g. dev/test, batch jobs, or variable workloads), allocate some portion of your commitment in a flexible or spend-based commitment slot. This will let you apply the benefit broadly instead of tying it to one exact resource.

After you commit, monitor utilization closely. If you see underutilized commitments, plan your future commit levels more conservatively. As Zarthi matures and patterns stabilize, you can increase your committed percentage.

In short: use a hybrid approach (resource + flexible), commit to ~ 60–80 % of your stable base, start with shorter terms, and revisit regularly to avoid waste.https://zarthi.com/solutions/services/compute-committed-use-discounts-recommendation/gke-long-term-savings