A sole-tenant node is a physical Compute Engine server dedicated to the virtual machines of a single project, or of the projects you choose to share it with.

Normally, Compute Engine is multi-tenant. That means many customers’ virtual machines run side by side on the same physical server, separated by strong software isolation. This is efficient and cheap, and for most workloads it is completely sufficient. But some organizations have needs that sharing cannot meet. They may have software licenses tied to physical servers, compliance rules that demand physical separation from other customers, or performance requirements that cannot tolerate any outside activity on the same hardware.

Sole-tenant nodes solve these problems. When you create one, Google sets aside an entire physical host in a zone for you. Only your virtual machines, the ones you choose to place there, run on it. You still use the normal Compute Engine tools, the same images, disks, networks, and APIs. The difference lies underneath: the hardware is yours alone.

The three reasons people choose it

The first reason is licensing. Some commercial software is licensed by physical cores or physical sockets rather than by virtual machine. To use such licenses honestly and cheaply, you need to know and control exactly which physical server your workload runs on. The second reason is compliance and security isolation. Some regulations, contracts, or internal policies require that regulated workloads not share hardware with other customers. The third reason is performance isolation. Even well-managed shared hosts can occasionally show a noisy neighbor effect, where another tenant’s heavy activity affects your latency. With dedicated hardware, that effect from outside tenants disappears.

Sole-tenancy has a compact vocabulary, and every later chapter assumes you know these terms.

Each concept below is explained by what it is, why it exists, and where you will meet it. Take a moment with each card, because confusing two of them is the most common source of design mistakes.

Node versus virtual machine

A node is not a virtual machine. You cannot log into a node, install software on it, or run programs directly on it. A node is a container for VMs: a slice of physical hardware with a capacity limit. Your virtual machines are what run your applications, and they occupy a portion of the node’s capacity.

The design is simple: a template creates a group, the group holds nodes, and VMs are matched to nodes by rules.

The architecture has three layers. At the bottom are the physical servers, which Google owns and operates in its data centers. In the middle is the grouping layer, made of templates and node groups, which you configure. At the top are your virtual machines, which carry scheduling rules that decide whether they land on shared hosts or dedicated nodes.

flowchart TD
  T["Node Template: type, labels, policies"] --> G["Node Group in one zone"]
  G --> N1["Node 1 physical server"]
  G --> N2["Node 2 physical server"]
  G --> N3["Node 3 physical server"]
  V1["VM with node affinity rule"] --> N1
  V2["VM with node affinity rule"] --> N1
  V3["VM with node affinity rule"] --> N2
  V4["VM with node affinity rule"] --> N3
  P["Project and Organization"] -.owns or shares.-> G
        

Everything is zonal

A node group lives in a single zone. Physical servers cannot span zones, so neither can a group. This has a direct consequence for resilience: if you want to survive the loss of a zone, you need node groups in more than one zone, with copies of your workload in each.

What stays the same as normal Compute Engine

Everything outside placement works as usual. VMs on sole-tenant nodes attach persistent disks, join your Virtual Private Cloud networks, use the same firewall rules and routes, sit behind the same load balancers, and use the same images. This means moving a workload onto dedicated hardware usually requires no change to the application at all.

Creating a node does not move any VM onto it. A VM lands on a node only when its affinity rules say so.

This is the idea beginners miss most often. If you create a node group and then create an ordinary VM, that VM goes to a shared host as always. The node group sits empty and you pay for it. To use dedicated nodes, each VM must carry a node affinity rule that points at them.

Labels and the two rule types

Every node carries labels. Some are applied automatically, including labels that identify the node group name and the individual node name. You can add your own through the node template, for example a label that marks a pool as holding a particular licensed database. A VM’s affinity rule then states either that it must run on nodes with a given label, or that it must not run on nodes with a given label. The first style is used to pin workloads to dedicated hardware. The second style is used to keep a workload away from certain nodes.

