Bare Metal and Dedicated Hosts

Most cloud compute is multi-tenant: your virtual machine shares a physical server with strangers’ virtual machines, kept apart by a hypervisor. Sometimes that is unacceptable — you need the whole physical machine, or at least a physical machine that no other customer touches. Two distinct primitives answer this. Bare-metal instances remove the hypervisor entirely and give your operating system direct access to the processor and memory of the underlying server (AWS bare-metal announcement) — you want this for nested virtualization, licenses that forbid virtualized environments, or workloads that read low-level hardware features. Dedicated hosts / dedicated instances / sole-tenant nodes keep the hypervisor but guarantee the physical server is dedicated to your account alone, no other tenant’s workloads co-resident (AWS Dedicated Hosts) — you want this for compliance mandates, bring-your-own-license economics tied to physical sockets/cores, and hardware isolation. Both trade the cloud’s cheap, elastic, shared-pool economics for control, isolation, and licensing fit. This note explains what each is, how the three major providers expose them, and how to choose. It owns what the tenancy primitives are; provisioning them lives in Infrastructure as Code MOC.

Mental Model — The Tenancy Spectrum

The single organizing idea is tenancy: how many customers share one physical server, and whether a hypervisor sits between the guest operating system and the silicon. Default cloud compute is shared tenancy — the physical host is a shared pool, sliced into virtual machines by a hypervisor, and your neighbours are other AWS/GCP/Azure accounts you never see. As you move rightward along the spectrum you buy progressively more isolation and control, and you give up progressively more of the elasticity and low price that made the cloud attractive in the first place.

flowchart LR
    subgraph SHARED["Shared tenancy (default)"]
        H1["Hypervisor"]
        H1 --> V1["Your VM"]
        H1 --> V2["Other account's VM"]
        H1 --> V3["Other account's VM"]
    end
    subgraph DEDINST["Dedicated instance / node"]
        H2["Hypervisor"]
        H2 --> W1["Your VM"]
        H2 --> W2["Your VM"]
        NOTE1["No other account<br/>on this host"]
    end
    subgraph DEDHOST["Dedicated host"]
        H3["Hypervisor"]
        H3 --> X1["Your VM"]
        H3 --> X2["Your VM"]
        NOTE2["You see sockets/cores;<br/>place VMs yourself;<br/>per-host billing"]
    end
    subgraph BARE["Bare metal"]
        OS["Your OS runs<br/>directly on hardware"]
        NOTE3["No hypervisor;<br/>direct CPU/memory access;<br/>run your own hypervisor"]
    end

    SHARED -->|"+isolation<br/>-elasticity"| DEDINST
    DEDINST -->|"+control<br/>+licensing fit"| DEDHOST
    DEDHOST -->|"remove hypervisor"| BARE

What it shows and the insight to take: all four are the same physical server, differing only in who else is on it and whether a hypervisor mediates. Moving right, the “blast radius” of noisy neighbours and co-tenancy shrinks to zero and your control over placement and licensing grows — but so does cost and the loss of the pay-by-the-second, scale-to-zero elasticity that shared tenancy gives you. Note the crucial distinction that trips people up: a dedicated instance/host still runs a hypervisor (you still get a VM); only bare metal removes it. Dedication is about who shares the box; bare metal is about whether there’s a hypervisor at all. These are orthogonal ideas that happen to both mean “single tenant.”

Bare Metal Instances — Removing the Hypervisor

A bare-metal instance is an operating system running directly on the physical server, with no hypervisor between it and the hardware. AWS describes its bare-metal instances as providing applications direct access to the processor and memory of the underlying server, with the operating system running directly on the hardware while still offering the cloud’s provisioning, elasticity, and integration (AWS bare-metal blog). On AWS these appear as instance sizes with the .metal suffix — for example m5.metal, c5.metal, u-6tb1.metal — and they are built on the AWS Nitro System, a collection of AWS-built hardware offload cards and a lightweight security chip that hand networking and storage virtualization off to dedicated hardware, so the main CPUs and memory can be exposed to the guest with essentially no virtualization overhead (EC2 instance types — hypervisor). It is worth internalizing the Nitro trick: AWS did not simply “turn off” virtualization; it moved virtualization into hardware (the Nitro cards), which is what lets a bare-metal instance still be an EC2 instance — attachable EBS volumes, security groups, Elastic Network Interfaces — while the customer OS sees raw silicon.

Why would you pay for a whole machine? The primary drivers are concrete:

