When a .metal instance is actually worth it

Published July 29, 2026

Every EC2 family that offers a .metal size has a rumor attached to it: that bare metal is the expensive option, a premium you pay for direct hardware access. Check the actual prices in our dataset and that rumor doesn’t hold up. Across every generation we checked, from c5.metal up through the newest c8i and r8g metal sizes, AWS charges exactly the same hourly rate for .metal as it does for the largest virtualized instance in that family, identical to the cent.

That changes the question this guide answers. It isn’t “is bare metal worth the extra money,” because there usually isn’t any. It’s “is your workload one of the few that needs what bare metal gives you instead of a hypervisor,” because that’s the real trade you’re making. Use the instance explorer to look up specific sizes and the comparison tool to check a metal candidate’s virtualized sibling side by side.

What “bare metal” means on EC2

A normal EC2 instance runs on a hypervisor. AWS’s Nitro Hypervisor carves one physical server into several virtual machines, and your instance is one of them, sharing the box with a security and networking layer that lives outside your control. A .metal instance is different: you get the entire physical server, with no hypervisor between your OS and the hardware. Your kernel boots directly on the CPU.

What doesn’t go away is the Nitro System itself. Nitro isn’t the hypervisor; it’s a set of dedicated cards handling networking, EBS, and security that sit outside the main CPU on every current-generation instance, virtualized or metal. That’s why a .metal instance still gets the same Elastic Network Adapter, the same EBS-optimized throughput, and the same VPC integration as its virtualized siblings. You’re opting out of the hypervisor, not out of Nitro.

Losing the hypervisor means losing what it does for you. No live migration off failing hardware. No pausing or resizing without a reboot. Host maintenance events that would normally be invisible now mean your instance goes down. In exchange, your OS sees real hardware: real performance counters, the real instruction set with nothing masked, and the option to run your own hypervisor inside it.

What it actually costs

Here’s the pricing pattern, pulled directly from our data (all Linux, on-demand, us-east-1):

We checked 148 metal-to-same-size-virtualized pairs across the full dataset; 138 matched exactly. The handful that didn’t are edge cases where a family doesn’t offer a same-size virtualized instance to compare against (see the High Memory instances below), not a metal premium.

Match the size, not just the family. Newer generations offer .metal at more than one size, and the price tracks the matching size, not the family’s biggest option. On c8g, c8g.metal-24xl costs $3.8285/hr, exactly what c8g.24xlarge costs, while c8g.metal-48xl costs $7.6570/hr, exactly double, matching c8g.48xlarge. Pick the metal size that corresponds to the vCPU count you actually need, not the largest one available.

Some families only exist as metal. The High Memory instances (u-6tb1 through u-24tb1, 6 to 24 TiB of RAM) ship only as .metal, with no virtualized size in the family at all. There’s no comparison to make there; metal is simply the only shape that instance comes in.

So the premium you’ve heard about isn’t in the invoice. If your workload already needs the top virtualized size in a family, moving that same workload to .metal costs nothing extra. The real cost of bare metal is operational: you’re now responsible for a layer AWS used to manage for you.

Why the price is identical

That follows from how the hardware is carved up, not from AWS discounting anything. The largest virtualized size in a family is already built to consume the entire physical host. Compare c5.24xlarge to what c5.metal would give you: both get 96 vCPUs across 48 physical cores, 25 Gbps of network bandwidth, and 2,375 Mbps of EBS throughput, because both are the whole machine. The hypervisor on c5.24xlarge isn’t holding back a resource pool for other tenants; there’s no room left for other tenants once you’ve taken the largest size. Bare metal just removes the (very thin, Nitro-based) software layer that would otherwise sit between your kernel and that same hardware.

That’s also why smaller virtualized sizes in the same family aren’t a fair comparison. A c5.4xlarge shares its physical host with other customers’ instances; a c5.metal or c5.24xlarge does not. If your workload fits comfortably in a 4xlarge, bare metal isn’t a discount waiting to be claimed, it’s a much bigger, differently-priced commitment.

Who actually needs it

A short list:

