Sole-tenancy gives you exclusive use of a physical Compute Engine server, so your virtual machines never share that machine with anyone else’s.

The simple definition

Compute Engine is Google Cloud’s service for virtual machines. Normally, when you create a virtual machine, Google places it on a physical server that also runs virtual machines for other customers. This is called multi-tenancy, because many tenants share the same hardware. A sole-tenant node is a physical server dedicated to hosting virtual machines from only your project, or from projects you explicitly choose to share it with.

You still create ordinary virtual machines. They look and behave like any other Compute Engine instance, with the same disks, the same networking, and the same tools. The difference is the place they run: instead of landing on whichever server has room, they land on a server reserved for you.

Why anyone needs it

Most workloads run perfectly well on shared hardware. Google isolates tenants strongly, and for typical applications there is no reason to pay for exclusivity. Sole-tenancy exists for a smaller set of situations where exclusivity is a requirement, not a luxury.

The first situation is regulation and policy. Some industries or internal security teams require that sensitive systems do not share physical machines with other organizations. The second is software licensing. Some vendors charge per physical socket or per physical core, and they expect you to prove which hardware runs their software. The third is performance isolation. If another tenant’s heavy workload can affect yours even slightly, and your latency targets are strict, a dedicated host removes that variable. The fourth is control: you want to decide which virtual machines sit together and which sit apart.

What you get and what you give up

You gain exclusivity, scheduling control, licensing options, and a clearer story for auditors. You give up the pay-only-for-what-you-run model of ordinary virtual machines: you pay for the whole node whether it is full or half empty. You also take on a new job, which is capacity planning, because a node is a fixed container and you decide how many nodes you need.

Where it sits in the Google Cloud family

Sole-tenant nodes belong to Compute Engine and are regional and zonal in the usual way: a node lives in one zone, and a group of nodes is created in one zone. Other Google Cloud services can use them too. For example, Google Kubernetes Engine can run node pools on sole-tenant nodes, which lets container platforms inherit the same physical isolation.

To understand why dedicated hosts matter, you first need to see how one physical machine becomes many virtual ones.

What virtualization does

A physical server has processors, memory, network cards, and storage connections. Virtualization is the technique of slicing those resources into several virtual machines, each of which believes it owns a complete computer. A special layer of software, called a hypervisor, sits between the hardware and the virtual machines. It decides which virtual machine gets processor time, keeps their memory separate, and prevents one from reading another’s data.

Google Cloud uses its own hypervisor technology and strong isolation boundaries. In everyday terms, one customer’s virtual machine cannot see into another’s. Sole-tenancy does not replace this isolation. It adds a second layer: the physical machine itself is reserved for you.

Tenancy in plain words

A tenant is a customer of a cloud platform. Multi-tenancy means many customers share the same physical infrastructure, and it is the reason cloud computing is affordable: the cost of a server is spread across many users. Single-tenancy means one customer has the infrastructure to themselves. It costs more because nobody else shares the bill, but it offers a stronger form of separation and more control.

The noisy neighbor problem

On shared hardware, a virtual machine that suddenly uses lots of processor cache, memory bandwidth, or input and output capacity can, in rare cases, slow down others on the same machine. People call this the noisy neighbor problem. Cloud providers work hard to limit it, and for most applications it is invisible. But for trading systems, real-time gaming servers, or latency-critical databases, even small variations matter.

On a sole-tenant node, the only neighbors are your own virtual machines. If a neighbor is noisy, you know who it is, and you can move it to another node using scheduling rules. This is both a performance benefit and a debugging benefit, because you control the whole population of the machine.

Shared and dedicated compared

Eight terms unlock the whole topic. Learn them in this order.

How the words fit together

Think of building a parking garage for your cars. The node type is the size of a parking bay. The node template is the plan that says what bays look like and how they are labeled. The node group is the actual garage floor built from that plan, with a certain number of bays. Affinity labels are the signs on the bays, and node affinity is the instruction on each car that says which signs it may park under. The maintenance policy is the rule for what happens when the floor needs repairs.

