A sole-tenant node is a physical Compute Engine server reserved for your projects alone.

Starting with the basics

In Google Cloud, a virtual machine, or VM, is a computer that exists as software. It borrows a slice of processing power and memory from a real physical server sitting in a data center. Normally, one physical server holds VMs that belong to many different customers at the same time. This is called multi-tenancy, and a “tenant” simply means a customer renting space. Google keeps the tenants strictly separated using software called a hypervisor, so your neighbors cannot see your data.

A sole-tenant node changes one thing: the neighbors disappear. The physical server hosts VMs from your Google Cloud projects only. Nobody else’s VM is allowed on that hardware. Google describes it as a Compute Engine server dedicated to hosting VMs from only your projects.

Why does it exist?

Most workloads are perfectly happy on shared servers. But some situations are different. A company may have software licenses that are tied to physical processors. A bank may have rules saying that its workloads must not share hardware with other organizations. A game studio may want steady performance with no surprise slowdowns from other customers. Sole-tenant nodes exist to give these teams dedicated hardware while still letting them enjoy the speed and flexibility of the cloud.

What stays the same

Even on a sole-tenant node, you still create ordinary Compute Engine VMs. You still use the same disks, networks, firewall rules, images, and tools. The VMs simply get placed onto a server that nobody else can use. That means most of what you already know about Compute Engine continues to apply, which makes the learning curve gentle.

The two models run the same kind of VM; what changes is who shares the hardware.

flowchart LR
  subgraph MT["Multi-tenant server"]
    A1["Your VM"]
    A2["Customer B VM"]
    A3["Customer C VM"]
    A4["Customer D VM"]
  end
  subgraph ST["Sole-tenant node"]
    B1["Your VM 1"]
    B2["Your VM 2"]
    B3["Your VM 3"]
    B4["Your VM 4"]
  end
        

The diagram shows the heart of the idea. On the left, four different customers share one physical machine. On the right, all four VMs belong to the same owner. The hardware is identical; the guest list is not.

Is it less secure to share?

Not necessarily. Google designs multi-tenant servers with strong isolation, and most organizations, including highly regulated ones, run safely on them. Sole-tenancy adds a different kind of assurance: physical separation. For some rules, contracts, and company policies, that physical separation is a requirement written on paper, and then sole-tenancy becomes the straightforward answer.

Five simple ideas make up the whole sole-tenant model.

If you learn these five terms, you understand most of what the documentation and architecture diagrams will say. We will go through them one by one and then see how they connect.

How the pieces connect

flowchart TD
  NT["Node Template: type, region, labels"] --> NG["Node Group in one zone"]
  NG --> N1["Node 1"]
  NG --> N2["Node 2"]
  NG --> N3["Node 3"]
  N1 --> V1["VM A"]
  N1 --> V2["VM B"]
  N2 --> V3["VM C"]
  N3 --> V4["VM D"]
  L["Affinity labels on VMs"] -.->|"steer placement"| NG
        

The flow is simple. You write the template once. You use it to create a node group in a zone. The group provides nodes. Your VMs land on those nodes, guided by affinity labels. If you later need more capacity, you add nodes to the group without writing a new template.

The node type decides how much room you rent, and the room is rented in one big piece.

What a node type tells you

A node type name usually spells out the processor family and the size of the server. For example, a name such as n1-node-96-624 describes a node from the N1 family with 96 vCPUs and 624 gigabytes of memory. Other families, such as N2, N2D, C2, and the high-memory M families, offer different mixes of processing power and memory, and the exact list changes as Google adds hardware. Not every node type is available in every zone, so you always check what your chosen zone offers before planning.

The jigsaw puzzle of packing VMs

A node is a fixed box. Your VMs are the pieces you fit inside. A node with 96 vCPUs could hold twelve VMs of 8 vCPUs each, or six VMs of 16 vCPUs, or one big VM plus several small ones. The art of sole-tenancy is filling the box well, because you pay for the whole box whether it is full or not. Half-empty nodes are the most common source of wasted money.

Choosing a node type: a short checklist

The workflow is short: describe, create, then place.

Step by step

Why a template at all?

A template is a promise of consistency. Every node in a group is built from the same recipe, so you know exactly what you are getting. If you later want a different size of server, you create a new template and a new group rather than quietly changing the old one. This keeps your environment predictable and easy to audit.

Groups live in a single zone

A node group belongs to one zone. That matches how Compute Engine treats zones everywhere: they are isolated failure areas. If you want your application to survive the loss of a zone, you create node groups in more than one zone and run copies of your VMs in each. A single group in a single zone is a single point of failure for everything on it.

Affinity labels are the steering wheel of sole-tenant placement.

Labels on both sides

