Who can decrypt this data?

“Encrypt it with KMS” is not a complete design. First name the data service, key owner, administrators, users, accounts, Regions, audit need, revocation need, and recovery path.

AWS owned keys require the least customer operation and offer the least customer control. AWS managed keys are visible in your account, but the AWS service controls their policy and lifecycle.

Customer managed KMS keys add customer-controlled policy, audit, disablement, deletion scheduling, rotation choices, and cross-account use. That control also adds cost, quotas, and lockout risk.

AWS CloudHSM fits an explicit need for dedicated HSM control. It is not the default upgrade for “stronger encryption”; it carries much more operation.

Choose the least-operational key type that still meets audit, revocation, tenancy, integration, and recovery requirements.

Separate key administrators from data users. One role can maintain policy and lifecycle without Decrypt; another can use only the cryptographic operations required by the workload.

Envelope encryption avoids sending large objects through KMS. The application or AWS service uses a data key to encrypt the data, then KMS protects that data key with a KMS key.

The encrypted data key can be stored beside the ciphertext. It is not useful as plaintext until an authorized KMS decrypt operation recovers the data key.

Encryption context can bind non-secret context to a cryptographic operation and policy where supported. A mismatched context can correctly prevent decryption.

KMS keys are Regional. A multi-Region key uses related key material in a primary and replicas, but each Regional key has its own policy and operational state.

Rotating eligible key material keeps the same logical key and old decrypt capability. It does not rewrite existing ciphertext. Disabling or deleting the key can make durable data unreadable.

For example, an S3 object can store ciphertext and its encrypted data key together. Reading the object still requires data access plus an authorized KMS path that can recover the data key.

Every KMS key has a key policy. IAM works only when the key policy directly allows the principal or delegates authority to the account's IAM policies.

Cross-account use needs both sides. The key-owning account authorizes the external principal in the key policy, and the caller account grants the required KMS action in IAM. The data policy must also allow access to the encrypted data.

Separate key administration from key use. Producers may need Encrypt or GenerateDataKey. Readers may need Decrypt. Neither role automatically needs to change policy or schedule deletion.

Keep a tested recovery administrator path that does not depend on the application role. Monitor policy changes, disablement, and deletion schedules.

A backup is not recoverable merely because its bytes exist. A restore drill must test the actual principal, key policy, IAM, data-service policy, Region, and encryption context.

Run negative tests as well as a successful decrypt. Test another prefix, a role from the wrong account, policy administration by an application role, and recovery through the independent administrator path.