GCP Cost Optimization Guide: Discounts, Stops and GKE
Google Cloud applies some discounts automatically and sells others by commitment. Knowing which is which decides what to stop and what to commit.
Google Cloud cost optimization is the work of matching what you run, and how you pay for it, to what your workloads need. On Google Cloud it has a specific shape: some discounts arrive automatically, some are bought, some compute can be reclaimed by Google at short notice, and several services keep charging after the thing you think of as “the server” is stopped.
Automatic discounts: sustained use
Sustained use discounts (SUDs) are calculated and applied by Compute Engine without any purchase. A resource used for more than 25% of a billing month earns a discount on every incremental hour, reaching a maximum monthly discount of 20% or 30% depending on the resource and machine type. They apply only to listed machine series, which include the vCPUs and memory of N1, N2, and N2D, C2, and M1 and M2 machine types. SUDs do not apply to usage already covered by committed use discounts.
One consequence for scheduling: a VM stopped nights and weekends runs a smaller share of the month, so it earns a smaller SUD on the hours it does run. Every stopped hour still removes a charge, since each incremental hour is billed at a positive rate, but estimate the saving on the discounted rate, not the list rate.
Bought discounts: committed use
Committed use discounts come in two forms. Resource-based CUDs commit you to a specific type and amount of Compute Engine resources in one region for one or three years, with the three-year plan discounted more. Compute flexible CUDs are spend-based: you commit to a minimum hourly spend on eligible Compute Engine, GKE, and Cloud Run usage. Either way you pay for the full term regardless of actual usage, so commit only to capacity that will run continuously. See committed use discounts.
Reclaimable compute: Spot VMs
Spot VMs are priced with up to 91% discounts for many machine types, GPUs, and TPUs, but Compute Engine can preempt them at any time to reclaim capacity, stopping them by default or deleting them if configured. Use them for batch and fault-tolerant work; see spot instances.
What a stop does and does not remove
- Compute Engine. Billing uses a one-minute minimum and then per-second increments. Stopping ends vCPU and memory charges, but you keep incurring charges for resources that remain attached, such as persistent disks and static external IP addresses, which Google treats as in use, and billed, while the VM is stopped.
- Cloud SQL. Setting the activation policy to NEVER stops the instance and suspends instance charges; storage and IP address charges continue.
- GKE. Scaling node pools to zero removes node VM cost, but the flat cluster management fee of $0.10 per cluster per hour applies to every cluster regardless of mode or size. The GKE free tier gives $74.40 of monthly credit per billing account, enough for one zonal or Autopilot cluster. Autopilot’s general-purpose workloads are billed on Pod resource requests, per second, so oversized requests cost money directly.
Sizing and analytics
Compute Engine generates machine type recommendations from Cloud Monitoring metrics over the previous eight days. For BigQuery, on-demand pricing charges per TiB processed, with the first 1 TiB per month free, while capacity pricing charges per slot-hour through BigQuery editions. Google’s cost best practices include previewing queries to estimate cost and setting custom daily query quotas.
Where ZopNight fits
ZopNight starts and stops Compute Engine VMs, GKE clusters and workloads, and Cloud SQL on schedules, and can stop individual GKE namespaces by scaling their Deployments and StatefulSets to zero. With billing export connected, GCP costs are read from BigQuery net of credits, so committed use and sustained use discounts are reflected as the invoice bills them. Try scheduling Compute Engine or scheduling Cloud SQL.