AWS Encryption and Data Sovereignty - Hardware-Level Isolation from KMS to Nitro Enclaves
We explain hardware-level encryption and data sovereignty assurance through AWS KMS, CloudHSM, and Nitro Enclaves, and compare design differences with other cloud providers.
The Layered Architecture of Encryption as a Design Principle
AWS's encryption strategy is designed as a layered architecture that you can choose from based on your use case and requirements. The first layer is server-side encryption with AWS managed keys, available on services such as S3, EBS, and RDS. In this layer, stored data is encrypted without users managing the keys, depending on the supported service and its settings. The next layer is KMS (Key Management Service) customer managed keys, where you can manage key rotation policies, usage audit logs, and access control through IAM policies yourself. For even stricter requirements, CloudHSM provides key management on dedicated hardware that, for clusters in FIPS mode, is validated at FIPS 140-2 Level 3 or FIPS 140-3 Level 3. The top layer is Nitro Enclaves, which isolates even data in use at the hardware level. This layered architecture allows you to choose an encryption level that fits your regulatory requirements and security policies.
KMS Design and Envelope Encryption
AWS KMS employs a technique called envelope encryption. Data itself is encrypted with a data key (DEK), and that data key is encrypted with a KMS key - a double-layered structure. There's a clear reason for this design. If you directly encrypt large amounts of data with the KMS key, the risk of KMS key exposure increases, and re-encrypting all data becomes necessary when rotating the key. With envelope encryption, only the data key needs to be re-encrypted during KMS key rotation - re-encrypting the data itself is unnecessary. KMS keys are protected by FIPS 140-3 Security Level 3 validated HSMs (Hardware Security Modules) and never leave AWS KMS unencrypted. Key usage is recorded in CloudTrail, enabling tracking of who used which key and when. With multi-region keys, you can maintain encryption during cross-region data replication while decrypting with local keys in each region.
Dedicated Hardware Key Management with CloudHSM
CloudHSM is a service that provides dedicated HSM appliances within your VPC, validated at FIPS 140-2 Level 3 or FIPS 140-3 Level 3 for clusters in FIPS mode. A difference from KMS is that the customer controls the algorithms and keys used. With KMS, you create and control keys in an AWS managed service, while with CloudHSM the data plane is end-to-end encrypted and not visible to AWS. Only the customer holds the HSM administrator credentials, and AWS is responsible only for the physical hardware operation. This separation is essential when financial regulations or government agency requirements demand a state where the cloud provider cannot access the keys. CloudHSM clusters can span multiple AZs with automatic key synchronization between HSMs, resulting in a configuration with high availability. It supports industry-standard APIs like PKCS#11, JCE, and CNG, making migration from existing on-premises HSMs relatively straightforward. CloudHSM can also be used for key management in Oracle TDE and Microsoft SQL Server transparent data encryption.
Nitro Enclaves - Hardware Isolation for Data in Use
Traditional encryption protects data at rest and in transit, but data in use exists in a decrypted state in memory, making it difficult to protect. Nitro Enclaves is an Amazon EC2 feature that addresses this challenge. Nitro Enclaves creates an isolated virtual machine within an EC2 instance, providing independent CPU and memory space that is inaccessible even from the parent instance. The Enclave has no persistent storage, interactive access, or external networking. Even the root user of the parent instance cannot access data inside the Enclave. This isolation is handled by the Nitro Hypervisor. By combining KMS with Nitro Enclaves, you can build an architecture where encrypted keys are decrypted only within the Enclave and sensitive data processing is completed entirely within the Enclave. This is suited for use cases requiring data-in-use protection, such as medical data analysis, financial transaction processing, and personal information matching.
Data Sovereignty and Comparison with Other Clouds
Data sovereignty refers to the principle that data should be managed according to the laws of the country where it physically resides. AWS provides mechanisms for data sovereignty requirements by combining geographic data control through region selection, customer-managed encryption keys through KMS and CloudHSM, and data-in-use protection through Nitro Enclaves. Azure offers confidential VMs based on AMD SEV-SNP under its Confidential Computing initiative. Azure's confidential VMs take the approach of encrypting the entire VM at the hardware level, without requiring application modifications. On the other hand, Nitro Enclaves takes a design that isolates only part of the application into the Enclave, offering the flexibility to minimize the scope of protection. GCP provides Confidential VMs and Confidential GKE Nodes, and also offers Cloud HSM as a dedicated HSM service equivalent to AWS CloudHSM.
Summary
AWS's encryption strategy provides a layered architecture ranging from encryption with managed keys, to KMS customer managed keys, to CloudHSM dedicated hardware, to Nitro Enclaves data-in-use protection - all selectable based on requirements. Efficient key management through envelope encryption, records of key usage through CloudTrail, and hardware-level isolation through the Nitro Hypervisor form the technical foundation for ensuring data sovereignty. Azure's Confidential Computing takes a whole-VM encryption approach, while AWS provides isolation with Nitro Enclaves and key management with CloudHSM. Applying encryption at each stage of data storage, transit, and processing, while retaining key management authority within your organization, is the path to achieving data sovereignty in the cloud era.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
If this page and the official documentation disagree, treat the official documentation as authoritative.