AWS KMS Manages Encryption Keys. The Keys Do Not Carry Governance.

Vendor and product reality

KMS is core AWS infrastructure. Symmetric KMS keys (AES-256-GCM under the hood) handle the bulk of envelope encryption use cases, where a data key is generated under a customer master key, used briefly in plaintext within the calling service, and then discarded. Asymmetric KMS keys (RSA, ECC, and increasingly SM2) support signing, verification, and key wrapping for cross-boundary scenarios. Grants allow temporary, scoped delegation of cryptographic permissions to ephemeral principals such as Lambda execution roles or EC2 instance profiles. Custom key stores backed by CloudHSM let regulated tenants satisfy single-tenant HSM requirements while continuing to use the KMS API surface. CloudTrail records every API call, with separate data-event logging for the cryptographic operations themselves.

Pricing is per-key-month plus per-request, with custom key store pricing reflecting the underlying CloudHSM cluster. The product's commercial position is essentially neutral: KMS is everywhere AWS is, integrated with virtually every AWS service that handles data at rest, and used by default for S3, EBS, RDS, Secrets Manager, and dozens of others. The integration is so thorough that for most AWS-native applications, KMS is not an explicit dependency to evaluate; it is an ambient property of the platform. This ambient quality is precisely what makes the structural gap easy to overlook: the cryptographic layer feels like governance because access to it is governed, but the cryptography itself is not the governance boundary.

The architectural gap

KMS key policies and IAM policies control who can encrypt, decrypt, and manage keys. When a service calls KMS to decrypt data, IAM evaluates whether the caller has permission for the kms:Decrypt action on the specific key, optionally constrained by encryption context, source VPC, or other condition keys. This is access governance at the key operation level, and it is well-implemented. But once the data is decrypted, KMS has no further role. The decrypted plaintext enters the calling service's memory with no cryptographic constraints on its use. The governance boundary ends at the decrypt call. What happens to the plaintext after that, whether it is logged, forwarded to a downstream service, used to train a model, or accessed by an agent acting on behalf of an unrelated principal, is entirely up to the application. The cryptographic system has done its job. The governance question has been deferred to whatever non-cryptographic system the application happens to use.

This separation between rules and data is the architectural problem. The rules about how decrypted material may be used live in IAM, in application code, in compliance documentation, in DLP scanners, in service control policies, and in human procedure. None of those rules are bound to the data cryptographically. A piece of decrypted PHI carries no signed assertion about its permissible scope of use. An agent that obtains it through legitimate kms:Decrypt access has no machine-checkable constraint on what it may do next. Compliance is achieved by perimeter argument: every system that might touch the data is individually audited, and the conjunction is presented as evidence. This works until the perimeter changes, at which point the entire compliance posture has to be re-established from scratch.

Key lifecycle is also not governance lifecycle. KMS provides annual key rotation for symmetric keys, scheduled key deletion with a recovery window, and CloudTrail-based usage auditing. These manage the lifecycle of the cryptographic primitive. But the governance lifecycle of the operations those keys enable, what actions are permitted, what compliance requirements apply, what audit trail is required, what data residency constraints attach, exists in separate systems that are not cryptographically linked to the keys at all. A key that has been rotated does not carry forward its prior governance state, because it never carried governance state to begin with.

The post-quantum migration timeline sharpens all of this. NIST has standardized ML-KEM and ML-DSA, and KMS will eventually offer post-quantum algorithms alongside classical ones. But because policy is not cryptographically bound to data, every system that holds previously-encrypted material has to be individually re-evaluated, re-encrypted, and re-audited as part of the migration. The cliff is not the cryptography itself; it is the lack of a portable governance artifact that travels with the data through the transition.

What cryptographic governance provides

Cryptographic governance binds policy to operations cryptographically. Every mutation, every data access, every agent action is gated by a signed policy reference attached to the data itself. The governance does not live in a separate IAM system that checks permissions at the point of access; it is a cryptographic artifact that travels with the payload, validated at every step by any system that processes it. The rules ship with the data.

In a cryptographically governed system, decrypted material would carry governance constraints that persist through every downstream operation that touches it. An agent accessing sensitive data would be validated not just for decryption permission, but for the specific use it intends, against the signed policy bound to the payload. A downstream service that receives the data inherits the constraint without needing to re-authenticate against a central authority. Audit becomes a property of the artifact rather than a reconstruction from logs. Migration, including post-quantum migration, becomes a matter of re-anchoring the policy artifact rather than re-establishing the perimeter argument from scratch.

Composition pathway

The path from KMS to cryptographic governance is compositional, not replacement. KMS continues to provide HSM-backed key custody, hardware attestation, and the operational rigor of multi-tenant key management at AWS scale. The governance layer sits above KMS and consumes it as a custody primitive. When data is encrypted, the encryption operation produces both the ciphertext and a signed governance artifact that references the KMS key, the policy applicable to the data, and the lineage of policy decisions that produced it. When data is decrypted, the consuming system receives both the plaintext and the policy artifact, and any further operation on the plaintext is validated against the artifact before proceeding.

For organizations already using grants and encryption context aggressively, the composition is natural: the encryption context becomes the binding point for the policy artifact, and grants become the executor of governance-validated operations rather than the policy authority itself. Custom key stores remain available for tenants whose compliance posture requires single-tenant HSM custody. The change is not in where keys live; it is in what travels with the ciphertext.

Commercial and licensing posture

AWS continues to be paid for KMS as it is paid today: per key, per request, plus CloudHSM where applicable. The cryptographic governance layer is licensed separately under the Adaptive Query primitive terms covering cryptographic governance. There is no migration event and no displacement of AWS revenue. The governance layer is additive, integrating through the existing KMS API surface and CloudTrail data plane. AWS KMS solved key management at a level of operational rigor that few organizations could replicate independently. The remaining gap is in governance scope: whether cryptographic policy can govern the entire lifecycle of data and operations rather than ending at the point of key access. Closing that gap does not require leaving KMS. It requires shipping the rules with the data.