GCP’s sole-tenant nodes let you run your workloads in a dedicated physical server, offering a level of isolation that’s often misunderstood as just "bare metal."
Let’s see what that looks like in practice. Imagine you’ve got a critical application that needs strict data residency or compliance guarantees, and you’ve decided sole-tenant nodes are the way to go. You’d start by creating a sole-tenant node template, specifying the machine type and the sole-tenant node group.
Here’s a snippet of what that might look like in gcloud:
gcloud compute sole-tenancy node-templates create my-sole-tenant-template \
--region=us-central1 \
--node-type=n2-standard-4 \
--node-count=1
Once the template is in place, you create a node group from it:
gcloud compute sole-tenancy node-groups create my-sole-tenant-group \
--region=us-central1 \
--node-template=my-sole-tenant-template \
--target-node-count=1
Now, when you create a Compute Engine instance, you must associate it with this node group. This is the crucial step that pins your VM to a specific physical server.
gcloud compute instances create my-isolated-vm \
--zone=us-central1-a \
--machine-type=n2-standard-4 \
--node-group=my-sole-tenant-group \
--nodeAffinity=node-group=my-sole-tenant-group
The nodeAffinity flag here isn’t just a suggestion; it’s a directive. It tells the GCP scheduler to place this VM only on a node within my-sole-tenant-group. Because this is a sole-tenant group, that means a dedicated physical server.
The core problem sole-tenant nodes solve is noisy neighbors and resource contention, but more importantly, it addresses regulatory and security requirements that mandate physical isolation. Think HIPAA, PCI DSS, or even just internal security policies that forbid shared physical infrastructure for sensitive workloads. When you provision a sole-tenant node, GCP carves out a physical server exclusively for your use. No other customer’s workloads will ever run on that hardware. This eliminates the possibility of side-channel attacks that exploit shared CPU caches or memory, and it guarantees a consistent performance baseline because you’re not competing for the underlying physical resources.
The mental model here is simple: you’re renting a physical server in GCP’s data center. You get to choose the hardware configuration (machine type), and GCP manages the lifecycle of that physical server, including patching and hardware maintenance. Your VMs are then scheduled onto this specific physical server. This is distinct from preemptible VMs or general-purpose VMs, where your workload could be placed on any available slice of hardware, potentially sharing it with other customers.
The key levers you control are the node template (defining the hardware characteristics like CPU, memory, and GPU type) and the node group (managing the quantity and placement of these dedicated nodes). You can scale the node group up or down based on your workload’s needs, and GCP automatically handles provisioning and de-provisioning the physical servers. You can also define "affinity" and "anti-affinity" rules at the VM level to control how multiple sole-tenant VMs are placed relative to each other on the same physical server or across different physical servers within the same node group.
Most people understand that sole-tenant nodes mean dedicated hardware. What they often miss is the granular control over how your VMs interact with that dedicated hardware. You can specify that a particular VM instance must run on a sole-tenant node group (node affinity), or conversely, that it must not run on a specific node group (node anti-affinity). This allows for complex scheduling strategies where you might want to ensure that two highly sensitive VMs never end up on the same physical server, even though they are both running on sole-tenant nodes. The nodeAffinity and nodeAntiAffinity fields in the instance’s metadata allow you to define these rules with specific node group names or even labels you assign to your node groups.
The next step after mastering sole-tenant node placement is understanding how to manage node affinity and anti-affinity rules for multiple VMs within a single node group.