Sole-Tenant Nodes for Compliance

Sole-tenant nodes are physical Compute Engine servers that are dedicated to hosting only your project's VM instances. Unlike regular multi-tenant environments where VMs from different customers may share the same physical server, a sole-tenant node ensures that no other customer's VMs run on that hardware. This provides a hard physical isolation boundary, which is often required for compliance with regulations such as HIPAA (Health Insurance Portability and Accountability Act), PCI DSS (Payment Card Industry Data Security Standard), or internal corporate policies that mandate dedicated hardware.

Google Cloud's default architecture uses multi-tenancy for efficiency. A single physical server can host dozens of VMs from multiple customers, with hypervisor-enforced isolation. However, some customers have regulatory or contractual requirements that demand strict physical separation. For example, a healthcare company processing protected health information (PHI) may need to demonstrate that PHI never resides on a server shared with other organizations. Similarly, companies with per-core licensing agreements (e.g., Microsoft SQL Server or Windows Server) may benefit from dedicating physical cores to their own workloads to avoid licensing complications. Sole-tenant nodes address these needs while still leveraging Google's infrastructure.

A sole-tenant node is a physical server in a Google Cloud data center. When you create a sole-tenant node, you specify the node type, which determines the hardware configuration (e.g., number of vCPUs, amount of memory, local SSD capacity). The node is then provisioned and dedicated to your project. You can then create VM instances on that node, just as you would on a regular host, but with the guarantee that no other project's VMs will be placed on that physical server.

Key internal mechanisms: - Node Affinity: VM instances are bound to a specific sole-tenant node using node affinity labels. You define a node group (a collection of identical sole-tenant nodes) and set affinity rules on your VMs to be scheduled only on nodes in that group. - Resource Allocation: When you create a VM on a sole-tenant node, the node's available vCPUs and memory are consumed. You cannot overcommit resources; the sum of all VM vCPU and memory requests must fit within the node's capacity. - Maintenance Events: Google Cloud may perform maintenance on sole-tenant nodes, such as kernel updates or hardware repairs. You can control how these events affect your VMs using maintenance policies (e.g., live migration or terminate). However, for sole-tenant nodes, live migration may not always be available during certain types of maintenance; you should plan for node-level events. - Node Types and Pricing: Each node type has a specific number of vCPUs and amount of memory. For example, n1-node-96-624 provides 96 vCPUs and 624 GB of memory. Pricing is per node per hour, regardless of how many VMs you run on it (as long as they fit). This can be cost-effective for high-density workloads.

- Node Types: Google Cloud offers several node families, including n1, n2, n2d, and c2 (compute-optimized). Each family has predefined node types with specific vCPU and memory ratios. For example: - n1-node-96-624: 96 vCPUs, 624 GB memory - n2-node-80-640: 80 vCPUs, 640 GB memory - c2-node-60-240: 60 vCPUs, 240 GB memory (compute-optimized) - Node Groups: A node group is a collection of sole-tenant nodes of the same type. You create a node group and then add nodes to it. Node groups can span zones within a region but not across regions. - Node Affinity Labels: You create a node affinity label on a node group (e.g., sole-tenant-node-group=my-group). Then, when creating VMs, you specify a node affinity rule that requires the VM to be scheduled on a node with that label. The rule can be REQUIRE (must be on that node group) or PREFER (prefer that node group but allow others). For sole-tenant isolation, you use REQUIRE. - Quotas: Sole-tenant nodes consume a separate quota, SOLE_TENANT_NODES_PER_ZONE, which defaults to 0. You must request an increase via the Google Cloud Console. - Maintenance Policy: You can set ON_HOST_MAINTENANCE to MIGRATE (default) or TERMINATE. For sole-tenant nodes, MIGRATE may not be available during certain host maintenance events; you should test your workloads with TERMINATE to ensure uptime requirements are met.

To create a sole-tenant node group and node, you can use the gcloud command-line tool:

# Create a node group in us-central1-a
gcloud compute sole-tenant node-groups create my-node-group \
    --node-template my-node-template \
    --zone us-central1-a \
    --target-size 1

# Create a node template
gcloud compute sole-tenant node-templates create my-node-template \
    --node-type n1-node-96-624 \
    --region us-central1

# Create a VM that uses the node group
gcloud compute instances create my-vm \
    --zone us-central1-a \
    --node-group my-node-group

To verify that a VM is running on a sole-tenant node:

gcloud compute instances describe my-vm --zone us-central1-a

Look for the soleTenantNode field in the output. It will show the node name and node group.

A large hospital chain runs its electronic health record (EHR) system on Google Cloud. The system processes protected health information (PHI) and must comply with HIPAA. The hospital's compliance officer requires that PHI never resides on a physical server shared with other customers. The solution is to deploy the EHR VMs on sole-tenant nodes. The architecture includes a node group of n1-node-96-624 nodes in us-central1-a and us-central1-b for high availability. Each node hosts multiple VMs (e.g., web servers, database servers) that all belong to the hospital's project. The node affinity labels ensure that no VM from any other project can be scheduled on these nodes. During a compliance audit, the hospital can provide Google Cloud documentation and gcloud output showing that the VMs are on dedicated nodes. A common misconfiguration is forgetting to set the node affinity rule to REQUIRE — if PREFER is used, the VM could be scheduled on a multi-tenant host during maintenance events, violating compliance. The hospital also uses Shielded VMs and encryption at rest to meet additional HIPAA requirements.

A financial services company uses Microsoft SQL Server with per-core licensing. To avoid paying for cores on a shared host that may run other workloads, they want to ensure that the SQL Server VMs run on dedicated physical cores. They deploy sole-tenant nodes of type n2-node-80-640 and create VMs for SQL Server. The company can then count only the cores on the sole-tenant node for licensing purposes, as no other customer uses those cores. A common pitfall is over-provisioning: if the node has 80 vCPUs but only 40 are used by SQL Server, the company may still need to license all 80 cores depending on the license agreement. They should carefully plan VM density. They also set maintenance policy to TERMINATE to avoid live migration issues, as SQL Server may not support migration seamlessly. They use a regional managed instance group with node affinity to automatically restart VMs on another node in the group if one fails.

A government contractor processes classified data that requires physical isolation. They use sole-tenant nodes with Confidential VMs (AMD SEV) to encrypt memory in use. The node group is created in a specific zone with limited access via VPC Service Controls. The contractor uses gcloud scripts to automate node creation and VM deployment. A common issue is quota: the default sole-tenant node quota is 0, so they must request an increase via the console before deployment. They also set up monitoring to track node utilization and alert if any VM is not on a sole-tenant node (e.g., due to misconfigured affinity).