6 KMS Key Rotation Decisions to Make Before Enabling
Enabling automatic KMS key rotation is almost always the right call, but the correct configuration is six decisions, not a single toggle. On AWS, automatic rotation on an AWS customer managed key generates new cryptographic material every year, with a default rotation period of 365 days that you can customize per key. Google Cloud KMS creates new key versions on the schedule you define for symmetric keys. Azure Key Vault applies a per-key rotation policy that creates new versions on your interval and can notify you before expiry. None of the three re-encrypts your existing data, which is the most misunderstood fact about rotation.
What rotation actually does
Key rotation replaces the wrapping key material, not the ciphertext it already protected. On AWS, the KMS key remains the same logical resource with the same key ID, and decryption transparently selects the exact key material version that encrypted each ciphertext, so applications need no code changes. AWS KMS retains every version of key material even when rotation is disabled, deleting material only when the key itself is deleted.
Google behaves differently at the version level: in Google Cloud KMS, rotation creates new active key versions but does not re-encrypt your data, and previous versions remain active until they are destroyed. That retention has a direct cost consequence, because old versions keep billing until you destroy them, and Google’s documentation tells you to verify a version is no longer in use before destroying it.
Azure sits between the two. Key Vault re-wraps data encryption keys with the new key version but leaves the underlying data encrypted under the old wrapped DEKs, which is why both old and new versions must stay enabled until re-wrapping completes. Microsoft’s guidance is blunt about propagation timing: Azure services can take from one hour to 24 hours or more to detect and apply a new key version after rotation, so you cannot disable the old version on a fixed timetable. Check the specific service documentation before retiring any old version.
How each provider rotates
| Provider | Rotation unit | Default or guidance | What changes | Old material handling |
|---|---|---|---|---|
| AWS KMS | Key material on the same key | Every year by default; custom period in days | Key ID unchanged; decryption picks the correct material version | All material retained; extra storage billed up to the second rotation |
| Google Cloud KMS | New key version | Schedule you define; no automatic rotation for asymmetric keys | New active version becomes current | Previous versions stay active and bill until destroyed |
| Azure Key Vault | New key version via rotation policy | Policy-driven; best practice calls for rotation at least every two years | Versionless key URI picks up the newest version | Old and new versions enabled until DEK re-wrapping completes |
The policy knob differs too. Azure Key Vault rotation policies enforce a minimum rotation interval of seven days from creation and from the expiration time, with Event Grid notifications available ahead of expiry. AWS exposes a rotation period you can shorten below the annual default, plus on-demand rotation that does not disturb the automatic schedule. Google lets the schedule trigger on key age or on the volume of messages encrypted with a version.
Six decisions before enabling
- Decide which keys rotate. Wrapping keys rarely face cryptographic exhaustion; AWS itself notes KMS keys are used far less often than the data keys they wrap, so real rotation drivers are usually compliance or contract rules. Inventory keys by driver before touching settings.
- Pick the period against the rule. If a standard such as PCI DSS requires regular rotation, a defined automatic period beats irregular manual work; Google’s documentation explicitly warns against relying on manual rotation as a primary control. The AWS default of 365 days may not satisfy a stricter internal policy.
- Check key-type eligibility. Automatic rotation is symmetric-only in practice: AWS limits it to symmetric encryption keys with AWS-generated material, leaving asymmetric, HMAC and custom key store keys to manual rotation, and Google Cloud KMS does not support automatic rotation of asymmetric keys because the new public portion must be redistributed.
- Plan version lifecycle and cost. Google versions bill until destroyed, AWS caps extra key-material storage charges at the second rotation, and Azure charges per scheduled rotation. Budget for retention, not just the rotation event.
- Use version-transparent references. Reference keys by alias or versionless URI so new material is picked up without a deployment; Azure requires this pattern to avoid decrypt and unwrap failures after rotation.
- Wire the evidence. Rotation you cannot prove did not happen. AWS writes a RotateKey event to CloudTrail and an EventBridge event, and Azure Key Vault can emit a near-expiry Event Grid notification. Route those into the same protected pipeline you use for audit log integrity controls, and alert when a scheduled rotation is missed.
What rotation will not fix
AWS is explicit on this point: key rotation has no effect on the data the key protects, does not rotate the data keys the KMS key generated, and will not mitigate a compromised data key. Rotation is hygiene, not incident response. If you suspect a specific key version is compromised, Google’s guidance is to disable that version and revoke access to it immediately, then re-encrypt what matters rather than waiting for the next scheduled rotation.
Rotation also does not compensate for weak access control around the key itself. Who can administer the rotation policy matters as much as the interval: in Azure, managing rotation requires the Key Vault Crypto Officer role, and that grant belongs in your least-privilege reviews. Treat rotation as one layer alongside controls like MFA fatigue defenses, never as a substitute for tight key administration.