How node types are named

Node type names are compact descriptions. They typically begin with the machine family, then include the word node, then the number of virtual processors on the node, and finally the amount of memory in gigabytes. A name like one of the N2 node types therefore tells you at a glance which family of virtual machines it can host, how many virtual processors exist in total, and how much memory the node carries. Always read the node type list for your zone before planning, because availability differs by zone and changes over time.

Because exclusivity costs more, the first design decision is whether you truly need it.

When you should not use it

If you have no compliance requirement, no licensing driver, and no measured performance problem, shared virtual machines are almost always the better choice. They cost less, scale more simply, and need no capacity planning. Adopting sole-tenancy because it sounds safer or faster, without a clear reason, is a common and expensive mistake.

A quick decision table

A sole-tenant deployment is a small hierarchy: templates define nodes, groups hold nodes, and virtual machines are scheduled onto nodes.

The big picture

flowchart TD
  NT["Node type - hardware shape"] --> TPL["Node template - blueprint and labels"]
  TPL --> NG["Node group - nodes in one zone"]
  NG --> N1["Node 1 - physical server"]
  NG --> N2["Node 2 - physical server"]
  N1 --> VM1["VM A"]
  N1 --> VM2["VM B"]
  N2 --> VM3["VM C"]
  POL["Maintenance policy"] --> NG
  AUTO["Autoscaling settings"] --> NG
  AFF["VM node affinity rules"] --> VM1
  AFF --> VM3
        

The diagram reads from top to bottom. The node type describes the hardware. The template packages that choice with labels. The node group creates real nodes from the template in a particular zone. Virtual machines then land on specific nodes, guided by affinity rules, while the group’s maintenance policy and autoscaling settings govern how the group behaves over time.

Component by component

Regional templates, zonal groups

A node template belongs to a region, so one template can be used to build groups in several zones of that region. A node group belongs to one zone, because physical servers live in a specific data center building. This is why high availability on sole-tenant nodes means creating groups in more than one zone and placing replicas across them, just as you would with shared virtual machines.

Understanding placement explains most of the errors and surprises that new users meet.

The placement journey

sequenceDiagram
  participant U as Engineer
  participant API as Compute Engine API
  participant S as Placement scheduler
  participant G as Node group
  U->>API: Create VM with node affinity
  API->>S: Find host matching labels
  S->>G: Check free capacity on matching nodes
  G-->>S: Node with room, or none
  S-->>API: Chosen node, or capacity error
  API-->>U: VM running on dedicated node
        

Capacity is a puzzle, not a pool

Each node has a fixed number of virtual processors and a fixed amount of memory. A virtual machine needs both at once, and it must fit entirely on one node; it cannot be split across two. This is the classic bin packing puzzle. Imagine suitcases of different sizes and trunks of fixed size: even when the trunks have enough total space, a large suitcase may not fit in any single trunk if the small suitcases are scattered poorly.

For that reason, a group with plenty of free capacity in total can still reject a large virtual machine. The fix is to place large machines first, to group machine sizes sensibly, or to add a node.

What a node problem looks like to your applications

Hardware can fail, even on dedicated servers. When a host has a serious fault, virtual machines on it may be restarted elsewhere or recreated, depending on the machine settings and the group policy. Your applications should expect this possibility just as they would on any cloud platform: restart cleanly, keep state on persistent disks or managed services, and run redundant copies on different nodes. Dedicated hardware improves isolation, but it does not make a single node immortal.

This is why the combination of affinity and anti-affinity matters. Rules that keep replicas apart ensure that one failing server removes at most one copy. Rules that keep dependent services together on the same group reduce network distance but increase shared fate. Decide consciously which risk you prefer for each service, and write the decision next to the rule so the next engineer understands it.

What is not different

Once running, a virtual machine on a sole-tenant node behaves like any other instance. Its persistent disks are network attached and independent of the node. Its network interfaces connect to the same virtual private cloud. Its identity, firewall rules, and monitoring work normally. This is an important design simplification: you are choosing a host, not changing the application model.