• Nested virtualization. A hypervisor cannot easily run inside another hypervisor without severe performance penalties or outright incompatibility. If you want to run your own hypervisor (VMware ESXi, a KVM-based platform, or nested containers-in-VMs), you need the bottom layer to be real hardware. Bare metal gives you that bottom layer.
• Licensing and support that forbids virtualization. Some enterprise software is licensed or supported only when run in a non-virtualized environment, or its vendor will not honour support tickets from inside a hypervisor. Bare metal satisfies that clause.
• Low-level hardware features. Applications that read CPU performance counters, use hardware virtualization instructions (Intel VT-x), or otherwise depend on features not reliably surfaced through a hypervisor need direct hardware access (AWS bare-metal blog).
• Specialized/latency-sensitive performance. Removing the hypervisor removes a source of jitter and overhead for workloads that are extremely sensitive to it.

The three providers expose bare metal differently. On AWS, bare metal is a size of an ordinary EC2 instance family (.metal). On Google Cloud, the equivalent for x86 is the Bare Metal Solution family (physically isolated servers, often for Oracle workloads) and, separately, general bare-metal machine types; the more common “single tenant but still virtualized” answer on GCP is sole-tenant nodes (below). On Azure, dedicated bare-metal offerings exist as specialized SKUs (for example the BareMetal Infrastructure for SAP HANA / Oracle and the Azure VMware Solution), rather than a simple .metal toggle on every VM series.

Uncertain

Verify: the exact current bare-metal offerings and names on GCP and Azure (GCP “Bare Metal Solution” vs general bare-metal machine types; Azure “BareMetal Infrastructure” SKUs). Reason: these product lines are narrower and rename more often than AWS .metal, and I did not fetch each provider’s dedicated bare-metal product page in this pass. To resolve: consult Google Cloud “Bare Metal Solution” docs and Azure “BareMetal Infrastructure” docs at write/read time and date the facts. #uncertain

Dedicated Hosts, Dedicated Instances, and Sole-Tenant Nodes — Keeping the Hypervisor, Losing the Neighbours

The second family keeps the hypervisor — you still launch virtual machines — but guarantees the underlying physical server carries only your account’s workloads. AWS splits this into two products with an important difference, and the other providers each have one primary analogue.

AWS: Dedicated Instances vs Dedicated Hosts

By default EC2 instances run on shared tenancy hardware, meaning multiple AWS accounts might share the same physical server (AWS Dedicated Instances). AWS offers two ways off shared tenancy:

• A Dedicated Instance runs on hardware dedicated to a single AWS account — physically isolated at the host hardware level from instances of other accounts. But it gives you no visibility or control over placement, does not support host affinity (stop/start may land you on a different physical server), and offers only partial bring-your-own-license support. Billing is per instance. It may still share hardware with your own non-dedicated instances.
• A Dedicated Host is a physical server fully dedicated to your use. Crucially it gives you visibility of the number of sockets and physical cores, lets you place instances on a specific host and keep them there (host affinity), and provides comprehensive Bring Your Own License (BYOL) support for per-socket, per-core, or per-VM licenses — Windows Server, SQL Server, SUSE, Red Hat, and so on. Billing is per host (you pay for the box regardless of how many instances you pack onto it) (AWS Dedicated Hosts).

AWS is explicit that there are no performance, security, or physical differences between a Dedicated Instance and an instance on a Dedicated Host — both put you on a single-tenant physical server (AWS Dedicated Instances). The difference is entirely about visibility, placement control, licensing, and billing model. The decision rule from the docs is clean: if you need dedicated hardware but don’t care about placement or socket/core licensing, a Dedicated Instance suffices; if you need host-level visibility, affinity, or per-socket/per-core BYOL, use a Dedicated Host.

The following table captures the differences AWS itself publishes:

Property	Dedicated Host	Dedicated Instance
Dedicated physical server	Server capacity fully dedicated to you	Server dedicated to a single account
Share capacity with other accounts	Yes (optional)	Not supported
Billing	Per host	Per instance
Visibility of sockets / cores / host ID	Yes	No
Host & instance affinity	Yes (pin to same server over time)	Not supported
Targeted placement	Yes	Not supported
BYOL (per-socket / per-core)	Supported	Partial support
Capacity Reservations	Not supported	Supported

Source: AWS Dedicated Hosts overview. The insight: the two products isolate you from other tenants equally; they differ in how much of the physical box you can see and steer, and whether you license per-box or per-instance.

On AWS, dedicated tenancy is set at the VPC or instance level. A VPC can have tenancy default or dedicated; launching into a dedicated-tenancy VPC forces all instances to be Dedicated Instances (AWS Dedicated Instances). Note a subtlety the docs flag: an EBS volume attached to a Dedicated Instance does not itself run on single-tenant hardware — the tenancy guarantee is about the compute host, not the block store.

Azure Dedicated Host

