Production Cloud SQL instances busy enough for a committed use discount
What does ZopNight detect here?
Production Cloud SQL instances are flagged when 60 days of history show them running at least 70% of the time with CPU or memory averaging 30% or more. Google's spend-based Cloud SQL CUDs cut vCPU and memory prices 25% for a 1-year term and 52% for 3 years, and ZopNight prices the saving from the instance's live rates.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-146 |
| Category | discount |
| Severity | low |
| Metric | cloudsql.googleapis.com/database/cpu/utilization |
| Threshold | 70% uptime and 30% average CPU or memory |
| Evaluation window | 60d |
| Source | ZopNight |
| Permissions used | cloudsql.instances.list · monitoring.timeSeries.list |
Where it applies
What a Cloud SQL commitment buys and locks in
Cloud SQL committed use discounts are spend-based. You commit to a consistent amount of usage, measured as hourly on-demand spend, in one region for one or three years. Google’s Cloud SQL CUD page lists the discount as 25% for a 1-year term and 52% for a 3-year term, the same in every region. The discount applies automatically to CPU and memory of MySQL, PostgreSQL and SQL Server instances in that region, including Enterprise and Enterprise Plus editions.
The limits matter as much as the rate. Shared-core machine types such as db-f1-micro are
excluded, and so are storage, backups, IP addresses, outbound data transfer and licensing. Usage
above the commitment is billed on demand. And a commitment cannot be cancelled once bought.
Sizing a commitment from your own data
List instances with their tier and labels, which is where production status usually shows:
gcloud sql instances list \ --format="table(name,region,settings.tier,settings.userLabels)"Then chart cloudsql.googleapis.com/database/cpu/utilization and
cloudsql.googleapis.com/database/memory/utilization over the last 60 days in Metrics Explorer.
The lowest steady level across your production instances in a region is a safe commitment size.
Four gates before a recommendation appears
- The instance looks like production: its name contains
prod,productionorlive, or anenv,environment,stageortierlabel is set toprod,production,prdorlive. - ZopNight has at least 60 days of history for it, and it was running at least 70% of that time.
- Measured CPU or memory utilisation averages at least 30%, so the commitment covers real load.
- The instance has a known cost and Google’s live rates show a positive commitment discount.
When ZopNight holds back
If any gate fails, or utilisation has never been measured, there is no finding. A break-even check then compares a commitment billed for all 730 hours of a month with on-demand for the hours the instance really ran; when the commitment would cost more, the rule stays silent. Non-production instances are never considered, however steady they look.
How the saving is calculated
saving = on-demand cost for measured running hours - 1-year commitment cost (730 h)fallback when running hours are unknown: saving = monthly cost x live commitment discountThe finding quotes the resulting percentage for the instance.
Buying the commitment
- Confirm the instance, or its replacement in the same region, will run for at least a year.
- Add up steady hourly spend across production instances in the region and commit to that baseline rather than peak.
- Purchase the Cloud SQL commitment in the billing console’s committed use discounts page for that region.
- Review coverage monthly; spend above the commitment is simply billed on demand.