AWS KMS Overview: Keys, Policies, Rotation, and Use Cases

Simple explanation

In technical terms: KMS stores key material inside tamper-resistant hardware security modules (HSMs) and never lets it out in plaintext. When an AWS service like S3 or EBS needs to encrypt data, it asks KMS to produce a data key. KMS returns an encrypted copy that the service stores alongside your data. When something needs to decrypt, it asks KMS to unlock that data key first.

You never handle raw key material. KMS handles the cryptography. You control who gets to ask KMS to encrypt or decrypt, and you get a log every time someone does.

Why AWS KMS matters

Encryption protects data only when key access is controlled separately from data access. If the same permissions that let a user read an S3 object also let them decrypt it, encryption adds no meaningful barrier. KMS creates that separation.

• Separate access control. A developer might have read access to an S3 bucket but no kms:Decrypt permission on the key. They can see that encrypted objects exist but cannot read the contents.
• Audit trail. Every Encrypt, Decrypt, and GenerateDataKey call is logged in CloudTrail. You can detect unusual decryption patterns or unauthorized access attempts.
• Compliance. Frameworks like HIPAA, PCI-DSS, SOC 2, and FedRAMP require that encryption keys are managed in certified hardware and that access is logged. KMS meets these requirements out of the box.
• Key lifecycle control. You can rotate keys, disable them immediately during an incident, or schedule deletion, all without touching the encrypted data.

For the broader picture of what gets encrypted in AWS and how, see the encryption in AWS guide.

How AWS KMS works

KMS uses a two-level encryption model called envelope encryption. Here is how it works step by step:

1. You create a KMS key. KMS generates the key material inside a hardware security module (HSM). The key never leaves the HSM in plaintext.
2. A service requests a data key. When S3, EBS, or another service needs to encrypt data, it calls GenerateDataKey. KMS returns two things: a plaintext data encryption key (DEK) and a copy of that DEK encrypted with your KMS key.
3. The service encrypts locally. The service uses the plaintext DEK to encrypt your data using fast local AES-256 operations. It then discards the plaintext DEK from memory.
4. The encrypted DEK is stored alongside the data. The encrypted DEK is small (a few hundred bytes) and useless without the KMS key that encrypted it.
5. Decryption reverses the process. The service sends the encrypted DEK back to KMS. KMS decrypts it and returns the plaintext DEK. The service uses it to decrypt the data locally, then discards it again.

Practical example: encrypting an S3 bucket

You create a customer managed KMS key called prod-data-key. You configure an S3 bucket to use SSE-KMS with that key. When a file is uploaded, S3 calls GenerateDataKey on prod-data-key, encrypts the file with the returned DEK, stores the encrypted DEK as object metadata, and discards the plaintext DEK.

When someone downloads the file, S3 calls Decrypt on the encrypted DEK, but only if the caller has kms:Decrypt permission on prod-data-key. Without that permission, the download fails even if the caller has s3:GetObject access.

AWS-owned vs AWS-managed vs customer managed KMS keys

AWS organizes KMS keys into three categories based on who manages them and how much control you have:

AWS-owned keys are completely transparent. AWS uses them to encrypt data on your behalf, but they do not appear in your KMS console and you cannot view or modify them.

AWS-managed keys appear in your KMS console with names like aws/s3, aws/ebs, aws/rds. They are scoped to your account and their usage appears in CloudTrail. You can view them but cannot modify their key policies, change their rotation settings, or delete them.

Customer managed keys are keys you create and fully control. You write the key policy, set the rotation schedule, tag the key, and can disable or delete it. Customer managed keys are what you need when compliance, cross-account sharing, or fine-grained access control is required. See the customer managed keys guide for a full walkthrough.

Symmetric vs asymmetric keys

Symmetric keys (AES-256-GCM)

The default type. One key handles both encryption and decryption. All AWS service integrations (S3, EBS, RDS, Secrets Manager) use symmetric keys. The key material never leaves KMS in plaintext. You call KMS APIs to encrypt and decrypt; you never see the raw key.

Use symmetric keys when: you are encrypting data within AWS using service integrations, or when both the encrypting and decrypting parties can call KMS.

Asymmetric keys (RSA, ECC)

Asymmetric keys have a public and private key pair. You can download the public key and share it. Only the private key (held by KMS) can decrypt data encrypted with the public key.

Use asymmetric keys when:

• You need to verify digital signatures (proving data came from a specific source)
• External systems outside AWS need to encrypt data that only your AWS account can decrypt
• You need a key exchange protocol between two parties

Asymmetric keys do not support automatic rotation and cost more per API call. Most AWS workloads use symmetric keys.

When to use AWS KMS

• Encrypting data at rest in S3, EBS, RDS, DynamoDB, or Redshift, especially when you need to control who can decrypt.
• Encrypting secrets. AWS Secrets Manager uses KMS to encrypt every secret. You can use a customer managed key for additional control.
• Meeting compliance requirements that mandate customer-controlled encryption with audit logging.
• Cross-account data sharing where you need to grant decryption access to another AWS account through the key policy.
• Application-level encryption. Your application code can call KMS directly to encrypt small payloads (up to 4 KB) or generate data keys for client-side encryption of larger data.
• Digital signatures using asymmetric keys to prove data integrity and origin.

When you do not need a customer managed key

Customer managed keys add cost ($1/month per key) and operational complexity (key policies to maintain, rotation to monitor, deletion risks). You do not need one if:

• You have no compliance requirement mandating customer-controlled keys.
• You do not need to restrict decryption separately from data access. The AWS-managed key is sufficient.
• You do not need to share encrypted data across AWS accounts.
• You do not need a custom rotation schedule. AWS-managed keys rotate automatically every year.
• You are running a development or staging environment where the default encryption is acceptable.

Key policy vs IAM policy vs grants

KMS has three access control mechanisms. Understanding how they interact prevents the most common permission mistakes.

Key policy (required)

Every KMS key has exactly one key policy: a resource-based JSON policy attached to the key itself. It is the primary access control mechanism. If the key policy does not allow an action, no IAM policy or grant can override it.

The default key policy created by the AWS console includes a statement granting the account root principal full access. This is critical: it allows IAM policies in the account to grant KMS permissions to other principals. Without this root account statement, only the key policy itself controls access.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow app role to decrypt only",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/MyAppRole"
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "*"
    }
  ]
}

In this example, the first statement lets IAM policies in account 123456789012 grant KMS permissions. The second statement gives MyAppRole only Decrypt and GenerateDataKey. That is enough to use the key for encryption and decryption, but not enough to manage, disable, or delete the key. This follows the principle of least privilege.

IAM policy

IAM policies attached to users, roles, or groups can grant or deny KMS actions, but only if the key policy delegates to IAM (via the root account statement). Think of it this way: the key policy opens the door, and IAM policies decide who walks through. This works the same way as managed and customer managed IAM policies for other AWS services.

Grants

Grants are temporary, scoped permissions on a KMS key. AWS services use grants internally. For example, when you launch an encrypted EBS volume, EC2 creates a grant to decrypt the volume key. Grants are useful when a service or workflow needs time-limited access without modifying the key policy or IAM policy.

AWS KMS vs Secrets Manager

KMS and Secrets Manager are frequently confused because both deal with sensitive data. They solve different problems and are designed to work together.

How they work together: when you store a database password in Secrets Manager, it encrypts the password using a KMS key (either AWS-managed or a customer managed key you specify). When your application calls GetSecretValue, Secrets Manager calls KMS to decrypt the secret before returning it. You control access at both levels: Secrets Manager resource policies control who can call GetSecretValue, and the KMS key policy controls who can decrypt.