AWS KMS Best Practices: Keys, Policies, and Rotation

AWS Key Management Service (AWS KMS) is the managed service that creates, stores, and controls the cryptographic keys that protect most data in an AWS account. Securing it well comes down to four habits: use customer managed keys for anything sensitive, write least-privilege key policies, separate the people who administer keys from the workloads that use them, and monitor every key operation in CloudTrail.

This guide walks through how KMS works, the key types you will choose between, how key policies and IAM policies interact, rotation, envelope encryption, and the mistakes that show up most often in real accounts and on the AWS Certified Security - Specialty exam.

Why AWS KMS matters for cloud security engineers

Almost every AWS service that stores data integrates with KMS: S3, EBS, RDS, DynamoDB, Secrets Manager, CloudWatch Logs, SQS, and many more. When you enable encryption on any of those services, KMS is doing the key work behind the scenes.

That makes KMS a high-value control. If key access is too broad, encryption is mostly ceremonial because anyone who can read the data can also decrypt it. If key access is too tight, workloads break in production. A cloud security engineer has to get the balance right. If you are new to the concepts, read our primer on encryption at rest versus in transit first.

How AWS KMS works

KMS keys are logical resources. The key material never leaves the service unencrypted; it lives inside validated hardware security modules that AWS operates. You call the KMS API, directly or through an integrated service, to encrypt, decrypt, sign, verify, or generate data keys, and KMS performs the operation inside the HSM boundary.

Three ideas underpin everything else:

1. A KMS key is a container plus metadata. It has an ARN, an alias, a key policy, tags, a key state, and one or more backing key versions.
2. Access is evaluated per API call. Every Encrypt, Decrypt, GenerateDataKey, and administrative call is authorized against the key policy, IAM policies, grants, and any applicable condition keys.
3. Every call is logged. KMS writes to AWS CloudTrail, so you can prove who used which key, when, and from where.

Key types: AWS owned, AWS managed, and customer managed

Key type	Who controls the key policy	Visible in your account	Rotation	Typical use
AWS owned key	AWS	No	Managed by AWS	Default encryption for some services when you do nothing
AWS managed key (aws/service)	AWS (policy is fixed)	Yes, read only	Automatic, managed by AWS	Quick default encryption with no configuration
Customer managed key (CMK)	You	Yes, full control	Optional automatic rotation you configure	Regulated data, cross-account access, fine-grained auditing

The practical rule: use customer managed keys for any data with a compliance, contractual, or breach-impact requirement. They are the only type where you write the key policy, restrict who can decrypt, enable or disable the key on demand, schedule deletion, and share access across accounts. AWS managed keys are convenient but you cannot restrict their policy, so every principal with the service permission can generally use them.

Customer managed keys also come in different flavors: symmetric keys for encrypt and decrypt (the default and the right choice for data), asymmetric keys for signing or public-key encryption, HMAC keys for message authentication, and multi-Region keys that replicate key material across Regions for disaster recovery. Key material can be generated by KMS (recommended), imported by you, or backed by a CloudHSM or external key store when regulations require keys to live outside AWS control.

Key policies versus IAM policies

This is the topic that trips up the most people, so it is worth being precise.

Every KMS key has exactly one key policy. The key policy is the primary access control. An IAM identity policy can grant KMS permissions only if the key policy allows it, which almost always happens through a statement that gives the account root principal kms:*. That statement does not give every user in the account access; it delegates the decision to IAM policies. Remove it, and IAM policies stop working for that key.

Some rules from the AWS KMS best practices guidance:

• Do not grant kms:* to real users or roles. It combines administrative and cryptographic permissions, which defeats separation of duties.
• Separate key administrators from key users. Administrators get kms:Create*, kms:Put*, kms:ScheduleKeyDeletion, and similar. Users get kms:Encrypt, kms:Decrypt, kms:GenerateDataKey*, and kms:DescribeKey. Some workloads should only be able to encrypt, not decrypt.
• Use condition keys to narrow access. kms:ViaService limits a key to calls that come through a specific service such as S3 or RDS. kms:EncryptionContext requires a matching context. aws:PrincipalOrgID restricts cross-account use to your AWS Organization.
• Use aliases and tags for attribute-based access control. Tag-based conditions let you write a small number of IAM policies that scale across many keys.
• Avoid wildcard principals. A key policy with "Principal": "*" and no restrictive condition is a public key policy. AWS Security Hub has a control for this, and it should be a critical finding.

A minimal healthy key policy has three statements: one that enables IAM delegation for the account, one that names the administrator role, and one that names the user role or roles. Anything beyond that should be justified in a comment or a ticket.

Grants are a second delegation mechanism. Integrated services create them automatically, for example when EBS needs to decrypt a volume key, and you can create them for time-bounded application access without editing the key policy. Grants are access, so include ListGrants output in every KMS audit.

Envelope encryption and data keys

KMS keys are limited to encrypting 4 KB of data per call. That is by design. Real workloads use envelope encryption:

1. The application calls GenerateDataKey. KMS returns a plaintext data key and the same data key encrypted under the KMS key.
2. The application encrypts the file, object, or database page locally with the plaintext data key, then discards the plaintext key from memory.
3. The encrypted data key is stored alongside the ciphertext.
4. To read the data, the application calls Decrypt on the encrypted data key, receives the plaintext data key, and decrypts locally.