sequenceDiagram
  participant U as Operator
  participant API as Compute Engine API
  participant S as Scheduler
  participant N as Node Group
  U->>API: Create VM with node affinity label
  API->>S: Find nodes matching the label
  S->>N: Check free vCPU and memory
  alt A matching node has room
    N-->>S: Capacity available
    S-->>API: VM placed on that node
  else No node has room
    S-->>API: Placement fails or autoscaler adds a node
  end
  API-->>U: VM running or error returned
        

What the scheduler considers

Designing a label strategy

Labels are cheap and powerful, so plan them. A good scheme separates pools by purpose, environment, or license. For instance, one label might identify production database nodes, another might identify nodes holding a specific licensed product. Because VMs pick nodes by label, a clean scheme lets you grow a pool by adding nodes without touching any VM definitions.

The node type decides what hardware you rent, so it is the first and most expensive choice you make.

Node types are named by their family, vCPU count, and memory in gigabytes. For example, a name that reads as the N1 family with ninety-six vCPUs and six hundred twenty-four gigabytes of memory describes the whole server, not one VM. Google offers node types across several general-purpose, compute-optimized, and memory-optimized processor families, and the list changes over time. Always confirm which node types exist in your target zone, because availability differs by zone.

Match the family to the workload

Why VM shape matters as much as node shape

A node is a fixed pool. Imagine a node with ninety-six vCPUs. If your VMs each need sixty-four vCPUs, only one fits on that node and thirty-two vCPUs are stranded, because no second VM can use the leftover. If your VMs need thirty-two vCPUs each, three fit perfectly with nothing wasted. This is the bin packing problem, and choosing VM sizes that divide evenly into the node size is one of the best ways to control cost.

Templates define what a node is. Groups define how many you have and how they grow.

The node template

A node template records the choices that should be uniform across a pool: the node type, the affinity labels, and certain policies. Because the template is a separate object, you can reuse it to create many groups, in many zones, with identical properties. Templates cannot be edited after creation. If you need different properties, you create a new template and a new group. This keeps pools predictable and auditable.

The node group

The node group is where you decide size. You can set a fixed number of nodes, or you can let the group scale. You can also choose which projects may use the group, and you set the maintenance policy and, where relevant, the maintenance window at the group level.

Autoscaling modes

When autoscaling is enabled, you set a minimum and a maximum number of nodes. The maximum is an important safety valve because every node costs money whether or not VMs are on it. Autoscaling reacts to placement demand, meaning it adds a node when a new VM cannot fit anywhere, not to CPU usage inside the VMs. It also removes nodes only when they hold no VMs, so scale-in depends on how your VMs are spread across nodes.

flowchart LR
  A["New VM requested with node affinity"] --> B{"Room on existing node?"}
  B -- Yes --> C["Place VM on that node"]
  B -- No --> D{"Autoscaling allows growth?"}
  D -- Yes --> E["Add a node up to the maximum"]
  E --> C
  D -- No --> F["Request fails with no capacity"]
  C --> G{"Node later empty?"}
  G -- Yes --> H["Scale in if mode allows removal"]
        

Physical servers need updates, and your maintenance policy decides how your VMs experience them.

Google periodically performs maintenance on host machines. On shared hosts, VMs are usually live migrated, meaning moved to another host while still running, with only a brief pause. With sole-tenant nodes you have a choice, because moving a VM to a different physical server can break a licensing or isolation promise. Three policies exist, and picking the right one is a core design decision.

Choosing between them

Why spare capacity matters

For a policy that moves VMs inside the group, there must be room to move them into. If every node is full, maintenance has nowhere to send the VMs. Plan a buffer, such as an extra node, so that taking one node out of service for maintenance still leaves enough room for its VMs elsewhere. Also check the current documentation for how autoscaling and maintenance windows interact with each policy before combining them.

Licensing is the most common business reason to adopt sole-tenant nodes, and it is easy to misunderstand.

Some enterprise software, including certain operating systems, databases, and middleware, is licensed by counting physical cores or physical processors rather than by counting virtual machines. If you run such software on shared hosts in a public cloud, you may be unable to prove which physical server it ran on, and some license terms simply do not allow it. If you already own licenses, you may want to bring them to the cloud instead of buying new ones.

