As enterprises migrate ever more of their operations to the cloud, the question of how to keep data safe has moved from the server room to the boardroom. Amazon Web Services (AWS), the dominant cloud provider, offers a sprawling toolkit for data protection—so sprawling, in fact, that navigating it can feel like exploring a fortress with seven different locking mechanisms, each with its own key. Understanding how these mechanisms work, and how they complement one another, is essential for any organization serious about security.
KMS Key Policies: Who Holds the Lock
At the heart of AWS's encryption architecture sits the Key Management Service (KMS), and at the heart of KMS sits the key policy. A key policy is a resource-based policy attached to a KMS key—the primary mechanism for controlling who can use a given key and how. Every KMS key must have exactly one key policy, and no AWS principal, not even the account root user or the key's creator, has any permissions to a key unless they are explicitly granted them in that policy.
This default-deny posture is a defining design choice. Unlike IAM policies, which are global across an AWS account, key policies are regional—a policy governs access only to the key in the same AWS Region and has no effect elsewhere. The default key policy enables IAM policies to supplement key policies, but this delegation must be explicitly included; without it, IAM policies that attempt to allow access to a key have no effect. Only IAM policy denials can override key policies without explicit permission.
For organizations, the practical implication is that key policies demand careful design. A poorly constructed policy can lock out legitimate users—or, worse, grant access too broadly. AWS recommends designing key policies, IAM policies, grants, and VPC endpoint policies in concert, since KMS keys protect some of the most sensitive resources in an AWS account. The interplay between these layers forms a defense-in-depth strategy: even if an attacker compromises an IAM role, a properly scoped key policy can prevent them from using the key to decrypt data.
CloudHSM: The Vault Within the Cloud
For some workloads, the shared-responsibility model of KMS—where AWS manages the underlying hardware security modules (HSMs)—is insufficient. Regulated industries, such as those handling payment card data or operating as public certificate authorities, may need sole custody of their cryptographic keys. This is where AWS CloudHSM comes in.
CloudHSM provides dedicated, single-tenant HSM instances within the AWS cloud, validated to FIPS 140-2 Level 3 (and, on newer instance types, FIPS 140-3 Level 3). The service is designed so that AWS personnel have no access to customers' keys or data. AWS holds only a limited credential that permits monitoring of HSM health, taking encrypted backups, and publishing audit logs to CloudWatch. All communication between client applications and the HSM is encrypted end to end; AWS cannot see or intercept it.
The operational model is instructive. Customers create a CloudHSM cluster—groups of HSMs spread across multiple Availability Zones that are automatically synchronized and load-balanced. AWS recommends at least two HSMs in separate zones for production workloads, and three or more for mission-critical systems. If an HSM fails, it is automatically replaced without interrupting processing. The hardware itself includes physical and logical tamper-detection mechanisms that trigger key deletion—a process called zeroization—if the device's physical barrier is breached.
CloudHSM integrates with KMS through the custom key store feature, allowing AWS services like EBS, S3, and RDS to use keys that reside in a customer's CloudHSM cluster. It also supports standard cryptographic APIs including PKCS#11, Java JCE, OpenSSL Dynamic Engine, and Microsoft KSP/CNG, making it compatible with third-party applications such as Oracle Database and Apache.
Envelope Encryption: Layers of Security
If KMS is the fortress, envelope encryption is the practice of putting documents inside safes inside vaults. The concept is elegant: rather than encrypting large volumes of data directly with a master key—which would require sending all that data to KMS, creating a performance bottleneck and a security risk—envelope encryption uses a two-tier system.
A master key (the Key Encryption Key, or KEK) resides in KMS and never leaves it. When an application needs to encrypt data, it asks KMS to generate a data key—a short-lived, 256-bit AES symmetric key. KMS returns both a plaintext copy and an encrypted copy of this data key. The application uses the plaintext data key to encrypt its data locally, then discards the plaintext key from memory. The encrypted data key is stored alongside the ciphertext. To decrypt, the application sends only the encrypted data key back to KMS, which decrypts it and returns the plaintext version.
This approach offers several advantages. The master key never leaves KMS's protected boundary, reducing exposure. Large datasets can be encrypted and decrypted locally without round-tripping through a remote service. And re-encrypting data under a new key—say, during key rotation—requires only decrypting and re-encrypting the data keys, not the underlying data itself. Secrets Manager, DynamoDB, S3, and numerous other AWS services all rely on envelope encryption under the hood.
The AWS Encryption SDK abstracts this process further, providing client-side encryption libraries that handle envelope encryption automatically, including data-key caching for performance optimization. For organizations building custom applications, the SDK removes much of the cryptographic heavy lifting.
Secrets Manager: Guarding the Crown Jewels
Passwords, API tokens, database credentials—these are the crown jewels of any application, and their protection demands more than simple encryption. AWS Secrets Manager is purpose-built for this task, and it leans heavily on KMS and envelope encryption to do it.
When a secret is created or its value changes, Secrets Manager requests a new data key from KMS. The data key is encrypted under the KMS key associated with the secret and stored in the secret's metadata. The plaintext data key is used to encrypt the secret value outside of KMS, then immediately removed from memory. Notably, Secrets Manager does not return the encrypted secret or the encrypted data key through any of its APIs—the decryption happens server-side, and only the plaintext secret value is returned to authorized callers.
Customers can choose between an AWS-managed key (aws/secretsmanager) or a customer-managed key for each secret. The AWS-managed key's policy restricts use to requests originating from Secrets Manager itself, using the kms:ViaService condition key—no user can employ it directly. Customer-managed keys offer finer control, allowing organizations to set custom permissions, audit specific operations, and even deny use of the managed key to enforce the use of their own.
Secrets Manager also attaches an encryption context—a set of key-value pairs cryptographically bound to the encrypted data—to every KMS request. This context includes the secret's ARN and version ID, enabling administrators to identify cryptographic operations in CloudTrail logs and use them as authorization conditions. The service supports automatic rotation through Lambda functions, cross-region replication, and fine-grained access control through IAM policies—all layered atop its encryption foundation.
S3 Object Lock: Making Data Indestructible
Encryption protects data from being read by the wrong people. Immutability protects data from being deleted by anyone at all. Amazon S3 Object Lock provides the latter, enforcing a write-once-read-many (WORM) model that prevents objects from being deleted or overwritten for a defined period.
Object Lock offers two retention mechanisms. A retention period specifies a fixed timeframe during which an object version is locked; a legal hold provides the same protection but with no expiration date, remaining in place until explicitly removed. Two retention modes govern how these protections behave. In governance mode, special permissions allow authorized users to alter retention settings or delete objects—useful for testing retention policies before committing to stricter rules. In compliance mode, no user, including the AWS account's root user, can overwrite or delete the object, shorten the retention period, or change the retention mode.
Compliance mode has made S3 Object Lock a cornerstone of ransomware defense strategies. If attackers gain access to an S3 bucket, locked objects cannot be deleted, undermining the extortion model that underpins most ransomware attacks. The feature has been assessed by Cohasset Associates for compliance with SEC Rule 17a-4(f), FINRA Rule 4511, and CFTC Regulation 1.31, making it viable for financial institutions subject to records-retention mandates.
S3 Versioning is automatically enabled when Object Lock is turned on, and the two features work in concert: each object version can have its own retention settings, meaning a new upload creates a new version with its own lock while the old version retains its original protection. For existing data, S3 Batch Operations can apply or extend locks across billions of objects at once.
Cross-Region Key Management: Keys Without Borders
Cloud computing is inherently global, but cryptographic keys have traditionally been regional—confined to the AWS Region where they were created. Multi-Region keys, introduced by AWS KMS, relax that constraint. A set of related multi-Region keys shares the same key material and key ID across different AWS Regions, allowing data encrypted in one Region to be decrypted in another without re-encryption or cross-Region API calls.
The architecture is carefully constructed. A customer creates a multi-Region primary key and then replicates it into selected Regions within the same AWS partition. Each replica is a fully independent KMS key with its own key policy, grants, aliases, and tags—managed separately from its siblings. AWS KMS securely transports key material across Region boundaries during replication, and the keys never leave KMS unencrypted. The primary key serves as the source for shared properties (key ID, key material, key spec), but independent properties like key policies and enable/disable states are not synchronized.
The use cases are compelling. For disaster recovery, multi-Region keys allow encrypted backup data to be decrypted in a backup Region even if the primary Region is down. For global applications, they eliminate the latency of cross-Region KMS calls. For distributed signing systems, multi-Region asymmetric keys can produce identical digital signatures across Regions. And for active-active architectures spanning multiple Regions, they reduce the complexity of managing separate keys for data that moves across boundaries.
There are trade-offs. Multi-Region keys introduce a broader blast radius: if key material is compromised, it is compromised everywhere. AWS recommends creating multi-Region keys only when replication is actually planned and using authorization tools to prevent their creation where single-Region keys would suffice. Existing single-Region keys cannot be converted to multi-Region, a deliberate design choice that preserves data residency and sovereignty guarantees.
Data Masking: Hiding in Plain Sight
Encryption renders data unreadable to those without the key. Data masking takes a different approach: it replaces sensitive values with scrambled or anonymized equivalents, allowing the data's structure to remain useful while concealing its content. On AWS, this is typically achieved through a combination of Amazon Macie, AWS Glue, and AWS Lake Formation.
Amazon Macie uses machine learning and pattern matching to discover personally identifiable information (PII) stored in S3—names, birthdates, account numbers, card numbers, and more. Once Macie identifies sensitive data, its findings can trigger an event-driven pipeline: EventBridge routes the findings to Kinesis Data Firehose, which stores them for processing; an AWS Glue job then reads the findings, masks or encrypts the identified fields, and writes the anonymized data to separate S3 locations.
The masking itself can take several forms. Values can be replaced with dummy data, partially obscured, or encrypted using a KMS key—so that authorized applications can decrypt the original values while human users see only masked versions. This last approach is particularly powerful for machine-learning workflows: a data scientist training a model can run the algorithm against real (encrypted) data without ever seeing the underlying PII, while the model's training function decrypts values programmatically using KMS.
AWS Lake Formation then provides the fine-grained access control layer. Administrators assign LF-tags to databases, tables, and columns, and grant users access based on those tags. A business analyst might see only non-sensitive columns in a customer table, while a data scientist might see all masked columns but not the encrypted originals. Column-based permissions can restrict access at the field level—granting a user access to a customer's ID and email but not their card number, for instance. Revoking the IAMAllowedPrincipals group's blanket Super permissions ensures that Lake Formation's granular controls, rather than broad IAM policies, govern data access.
This layered approach—detection by Macie, transformation by Glue, governance by Lake Formation—reflects a broader philosophy in AWS data protection: no single tool is sufficient, but together they form a coherent defense. The same principle applies across the entire toolkit described here. Key policies govern who can use encryption keys; CloudHSM provides hardware-level key isolation for the most sensitive workloads; envelope encryption keeps master keys safe while enabling performant data encryption; Secrets Manager protects application credentials; S3 Object Lock ensures data cannot be destroyed; multi-Region keys enable global encryption without compromise; and data masking keeps sensitive information hidden even from those who have legitimate access to the systems that store it.
For organizations operating in the cloud, the imperative is not to choose among these tools but to understand how they interlock—and to deploy them with the precision that modern threats demand.