What happens during host maintenance

Physical servers need maintenance such as firmware updates and hardware repairs. On shared hardware, Google typically moves running virtual machines with live migration so users rarely notice. On sole-tenant nodes the question is trickier, because your whole point is to stay on controlled hardware and sometimes on specific physical hardware. That is why node groups carry an explicit maintenance policy, which Chapter 9 explains in detail.

Good sole-tenant design starts with choosing the right node shape and the right number of groups.

Choosing a node type

Start from the virtual machines you want to run. List their machine families, their virtual processor counts, and their memory sizes. Then look for a node type in your zone that matches the family and divides evenly by your typical machine size. If most of your virtual machines use eight virtual processors, a node with a number of virtual processors divisible by eight wastes little capacity. If your machines use odd sizes, leftover fragments will appear on every node, and you will pay for capacity that nobody can use.

What goes into a node template

Templates are blueprints, not live settings

A node template is not edited after creation. When you need different labels or a different node type, you create a new template and build a new node group from it. This may feel inconvenient, but it has a benefit: every node in a group is guaranteed to match one known blueprint, so labels and hardware never drift apart.

How many node groups?

Google’s own guidance frames this as a trade between availability and utilization. Fewer, larger groups pack virtual machines more tightly and cost less because there is less stranded space. More, smaller groups isolate failures and let you run different maintenance policies, different owners, or different licensing pools separately.

A step-by-step planning method

Affinity rules are the steering wheel of sole-tenancy. They decide which virtual machines share a node and which never do.

The basic idea

Every node carries labels from its template. Every virtual machine carries rules in its scheduling options. A rule has three parts: the label key, an operator, and one or more values. The operator is either in, meaning the node must have one of these values, or not in, meaning the node must not have these values. The scheduler obeys these rules strictly. If no node satisfies them, the machine is not created.

Built-in labels

Besides your own labels, Compute Engine automatically attaches labels that identify the node group name and the individual node name. These are helpful for simple cases: a virtual machine can be pinned to one node group by naming it, or to one exact node by naming that node. In shared-group designs, a label identifying the project can also help.

Three common placement goals

flowchart LR
  subgraph G1["Node group A - label tier equals database"]
    A1["Node A1 - DB primary"]
    A2["Node A2 - DB analytics"]
  end
  subgraph G2["Node group B - label tier equals web"]
    B1["Node B1 - web servers"]
    B2["Node B2 - cache servers"]
  end
  R1["Rule: tier IN database"] --> G1
  R2["Rule: tier IN web"] --> G2
        

Using affinity to isolate noisy workloads

Suppose a heavy reporting job runs at night and slows the transactional database it shares a node with. You can give the reporting machines a label that points to a separate group and move them. The database keeps a quiet host, and you still pay for dedicated hardware only where you need it. This is performance tuning by placement, not by code change.

Controlling affinity as a policy

Because forgetting the affinity rule silently defeats the compliance goal, mature teams enforce it. They use instance templates that already contain the rules, deployment pipelines that reject machines without them, and organization policies or reviews that check that regulated projects only create machines with approved labels. Prevention beats auditing after the fact.

The maintenance policy decides what happens to your virtual machines when Google must service the physical host.

Why maintenance matters more here

Physical servers occasionally require firmware updates, security fixes, and hardware replacement. For ordinary virtual machines, Google handles this quietly with live migration, which moves a running machine to another host without stopping it. On a sole-tenant node, your design might depend on staying on specific hardware or on a specific set of dedicated hosts. For that reason each node group has a maintenance policy that you choose deliberately.

The three policies

Testing before trusting

Never discover how a maintenance policy behaves during a real incident. Build a small non-production node group with the same policy, run representative virtual machines on it, and observe what happens during simulated maintenance and during manual node events. Record how long interruptions last, whether applications reconnect cleanly, and whether licensing and monitoring tools still see the machines correctly. These rehearsals turn policy descriptions into operational knowledge and expose gaps such as applications that do not retry connections or scripts that assume a machine never restarts.

