You enable automatic key rotation on a customer managed symmetric AWS KMS key. What actually changes, what happens to data already encrypted under it, and when would you instead create a new key and repoint an alias?

## What rotation does to the key A KMS key is a container with an identity (key ID, ARN, aliases, policy, grants, tags) and *backing key material* inside it. Automatic rotation, enabled with `EnableKeyRotation`, changes only the material. On each rotation KMS generates new backing key material and marks it current; every subsequent `Encrypt` or `GenerateDataKey` uses it. Everything about the key's identity is untouched. Critically, KMS **keeps all previous backing keys** for the life of the KMS key. A ciphertext blob records which backing key produced it, so `Decrypt` picks the right one automatically. You cannot delete an individual old backing key, and you never need to know one exists. The practical consequence is that rotation is invisible and safe: no config change, no re-encryption, no window in which old ciphertext is unreadable. ## What rotation does not do It does not re-encrypt anything. Data encrypted last year is still protected by last year's backing key, exactly as before. So: - Rotation **does not** make previously exposed data safe. If a plaintext data key leaked, rotating the KMS key changes nothing about that data key or the object it opens. - Rotation **does not** revoke anyone's access. Access is governed by the key policy, IAM, and grants. - Rotation **does not** retire old material. As long as the KMS key exists, so does every backing key it ever had. What it does buy is a bound on how much *new* data any single piece of backing key material protects, which is a real cryptographic hygiene property and is what most compliance frameworks are actually asking for when they say "rotate your keys annually". ## Cadence and scope Automatic rotation applies to symmetric encryption KMS keys with KMS-generated key material. The default rotation period is 365 days; since 2024 the period is configurable via `RotationPeriodInDays` (from 90 days up to 2560), and `RotateKeyOnDemand` performs an immediate rotation outside the schedule. AWS managed keys rotate automatically about once a year and the cadence is not yours to change. Keys with imported key material and asymmetric keys are not covered by the standard automatic-rotation scheme — for those, rotation means creating new material or a new key and managing the cutover yourself. Rotation is not free of cost implications either: rotation itself is not billed per operation the way cryptographic calls are, but a rotated key that also exists as multi-Region replicas propagates its new material to those replicas, and each replica is a separately billed key. ```bash aws kms enable-key-rotation --key-id alias/payments --rotation-period-in-days 180 aws kms get-key-rotation-status --key-id alias/payments ``` ## Manual rotation, and when you actually need it Manual rotation means creating a genuinely new KMS key and moving traffic to it. The mechanism that makes this bearable is the **alias**: application config names `alias/payments`, and `UpdateAlias` repoints that alias at the new key. New encrypt operations immediately use the new key; decrypts of old data continue to reference the old key ARN embedded in their ciphertext blobs, so the old key must stay enabled until every object has been re-encrypted or aged out. You choose manual rotation when: - The key material may be compromised, or the key spec must change (symmetric to a different spec, KMS-generated to imported, single-Region to multi-Region). - A regulator or contract requires that data be re-encrypted under fresh material on a schedule, not merely that new data use fresh material. - You are separating a tenant or an environment onto its own key for blast-radius or erasure reasons. The cost is real work: you have to enumerate and rewrite the data. For envelope-encrypted objects, `kms:ReEncrypt*` re-wraps a data key from the old KMS key to the new one server-side without exposing the plaintext key — that rewrites the small blob, not the bulk ciphertext, which makes the migration far cheaper than decrypting and re-encrypting whole objects. It does, however, require permission on both keys. ## The related question interviewers slide into If the requirement is "make this data permanently unreadable", the answer is not rotation at any cadence — it is scheduling the key for deletion, with its 7-to-30-day waiting period, so that every data key wrapped under it becomes unrecoverable. Rotation and destruction are different tools; conflating them is the most common error in this area.