The CFO hears “we rotate encryption keys” and files it next to password rotation. The staff engineer owns two different systems. AWS database encryption key rotation architecture is the KMS key that encrypts RDS or Aurora storage, plus the application secrets that open the database. Those are not the same control. Automatic KMS rotation changes key material behind a stable key ARN. It does not rotate the database password, the IAM DB user, or a plaintext credential in a Lambda environment variable. Auditors sample both stories. Teams that show only the KMS checkbox fail the secret one.
Rutagon builds the pair on AWS cloud infrastructure. We do not claim a FedRAMP authorization or a SOC 2 certification. We produce the key ARN, rotation flag, RDS encryption status, and the secret-rotation or IAM-auth evidence from the window. Backup copies of the database inherit encryption rules you must be able to explain — that path sits next to AWS Backup restore testing.
AWS Database Encryption Key Rotation Architecture vs Application Secrets
RDS and Aurora encrypt storage with a KMS key you choose at create time. You cannot change that key on an existing instance without a snapshot copy into a new instance (or an equivalent rebuild). That is a migration, not a rotation. What you can do without a rebuild is enable automatic annual rotation on a customer-managed key. AWS rotates the backing material. The key id in the RDS console stays the same. Old snapshots remain decryptable because KMS keeps prior material.
AWS documents this behavior in the KMS key rotation guide. Automatic rotation is a property of the CMK. AWS-owned keys that RDS uses when you pick the default aws/rds alias are not a key you operate. If the auditor asks who can disable rotation or schedule key deletion, “we used the AWS-managed RDS key” is a weaker story than a CMK with a key policy you own.
Application secrets are the login path. Secrets Manager or IAM database authentication are the usual mid-market shapes. Rotating a Secrets Manager secret changes the password RDS knows. It does not rotate the KMS CMK. Rotating the CMK does not change the password. A runbook titled “key rotation” that only clicks the KMS checkbox is incomplete.
IAM database authentication removes the standing password for the applications that can use it. That is a credential-elimination project, not a KMS project. We still keep KMS rotation on the storage key. The auditor will ask about encryption at rest and about access to the data. Answer both.
What an Auditor Samples
For encryption at rest they sample: is storage encrypted, which key ARN, is it customer managed, is rotation enabled, who can kms:DisableKey and kms:ScheduleKeyDeletion, and whether snapshots and replicas use the same key story. They may ask you to show a snapshot that will not restore in another account without a grant. That is a perimeter question as much as a rotation question — see AWS data perimeter architecture for SOC 2.
For access they sample: how applications authenticate, how often secrets rotate or whether IAM auth is on, who can read the secret, and whether a leftover master password lives in a ticket. A CMK rotation log does not answer those questions.
For backups they sample: encrypted snapshots, vault access, and a restore test that proved a recent copy. Rotation of the CMK must not be an excuse to skip restore tests. After a key-policy change, restore in a isolated account is how you learn you dropped a grant.
We do not invent rotation intervals. Annual automatic KMS rotation is the AWS default for that feature. Secret rotation intervals are yours. Pick them in the control set you already operate and implement them.
CMK Design We Actually Ship
One CMK per data-store class in the account, or per environment if you need blast-radius isolation. Production Aurora does not share a key with a shared-services utility bucket. The key policy allows the RDS service to use the key, allows a DBA break-glass role to use the key, and allows the backup role to use the key. Application task roles do not get kms:Decrypt on the storage key unless you have a design that requires client-side use of the same key. Most applications never call KMS for RDS storage. They call the database.
Replicas and cross-region copies need a key in the destination region. That is a second CMK with its own rotation flag. People forget the replica key and only rotate the primary. The sample will include the replica if you sell multi-AZ or multi-region.
Snapshot copy to another account for ransomware isolation needs a grant or a key policy that names the destination. That is intentional sharing. It belongs in an exception register, not in a wildcard principal.
Default aws/rds is acceptable as a bootstrap. We migrate new production instances to a CMK when the evidence program starts asking about key owners. We do not do in-place key swaps. We plan a snapshot-and-restore window.
Application Path: Rotate or Eliminate
If the app still uses a password, Secrets Manager rotation with an RDS rotation Lambda (or the managed rotation AWS provides for supported engines) is the control. The rotation function’s role is tightly scoped. The secret resource policy does not allow every task role in the account to GetSecretValue.
If the app can move to IAM database authentication, we prefer that for the application user. Master-user password remains a break-glass secret with its own rotation and a tiny reader list. Do not store it in the same secret the app reads on every cold start.
Config rules can detect unencrypted RDS and missing rotation flags. That is detective. The preventive control is Terraform that refuses an unencrypted instance and that sets enable_key_rotation = true on the CMK. Detective packs are optional coverage — we already wrote AWS Config conformance packs for SOC 2 as the pack story. This article stays on the key and secret architecture.
A Terraform Shape
resource "aws_kms_key" "aurora" {
description = "aurora storage"
deletion_window_in_days = 30
enable_key_rotation = true
}
resource "aws_rds_cluster" "app" {
storage_encrypted = true
kms_key_id = aws_kms_key.aurora.arn
# master credentials via Secrets Manager or IAM auth — not inline
}
The deletion window is not rotation. It is how long a deleted key can be recovered. Short windows feel tidy and fail restores. We keep a window you can survive.
Frequently Asked Questions
Does enabling KMS rotation re-encrypt the RDS volume?
No. Automatic rotation creates new key material for the same key ARN, and RDS keeps using that ARN. Historical snapshots decrypt with the material that was current when they were written, which KMS retains. A new key ARN still requires a snapshot copy or rebuild.
Is AWS-managed aws/rds enough for an audit sample?
It proves encryption at rest. It is weaker on key ownership, rotation you control, and who can delete the key. Many mid-market samples accept it for a first review and then ask for a CMK on the next cycle. If you already know you will be asked about key administrators, create the CMK before the instance so you are not planning a rebuild during fieldwork.
Does secret rotation replace database encryption key rotation?
No. Secret rotation changes authentication material, while KMS rotation changes encryption material for storage. If you only rotate passwords, the storage-key question is still open. If you only enable KMS rotation, the standing database password is still open.
What happens to Aurora clones and snapshots after a key-policy change?
They still encrypt with the same key ARN unless you copied them under a new key, and a tighter key policy can block a restore role you forgot. After you edit the key policy, restore a recent snapshot to a throwaway instance with the role you claim is sufficient. Keep the artifact.
If you want an architecture review tied to audit evidence — CMK rotation, RDS encryption, secret or IAM-auth path, and a restore that still opens — call 907-841-8407, email contact@rutagon.com, or use rutagon.com/contact.