Choosing a policy with a simple question

Maintenance windows and advanced control

Google provides controls that let you influence when planned maintenance happens, so you can steer it to a quiet time such as a weekend night. These controls are especially helpful with the restart in place policy, because you would rather schedule an interruption than receive it at peak traffic. Combine this with redundancy: if your service runs on two nodes in two groups, restarting one at a time never takes the service fully down.

Because nodes are a fixed container you pay for, capacity planning is part of the job. Autoscaling helps, but it does not replace thinking.

Manual sizing

The simplest approach is to set a fixed number of nodes in a group and resize it when needed. This gives predictable cost and predictable placement. It works well for stable workloads, such as a database estate with a known number of servers, where growth is slow and planned.

Autoscaling node groups

For workloads that change in size, node groups can scale automatically. The autoscaler watches for virtual machines that cannot be placed because the group is full, and adds nodes up to a maximum you set. When nodes are empty it can remove them, down to a minimum. You choose a mode that matches how adventurous you want the automation to be.

How a scale-out decision looks

flowchart TD
  A["New VM requested with affinity"] --> B{"Matching node with enough room?"}
  B -- "Yes" --> C["Place VM on that node"]
  B -- "No" --> D{"Autoscaling allows growth?"}
  D -- "Yes, below maximum" --> E["Add a node to the group"]
  E --> C
  D -- "No or at maximum" --> F["Request fails - capacity error"]
        

Bin packing in practice

To use nodes efficiently, create large virtual machines first and fill gaps with small ones afterward. Use a small number of standard machine sizes across the estate so that gaps left by one machine can be filled by another. Avoid placing many medium machines that leave awkward remainders. Review utilization regularly: if nodes sit at thirty percent usage, you are paying for unused hardware and should consolidate or consider overcommit.

A worked capacity example

Suppose a node offers eighty virtual processors and six hundred and forty gigabytes of memory, and your standard machine uses sixteen virtual processors and one hundred and twenty eight gigabytes. By processors, five machines fit exactly. By memory, five machines also fit exactly. The node is perfectly packed with five identical machines and nothing is wasted. Now imagine your teams create machines of twelve virtual processors instead. Six of them need seventy two virtual processors, leaving eight spare, which is not enough for another twelve-processor machine. Eight processors sit idle on every node, a ten percent loss that repeats across the whole estate.

The lesson is that small differences in machine size create large differences in cost. Before launch, agree on a short menu of approved sizes that divide your chosen node type neatly, and make that menu part of your templates. When a team requests an unusual size, the cost of the leftover space should be part of the conversation.

Spare capacity for failure and maintenance

A group with no free room is fragile. If a node is repaired or a policy needs to move machines, there is nowhere to go. A common rule of thumb is to keep enough headroom to absorb the loss or maintenance of one node, but the right amount depends on your policy, your service level goals, and your budget. Write down the rule so that future capacity reviews use the same standard.

Overcommit lets you schedule more virtual processors on a node than it physically has, betting that your virtual machines will not all be busy at once.

The idea in plain words

Many virtual machines are idle most of the time. A development server may use a few percent of its processors. When many such machines sit on a dedicated node, much of the hardware does nothing. Overcommit lets these machines share spare processor time, so you can place more of them on one node. The node’s cost is then divided among more machines, lowering the cost per machine.

The minimum guaranteed allocation

For each overcommitted virtual machine, you set a minimum allocation: the number of underlying processor threads that are always guaranteed to that machine. If the machine has more virtual processors than guaranteed threads, the extra virtual processors share resources and may run slower when the node is busy. Different machines on the same node can have different ratios, so you can protect important machines with a higher guarantee and stretch less important ones further.

When overcommit helps

When overcommit hurts

