Configuring automatic key rotation in AWS KMS

Encryption keys that never change are a liability. If a customer managed key (CMK) in AWS KMS is ever exposed — through a misconfigured IAM policy, a leaked CloudTrail log, or an insider mistake — every object it has ever encrypted stays vulnerable until that key is replaced. That's exactly the risk AWS KMS key rotation is designed to eliminate: it periodically swaps the underlying cryptographic material behind a key while preserving the key's ARN, aliases, and permissions, so nothing downstream breaks.

Despite being a checkbox in the console, a lot of teams either leave it disabled on customer managed keys or don't fully understand what "rotation" actually rotates. This guide walks through enabling and verifying automatic key rotation, tuning the rotation schedule, handling multi-Region keys, and building alerting so a stalled rotation never goes unnoticed. By the end, you'll have a repeatable, auditable rotation setup across every KMS key your account manages.

Step 1: Understand what AWS KMS key rotation actually does

Before touching any settings, it's worth being precise about the mechanics, because the terminology trips people up.

• AWS managed keys (the ones with aliases like aws/s3, aws/rds) are rotated automatically every year. You cannot disable, delay, or configure this.
• Customer managed keys (CMKs you create yourself) support automatic key rotation KMS functionality, but it is off by default and must be explicitly enabled per key.
• Rotation generates new cryptographic material for the key while keeping the key ID and ARN unchanged. AWS KMS retains all prior versions of the key material internally, so data encrypted under an older version can still be decrypted — you never need to re-encrypt existing ciphertext after a rotation.
• Rotation does not apply to asymmetric keys, HMAC keys, or keys imported with your own key material (those require manual rotation via a new key and alias swap).

This distinction matters for compliance narratives too: auditors frequently ask specifically about customer managed key rotation, since AWS managed keys are outside your control and asymmetric/imported keys need a documented manual process.

Step 2: Enable automatic rotation on a customer managed key

For any symmetric CMK, enabling rotation is a single API call. Using the AWS CLI:

aws kms enable-key-rotation \
  --key-id arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

Or, if you manage infrastructure as code, add it directly to your Terraform resource:

resource "aws_kms_key" "app_data" {
  description             = "CMK for application data encryption"
  deletion_window_in_days = 30
  enable_key_rotation     = true
}

If you're creating keys through CloudFormation:

Resources:
  AppDataKey:
    Type: AWS::KMS::Key
    Properties:
      Description: CMK for application data encryption
      EnableKeyRotation: true

Whichever path you use, make rotation part of the key's creation template rather than a follow-up step — new keys created outside a reviewed template are the most common source of rotation gaps.

Step 3: Set a custom rotation period

Since late 2023, AWS lets you customize the rotation interval for customer managed keys instead of accepting the fixed 365-day default. Valid values range from 90 to 2,560 days.

aws kms enable-key-rotation \
  --key-id arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \
  --rotation-period-in-days 180

If rotation is already enabled and you just want to change the cadence, the same command updates it in place — you don't need to disable rotation first. Choosing a shorter period (say, 90–180 days) is a reasonable move for keys protecting highly sensitive data classes, while less sensitive, low-blast-radius keys can stay on the annual default. Document the rationale for any non-default period somewhere your auditors can find it; "why is this key rotating every 90 days" is a question you want a ready answer for.

Step 4: Handle multi-Region keys correctly

Multi-Region keys behave differently: you enable rotation only on the primary key, and AWS automatically propagates rotation to all replica keys in other Regions. Attempting to enable rotation directly on a replica will fail.

# Enable rotation on the primary key only
aws kms enable-key-rotation --key-id arn:aws:kms:us-west-2:111122223333:key/primary-key-id

Verify the primary/replica relationship before making changes:

aws kms describe-key --key-id <key-id> --query 'KeyMetadata.MultiRegionConfiguration'

If you manage disaster-recovery Regions with separate Terraform state, make sure the replica key resources don't also declare enable_key_rotation = true — it's a no-op at best and a plan-apply error at worst.

Step 5: Update key policies and grants if needed

Enabling rotation itself doesn't require new IAM permissions on downstream consumers, since the ARN and aliases don't change. But you do need kms:RotateKeyOnDemand (for on-demand rotation, see Step 6) and kms:GetKeyRotationStatus available to whichever role or pipeline audits rotation state:

