Overview and What You Will Learn
In this lab, you will create a Spot VM for a batch workload and observe its discounted pricing and interruption behavior, then create a custom machine type sized to a workload's actual needs rather than the nearest predefined size.
Why This Matters in Production
A team runs a nightly batch processing job on a standard predefined machine type that's noticeably larger than the job actually needs, simply because it was the closest predefined size available. A custom machine type sized to the job's real CPU and memory requirements, combined with Spot pricing for this genuinely interruption-tolerant workload, meaningfully reduces the cost of a job that runs every single night indefinitely.
Core Principles
Spot VMs and custom machine types solve two different cost problems and should not be confused with each other.
+------------------------------------------+| Spot VMs || For: fault-tolerant batch or stateless || workloads that can handle interruption || Effect: steep discount, but Google can || reclaim the VM with short notice |+------------------------------------------+| Custom Machine Types || For: any workload whose actual needs fall || between two predefined sizes || Effect: pay for exactly the vCPU/memory || combination needed, no more |+------------------------------------------+Spot VMs are appropriate specifically for workloads that can tolerate being interrupted and restarted elsewhere - never for anything customer-facing that needs to be reliably available. Custom machine types are appropriate whenever a workload's real requirements don't cleanly match a predefined size, regardless of whether that workload is fault-tolerant or not.
Detailed Step-by-Step Practical Lab
- Create a project and enable Compute Engine:
gcloud projects create gcp-cost-lab-2026 --name="Compute Cost Lab"gcloud config set project gcp-cost-lab-2026gcloud services enable compute.googleapis.com- Create a Spot VM for a batch-processing workload:
gcloud compute instances create vm-batch-spot \ --zone=asia-south1-a \ --machine-type=e2-standard-4 \ --image-family=debian-12 \ --image-project=debian-cloud \ --provisioning-model=SPOT \ --instance-termination-action=STOPNote
--instance-termination-action=STOPmeans an evicted Spot VM is stopped rather than deleted, preserving its disk and configuration so it can be restarted later - similar in spirit to Azure's DeleteOnTermination-equivalent choice or AWS Spot's stop-vs-terminate interruption behavior.
- Confirm the VM was created with the expected Spot pricing model:
gcloud compute instances describe vm-batch-spot \ --zone=asia-south1-a \ --format="value(scheduling.provisioningModel)"- Create a custom machine type sized to a specific, real workload need - here, 6 vCPUs and 20GB memory, a combination that falls between two standard predefined sizes:
gcloud compute instances create vm-custom-shape \ --zone=asia-south1-a \ --custom-cpu=6 \ --custom-memory=20GB \ --image-family=debian-12 \ --image-project=debian-cloud- Compare the custom machine type's actual specification against the nearest predefined alternatives:
gcloud compute instances describe vm-custom-shape \ --zone=asia-south1-a \ --format="value(machineType)" gcloud compute machine-types list \ --filter="zone:asia-south1-a AND name~'e2-standard'" \ --format="table(name,guestCpus,memoryMb)"- Check current Recommender suggestions for any existing VMs that might be over-provisioned:
gcloud recommender recommendations list \ --project=gcp-cost-lab-2026 \ --location=asia-south1-a \ --recommender=google.compute.instance.MachineTypeRecommender- Clean up:
gcloud compute instances delete vm-batch-spot vm-custom-shape \ --zone=asia-south1-a --quietgcloud projects delete gcp-cost-lab-2026 --quietProduction Best Practices & Common Pitfalls
Common MistakeUsing a Spot VM for a customer-facing or otherwise critical workload to save money, then experiencing an unexpected outage when Google reclaims the capacity with only a short notice period. Spot pricing is a genuine discount, but it comes with a real availability trade-off that only fits fault-tolerant, interruption-tolerant workloads.
TipCheck Recommender's machine type suggestions periodically for existing VMs - it analyzes actual historical CPU and memory utilization and suggests a better-fitting predefined or custom machine type, often surfacing meaningful savings on VMs that were sized as a rough guess at launch time and never revisited.
- Custom machine types are billed based on the specific vCPU and memory configuration chosen, not rounded up to the nearest predefined size - this is what makes them genuinely cost-effective for a workload whose real needs fall between two standard offerings.
- Combining Spot pricing with a custom machine type stacks both savings for a workload that is both fault-tolerant and has non-standard resource needs - a batch job with unusual memory requirements is a strong candidate for both optimizations simultaneously.
Quick Reference & Troubleshooting Commands
| Command | Description |
|---|---|
gcloud compute instances create --provisioning-model=SPOT |
Create a Spot VM |
gcloud compute instances create --custom-cpu= --custom-memory= |
Create a custom machine type VM |
gcloud compute machine-types list |
List available predefined machine types |
gcloud recommender recommendations list |
Check machine type rightsizing suggestions |