Optimizing performance and cost · Topic 2 of 2
FinOps: Spot VMs, Discounts, Network Tiers and Workload Cost Tuning
Apply FinOps on Google Cloud: observability costs, Spot VMs, rightsizing, committed and sustained use discounts, network tiers and GKE and Cloud Run costs.
- 5 min
- Billing export to BigQuery plus labels show cost per team and service.
- Observability costs come from log volume and retention, metric samples, spans and flow logs.
- Spot VMs: big discount, preemptible at any time, for fault-tolerant work.
What it is
FinOps is the practice of making engineering teams accountable for cloud spend: seeing costs clearly, choosing the right pricing model, and removing waste continuously. For a DevOps engineer, it means building cost into designs and pipelines, not cleaning up afterwards.
The biggest levers are pricing models (discounts and Spot), rightsizing, autoscaling, and keeping observability data under control.
How it works
Seeing the costs
- Cloud Billing export to BigQuery gives detailed cost data to query and chart by project, service, SKU and label.
- Labels on resources (team, environment, application) let you split costs; GKE cost allocation splits cluster costs by namespace and label.
- Budgets alert on actual or forecast spend per project, folder or label.
Observability costs
| Signal | What drives cost | How to reduce |
|---|---|---|
| Cloud Logging | Volume stored in log buckets, and retention beyond the default | Lower log levels, exclusions, sampling, shorter retention, archive to Cloud Storage |
| Cloud Monitoring | Ingested metric data: samples for Prometheus metrics, volume for custom and agent metrics | Longer scrape intervals, fewer metrics, low label cardinality |
| Cloud Trace | Number of spans ingested | Sample traces |
| VPC Flow Logs | Sample rate, aggregation interval, metadata | Lower sampling on busy subnets |
Platform metrics from Google Cloud services carry no charge, and Cloud Logging includes a free monthly allotment per project.
Spot VMs
Spot VMs use spare Compute Engine capacity at a large discount. Google can preempt them at any time, with a short notice, and they have no availability guarantee.
gcloud compute instances create batch-worker-1 --zone=europe-west1-b \
--machine-type=e2-standard-4 --provisioning-model=SPOT \
--instance-termination-action=DELETE| Good for | Not for |
|---|---|
| Batch jobs, CI runners, rendering, fault-tolerant data processing | Databases, stateful single instances |
| GKE node pools for stateless, replicated workloads | Workloads that cannot tolerate interruption |
Design for interruption: checkpoint work, use managed instance groups to recreate VMs, and on GKE keep critical pods on standard nodes.
Optimizing resource usage
- Rightsize with Active Assist machine type recommendations; use custom machine types when a standard shape wastes memory or CPU.
- Autoscale so capacity follows demand; scale non-production down or off outside working hours with instance schedules.
- Delete idle resources: unattached disks, unused static IP addresses, old snapshots and images, forgotten ephemeral environments.
- Storage classes and lifecycle rules move old objects to cheaper classes.
Infrastructure cost planning
| Model | How it works | Best for |
|---|---|---|
| Committed use discounts (CUDs), resource-based | Commit to an amount of vCPU, memory or other resources in a region for 1 or 3 years | Steady baseline load on Compute Engine |
| CUDs, spend-based | Commit to an hourly spend on a service for 1 or 3 years | Steady use of services such as Cloud Run or Cloud SQL, and flexible commitments across machine families |
| Sustained use discounts | Applied automatically when certain machine types run for a large part of the month; not available on all machine series, such as E2 | VMs that run continuously without a commitment |
| Spot VMs | Deep discount, can be preempted | Interruptible work |
Commit only to the stable baseline you are sure of, and cover peaks with on-demand or Spot capacity.
Network tiers
| Tier | Path | Cost and features |
|---|---|---|
| Premium (default) | Traffic stays on Google's global network close to the user | Higher performance; required for global load balancing |
| Standard | Traffic uses the public internet for more of the path | Lower egress cost; regional resources only |
Choose Standard for cost-sensitive, regional workloads where some extra latency is acceptable.
Optimizing individual workload costs
| Platform | Levers |
|---|---|
| GKE | Autopilot charges for pod resource requests, so right-size requests; Standard clusters need cluster autoscaler and bin packing; Spot node pools or Spot pods; VPA recommendations; GKE cost allocation |
| Cloud Run | Raise concurrency so fewer instances serve the load; request-based billing charges only while handling requests; keep min instances low outside peak; set max instances |
| Compute Engine | Rightsize, E2 machine types for general workloads, CUDs for baseline, Spot for batch, schedules for non-production |
A worked example
A media company's monthly bill grows 20% each quarter. Billing export to BigQuery shows the largest costs are always-on GKE nodes, nightly transcoding VMs and Cloud Logging.
The team buys 3-year CUDs for the GKE baseline, moves transcoding to Spot VMs in a managed instance group with checkpointing, and applies log exclusions for health check requests. Budgets per team, built from labels, alert at 80% and 100% of forecast.
How the exam asks about this
- "A nightly batch job can restart if interrupted and must be as cheap as possible." Run it on Spot VMs.
- "A service runs at the same load all year and will for the next three years." Buy 3-year committed use discounts for the baseline.
- "An internal regional application is cost sensitive and not latency critical." Use the Standard network tier.
What to remember for the exam
- Billing export to BigQuery plus labels show cost per team and service.
- Observability costs come from log volume and retention, metric samples, spans and flow logs.
- Spot VMs: big discount, preemptible at any time, for fault-tolerant work.
- CUDs for steady load (1 or 3 years); sustained use discounts are automatic on eligible machine types.
- Premium tier is global and faster; Standard tier is regional and cheaper.
Committed use discounts are billed for the full term whether or not you use the resources. Commit only to the baseline you are confident will run for the whole period.
Common mistakes
Putting stateful databases on Spot VMs. Preemption causes outages and data risk. Use standard VMs and CUDs.
Overcommitting on CUDs. Unused commitments still cost money. Cover peaks with on-demand or Spot.
Oversized GKE requests on Autopilot. You pay for what you request, not what you use. Right-size requests.
Check yourself
Why are Spot VMs a poor choice for a single database server?
They can be preempted at any time with little notice and have no availability guarantee, so the database would go down unexpectedly.
When do sustained use discounts apply?
Automatically, when eligible machine types run for a large part of the billing month, without any commitment.
What does Autopilot charge for in GKE?
The CPU, memory and storage that pods request, so oversized requests directly increase cost.
Topic 2 of 2 in Optimizing performance and cost
Test yourself on Optimizing performance and cost
The full Google Cloud Professional Cloud DevOps Engineer question bank has 751 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.