Every node carries labels. Some are added automatically, such as the name of its node group and the name of the node itself. You can also add your own labels through the node template, for example a label saying which department owns it or which license type it is used for. Every VM can then say, “I want to run only on nodes that have this label,” or “I never want to run on nodes with that label.”

Real uses of affinity

sequenceDiagram
  participant You
  participant CE as Compute Engine
  participant NG as Node Group
  You->>CE: Create VM with affinity label
  CE->>NG: Look for nodes matching the label
  NG-->>CE: Node with free vCPU and memory
  CE->>NG: Place the VM on that node
  CE-->>You: VM is running on your dedicated node
        

Physical servers need care, and you decide how your VMs behave when it happens.

Why maintenance matters

Every physical server eventually needs software updates, hardware checks, or repairs. On ordinary VMs, Google usually moves your VM to another server with a technique called live migration, so the VM keeps running with only a tiny pause. With sole-tenant nodes, you get to choose how that works, because the hardware is yours and the rules about where your VMs may run can matter a great deal.

Three maintenance policies

Spare capacity is part of the plan

The “migrate within node group” policy only works if there is room for the VMs to move into. That means you must keep some spare capacity in the group, often at least one node’s worth, so that a node under maintenance can empty its VMs onto the others. Planning for this is part of good sole-tenant design, and it is a hidden cost many beginners forget to include in their budget.

Let the group grow when it is full and shrink when it is empty.

The problem it solves

Since you pay for whole nodes, running too many is wasteful and running too few leaves new VMs with nowhere to go. Doing the counting by hand every day is tiring. The node group autoscaler watches the group and adjusts its size for you.

How it behaves

The autoscaler scales out when a VM needs to be placed and no node in the group has room. It adds a node, and the VM is then scheduled without anyone lifting a finger. It scales in when the group has empty nodes, reducing the group so that you stop paying for servers that are sitting idle. You can turn this on when you create the group or add it later, and you set limits for the smallest and largest size the group may reach so that a mistake cannot create a runaway bill.

flowchart TD
  S["New VM needs a node"] --> Q{"Room on an existing node?"}
  Q -->|Yes| P["Place VM on that node"]
  Q -->|No| M{"Group below its maximum size?"}
  M -->|Yes| A["Autoscaler adds a node"]
  A --> P
  M -->|No| F["Placement fails: raise the limit or free capacity"]
  E["Node becomes empty"] --> R{"Group above its minimum size?"}
  R -->|Yes| D["Autoscaler removes the empty node"]
  R -->|No| K["Keep the node"]
        

When to skip autoscaling

If your licenses are tied to specific servers, or your fleet is small and steady, a fixed group size is simpler and more predictable. Autoscaling shines when demand changes often, such as test labs, seasonal sales systems, or batch processing farms.

The most famous reason to choose sole-tenancy is software licensing.

What is a BYOL?

BYOL stands for Bring Your Own License. A company that already owns expensive software licenses, for example for an operating system or a database, wants to keep using them in the cloud rather than buying new ones. Many such licenses are priced by physical processor sockets or physical cores. On a shared server, it is hard to say which physical cores your VM is using, so the vendor may refuse to count it. On a sole-tenant node, the physical server is yours and its core count is known, which helps you show the vendor exactly what you are running.

How sole-tenancy supports licensing

When nobody else is on your server, your speed becomes much more predictable.

The noisy neighbor problem

On a shared server, one customer who suddenly uses a lot of processing power or memory bandwidth can, in theory, slow down others on the same machine. People call this the noisy neighbor problem. Google works hard to keep it small, but some workloads are so sensitive, such as high-frequency trading, real-time game servers, or latency-critical databases, that even a small unpredictable slowdown is unwelcome. On a sole-tenant node, the only noise comes from your own VMs, and you can control that.

Making fuller use of the box

Since you pay for the entire server, you want to use all of it. Some node types support CPU overcommit, a feature that lets you run VMs whose combined vCPU count is higher than the number of physical cores, sharing them among your own VMs. It works because workloads rarely use all of their processors at the same time. It is a good idea for development and test environments and for lightly used VMs, and a bad idea for VMs that are busy all day. Availability and limits vary by node type, so check Google’s current documentation before relying on it.

Physical separation is one layer of protection, never the only one.

Shared responsibility still applies

Google protects the data center, the hardware, and the hypervisor. You protect your operating systems, applications, identities, and network rules. Moving to a sole-tenant node changes who shares the hardware, but it does not change this split. A VM with a weak password is just as exposed on a dedicated node as on a shared one.

Where sole-tenancy helps

The controls you still need

One rented server fleet can serve many teams, which is a very good way to avoid waste.

The idea

Large companies usually have many Google Cloud projects, one for each team or application. If every project rented its own node group, many nodes would sit half empty. Google lets you share a node group so that other projects in your organization can place their VMs on it. The group lives in one parent project, and the other projects use the spare room. According to Google’s documentation, shared node groups cost the same as local ones and use the same quota, and they remain under the parent project.