This is exactly what S3, EBS, and RDS do. It keeps large data out of KMS and means that rotating the KMS key does not require re-encrypting every object. The AWS Encryption SDK implements envelope encryption for you and is safer than writing it by hand.

Rotation: what actually happens

Automatic rotation on a symmetric customer managed key generates new key material on a schedule you choose (yearly by default). The key ARN, alias, policy, and grants do not change. Old key material is retained so previously encrypted data can still be decrypted, and new operations use the new material. Because the identifier is stable, rotation is invisible to applications, which is a strong argument to enable it on every key holding long-lived data. Security Hub and the CIS AWS Foundations Benchmark both check for it.

Asymmetric keys, HMAC keys, imported key material, and custom key stores do not support automatic rotation. For those, rotation means creating a new key and repointing the alias, a common exam scenario.

Key lifecycle: disable and delete

Disable a key when you suspect misuse. All cryptographic operations fail immediately, but the key can be re-enabled, which makes it the safe first response in an incident. Scheduling deletion starts a waiting period of 7 to 30 days during which the key is unusable and the deletion can be cancelled. After that, data encrypted under the key is unrecoverable. Treat ScheduleKeyDeletion as one of the most dangerous permissions in the account.

Monitoring KMS with CloudTrail and CloudWatch

Every KMS API call lands in CloudTrail, including the encryption context and the principal. A short list of events worth alerting on:

Event	Why it matters
ScheduleKeyDeletion, DisableKey	Potential destructive or denial-of-service action
PutKeyPolicy	Someone changed who can use the key
CreateGrant from an unexpected principal	New delegated access path
Decrypt failures with AccessDenied in volume	Possible probing or a broken deployment
ImportKeyMaterial, DeleteImportedKeyMaterial	BYOK lifecycle changes

Feed these into CloudWatch metric filters, EventBridge rules, or your SIEM. Pair KMS monitoring with GuardDuty for credential-based threat detection and with Security Hub for configuration drift.

Common KMS mistakes in real accounts

1. Using AWS managed keys for regulated data. You cannot restrict the policy or share the key across accounts.
2. Key policy with the account root and nothing else. Fine for a lab, but it puts all access control on IAM policies that often end up broad.
3. kms:* on a developer role. Developers should not be able to delete keys.
4. Cross-account access without aws:PrincipalOrgID. A typo in an account ID can hand key access to a stranger.
5. Storing plaintext data keys. Envelope encryption only works if the plaintext data key is discarded.
6. No alarm on deletion. A scheduled deletion that nobody notices for 30 days is catastrophic.
7. Ignoring grants during audits. Grants are access, and they do not show up in the key policy.

How this fits into a cloud security career

KMS is the connective tissue between IAM and data protection. If you already understand AWS IAM least privilege, key policies are a natural next step because they use the same policy language with a different evaluation order. From there, S3 bucket hardening makes more sense, because SSE-KMS is simply KMS applied to objects.

In the PrimeSec Academy AWS labs you build a key policy from scratch, break it on purpose, read the CloudTrail denial, and fix it, then reuse the key across S3, RDS, and Secrets Manager. The topic is also a core domain of the AWS Security Specialty exam covered in our certifications track.

Frequently asked questions

What is the difference between a KMS key policy and an IAM policy? The key policy is attached to the key and is the primary access control. An IAM policy can grant KMS permissions only when the key policy delegates to IAM, usually by allowing the account root principal. If the key policy does not allow a principal directly or through IAM delegation, access is denied regardless of what the IAM policy says.

Should I use AWS managed keys or customer managed keys? Use customer managed keys for anything sensitive, regulated, or shared across accounts, because you control the key policy, rotation, and lifecycle. AWS managed keys are acceptable for low-risk data where convenience matters more than fine-grained control.

Does rotating a KMS key require re-encrypting my data? No. Automatic rotation adds new key material while keeping the old material available for decryption. The key ARN and alias stay the same, so applications continue to work and existing ciphertext remains readable.

What is envelope encryption? Envelope encryption uses the KMS key to encrypt a data key, and the data key to encrypt the actual data. The encrypted data key is stored with the ciphertext. This keeps large data out of KMS and allows efficient rotation.

How do I share a KMS key with another AWS account? Add the external account or role as a principal in the key policy, and have the other account grant its identities the matching KMS permissions in their IAM policies. Restrict the statement with a condition such as the organization ID so the key cannot be used by unintended accounts.

What should I monitor for KMS security? Watch CloudTrail for key deletion scheduling, key disabling, key policy changes, unexpected grant creation, and spikes in access denied errors. Alert on these events and review them as part of incident response.

Next step

If you want to move from reading about KMS to building and breaking real key policies in a live AWS account, the PrimeSec Academy curriculum covers KMS inside a full AWS, Azure, GCP, and AI security track with 36 hands-on projects and a defended capstone. Ready to start? Enroll here, or check whether the program fits you with the eligibility quiz.

External references: AWS KMS best practices (AWS Prescriptive Guidance) and Key policies in AWS KMS.