AWS KMS: Encryption Keys, Envelope Encryption, and Key Policies

Encryption protects data, but encryption keys must also be protected, controlled, audited, and made available only to authorised workloads. AWS Key Management Service (AWS KMS) is the managed service for creating and controlling cryptographic keys used by applications and AWS services.

This is Part 57 of the AWS Cloud Practitioner Study Notes. The most important boundary is:

AWS KMS → Manages cryptographic keys
Secrets Manager → Stores secrets such as passwords and API keys

KMS does not store your application database, uploaded files, passwords, or secret values. It protects keys and performs or enables cryptographic operations for data stored elsewhere.

What AWS KMS does

KMS can create and manage KMS keys, control their use with key policies and IAM, record key activity through CloudTrail, and perform operations such as:

• Encrypt and decrypt small amounts of data
• Generate data keys for envelope encryption
• Generate random values
• Sign and verify messages with supported asymmetric keys
• Enable, disable, rotate, tag, and schedule deletion of customer managed keys

AWS services such as S3, EBS, RDS, Lambda, Secrets Manager, and Systems Manager can integrate with KMS for encryption at rest. The service stores or processes the protected data; KMS controls the key material and authorises its use.

KMS keys and key material

An AWS KMS key is a logical resource that represents cryptographic key material and its configuration. The key material for a KMS key generated by AWS KMS cannot be downloaded in plaintext. Applications ask KMS to perform an operation or to generate a data key; they do not hardcode the KMS key in source code.

Common KMS key choices include:

Key type	Who manages it?	Typical use
AWS owned key	AWS service	Default protection managed entirely by the service
AWS managed key	AWS, in your account	Service-specific key such as an aws/s3 key where supported
Customer managed key	You	Fine-grained policy, audit, sharing, lifecycle, and compliance control
Imported key material	Customer supplies material	Workloads with external key-generation or compliance requirements
Multi-Region key	Customer configures a related key set	Multi-Region applications that need related key material in several Regions
Custom key store	Customer controls CloudHSM-backed storage	Highly regulated workloads requiring a custom key store

The exact key choices and features depend on the AWS service using the key. An AWS owned key is convenient but offers little customer control. A customer managed key gives more control, but also creates responsibilities for permissions, monitoring, rotation, and deletion planning.

Symmetric and asymmetric KMS keys

Symmetric encryption uses the same key material for encryption and decryption:

Plaintext
   ↓ symmetric key
Ciphertext
   ↓ same key
Plaintext

Most AWS service encryption integrations use symmetric KMS keys. For example, S3, EBS, RDS, and Secrets Manager generally use symmetric encryption keys to protect data at rest.

An asymmetric KMS key contains mathematically related public and private keys:

Public key  → can be shared
Private key → remains protected in KMS

Asymmetric keys can support encryption/decryption or signing/verification use cases, depending on the selected key specification and usage. They are useful when a party outside AWS KMS must use a public key, but AWS services that integrate with KMS for data-at-rest encryption use symmetric KMS keys.

Envelope encryption

KMS is not intended to encrypt every byte of a large file through repeated direct KMS calls. Instead, applications and integrated services commonly use envelope encryption.

The pattern is:

KMS key
    ↓ protects
Data key
    ↓ encrypts locally
Large application data

The application requests a data key from KMS using GenerateDataKey. KMS returns:

1. A plaintext copy for immediate local encryption.
2. An encrypted copy of the data key, wrapped by the KMS key.

The application encrypts the large file with the plaintext data key, then removes the plaintext data key from active memory as soon as practical. It stores the ciphertext together with the encrypted data key.

To decrypt later:

Encrypted data key
        ↓ KMS Decrypt
Plaintext data key
        ↓ local decryption
Plaintext application data

KMS protects the data key, while the application or integrated AWS service performs the large-data encryption. AWS KMS does not store, manage, or perform cryptographic operations with the data key after returning it; the caller is responsible for using it securely. The AWS Encryption SDK can help implement this pattern when an application needs a tested envelope-encryption implementation.

KMS permissions

Access to a customer managed KMS key can involve several policy mechanisms:

IAM policy
      +
KMS key policy
      +
KMS grant, when applicable
      +
Other controls such as SCP or VPC endpoint policy

IAM policies

An IAM policy attached to a user, group, or role can allow operations such as kms:Encrypt, kms:Decrypt, kms:GenerateDataKey, or kms:DescribeKey. It can also allow administrative operations such as creating or disabling keys.

Key policies

Every KMS key has a key policy. A key policy is a resource-based policy attached to the key and is the primary way to control access to that key. Unlike many AWS resource policies, a KMS key policy must be written so that the account can use IAM policies to delegate access; an IAM allow is not automatically enough if the key policy does not enable that path.

