How to Deploy Google Cloud Confidential Computing (CVM) with AMD SEV-SNP

Traditional cloud security focuses on two pillars: encrypting data at rest (using AES on the storage drives) and encrypting data in transit (using TLS over the network). However, there has always been a fundamental vulnerability: data in use. When an application needs to process data, it must decrypt the data and place it in plain-text inside the physical RAM of the cloud hypervisor. If a highly sophisticated attacker compromises the hypervisor operating system, they can read the RAM and steal the keys.

Confidential Computing closes this final security gap. By leveraging hardware-based Trusted Execution Environments (TEEs) built directly into modern processors, cloud providers can mathematically guarantee that even they cannot read your memory.

In Google Cloud, this is achieved using Confidential VMs (CVMs) backed by AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) technology. This guide explains how this hardware cryptography functions and how to deploy a CVM to protect highly regulated, in-use workloads.

Understanding AMD SEV-SNP Architecture

AMD’s Secure Encrypted Virtualization (SEV) places a dedicated, isolated cryptographic co-processor inside the physical AMD EPYC CPU silicon.

1. Memory Encryption: When you deploy a Confidential VM, the AMD Secure Processor generates an ephemeral, AES-128 (or AES-256) memory encryption key. This key is stored securely within the hardware. The Google Cloud hypervisor (the host OS) never sees this key.
2. In-Line Decryption: As the VM writes data to RAM, the CPU silicon encrypts the data on the fly. As it reads data from RAM back into the L1 cache for processing, it decrypts it.
3. The Threat Model: If a Google engineer, a malicious administrator, or a piece of hypervisor malware attempts a memory-scraping attack against the physical RAM bus, they will only retrieve encrypted ciphertext.
4. SNP (Secure Nested Paging): The latest iteration, SNP, adds hardware-enforced memory integrity. It prevents the hypervisor from maliciously mapping a different physical memory page into the VM’s virtual memory space, defeating complex “memory replay” or “aliasing” attacks.

Step 1: Identifying Compatible Machine Types

Because Confidential Computing relies on physical AMD CPU features, you cannot deploy it on just any instance type. It is specifically supported on the N2D, C2D, and C3D machine families (which are powered by 2nd, 3rd, and 4th generation AMD EPYC processors).

Furthermore, you must select a Google Cloud region that supports these specific machine types and has Confidential Computing capacity enabled.

Step 2: Deploying a Confidential VM via gcloud

Deploying a CVM is remarkably straightforward. There are no massive architectural changes required in your application code; the hardware abstraction handles the encryption entirely transparently to the guest OS.

However, you must use a compatible OS image. Most modern images (Ubuntu 22.04, RHEL 9, Windows Server 2022) include the necessary NVMe and VirtIO drivers compiled to support memory encryption.

Use the gcloud CLI to deploy the instance. The critical flags are --machine-type, --confidential-compute, and --maintenance-policy=TERMINATE.

gcloud compute instances create my-secure-cvm \
    --zone=us-central1-a \
    --machine-type=n2d-standard-4 \
    --image-family=ubuntu-2204-lts \
    --image-project=ubuntu-os-cloud \
    --confidential-compute \
    --maintenance-policy=TERMINATE

Crucial Note on Maintenance Policy: Because the encryption keys are physically locked to the silicon of the specific CPU socket the VM is running on, Google Cloud cannot perform Live Migration on Confidential VMs. If the underlying hardware requires maintenance, the VM must be terminated and restarted on a new node (where a new key will be negotiated). Therefore, your architecture must be highly available (e.g., using Managed Instance Groups).

Step 3: Verifying the Confidential Status

Once the VM is running, you must verify that the hardware encryption is actively protecting the memory.

SSH into the newly created Ubuntu Confidential VM:

gcloud compute ssh my-secure-cvm --zone=us-central1-a

Query the kernel’s message buffer (dmesg) to confirm that the AMD SEV drivers initialized the memory encryption during boot:

dmesg | grep -i sev

You should see output similar to:

AMD Memory Encryption Features active: SEV SEV-ES SEV-SNP

This confirms that the Linux guest OS is aware that it is running inside a hardware-encrypted trusted execution environment, and that Secure Nested Paging (SNP) is active.

Step 4: Integrating with vTPM for Remote Attestation

While memory encryption is the primary feature, true Zero Trust requires Attestation. How do you cryptographically prove to a remote auditor (or a key management server) that the VM is genuinely running on AMD SEV-SNP silicon and not a software emulator?

Google Cloud Confidential VMs automatically enable the Virtual Trusted Platform Module (vTPM). The hypervisor injects a cryptographic health certificate (an attestation report) into the vTPM generated by the AMD Secure Processor.

You can use the Go-based go-tpm-tools package to extract this attestation report and pass it to a remote relying party (like a KMS server), proving the hardware’s integrity before the KMS server releases sensitive decryption keys to the application.

Conclusion

Confidential Computing represents the final frontier in cloud data security. By deploying Google Cloud Confidential VMs backed by AMD SEV-SNP, architects can construct environments where data remains cryptographically shielded during execution. This allows the migration of the most heavily regulated, privacy-sensitive workloads (such as genomic sequencing or raw financial analytics) into the public cloud without sacrificing absolute, hardware-enforced data sovereignty.