Special VM types
Beyond a standard VM, Compute Engine offers special configurations that trade off cost (Spot / preemptible), physical isolation (sole-tenant), and security (shielded, confidential). For how Spot / preemptible are billed against SUD/CUD see Pricing & discounts; everything else - the provisioning-model mechanics and the three isolation / security types - is here.
Preemptible & Spot VMs
Preemptible is the original interruptible model; Spot is its successor. Both share the same deep discount and both can be reclaimed by Compute Engine at any time, but they differ on runtime cap and availability behavior.
| Preemptible VM | Spot VM | |
|---|---|---|
| Discount | 60% - 91% off | 60% - 91% off (same pricing model) |
| Max runtime | 24 hours | No maximum runtime |
| Preemption notice | 30-second warning (not guaranteed) | 30-second warning (not guaranteed) |
| Live migrate / auto restart | Neither | Neither |
| Availability | Best-effort | Finite resource - may be unavailable |
Interruptible VMs carry no SLA. Preemptibility is set at VM creation and cannot be changed - you can't convert an existing VM to or from Spot/preemptible.
- Discount is 60% to 91% off the standard price.
- No charge if the VM is preempted within the first minute.
- Runs for up to 24 hours, then is preempted regardless.
- You get a 30-second shutdown notification (enough time for a short shutdown script).
Preemptible and Spot VMs never live-migrate and never auto-restart on a maintenance event. To keep an interruptible workload running, attach monitoring + a load balancer (or a MIG) that starts up new instances when one is preempted. There is no built-in restart.
Spot VMs are carved from excess and backup Google Cloud capacity, so they are not always available. Capacity is generally easier to get for smaller machine types (fewer vCPUs and less memory). Size down if you keep failing to get Spot capacity.
The classic fit is batch processing: if some instances are preempted mid-job the work slows but does not stop, and you finish the batch without paying full price for extra normal instances. Avoid for anything stateful or latency-critical.
If the workload can't tolerate sudden termination (databases, long single-run jobs without checkpointing), Spot is the WRONG answer. Combine Spot with MIGs + checkpointing for batch.
- By default, preemptible VMs count against your regional CPU quota just like normal VMs.
- You can request a separate quota so a region's CPU quota is split between regular and preemptible usage.
Sole-tenant nodes
A sole-tenant node is a physical Compute Engine server dedicated to hosting VM instances for one project only. On a normal host your VMs share hardware with other customers' VMs; on a sole-tenant node the entire physical machine is yours.
Reach for sole-tenant when a workload (for example, payment processing) must be physically separated from instances in other projects to meet compliance requirements, or when you want to group your instances together on the same host hardware.
- The whole physical server hosts only your project's VMs.
- You can pack it with multiple smaller VMs of varying sizes, including custom machine types and instances with extended memory.
- Bring your own license (BYOL): carry existing per-core OS licenses to Compute Engine, and the in-place restart feature minimizes physical core usage.
Shielded VMs
Shielded VMs provide verifiable integrity so you can be confident the instance hasn't been compromised by boot- or kernel-level malware or rootkits. They are the first offering in Google's Shielded Cloud Initiative.
- Secure Boot - only signed, verified boot software runs.
- vTPM-enabled Measured Boot - a virtual Trusted Platform Module records boot measurements.
- Integrity monitoring - alerts on changes to the boot measurement baseline.
The shielded features only work if you select a shielded image when creating the VM. Images are covered in Disks & images.
Confidential VMs
Confidential VMs let you encrypt data in use - that is, while it is being processed in memory, not just at rest or in transit. Deployment needs no code changes and does not compromise performance.
- It is an N2D Compute Engine instance running on 2nd-generation AMD EPYC processors (code-named "Rome").
- Uses AMD SEV (Secure Encrypted Virtualization) for inline memory encryption.
- Best for high-memory, high-throughput, parallel / compute-heavy enterprise workloads.
The encryption keys are managed in hardware and Google does not have access to them, so your sensitive code and data stay encrypted in memory during processing. Enable it at creation via the Console, the Compute Engine API, or gcloud.