How sole-tenancy helps

On a sole-tenant node, the physical server is dedicated and identifiable. You know how many physical cores the node has, and you know all the VMs running on it are yours. That allows many organizations to count licenses against the dedicated server instead of against each virtual machine. Where license rules also care about the processor type, the node type tells you the processor family, and Google provides visibility into hardware details that support license audits. Because the details of these tools evolve, confirm the current options in the official documentation.

Fixed pools versus growing pools

For per-server licensing, a fixed-size group with a stable maintenance policy is easiest to defend. Every new node is a new physical server and may need an additional license. Plan growth as a deliberate licensing decision rather than an automatic reaction to load.

Dedicated hardware removes some risks and some uncertainties, but it is not a complete security solution.

Compliance drivers

Some regulations, customer contracts, or internal risk policies state that sensitive workloads must not share physical hardware with workloads from other organizations. Sole-tenant nodes let you satisfy that specific requirement. The requirement is often written into financial, healthcare, government, and defense-related frameworks or into contracts with large customers. Note that sole-tenancy meets the physical separation clause only; frameworks have many other requirements, such as access control, encryption, and audit, which you must handle separately.

Security isolation

Shared hosts are well isolated by the hypervisor, and Google invests heavily in that boundary. Still, some organizations want a stronger story: the only workloads that share the hardware are their own. This reduces the exposure to a class of risks known as side-channel attacks, where one tenant tries to learn information about another by observing shared hardware behavior. Dedicated hardware removes outside tenants from that picture, although your own VMs on the same node still share it with each other.

Performance isolation

Latency-sensitive systems, such as trading platforms, real-time bidding engines, and gaming back ends, may dislike any variation in performance. With outside tenants gone, the main sources of variation left are your own workloads. You can then control contention by deciding how many VMs share each node, leaving headroom, and separating heavy workloads from sensitive ones.

Combining with other protections

Sole-tenancy works alongside, not instead of, other controls. Encryption, Shielded VMs, careful identity design, private networking, and organization policies all remain essential. Where regulations require customer-managed encryption keys or confidential computing, check compatibility between those features and your chosen node type before committing to a design.

A pleasant surprise: almost nothing about the surrounding architecture changes when you adopt sole-tenancy.

VMs on sole-tenant nodes belong to normal subnets in your Virtual Private Cloud. They receive internal addresses, can have external addresses, obey the same firewall rules, and can be targets of the same load balancers and managed instance groups. This means existing network designs, security tooling, and monitoring continue to work.

Storage behavior

Persistent disks are network-attached and independent of the node. If a VM moves to another node, its disks follow it without data loss. Local disks, where supported by the node type, live on the physical server and have different durability behavior, so treat them as temporary scratch space unless you have a clear plan. Image sources, snapshots, and backups work as in standard Compute Engine.

Managed instance groups and containers

Instance templates can include node affinity, so a managed instance group can create and heal VMs directly onto your dedicated nodes. Google Kubernetes Engine can also place node pools on sole-tenant nodes, so a whole container platform can run on dedicated hardware. In both cases, the affinity rule is the bridge between the workload and the dedicated pool.

flowchart LR
  U["Users"] --> LB["Load Balancer"]
  LB --> MIG["Managed Instance Group with node affinity"]
  MIG --> NG["Sole-Tenant Node Group"]
  NG --> PD["Persistent Disks"]
  NG --> VPC["VPC Subnet and Firewall Rules"]
  VPC --> DB["Private Services and Databases"]
        

Dedicated capacity is expensive, so governance is as important as technology.

Who may create nodes

Creating templates and groups requires specific permissions on Compute Engine resources. Because a node group represents a recurring cost, organizations commonly restrict these permissions to a small platform or infrastructure team, while allowing application teams to create VMs that target approved pools. This separates the people who buy capacity from the people who use it.

Sharing a node group across projects

By default a node group serves only the project that owns it. Sharing settings let the owner allow other projects to place VMs on the group. You can share with specific projects or across the organization, depending on the setting. Sharing is powerful because it lets many teams fill the same nodes, which raises utilization and lowers cost per team. It also needs clear rules about who pays, who sets priorities, and who can see what.