Azure Dedicated Host is a service that provides physical servers able to host one or more virtual machines assigned to a single Azure subscription (Azure Dedicated Host). Azure organizes this into a host group (a collection of dedicated hosts in a region and availability zone) containing hosts (each mapped one-to-one to a physical server), onto which you place VMs. A host has a SKU that dictates which VM size series it can run — you can mix multiple sizes on one host as long as they share the size series. The published benefits map neatly onto the same four drivers:

• Cost optimization via BYOL — with Azure Hybrid Benefit you bring Windows Server and SQL Server licenses onto the host.
• Reliability via maintenance control — you get near-complete control over platform-initiated maintenance, opting into a maintenance window (a 35-day rolling window) so a maintenance-sensitive workload is not paused unexpectedly.
• Performance efficiency — because you own the physical host, you choose which of your applications share its memory and storage, reducing contention.
• Security via hardware isolation — hardware isolation at the physical server level keeps sensitive memory data isolated; no other customer’s VMs are placed on your hosts (Azure Dedicated Host).

Azure charges per dedicated host regardless of how many VMs are deployed; the VMs themselves show on the bill at a price of zero, and software licensing, storage, and networking are billed separately. Azure’s model closely mirrors an AWS Dedicated Host (per-host billing, BYOL, placement control) rather than a Dedicated Instance.

Google Cloud Sole-Tenant Nodes

Google’s analogue is the sole-tenant node: a physical Compute Engine server dedicated to hosting only one project’s VMs (GCP sole-tenant nodes). Where standard Compute Engine spreads your VMs across shared physical servers, a sole-tenant node holds a one-to-one mapping to the physical server so no other organization’s workload lands on it. GCP organizes this with node templates (defining the hardware specification) and node groups (collections of dedicated nodes in a zone). The use cases are the familiar quartet:

• Compliance and security — physical isolation for regulatory requirements demanding hardware separation from external tenants.
• Licensing — ideal for per-core or per-processor BYOL, because Compute Engine reports the ID of the physical server on which a VM is scheduled, letting you track license consumption to specific hardware.
• Performance — gaming and data-intensive workloads benefit from dedicated resources and lower latency.
• Maintenance flexibility — configurable host-maintenance policies control whether VMs live-migrate or restart in place during Google’s infrastructure maintenance (GCP sole-tenant nodes).

Across all three providers the pattern is identical: a single-tenant physical box, host-level visibility for BYOL, placement/affinity control, and maintenance control — differing mainly in naming and in the exact billing and grouping constructs.

Configuration Walk-through — Requesting Single-Tenant Compute

The mechanics differ per provider but the shape is the same: allocate the physical capacity, then place workloads on it. Illustrative AWS CLI, annotated:

# 1. Allocate a Dedicated Host for the m5 family in one AZ.
aws ec2 allocate-hosts \
  --instance-family m5 \          # host will run m5.* instances (or m5.metal if allocated for metal)
  --availability-zone us-east-1a \
  --auto-placement on \          # let matching dedicated-tenancy launches land here automatically
  --quantity 1
 
# 2. Launch an instance with host tenancy onto that host.
aws ec2 run-instances \
  --instance-type m5.large \
  --placement Tenancy=host,HostId=h-0123456789abcdef0 \  # pin to the specific dedicated host
  --image-id ami-xxxxxxxx --count 1

Line-by-line, the load-bearing detail is --placement Tenancy=host: the tenancy flag is what moves the instance off the shared pool. Tenancy=dedicated would instead give a Dedicated Instance (no HostId, no visibility). A key restriction from the docs: once you allocate a host for a virtualized instance type you cannot later switch it to a .metal type on the same host, and vice versa — the host’s metal-vs-virtual nature is fixed at allocation (AWS Dedicated Hosts).

A bare-metal launch, by contrast, is just choosing a .metal size:

aws ec2 run-instances --instance-type c5.metal --image-id ami-xxxxxxxx --count 1
# The guest OS boots directly on the hardware; no hypervisor. You can install your own on top.

On Azure the analogous flow is: create a host group (region + zone + fault-domain count), create a host of a given SKU inside it, then create VMs referencing the host. On GCP: create a node template, create a node group from it in a zone, then launch VMs with node affinity labels that steer them onto the group.

Failure Modes and Gotchas

