When migrating highly sensitive workloads to the public cloud (such as financial trading algorithms, cryptographic key generation services, or patient healthcare data processing), traditional encryption paradigms are insufficient. While standard Azure features encrypt data at rest (on the physical disks) and in transit (over TLS), the data must still be decrypted in the server’s physical RAM to be processed by the CPU. If a malicious hypervisor administrator, a compromised host operating system, or a rogue neighboring tenant manages to perform a memory dump of the physical host, they could extract plaintext passwords and proprietary algorithms directly from RAM. To close this final security gap, Microsoft introduced Azure Confidential Computing utilizing hardware-backed Intel SGX (Software Guard Extensions) Secure Enclaves.
The Architecture of Intel SGX Enclaves
Intel SGX fundamentally alters the CPU’s execution architecture. It allows an application to instantiate a mathematically sealed region of physical memory called an Enclave.
When a Confidential Virtual Machine (running in Azure’s DC-series infrastructure) executes code inside the SGX Enclave, the data and code are cryptographically isolated at the hardware level. The CPU’s integrated Memory Encryption Engine (MEE) encrypts the RAM utilizing a key generated by the CPU silicon itself—a key that neither the Azure hypervisor, the Microsoft cloud administrators, nor the guest operating system kernel can ever access.
Even if an attacker gains absolute root privileges on your Linux or Windows Virtual Machine and attempts to read the memory address space belonging to the Enclave, the CPU hardware intercepts the request and returns only mathematically useless ciphertext. The data remains decrypted only inside the physical CPU package during active execution.
Deploying a Confidential Virtual Machine
To leverage SGX Enclaves, you cannot use standard, general-purpose Azure VMs (like the D-series or E-series). You must deploy a specialized Confidential VM from the DC-series family.
- Log in to the Azure Portal and initiate the creation of a new Virtual Machine.
- In the Security type dropdown, you must select Confidential virtual machines.
- Select a compatible Image. Azure provides specialized Ubuntu Server and Windows Server images optimized for confidential computing (e.g., Ubuntu 20.04 LTS Confidential Computing).
- Select a Size from the DCsv2, DCsv3, or DCdsv3 series. Only these specific instances possess the underlying Intel Xeon processors equipped with the SGX instruction set.
- Deploy the Virtual Machine into your Virtual Network (VNet).
Refactoring Applications for the Enclave
Deploying the hardware is only the first step; your application must be explicitly engineered to interact with the SGX instruction set. A standard Python script or Node.js application cannot automatically run inside an Enclave.
To execute code within the Enclave, developers must partition their application into two distinct components:
- The Untrusted Component: This is the standard application (the web server, the database connector) running in the normal OS environment.
- The Trusted Component (The Enclave): This is the highly sensitive code (e.g., the cryptographic signing function or the proprietary trading logic) compiled utilizing an SGX SDK (like the Open Enclave SDK or the Intel SGX SDK).
When the Untrusted Component needs to process a credit card transaction, it passes the encrypted payload into the Enclave via a specialized ECALL (Enclave Call). The Enclave decrypts it, processes it safely out of reach of the OS kernel, and returns the encrypted result.
Utilizing Confidential Containers (Lift and Shift)
Because rewriting millions of lines of legacy code to support explicit SGX ECALLs is often impossible for enterprise organizations, Azure supports Confidential Containers on Azure Kubernetes Service (AKS).
By deploying specialized wrapper technologies like Gramine or Occlum (Library OSes), you can take an unmodified, pre-compiled Docker container (like a standard Redis or Nginx image) and force it to run entirely within an SGX Enclave. The Library OS translates standard Linux system calls into the appropriate SGX instructions.
You define a new node pool in AKS utilizing the DC-series VM sizes. You then deploy your standard Kubernetes YAML manifest, annotating the deployment to utilize the Gramine runtime. The entire containerized application is lifted and shifted into the hardware-protected enclave, instantly shielding your most critical intellectual property from infrastructure-level compromise without altering a single line of application source code.