Chargeback and visibility

When several teams share nodes, cost allocation becomes a question. The node cost lands on the owning project, while VM usage belongs to the teams. Use labels on VMs and billing exports to estimate each team’s share of node usage, and agree on a chargeback rule such as a share proportional to vCPU hours consumed.

Policy guardrails

Organization policies and approval processes can prevent accidental creation of expensive node groups. Combine these with budget alerts so unexpected growth is noticed quickly. Audit logs record who created or resized node groups and which VMs were placed on them, which supports both security review and licensing evidence.

You pay for the node, not for the VMs, and that changes how you think about efficiency.

On shared hosts, you pay for the vCPUs and memory of each VM while it runs. On sole-tenant nodes, you pay for all the vCPUs and memory of the node for as long as the node exists, regardless of how many VMs run on it or whether any run at all. Google also applies a sole-tenancy premium on top of the node’s normal price, and it has historically been around ten percent. VMs placed on the node carry no separate compute charge. Discounts such as sustained use and committed use arrangements can apply to node usage. Always check the official pricing page for the current premium and discount rules, since these details can change.

Utilization is everything

If a node is ninety percent filled with VMs, you pay a small amount for the unused tenth. If it is thirty percent filled, you pay for seventy percent of nothing. So the central cost metric is node utilization, the share of node vCPUs and memory actually assigned to VMs. Teams that treat sole-tenancy like shared VMs, spinning up one node per small workload, often discover very low utilization and bills that surprise them.

Practical cost levers

Because nodes are fixed-size, planning capacity is a puzzle worth solving carefully.

Capacity planning for sole-tenant nodes combines three considerations: the size of your VMs, the size of the node, and the buffer you need for maintenance and growth. Doing the arithmetic on paper before ordering nodes is cheap, and mistakes are expensive.

The two-dimensional trap

Each node has both a vCPU limit and a memory limit. A node may run out of memory long before it runs out of vCPUs if your VMs are memory-heavy, and the reverse is true for CPU-heavy VMs. Choose the node type so the ratio of memory to CPU on the node resembles the ratio in your VMs. If your VMs use a lot of memory per vCPU, a memory-optimized node type will pack them much better than a general-purpose one.

Running dedicated nodes well means watching both the nodes and the VMs on them.

Operational visibility has two layers. The node layer answers questions about capacity: how full is each node, which VMs are on it, and is there room for more. The VM layer answers the usual questions about application health. Both are needed because a node can be healthy while a VM on it is struggling, and the reverse.

What to watch

Alerting that helps

Alert when a node group approaches full capacity, because the next VM placement will fail or force autoscaling. Alert on unexpected node count growth, which can signal a runaway deployment. Alert on upcoming maintenance events for pools with strict licensing. Treat these as capacity signals separate from application health signals.

Lifecycle management

Node templates are immutable, so changes mean new templates and new groups. A typical change process creates the new group, moves workloads over using updated affinity, validates, then removes the old group. Because VMs have to be stopped and restarted to change their affinity, plan these moves in maintenance windows and test the process in a lower environment first.

A few well-known patterns solve most sole-tenancy problems, and a few traps repeat across organizations.

Patterns that work well

Anti-patterns to avoid

Dedicated hardware is one option among several, and each answers a different need.

Google Cloud offers multiple ways to get isolation, control, or special hardware. Understanding how they differ prevents you from buying a more expensive option than your requirement needs.

How to choose

Start with the requirement, not the product. If the requirement is protection of data in memory, Confidential VMs may already satisfy it at no hardware dedication cost. If the requirement is boot integrity, Shielded VMs answer it. If the requirement is physical separation or per-server license counting, sole-tenant nodes are the natural fit. If the requirement is raw hardware access, a bare metal offering is the closer match. These can also be combined, so a sole-tenant design may add Shielded VMs for boot protection.

A short checklist separates efficient dedicated pools from expensive, half-empty ones.

Best practices

Common mistakes

Seeing how organizations combine the pieces makes the concepts concrete.