If your workloads burst at the same time, such as everything running at month end, overcommitted machines compete for the same processors and slow down together. This is the risk the guaranteed minimum is meant to bound. Finding the right ratio is an experiment: start conservative, measure processor utilization and latency across busy periods, and tighten gradually.

For many organizations, license savings are the single biggest financial reason to choose dedicated hosts.

Why licenses care about hardware

Some software vendors set prices by the physical resources that run their product: the number of sockets, which are the physical processor chips in a server, or the number of physical cores. In a normal shared cloud you cannot easily say which physical hardware ran your software, so vendors may restrict or price these licenses differently. On a dedicated node, the physical hardware is yours and countable, which can make existing licenses portable to the cloud.

How sole-tenancy helps

Counting licenses on dedicated hardware

License counting rules differ, but the habit of good record keeping is universal. Keep a simple register that lists each node, its physical core and socket count as published for the node type, the software licensed on it, and the date each virtual machine started and stopped there. When an auditor asks how many cores ran a database last quarter, the register and the platform logs together give an answer in minutes. Without a register, teams often over-license out of caution, wasting the very savings they moved to dedicated hosts to capture.

Doing the arithmetic

Compare the full cost of two options. The first is shared virtual machines with cloud-provided licenses. The second is dedicated nodes with your own licenses. Include the sole-tenancy premium, the cost of idle node capacity, the license fees you avoid, and the operations effort. For a large, steady, license-heavy estate, dedicated nodes often win. For a small or variable estate, the idle capacity usually erases the savings.

The pricing model differs from ordinary virtual machines, and understanding it prevents the most common budget surprise.

What you are charged for

You pay for all the virtual processors and all the memory on each node from the moment the node is created, whether or not any virtual machine is running on it. Virtual machines placed on the node do not add their own compute charge. Pricing depends on the node type’s size and the region. Other resources, such as persistent disks and premium operating system images, are billed separately.

The sole-tenancy premium

On top of the underlying processor and memory cost, Google charges a premium of ten percent for the exclusivity. Sustained use discounts apply to the premium. Flexible committed use discounts also apply to it, while resource-based committed use discounts cover the processor and memory but leave the premium payable. Because discounts and prices change, always confirm figures on the official pricing page.

A worked cost thought experiment

Imagine two ways to run twenty virtual machines of similar size. In the first, they run as shared virtual machines and each is billed only while it runs. In the second, they run on three sole-tenant nodes that are always on. The shared option scales its bill with the number of machines running, which is perfect if some of them are switched off at night. The dedicated option charges the same amount whether you run twenty machines or two, so its cost per machine is lowest when the nodes are nearly full and highest when they are mostly empty.

This means the break-even point depends on three numbers you can measure: how full your nodes will be on average, how much you save on licenses, and how much discount your commitments give. A design that fills nodes to eighty percent, avoids expensive per-core licenses, and uses a long commitment can beat the shared option. A design that fills nodes to thirty percent and has no licensing driver almost never does. Do this arithmetic with real numbers from the pricing page before you commit.

Minimum billing time

Node usage is charged for a minimum of one minute, and after the first minute it is billed in one-second increments. Short experiments are therefore not heavily penalized by the minimum itself, but remember that a node is large, so even a short test can cost real money if you forget to delete it.

Ways to reduce cost

Everything around the virtual machine works as usual, but a few details deserve attention on dedicated hosts.

Networking is unchanged

Virtual machines on sole-tenant nodes attach to your virtual private cloud networks like any other instance. They receive internal addresses, follow your firewall rules, use your routes, and can reach private services. A dedicated host does not isolate a machine from your own network and does not by itself block the internet. You still design network security separately.

Storage is network attached

Persistent disks are independent of the node, so a virtual machine that restarts on a different node can reattach its disks. Some node types also offer local solid state storage, which is fast but tied to the machine’s life and behaves differently during maintenance. Treat local storage as temporary and keep important data on persistent disks or managed storage, and check the pricing page for how local storage is billed on your chosen node type.

Who may do what

Sharing a node group across projects