• Per-core or per-socket licensed software. Some Oracle Database, VMware, and other enterprise licenses meter by physical core or socket, and the license terms may require the vendor to be able to verify that count directly rather than trust a hypervisor’s report. Bare metal removes the ambiguity.
• Nested virtualization. Running your own hypervisor, whether that’s VMware ESXi, KVM for CI runners that themselves boot VMs, or a lab environment that needs real virtualization extensions, generally requires access to hardware virtualization features that AWS’s own hypervisor doesn’t pass through to a guest.
• Hardware performance counters and low-level profiling. Tools that read CPU performance counters, do cycle-accurate profiling, or need an instruction set with nothing masked or emulated (certain AVX-512 paths, specific model-specific registers) can behave differently or fail entirely under virtualization.
• Physical isolation requirements. Some compliance regimes and threat models call for guaranteed single-tenant hardware with no hypervisor in the trust boundary, not just AWS’s word that your instance is the only one on the host.
• The largest workload in a family that needs it anyway. If you were already going to provision the top virtualized size, there’s no reason not to take .metal at the same price, unless you specifically want AWS’s hypervisor for live migration and simplified maintenance.

Who doesn’t

Nearly everyone else. If your answer to “why bare metal” is “it sounds faster” or “it seems like the premium option,” it isn’t, and it costs the same as the virtualized size you’d otherwise pick, so there’s no financial reason to default to it, either. Specifically:

• Standard application, database, and web workloads. The hypervisor overhead on modern Nitro instances is small enough that almost nothing running a typical stack notices it.
• Anything that benefits from live migration or managed maintenance. Bare metal means host hardware issues become your incident, not AWS’s. Most teams would rather keep that abstraction.
• Workloads that don’t need the whole host. If a 4xlarge or 8xlarge does the job, there’s no metal-equivalent size to reach for anyway. Right-size first; see cost-per-vCPU for how to check.
• Licensing that’s already per-vCPU or per-instance. If your vendor doesn’t care about physical cores, the reason to go bare metal disappears along with the licensing math.

Deciding for your workload

1. Check whether you actually need the top size in the family. Bare metal only exists at the sizes AWS offers it for, usually the family’s largest one or two. If your workload doesn’t need that much host, this whole question is moot; look at the instance explorer for a mid-size option instead.
2. Name the specific requirement. “Per-core licensing,” “nested KVM for CI,” “compliance requires single-tenant hardware,” “reading hardware performance counters directly” are real answers. “It might be faster” or “it’s the most powerful option” are not; the top virtualized size gives you the same hardware.
3. Confirm the size match. Compare your candidate .metal size against the same-size virtualized instance using the comparison tool. Confirm vCPU, memory, network, and EBS throughput line up (they should, since it’s the same hardware). If the price differs from what you expect, you’re probably comparing against the wrong size.
4. Plan for the operational shift. No live migration, no pause/resize without a reboot, and host maintenance events hit you directly instead of being handled behind the scenes. Budget for monitoring and patching a bare OS the way you would for on-prem hardware, because that’s effectively what you now have.
5. Re-check the price in your region. The pairs above are us-east-1; confirm on the instance detail pages before committing, since regional pricing can shift the absolute numbers even though the metal/virtualized ratio should hold.

Making the call

Clear yes. Per-core licensed software that requires physical hardware verification. Nested hypervisors and workloads that need virtualization extensions AWS’s own hypervisor doesn’t expose. Compliance requirements for verified single-tenant hardware. Anyone who was already sizing for the top virtualized instance in a family, since metal costs the same and removes the hypervisor layer for free.

Worth checking first. Performance profiling or low-level CPU work that might be hypervisor-sensitive. Test on the virtualized top size before assuming metal is required; Nitro’s overhead is small, and you may not need to make the jump at all.

Stay virtualized. Anything that fits in a smaller size than the family’s .metal offering. Standard application and database workloads. Anyone who wants AWS to handle live migration and host maintenance rather than owning that themselves. Licensing that’s metered per-vCPU or per-instance rather than per physical core.

Bottom line: the premium you’ve heard about attached to .metal doesn’t show up in the data. AWS prices it identically to the largest virtualized size in the family, because it’s the same hardware either way. What you’re actually deciding is whether to keep the hypervisor or remove it, and for the vast majority of workloads, keeping it, and letting AWS handle the host, is the better trade even at an identical price.