Dedicated hardware does not make a workload more available; design decides that.

A node is a single physical server, and a node group lives in a single zone. If you put a critical workload on one node, its availability depends on that server and zone. Designing for resilience therefore follows the same rules as any distributed system, with extra attention to the fixed nature of node capacity.

The licensing and resilience tension

Resilience wants spare nodes and multiple zones. Per-server licensing wants a small, controlled number of servers. These goals pull against each other, and the balance depends on your license terms. Some licenses allow passive standby servers at reduced cost, while others do not. Involve licensing specialists when designing disaster recovery for licensed pools.

Zonal capacity and quota risk

During a zonal failure, many organizations try to create new capacity in surviving zones at the same moment. Node types and quotas may be limited there. Reserve capacity ahead of time by pre-creating nodes, requesting quota increases early, and testing failover in advance rather than discovering limits during an outage.

flowchart TD
  LB["Global or Regional Load Balancer"] --> ZA["Zone A Node Group"]
  LB --> ZB["Zone B Node Group"]
  ZA --> A1["Replica 1"]
  ZA --> A2["Replica 2"]
  ZB --> B1["Replica 3"]
  ZB --> B2["Replica 4"]
  A1 --> DB["Replicated Data Layer"]
  B1 --> DB
        

A handful of constraints surprise teams, so it pays to know them before design review.

Always confirm the exact current limits in the official documentation, because values and supported features change over time. The themes below are the ones that most often matter in practice.

Overcommit with care

On supported setups, you can allow the VMs on a node to be configured with more total vCPUs than the node physically offers. This can raise utilization when workloads are idle much of the time, because VMs rarely use all their CPUs at once. The risk is contention: if several VMs become busy simultaneously, they compete for the same physical cores. Overcommit suits lightly loaded development or test pools, and it is a poor fit for latency-sensitive or license-counted workloads where the physical core count matters.

Short answers to the questions engineers and architects ask most.

No. A sole-tenant node is a dedicated physical host, but your workloads still run as virtual machines on a hypervisor. Bare metal offerings give direct access to hardware without that virtualization layer for your workload.

No. A VM must carry a node affinity rule that points to your node labels. Without it, the VM runs on shared hosts and the nodes sit empty while still billing.

You pay for the node, meaning all its vCPUs and memory plus a sole-tenancy premium, rather than paying for each VM’s compute separately. Other resources such as disks and network traffic are still billed as usual. Check current pricing for exact details.

No. A node group lives in one zone because a physical server is in one zone. Use separate node groups in different zones for zonal resilience.

Policies that keep VMs on a fixed set of servers, restart in place or migrate within the node group, are the usual choices. The default policy can move VMs to other nodes. Confirm the exact requirement with your licensing owner.

Yes. Share settings let the owning project allow specific projects, or the whole organization, to place VMs on the group. Agree on chargeback rules so cost is fair.

No. It separates you from other customers. VMs of your own that share a node still share that server, so separate trust levels onto different nodes with labels.

Yes. Instance templates can include node affinity, and container platforms can place node pools on dedicated nodes. In both cases, the affinity rule connects the workload to the pool.

It suits variable workloads such as test fleets or game servers. For per-server licensed pools, fixed size is usually safer, because every automatically added node is a new physical server.

Node utilization, the share of each node’s vCPUs and memory assigned to VMs. High utilization turns a premium product into a reasonable one, while low utilization wastes money quickly.

Sole-tenant nodes give you something simple and valuable: a physical Google Cloud server that belongs to your workloads alone. That single fact supports three important use cases. It lets you reuse per-core or per-socket licenses, it provides physical separation required by some regulations and contracts, and it gives predictable performance without outside neighbors. The rest of the platform, networking, disks, images and management tools, stays familiar.

The trade-off is that you now think like a capacity planner. You pay for whole nodes, so fill them. You choose maintenance behavior, so match it to your license and uptime needs. You place VMs with affinity rules, so design labels carefully. Used on purpose, for a clear requirement, sole-tenancy is efficient and defensible. Used casually, it becomes a collection of half-empty and expensive servers.