Dora NodaIn February 2026, OVHcloud rolled out its Scale 2026 bare-metal line — dual-socket AMD EPYC 9005 boxes scaling to 384 cores, 768 threads, and 3TB of DDR5 ECC memory — with AMD SEV-SNP confidential computing support built in. Five months later, AWS did the same thing to EC2 Dedicated Hosts, for a fee: 10% on top of the on-demand hourly rate. Two very different clouds, same feature, same season. That's not a coincidence — it's a threat model catching up to what "multi-tenant" has actually meant all along.
Here's the question a Cluster API operator actually needs answered: what does hardware-encrypted memory close that container namespaces and cgroups already don't, what does turning it on cost, and does a self-hosted fleet running its own bare metal need it at all?
What Namespaces and Cgroups Were Never Designed to Stop
Kubernetes-style isolation — namespaces, cgroups, seccomp, RBAC — is resource-management tooling repurposed as a security boundary. It does a solid job of stopping one container from seeing another container's processes, network, or filesystem. It was never built to stop something with access to the host or the hypervisor underneath. AMD SEV-SNP (Secure Encrypted Virtualization–Secure Nested Paging) targets exactly that layer: it encrypts a VM's memory with a key generated and held inside the AMD Secure Processor, invisible even to the hypervisor, and adds remote attestation so a guest can cryptographically prove its boot state hasn't been tampered with.
The two mechanisms answer different questions, and the gap between them is the whole point of the feature:
| Threat vector | Container namespaces / cgroups | AMD SEV-SNP |
|---|---|---|
| Tenant A's container escapes to attack Tenant B's container | Mitigated (process/network/mount isolation) | Not its job — same guest, doesn't apply |
| A compromised or malicious co-tenant VM attacks the shared hypervisor | Not addressed — no VM boundary in a pure-container model | Doesn't stop the attack, but limits blast radius: an attacker with hypervisor access still can't read encrypted guest memory |
| A curious or compromised hypervisor operator inspects guest memory | Not addressed at all — the whole stack trusts the operator | Addressed — memory is encrypted against the host and the hypervisor itself |
| Cold-boot or physical memory-dump attack on the host | Not addressed | Addressed — DRAM contents are encrypted at rest, not just access-controlled |
| DMA attack from a compromised peripheral or BMC | Not addressed | Addressed — SNP's memory integrity checks catch unauthorized writes into guest pages |
| Guest attests its own boot integrity to a remote party before trusting it with secrets | Not possible | Addressed — SEV-SNP attestation reports are the mechanism |
The pattern is consistent: cgroups and namespaces assume the kernel and the operator are trustworthy and only worry about tenants attacking each other sideways. SEV-SNP assumes the operator, the hypervisor, and even someone with a screwdriver and physical access to the rack might not be, and encrypts against all three. That's a genuinely different threat model, not a stronger version of the same one — which is also why it's the wrong tool if the threat you actually have is a noisy neighbor or a container escape, not a rogue admin.
The Bill for Turning It On
Security that closes a real gap is still a cost decision, and the two clouds that shipped SEV-SNP this year priced it in opposite ways.
AWS made the cost explicit. EC2 Dedicated Host SEV-SNP support, added in July 2026, is billed as a flat 10% surcharge on the on-demand hourly rate of whatever instance category you allocate — a separate, visible line item on top of normal Dedicated Host pricing. Run an m6a.2xlarge-class Dedicated Host at roughly $0.35/hr on-demand equivalent and confidential computing adds about $0.035/hr to it — call it an extra $25–$30/month per host for an always-on service, before you've moved a single byte.
OVHcloud folded it in. Public Scale 2026 pricing and documentation describe SEV-SNP as a capability of the line, not a separately priced add-on — there's no disclosed confidential-computing surcharge tier the way there is for AWS's Dedicated Hosts. Entry Bare Metal 2026 pricing starts around €54.99/month, with Scale-tier US pricing around $423/month for the high-end configuration; whether or not you turn SEV-SNP on doesn't appear to move that number. If that holds once you're actually configuring an order, it's the more attractive economics for anyone who wants the guarantee without a metered second bill — but it's worth confirming against your own quote before you build a cost model on it, since OVHcloud hasn't published a rate card that breaks the two apart.
The part neither vendor puts on the pricing page is the performance tax, and it isn't flat. Independent benchmarking (Phoronix's EPYC 9005 SEV-SNP review and academic confidential-VM studies) puts the overhead at:
- ~2–3% for CPU-bound workloads — barely measurable
- ~7–9% average overhead on memory bandwidth/injection benchmarks
- ~8–12% throughput reduction on database-shaped, memory-intensive workloads
- Up to 15–20% latency increase on memory-latency-sensitive access patterns (e.g., graph/index traversal), driven by the TLB miss penalty of walking encrypted page tables
Put a number on it: an always-on Postgres-backed tenant app that would run at 10,000 req/s unencrypted might land closer to 8,800–9,200 req/s with SEV-SNP on — plus, on AWS, another $25–30/month for the privilege. On CPU-bound API workloads with a small working set, the same toggle might cost you nothing you'd notice. The overhead isn't a rounding error, but it isn't the same tax for every workload either — measure your own before deciding, don't assume the CPU-bound number applies to your memory-heavy service.
Who Actually Needs It
The threat table above only matters if your fleet's architecture puts the threat in play. Three shapes, three answers:
A Cluster API fleet running one tenant per bare-metal node — the architecture bex and similar self-hosted PaaS setups favor — has no shared hypervisor sitting between tenants in the first place. There's no "compromised co-tenant attacks the hypervisor" scenario to defend against, because there's no multi-tenant hypervisor. SEV-SNP would be encrypting memory against a threat that architecturally isn't there. It's not wrong to enable it, but it's also not buying you the thing it's designed to buy.
A fleet packing multiple untrusted tenants' VMs onto shared bare metal through a hypervisor — the classic public-cloud shape — is exactly SEV-SNP's target case. Here, the hypervisor operator (or anyone who compromises it) genuinely can read guest memory without SEV-SNP, and genuinely can't with it. If your isolation story depends on "trust the hypervisor layer," SEV-SNP is closing a real, previously-open door.
Regulated or sovereignty-constrained workloads are where this stops being optional and starts being a procurement checkbox. As EU sovereignty frameworks move from advisory ratings toward legislated tiers tied to public contracts, hardware-attested isolation — proving cryptographically, not just contractually, that a workload's memory was never readable by the host operator — is becoming table stakes for the most sensitive tier of government and critical-infrastructure work, independent of whether the operator is trusted in practice.
Where This Leaves a Self-Hosted Fleet
If you're running bex-style, one-tenant-per-machine deployments on owned or rented bare metal, SEV-SNP is solving a problem your architecture has already sidestepped by not sharing a hypervisor across tenants in the first place — the dedicated-machine model closes the same gap by removing the shared layer, rather than encrypting around it. Where it still earns its keep on owned hardware is the narrower slice the table above calls out directly: insider threats and physical access — a data-center technician, a compromised remote-management interface, a stolen drive — scenarios that persist even when there's no other tenant's hypervisor in the picture at all.
The right sequencing is threat model first, feature second: map which row of that table you're actually exposed to before pricing out the extra $30/month or the 10% throughput hit. For most self-hosted, dedicated-node fleets, that's a small slice of the SEV-SNP threat model, not all of it — worth knowing you could turn on if a customer's compliance requirements demand attested hardware isolation, without treating it as a default.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with Cluster API managing the bare metal underneath. Because each tenant gets its own dedicated node rather than a slice of a shared hypervisor, the multi-tenant threat model SEV-SNP is built for mostly isn't one you're carrying to begin with. Star the repo on GitHub or deploy your first app today.
Sources
- OVHcloud unveils Bare Metal 2026 line-up powered by the latest AMD processors
- OVHcloud reveals Bare Metal 2026 generation of dedicated servers — Data Center Dynamics
- OVHcloud debuts Bare Metal 2026 AMD servers in APAC
- Amazon EC2 Dedicated Hosts now support AMD SEV-SNP — AWS What's New
- Evaluating the Performance Cost of AMD SEV-SNP on Modern EPYC VMs — Phoronix
- Confidential VMs Explained: An Empirical Analysis of AMD SEV-SNP and Intel TDX
- Three multi-tenant isolation boundaries of Kubernetes — Sysdig
- Containers Are Not a Security Boundary — Christian Del Monte