{
  "Effect": "Allow",
  "Action": [
    "kms:EnableKeyRotation",
    "kms:GetKeyRotationStatus",
    "kms:RotateKeyOnDemand",
    "kms:ListKeyRotations"
  ],
  "Resource": "arn:aws:kms:*:111122223333:key/*"
}

Scope this to a dedicated security or platform-engineering role rather than granting it broadly — key rotation configuration should go through the same change-review process as any other security control.

Step 6: Trigger an on-demand rotation when necessary

Automatic rotation runs on its schedule, but sometimes you need rotation now — after a suspected key exposure, for instance. AWS KMS supports on-demand rotation independent of the automatic schedule:

aws kms rotate-key-on-demand \
  --key-id arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

You can queue up to 10 on-demand rotations per key per year without disrupting the automatic schedule, which makes this a safe incident-response lever rather than something that requires disabling and re-enabling automatic rotation.

Step 7: Monitor rotation with CloudWatch and CloudTrail

Enabling rotation and forgetting about it is how gaps happen silently. Wire up detection so a failed or skipped rotation surfaces immediately:

• CloudTrail logs RotateKey, EnableKeyRotation, and DisableKeyRotation events — route these into your SIEM or a dedicated CloudWatch Logs group.
• Build an EventBridge rule that fires on DisableKeyRotation calls against production keys and alerts your security channel in real time.
• Schedule a periodic Lambda or Config rule using managed-rule: cmk-backing-key-rotation-enabled (AWS Config) to continuously check that every CMK in scope still has rotation enabled — configuration drift from a well-meaning "just disable it for testing" change is common.

aws configservice put-config-rule \
  --config-rule '{
    "ConfigRuleName": "cmk-rotation-enabled",
    "Source": {
      "Owner": "AWS",
      "SourceIdentifier": "CMK_BACKING_KEY_ROTATION_ENABLED"
    }
  }'

Verification and troubleshooting

Once rotation is configured, confirm it's actually working rather than trusting the console checkbox.

Check rotation status directly:

aws kms get-key-rotation-status --key-id <key-id>

This returns KeyRotationEnabled: true/false and, for customer-configured periods, the RotationPeriodInDays value.

List rotation history (useful after an on-demand rotation or when investigating a compliance question):

aws kms list-key-rotations --key-id <key-id>

Common issues:

• "Rotation status shows disabled after I enabled it" — you likely called the API against an alias ARN instead of the key ID, or against a replica key instead of the primary in a multi-Region setup.
• AccessDeniedException on EnableKeyRotation — the calling principal's key policy or IAM policy is missing kms:EnableKeyRotation; remember KMS key policies are evaluated in addition to IAM, not instead of it.
• Rotation "isn't rotating" on schedule — automatic rotation runs within the UTC day it's due, not at a guaranteed timestamp; use list-key-rotations rather than watching the clock.
• Imported key material or asymmetric/HMAC keys can't enable rotation — this is expected; these key types require a manual rotation process (create new key, update alias, phase out old key on a deprecation timeline).
• Terraform plan shows perpetual diff on enable_key_rotation — confirm you're not managing the same key with both a CloudFormation stack and Terraform; ownership conflicts often surface first as rotation-setting drift.

Treating these checks as part of routine KMS best practices — not a one-time setup task — is what keeps rotation coverage from quietly decaying as new keys get created by different teams and pipelines over time.

How Safeguard Helps

Manually verifying that every customer managed key across every account and Region has rotation enabled, on the right schedule, doesn't drift out of policy, and generates an audit trail is exactly the kind of control that's easy to configure once and hard to keep correct at scale. Safeguard continuously inventories KMS keys across your AWS organization, flags any customer managed key with rotation disabled or a rotation period that falls outside your defined policy, and correlates key rotation events with your broader software supply chain — so a stale key protecting a build artifact or CI secret doesn't sit unnoticed alongside an otherwise strong security posture.

Instead of relying on point-in-time audits or one-off AWS Config rules, Safeguard gives you a living view of key rotation health next to the rest of your supply chain security signals: signing keys, artifact provenance, dependency risk, and infrastructure configuration in one place. When a key falls out of compliance — disabled rotation, an overdue on-demand rotation after an incident, or a newly created CMK that skipped your standard template — Safeguard surfaces it before an auditor or an attacker does.