Confidential Computing's Real Tax: SEV-SNP vs TDX vs H100 Confidential Mode

Confidential computing has spent a decade as a compliance checkbox and is now being pulled into production by a concrete commercial need: customers who will not send data to a model they cannot verify. The pitch is clean. Encrypt memory so the host cannot read it, attest the software stack so the customer knows what is running, and let them trust the math instead of the operator.

The pitch is also incomplete, because every one of those guarantees costs throughput, and the cost is not evenly distributed across the stack. Some of it is nearly free. Some of it is 30% and no amount of tuning removes it.

Part One: What memory encryption actually costs

AMD SEV-SNP and Intel TDX both encrypt guest memory with a key the hypervisor does not hold, and both use hardware AES engines in the memory controller to do it. Published benchmarks put the CPU-side overhead in the low single digits for memory-bound workloads, and near zero for compute-bound ones.

That is the part people hear, and it is genuinely good news: if your workload is a CPU service, confidentiality is almost free. A database, an API server, a batch job — the tax is a rounding error, and the operational complexity is a boot parameter and an attestation flow.

The trouble starts when the workload is not a CPU service.

Part Two: Where the tax concentrates

Three places.

Attestation itself. Every confidential VM must produce a report the relying party verifies, and that report has to be tied to a key the guest generates. The flow is a round trip: guest generates key, requests report, sends report to verifier, verifier checks signature chain against the vendor's root, returns a token, guest unwraps a secret. That is one to three seconds of latency at startup, which matters for autoscaling and for anything that spawns short-lived workers.

IO. Confidential VMs cannot trust the hypervisor's device emulation, so virtio has to be protected: shared memory regions, bounce buffers, an encrypted channel. Every network packet and every disk block takes an extra copy. For a workload that moves a lot of bytes, this is where a double-digit percentage disappears.

GPUs. This is the expensive one. H100 confidential computing mode encrypts the PCIe path between host and device and adds bounce buffers for every transfer. Published figures from early access show roughly 10-20% throughput loss for large-model inference, and worse for small-batch workloads where the transfer is a larger fraction of the step.

Part Three: The number that decides adoption

Combine the throughput loss with the price of confidential SKUs and you get an effective cost premium. My model: about 4-5% for CPU-only confidential VMs, around 22% for H100 confidential mode, and up to 38% for confidential GPU SKUs that also carry a price premium.

Now compare that to willingness to pay. Regulated workloads — health records, financial positions, anything under a data processing agreement with an audit clause — will pay a large premium because the alternative is not running the workload in the cloud at all. Workloads outside that category will not, because the benefit is invisible to their users.

So the market splits cleanly: confidentiality is a compliance product, not a performance product. Teams that adopt it for architectural elegance rather than a specific contractual requirement end up paying 22% for a property nobody asked for.

Part Four: The architecture that makes it affordable

Three patterns that work.

Split the workload. Put the CPU-side orchestration, the tokenisation, and the business logic in a confidential VM where the tax is 4%, and send only the tensor operations to the confidential GPU. Most of the data-handling surface is then protected at near-zero cost, and the expensive part does the minimum work necessary.

Batch hard on the GPU. The confidential-mode overhead is dominated by transfers per kernel launch, so larger batches amortise it. A confidential H100 at batch 1 is a bad deal; at batch 64 it is close to a plaintext H100 at batch 32 in cost per token.

Cache attestation results. Do not re-attest on every request. Attest once per instance, cache the token with a TTL, and treat the instance as trusted until the TTL expires. This turns a startup cost into an infrastructure cost.

Part Five: The thing to measure before you commit

Benchmark your own workload, not the vendor's. The published overhead figures are for large-batch inference and memory-bound microbenchmarks; your workload is probably neither.

Specifically measure three things: tokens per second at your production batch size, p99 latency including the encrypted transfer, and the number of times per hour your autoscaler would need to attest a new instance. The third number is the one that surprises people, because a scale-to-zero design can attest hundreds of times a day.

Then compare the premium to the deal. If a customer's contract requires verifiable execution, the 22% is a cost of goods. If it does not, you are buying insurance against a threat model your customer has not articulated.

The transferable lesson

Every security property is a trade against a threat model, and the trade only makes sense when the threat is named. Confidential computing names it precisely: the cloud operator. If that is not a threat you are contractually obligated to address, the tax buys nothing.

The broader pattern is that hardware security features arrive with uneven costs. Encryption of memory is cheap because it is a wide, parallel operation. Encryption of a serial interconnect is expensive because it is on the critical path of every transfer. Knowing which side of that line a feature sits on tells you more about its adoption curve than any marketing deck.

SOL: HCqPmPJM3NVtS6YrmVaTZYnuP8XZ2PFgQZKT94VK1LkS
Creating this takes real effort — thank you for the support.