Because a node is expensive, one group is often more useful when several teams can use it. Compute Engine lets you share a node group with other projects in the same organization, either with the whole organization or with a named list of projects. Teams in those projects create virtual machines that target the shared group using affinity rules. The owner project pays for the nodes, which allows central capacity management and higher utilization.

Dedicated hardware strengthens one layer of security, but it is only one layer among many.

What sole-tenancy adds

It removes other customers from the physical server. For some risk models and rules, that is a meaningful reduction in exposure and a clear statement to give auditors. It also gives you stronger control over which of your own workloads share a host, which helps to separate production from test, or sensitive data processing from general services.

What it does not do

It does not encrypt your data by itself, authenticate your users, patch your guest operating systems, or block misconfigured firewalls. It does not protect against a weak password or a leaked key. Think of it as a locked room: useful, but not a substitute for a good lock on every cabinet inside.

Layers to combine

Separation of duties

A well-run environment separates the people who manage the nodes from the people who run workloads on them, and both from the people who audit. The capacity team can create and resize groups but cannot read application data. Workload teams can create virtual machines on approved labels but cannot change maintenance policies or delete nodes. Auditors can read configuration and logs but cannot change anything. Each person has what they need and nothing more, which reduces both accidents and abuse.

Combine this with change review. Any change to a node group, a template, a label, or a sharing setting should pass through the same review process as application code. A single careless sharing change can open dedicated capacity to projects that should never have had it, and a single deleted label can leave critical machines without a valid host.

Proving compliance

Auditors ask for evidence. Useful evidence includes the configuration of your node groups, a list of virtual machines with their placement, change logs showing who created or moved machines, and a policy that prevents regulated machines from being created without affinity rules. Gather these regularly and store them with your compliance documents so that an audit is a calm retrieval, not a scramble.

You need two views: how full your nodes are, and how healthy the virtual machines on them are.

Metrics worth watching

Reading the logs

Administrative activity logs record who created, resized, or deleted nodes and groups, and who created virtual machines with which affinity. Use them to answer the questions that arise after surprises: who added that node, when did the group grow, which machine was moved. Send these logs to a central location and keep them as long as your compliance rules require.

Common problems and their usual causes

A few repeatable patterns cover most real designs.

flowchart LR
  subgraph Z1["Zone one"]
    G1["Node group - licensed pool"]
    G2["Node group - database tier"]
  end
  subgraph Z2["Zone two"]
    G3["Node group - licensed pool replica"]
    G4["Node group - database replica"]
  end
  APP["Application tier on shared VMs"] --> G2
  APP --> G4
  G2 -. "replication" .-> G4
  G1 -. "failover" .-> G3
        

Mixing shared and dedicated

You rarely need to place the entire estate on dedicated nodes. A common, cost-aware design keeps only the regulated or licensed components on sole-tenant nodes, and runs stateless application servers on ordinary shared virtual machines. The result satisfies the requirement while limiting the expensive footprint to what truly needs it.

These mistakes appear repeatedly in real projects.

A compact guide to getting good results from the first deployment.

Planning practices

• Start with the requirement. Document the compliance rule, license term, or performance evidence that justifies dedicated hosts.
• Standardize machine sizes. Fewer sizes mean fewer fragments and better packing.
• Plan zones early. Decide how many zones and how much headroom you need before buying capacity.
• Check quotas and availability in every region you may use, including your recovery region.

Operating practices

• Keep labels small and documented so that placement rules are understandable and enforceable.
• Review utilization monthly and consolidate or shrink groups that are mostly idle.
• Prefer scale-out-only automation when licensing or headroom depends on a stable node count.
• Test maintenance behavior in a non-production group before relying on it for critical services.
• Describe infrastructure as code so templates, groups, and rules are reviewed like application changes.

A readiness checklist

Common mistakes at a glance

Several Google Cloud options give more isolation or control. Knowing the differences prevents over-buying.

A simple escalation ladder

