AWS Certified Solutions Architect – Associate

AWS KMS key types, envelope encryption and KMS vs CloudHSM

You create and control customer managed keys, including their key policy, rotation, deletion and sharing with other accounts. AWS managed keys (alias aws/<service>) are created by a service in your account, can only be used by that service for principals in the same account, and cannot be shared cross-account. For large data, KMS uses envelope encryption: a data key encrypts the data and the KMS key encrypts the data key.

The three key types

Customer managed keys are in your account and fully under your control: key policy, IAM policies, grants, enable and disable, rotation, tags, aliases and deletion. They have a monthly fee and a per-use fee.

AWS managed keys are in your account but created and used by a service on your behalf. You can view them, view their key policies and audit their use in CloudTrail. You cannot change their key policy, change their rotation, or schedule them for deletion, and you cannot use them directly in cryptographic operations. They rotate every year. There is no monthly fee, but use can be charged.

AWS owned keys live in an account the service owns. You cannot view, audit, change or delete them, and they cost you nothing.

Envelope encryption and data keys

The Encrypt operation takes at most 4,096 bytes with a symmetric KMS key. It is meant for small values such as a database password. For anything larger, call GenerateDataKey. It returns a plaintext data key and a copy encrypted under your KMS key.

Encrypt the data with the plaintext data key outside KMS, remove the plaintext key from memory, and store the encrypted data key next to the data. To decrypt, send the encrypted data key to Decrypt, get the plaintext key back, decrypt the data, and remove the key from memory again. KMS does not store, track or use data keys.

S3 SSE-KMS follows this pattern. S3 Bucket Keys can cut KMS request costs by up to 99 percent by reducing the requests S3 makes to KMS. With SSE-KMS the KMS key must be in the same Region as the bucket, and S3 accepts only symmetric keys.

Using a key from another account

Cross-account use needs two policies. The key policy in the key's account must allow the other account or its roles. An IAM policy in the other account must then give those permissions to its users or roles. Neither one is enough alone. Cross-account permission works only for cryptographic operations and a few others such as DescribeKey and CreateGrant. Callers in another account must name the key by key ARN or alias ARN.

Objects encrypted with the AWS managed key aws/s3 cannot be shared across accounts. Use a customer managed key and allow the other account in its key policy. When the other account names the key on upload, use the full key ARN. An alias is resolved in the requester's account, which can encrypt the data under the requester's key instead of the bucket owner's.

Rotation, and when CloudHSM fits

Automatic rotation is optional for customer managed keys. The default period is 365 days and you can set a custom period. You can also rotate on demand. Rotation replaces only the key material: the key ID and ARN stay the same, older material is kept to decrypt older data, and existing data keys are not re-encrypted. Asymmetric keys, HMAC keys and keys in custom key stores cannot rotate automatically.

AWS CloudHSM gives you single-tenant HSMs. Clusters in FIPS mode are validated to FIPS 140-2 level 3 or FIPS 140-3 level 3. You choose the algorithms and keys and manage HSM users yourself, outside IAM. Applications built on PKCS #11, JCE, CNG or KSP move to it with fewer changes. AWS points teams that want managed keys without operating HSMs to KMS.

Where the exam catches people

Believing you can edit the key policy of aws/s3 to share it: you cannot change an AWS managed key's policy, so cross-account sharing needs a customer managed key.
Believing Encrypt can encrypt a large file: it accepts at most 4,096 bytes with a symmetric key, so large data uses a data key from GenerateDataKey.
Believing key rotation changes the key ID or re-encrypts existing data: only the key material changes, and older material is kept for decryption.
Believing a key policy entry is enough for another account: the other account also needs an IAM policy that allows the key's use.
Believing KMS meets a single-tenant HSM requirement where you pick the algorithms: that is AWS CloudHSM.