Example key-user statement:

{
  "Sid": "AllowApplicationRoleToDecrypt",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::123456789012:role/ImageProcessor"
  },
  "Action": [
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

In a real key policy, use the required account, role, conditions, and actions for your workload. Separate key administrators from key users where practical: an administrator may manage the key policy and lifecycle without being allowed to decrypt application data.

Grants

A KMS grant is a delegated permission for a principal to use a particular KMS key. AWS services commonly use grants to obtain narrowly scoped access when they protect a resource on your behalf. Grants can be created and retired without editing the key policy, but they can allow permissions; they are not a mechanism for denying access.

For cross-account use, the KMS key policy in the owning account and an IAM policy in the caller’s account generally both need to allow the requested use. SCPs, permissions boundaries, and endpoint policies can still restrict the request.

Key rotation and lifecycle

Customer managed keys have a lifecycle that should be planned carefully:

• Create the key and its policy.
• Assign an alias such as alias/production-data.
• Enable or disable the key when appropriate.
• Monitor use and policy changes with CloudTrail.
• Configure automatic or on-demand rotation where supported.
• Schedule deletion only after confirming that protected data no longer needs the key.

Automatic rotation is optional for customer managed symmetric keys whose material is generated by KMS. AWS managed keys are rotated by AWS according to the service’s policy; AWS documentation currently states that AWS managed key material is rotated every year. AWS owned key rotation is handled by the owning service.

Disabling or deleting a key can make encrypted data inaccessible. Key deletion uses a waiting period rather than immediate removal, but scheduling deletion is still a high-impact operation. Keep recovery, retention, and compliance requirements in the key-management design.

AWS service integrations

KMS commonly appears in these architectures:

Service	What KMS protects or enables
Amazon S3	Server-side encryption with a customer managed KMS key where configured
Amazon EBS	Encrypted volumes and snapshots
Amazon RDS	Encrypted database storage and snapshots
AWS Lambda	Encrypted environment variables and other supported features
Secrets Manager	Encryption of stored secrets; Secrets Manager stores the secret value
Systems Manager Parameter Store	Encryption of SecureString parameters
Amazon SQS/SNS	Encryption of messages or topics where configured

The integration does not mean KMS stores the resource’s data. For example:

Database password
        ↓ stored by
Secrets Manager
        ↓ protected with
KMS key

Secrets Manager is the secret store and can manage secret rotation. KMS is the cryptography and key-management service used to protect the secret.

KMS versus related services

Service	Stores or manages	Main purpose
AWS KMS	Cryptographic keys	Key management and cryptographic operations
Secrets Manager	Passwords, API keys, tokens, and other secrets	Secure secret storage and rotation
Parameter Store	Configuration values and SecureString parameters	Configuration management and parameter retrieval
AWS CloudHSM	HSMs and customer-controlled key operations	Dedicated hardware-backed cryptography and control
Amazon Cognito	Application identities and tokens	Customer sign-in and identity federation

KMS may protect data stored by Secrets Manager or Parameter Store, but it does not replace them as a place to store passwords or API credentials.

Common exam questions

Which service manages encryption keys for S3, EBS, RDS, and other AWS services?

AWS KMS.

Where should a database password be stored?

Secrets Manager or an appropriate Parameter Store parameter, not KMS itself.

How are large files encrypted efficiently with KMS?

Envelope encryption: KMS protects a data key, and the application or service encrypts the large data with that data key.

Which key gives the customer the most control over policy and lifecycle?

A customer managed KMS key.

Which KMS key type is commonly used by AWS service encryption integrations?

A symmetric KMS key.

What must be checked when an IAM policy allows kms:Decrypt but access is denied?

Check the KMS key policy, applicable grants, SCPs, permissions boundaries, VPC endpoint policies, Region, and whether the ciphertext was encrypted under the intended key.

Final memory map

KMS key
   ↓ protects
Data key
   ↓ encrypts
Large data in S3, EBS, RDS, or an application

KMS key policy + IAM policy + grants
   ↓ control
Who may use or manage the key

The one-sentence takeaway is: AWS KMS manages cryptographic keys and controls their use; envelope encryption lets KMS protect a data key while an application or AWS service encrypts the actual data efficiently.

Sources

• AWS KMS keys and key hierarchy
• Generate data keys and envelope encryption
• KMS key policies and default policy
• Troubleshooting KMS permissions
• Grants in AWS KMS
• Symmetric and asymmetric KMS keys
• KMS key rotation
• AWS KMS IAM policy best practices