4.2 Spot VMs, Custom Machine Types & Cost-Optimized Compute Planning
Key Takeaways
- Spot VMs offer a variable discount of at least 60% and up to 91% off on-demand pricing, but Google can preempt them at any time with short notice.
- Spot VMs fit fault-tolerant, restartable, stateless batch work (transcoding, CI/CD, big data); never workloads needing guaranteed uptime or an SLA.
- Custom machine types let you specify exact vCPU and memory instead of a predefined bundle, available on E2, N1, N2, N2D, and newer N-series families.
- Extended memory removes the standard ~8 GB-per-vCPU ceiling for N1/N2/N2D/newer N-series custom types, but is not available on E2 or G2.
- Resource-based committed use discounts reach roughly 37% (1-year) to 55% (3-year) and suit predictable, steady-state baseline workloads instead of variable ones.
Why This Section Matters
The official exam guide's second bullet under "Planning and configuring a cloud solution" specifically calls out Spot VM instances and custom machine types. Google Cloud rewards candidates who can reason about cost the same way it rewards candidates who can reason about architecture — the ACE exam is a cost-conscious exam, and this section is where that shows up most directly. Expect scenarios that describe a workload's fault tolerance, duration, and resource shape, and ask you to pick the pricing model and machine configuration that minimizes spend without breaking the requirement.
Machine Families: The Building Blocks
Every Compute Engine VM is built from a machine family (a hardware/architecture generation) and a machine type (a specific vCPU/memory combination within that family, or a custom combination you define).
| Family | Focus | Typical vCPU/memory ratio | Good for |
|---|---|---|---|
| E2 | Lowest cost, general purpose | Up to 8 GB RAM per vCPU | Web servers, dev/test, small databases |
| N2 / N2D | Balanced general purpose (Intel / AMD) | Up to 8 GB RAM per vCPU | Business apps needing more sustained throughput than E2 |
| C3 / C3D | Compute-optimized | 2, 4, or 8 GB RAM per vCPU | HPC, gaming, ad serving, latency-sensitive workloads |
| M2 / M3 | Memory-optimized | Very high RAM per vCPU | In-memory databases (SAP HANA) |
| A2 / A3 | Accelerator-optimized | GPU-attached | ML training/inference |
Spot VMs: The Core Cost Lever
Spot VMs are spare Compute Engine capacity offered at a steep, variable discount — at least 60% off, and up to 91% off, the equivalent on-demand price. The catch: Google can preempt (forcibly stop) a Spot VM at any time, typically with a short (roughly 30-second) termination notice, whenever it needs the capacity back or the market price rises. There is no guaranteed minimum runtime.
Preemptible VM instances are the older, functionally similar model (a fixed 24-hour maximum runtime and single flat discount); Spot VMs are the current generation and use the same variable discount range, so on the exam treat "Spot VM" as the modern default answer whenever a scenario simply calls for "the cheapest way to run an interruptible workload."
The rule of thumb the exam expects: Spot VMs are appropriate for fault-tolerant, stateless, restartable batch work — video transcoding, CI/CD build agents, big-data/Spark jobs, rendering — and never for workloads that need continuous availability, hold long-lived state without checkpointing, or serve production user traffic with an SLA.
Custom Machine Types & Extended Memory
A custom machine type lets you specify an exact vCPU count and memory amount instead of choosing a predefined bundle, so you stop paying for RAM or cores your application doesn't use. Custom machine types are available on the E2, N1, N2, N2D, and newer N-series families.
Two rules matter for the exam:
- Standard limit: most families allow roughly 0.5 GB to 8 GB of memory per vCPU, and memory must be specified in increments of 256 MB.
- Extended memory: for workloads needing more RAM per vCPU than the standard ratio allows (a memory-heavy Java service that only needs 2 vCPUs but 20 GB of RAM, for example), N1, N2, N2D, and newer N-series machine types support extended memory at an additional per-GB cost, removing the per-vCPU ceiling. E2 and G2 custom machine types do not support extended memory.
Other Cost-Optimization Levers
| Mechanism | How it works | Best for |
|---|---|---|
| Sustained use discounts | Automatic discount that grows the longer a VM runs within a month, applied without any commitment | Workloads with unpredictable but recurring usage |
| Committed use discounts (CUDs) | You commit to 1 or 3 years of spend/resource usage in exchange for a discount (roughly 37% at 1 year, up to 55% at 3 years for resource-based CUDs) | Steady-state, predictable baseline workloads |
| Spot VMs | Variable 60-91% discount, preemptible | Fault-tolerant batch/interruptible work |
| Custom machine types | Pay only for the exact vCPU/memory you need | Any workload whose ratio doesn't match a predefined type |
Realistic Exam Scenario
A media company runs a nightly batch job that transcodes thousands of video files. Each job can be safely restarted from a checkpoint if interrupted, and the job has no fixed deadline within the night's processing window. The most cost-effective infrastructure choice is a managed instance group of Spot VMs — the workload is fault-tolerant and stateless-enough to tolerate preemption, so it can capture up to 91% savings versus on-demand pricing.
Now contrast: an application requires 4 vCPUs but a full 64 GB of memory — a ratio no E2 predefined type offers. The answer here is a custom machine type with extended memory (assuming a family like N2), letting the team provision exactly the memory needed rather than over-provisioning with a larger predefined type.
Common Traps
- Recommending Spot VMs for anything described as "production," "customer-facing," or "must not be interrupted." If the scenario has an availability requirement, Spot VMs are wrong regardless of the cost savings mentioned.
- Confusing preemptible VMs (legacy, 24-hour cap) with Spot VMs (current, no fixed cap, same discount range) — the exam may reference either name, so know both point to the same underlying trade-off.
- Forgetting that extended memory is unavailable on E2 and G2 custom machine types — a scenario needing an extreme memory-to-vCPU ratio on a cost-sensitive E2 workload cannot be solved with extended memory; you would need to move to an N-series family or a memory-optimized machine family instead.
A data science team runs a distributed Spark job that checkpoints progress every few minutes and can resume from the last checkpoint if a worker node disappears. The job has no strict completion deadline. Which Compute Engine pricing model minimizes cost for the worker nodes?
An application on the E2 machine family needs only 2 vCPUs but requires 32 GB of memory, well above the standard per-vCPU memory ceiling for E2. What should the team do?