• You lose elasticity. A dedicated host or sole-tenant node is capacity you have reserved and are paying for whether or not it is full. The cloud’s headline benefit — scale to zero, pay by the second — is gone. If you allocate a host and run one small VM on it, you pay for the whole host. Right-sizing (packing many VMs onto each host) is essential to the economics, which is the opposite instinct from elastic shared tenancy.
• Quotas and capacity limits. Providers cap dedicated capacity separately. AWS limits running Dedicated Hosts per instance-family per Region per account. Azure imposes a dedicated-host vCPU quota (default 3000 vCPUs per region) plus a VM-size-family quota, and provisioning a host consumes both (Azure Dedicated Host). You can hit these before you hit your normal VM quota.
• Confusing dedication with bare metal. A Dedicated Instance still runs on a hypervisor and still gives you a VM — it is not bare metal. If your requirement is “run my own hypervisor” or “no virtualization at all,” a dedicated instance/host does not satisfy it; you need .metal or an equivalent bare-metal SKU. Conversely, if your requirement is merely “no other tenant on my box,” you do not need bare metal — dedicated tenancy suffices and is cheaper to operate.
• Host maintenance and service healing. On Azure, if the underlying node fails and you have disabled auto-replace (to preserve a strong host-to-hardware affinity for compliance), your host can enter Pending Deallocate and eventually deallocate, requiring you to manually redeploy VMs (Azure Dedicated Host). The compliance win (stable hardware affinity) and the availability win (auto-heal to new hardware) are in direct tension — you pick one.
• BYOL license math must actually pay off. The whole point of per-socket/per-core BYOL on a dedicated host is amortizing an expensive license (e.g. a database engine licensed per physical core) across as many VMs as the box holds. If you cannot fill the host, the dedicated-host premium can exceed what you saved on licensing — do the arithmetic before committing.
• EBS/volumes are not single-tenant. As noted, on AWS the block volume attached to a Dedicated Instance is not on single-tenant hardware. If your compliance requirement extends to storage isolation, dedicated compute tenancy alone does not cover it.

Alternatives and When to Choose Them

The honest default is shared multi-tenant VMs — cheaper, elastic, and secure enough for the overwhelming majority of workloads (the hypervisor isolation boundary is robust and continually hardened). Reach for single-tenant compute only when a concrete driver forces it:

Driver	Best fit	Why
Need to run your own hypervisor / nested virtualization	Bare metal (.metal, GCP/Azure bare-metal SKUs)	Only removing the hypervisor gives a real bottom layer
License forbids virtualization or needs raw hardware features	Bare metal	Vendor support / VT-x / performance counters need direct access
Regulatory mandate: no co-tenants on the physical server	Dedicated instance (simplest) or dedicated host / sole-tenant node	Guarantees physical isolation from other accounts
Per-socket / per-core BYOL (Windows, SQL, Oracle)	Dedicated Host / sole-tenant node	Host-level socket/core visibility + affinity for license tracking
Control over maintenance timing for sensitive workloads	Dedicated Host / sole-tenant node	Maintenance-window / host-maintenance-policy control
Just need isolation, don’t care about placement or licensing	Dedicated Instance	Cheapest path off shared tenancy; per-instance billing
Nothing of the above	Shared multi-tenant VM (default)	Elastic, cheap, scale-to-zero

The overarching trade is always the same: single-tenant compute buys isolation, control, and licensing fit at the cost of higher price and lost elasticity. This is one specific point on the broader shared-responsibility and cost/control spectrum that runs through the whole Cloud Architecture MOC.

Production Notes

In practice, dedicated hosts are most often justified not by paranoia about co-tenancy but by software licensing economics — particularly Microsoft and Oracle licensing that is priced per physical core and, in some editions, requires you to license every physical core on the host. A Dedicated Host lets an enterprise bring an existing datacentre license to the cloud and consolidate many VMs onto known physical cores, which can dwarf the compute savings. Bare metal, by contrast, shows up in two recurring places: VMware-style lift-and-shift (running an existing on-prem hypervisor estate unchanged in the cloud) and high-performance / specialized workloads (HPC, certain databases, or systems that measure hardware counters). Compliance regimes (PCI-DSS, some government and healthcare frameworks) sometimes require physical isolation, which is where dedicated tenancy becomes a checkbox rather than an optimization. When evaluating, always separate the two questions the primitives answer — “do I need the hypervisor gone?” (bare metal) and “do I need the box to myself?” (dedicated) — because conflating them leads to over-buying bare metal when a dedicated instance would do, or under-buying a dedicated instance when only bare metal satisfies a hypervisor requirement.

See Also

• Virtual Machine Instances and Instance Families — the shared-tenancy default these primitives depart from; families and sizes
• Instance Sizing and Right-Sizing — packing VMs onto a dedicated host to justify its cost
• Reserved Instances and Committed Use Discounts — commitment discounts that also apply to Dedicated Host Reservations
• The Shared Responsibility Model — tenancy is one axis of the control-vs-managed spectrum
• Regions Availability Zones and Edge Locations — hosts/host-groups/node-groups are scoped to zones
• Cloud Architecture MOC — §2 Compute, parent map