flowchart TD
  ORG["Organization"] --> PP["Parent project owns the node group"]
  ORG --> P1["Project: Billing app"]
  ORG --> P2["Project: Reporting app"]
  ORG --> P3["Project: Analytics app"]
  PP --> NG["Shared node group"]
  P1 -.->|"places VMs"| NG
  P2 -.->|"places VMs"| NG
  P3 -.->|"places VMs"| NG
        

Benefits and cautions

You pay for the whole box, so using the box well is the main way to save.

How you are billed

For sole-tenant nodes, you pay for all of the vCPUs and memory on the node, whether or not your VMs use them. On top of that, Google adds a sole-tenancy premium of ten percent of the cost of those vCPU and memory resources. Running VMs on the node adds no extra charge of their own. Other resources, such as persistent disks and premium operating system images, are billed at their normal rates. Billing has a one-minute minimum and is then charged per second.

Discounts that can help

Practical ways to keep the bill sensible

With a fixed number of rented servers, knowing how full they are is the key number.

What to watch

Cloud Monitoring and Cloud Logging work with sole-tenant VMs just as they do with ordinary ones. In addition, you want a view at the node level: how much of each node’s CPU and memory is actually allocated to VMs, and how much is still free. This tells you whether you can place another VM, whether you are wasting money, and whether you have room for maintenance moves.

Logs and audit trails

Audit logs record who created or changed node templates, node groups, and VMs. This is valuable for security reviews and for software license audits, where you may need to prove which VM ran on which server on which day. Keep these logs for as long as your rules require.

Teams that succeed with sole-tenancy tend to repeat a few simple habits.

Patterns that work

Anti-patterns to avoid

Every strong tool comes with a price, and sole-tenancy is no exception.

Best practices checklist

Sole-tenant nodes are one of several ways to get isolation or control on Google Cloud.

flowchart TD
  S["Need to run a workload"] --> Q1{"License or policy requires dedicated hardware?"}
  Q1 -->|No| Q2{"Need extra VM protection only?"}
  Q2 -->|Yes| SC["Shielded or Confidential VMs"]
  Q2 -->|No| R["Regular multi-tenant VMs"]
  Q1 -->|Yes| Q3{"Can you keep nodes well filled?"}
  Q3 -->|Yes| ST["Sole-tenant nodes"]
  Q3 -->|No| P["Share node groups across projects or reconsider"]
        

If you know another cloud

People who have used other clouds will find familiar ideas under different names.

Here is how different kinds of organizations typically use dedicated nodes.

Questions beginners ask most often, answered in plain words.

It is a physical Compute Engine server that hosts VMs from only your Google Cloud projects. No other customer’s VMs run on it.

Yes. You create regular VMs with the usual disks, images, and networks. The only difference is that you tell them to run on your node group, using node affinity.

You pay for all the vCPUs and memory of the node, whether used or not, plus a ten percent sole-tenancy premium on those costs. VMs on the node add no extra charge, but disks and premium images are billed at normal rates. Discounts such as sustained use and committed use can reduce the price.

A template is the recipe: it states the node type, region, and labels. A node group is the real set of nodes in one zone built from that recipe.

No. A VM must fit inside a single node, because it cannot be split across two physical servers. Pick a node type large enough for your biggest VM.

That depends on the maintenance policy you choose. VMs can be live-migrated to a server chosen by Google, restarted in place on the same node, or moved to other nodes inside the same node group.

Yes. The autoscaler adds a node when a VM needs room and none is available, and removes empty nodes to save money. You can set limits for the group’s smallest and largest size.

Yes, within your organization. You can share a node group so that other projects place VMs on it. It remains under its parent project and uses the same quota and price as an unshared group.

Not by itself. It gives physical isolation, which may be one requirement among many. You still need identity controls, encryption, logging, patching, and documentation.

No. Node types differ by zone, and not every zone offers every type. Check availability and quota for your chosen zone before you plan.

Yes. The node itself is what you rent. To stop paying, you must reduce or delete the node group, not merely stop the VMs.

Avoid them when you have no license, policy, or performance reason for dedicated hardware, or when you cannot keep the nodes reasonably full. Regular VMs and managed services are cheaper and simpler in those cases.

Sole-tenant nodes give you a physical Compute Engine server that only your projects can use. You describe the server in a node template, build a node group from it in one zone, and place your regular VMs onto it using node affinity labels. You pick a maintenance policy that fits your licenses and availability needs, let autoscaling add or remove nodes, and optionally share the group with other projects in your organization. Because you pay for the entire node plus a premium, the winning habit is simple: use sole-tenancy only when you can name a clear reason, then keep every node well filled. Done this way, it is a powerful tool for licensing, isolation, and predictable performance without leaving the cloud.