CUDs Plan
1. Existing - Machine Type Usage [Grouped Instance Family-Wise]
E2 Family
- Standard
- e2-standard-2 (2 vCPUs, 8 GB memory) × 5
- e2-standard-4 (4 vCPUs, 16 GB memory) × 1
- Custom
- e2-custom-4-10240 (4 vCPUs, 10 GB memory) × 2
- Shared-core
- e2-medium (2 vCPUs, 4 GB memory) × 4
- e2-micro (2 vCPUs, 1 GB memory) × 1
C2 Family
- Standard
- c2-standard-4 (4 vCPUs, 16 GB memory) × 8
So in total:
- E2 family → 13 instances
- C2 family → 8 instances
Type | What you Commit | What Services / Resources it Covers | Scope / Restrictions |
|---|---|---|---|
Resource-based CUDs | Amounts of specific resources (vCPUs, memory, Local SSDs, GPUs, etc.), by machine family, region, project. | Compute Engine resources (vCPUs, memory, GPUs, local SSD etc.) for specific machine types; there are different “machine series” with different eligible resources. | Must specify region, project; applies to particular machine families; discount highest when usage is stable & predictable. |
Spend-based CUDs | A minimum hourly spend amount (in dollars) for eligible services. You commit to spending $X per hour (for 1 or 3 years). | Several services: Compute Engine / GKE / Cloud Run (flexible compute spend), plus service-specific spend CUDs for things like AlloyDB, Cloud SQL, Bigtable, Spanner, Memorystore, etc. | Scope is at billing account level (so can apply to all projects under that account). Covers eligible usage for those services. Overages (spend beyond committed) are charged at regular rates. |
1. Resource-based CUDs (classic)
- You commit to specific resources (vCPUs + RAM) in a region.
- They are machine-family agnostic within that region — meaning if you move from
e2-standard-2→e2-standard-4(same family, same region), you’re still covered, because both consume vCPUs + memory from the committed pool. - What doesn’t work: if you switch to a different family (say E2 → N2 or C2) or to a different region, that commitment won’t apply.
Resource-based covers the case of scaling e2-standard-2 → e2-standard-4 (as long as you stay in the same family/region).
2. Flexible / Spend-based CUDs
- You commit to a spend ($/hour) instead of resources.
- This covers any eligible Compute SKUs across machine families and regions (with some exclusions).
- So if you switch families (E2 → C2, or change region), you’re still covered as long as the usage is in the eligible set.
This gives maximum safety (safety of not over commiting) if we think we'll migrate away from E2 entirely or need to shuffle workloads between regions/projects.
What we can do :
We need to go with different CUDs for different spends through prod, non-prod, and tooling.
For Tooling (Which costs us anywhere around 900-1000 USD) -> Here our region, machine type are fixed. (To avail higher discounts >30% /month for 1Y commitment)
Need to Finalize on the number of environments we would be considering on the upfront
No Comments