When a requirement appears, climb the ladder only as far as needed. Start with shared virtual machines and strong identity and network controls. If the requirement asks for physical separation, move that workload to sole-tenant nodes. If it also asks for protection of data while in use, add encrypted memory options. If software needs direct hardware access, consider bare metal style offerings. Each step costs more in money and in operations effort, so stopping at the lowest sufficient step is a sign of good engineering, not of weak security.

Combining options

These choices are not exclusive. A sensitive database may run on sole-tenant nodes with encrypted memory options, while the application tier uses shared virtual machines and managed services. Choose the strongest control for each layer only where the requirement demands it, and let the rest remain simple.

Containers on dedicated nodes

Kubernetes node pools in Google Kubernetes Engine can run on sole-tenant nodes. This allows container platforms to meet the same hardware isolation requirements. The design questions are similar: choose a node type that matches the machines your pool needs, use labels to steer pods or node pools, and plan capacity and maintenance for the underlying nodes.

Moving an existing dedicated-host estate

These scenarios are illustrative composites of how organizations typically use sole-tenancy, not descriptions of any specific company.

Every choice has a cost. Weigh both sides honestly.

Questions to ask before you commit

Which exact rule, contract, or measurement requires dedicated hardware? Which workloads are covered, and which are not? How full will the nodes be after six months, and what happens if the estate shrinks? Who owns the capacity plan, and how often will it be reviewed? What is the exit plan if the requirement disappears? Teams that can answer these questions in a few sentences usually succeed with sole-tenancy. Teams that cannot often end up with expensive, half-empty nodes and no clear owner.

Reading the trade-offs correctly

The cost of sole-tenancy is mostly the cost of idle capacity and operations effort, not the ten percent premium. A well-packed node group with committed use discounts can be cost-competitive, especially with licensing savings. A poorly packed group, kept only out of habit, is a steady drain. The deciding factor is therefore not whether dedicated hardware is good, but whether your requirement justifies it and whether you can keep nodes busy.

No. A sole-tenant node is a dedicated physical server, but your workloads still run as virtual machines on top of a hypervisor. Bare metal style options give direct hardware access without that layer.

No. Only virtual machines from your project, or from projects you explicitly share the node group with, can run on it.

You pay for the node’s total processors and memory plus the premium. The virtual machines placed on it do not add separate compute charges, but their disks and other resources are billed normally.

It is placed on shared hardware, not on your dedicated nodes. Dedicated placement applies only when the machine asks for it through node affinity.

Yes, as long as the machines belong to a compatible family and fit together within the node’s processors and memory. Standardizing sizes improves packing.

Templates are blueprints and are not edited in place. To change labels or the node type you create a new template and build a new group from it.

Choose the default for simplicity, restart in place when licenses require staying on the same hardware, and migration within the group when you need continuity inside your own nodes and can hold spare capacity.

Yes. Node groups support autoscaling modes including off, on, and scale-out only. Many teams prefer scale-out only so they control when capacity is removed.

It improves host-level separation, but you still need patching, identity controls, network rules, and encryption. It is one layer, not the whole defense.

Yes, within your organization, through sharing settings. Use labels and reports so that each team sees its own usage and cost.

Pack machines tightly, use autoscaling carefully, review utilization on a schedule, and delete groups that no longer meet a requirement.

The official Compute Engine sole-tenancy documentation and pricing pages are the source of truth. Node types, prices, and policies change over time and differ by region and zone.

Sole-tenant nodes give you a physical Compute Engine server that hosts only your virtual machines. You choose a node type, capture it in a template, build a node group in a zone, and steer virtual machines onto it with affinity rules. Maintenance policies, autoscaling, and overcommit let you balance continuity, capacity, and cost. The model pays off when a clear requirement exists, such as compliance, per-core licensing, or strict isolation, and when you can keep nodes well filled. It disappoints when it is adopted by habit. Keep dedicated hardware for what truly needs it, enforce placement through templates and policy, plan headroom and zones, and always verify current limits, prices, and license terms in official sources.