Key Management Service

AWS KMS provides several key types, each designed for different use cases. Choosing the right key type depends on your encryption requirements and compliance needs.

Symmetric Keys use a single key for both encryption and decryption. This is the most common KMS key type and is used by most AWS services for server-side encryption. When you create a symmetric KMS key, KMS generates and manages the key material. You never see the plaintext key.

For example, when S3 encrypts an object with SSE-KMS, it uses your symmetric KMS key. The API call kms:GenerateDataKey returns a plaintext data key and an encrypted copy. S3 encrypts data with the plaintext key, discards it, and stores the encrypted copy.

Asymmetric Keys use a public/private key pair. The public key encrypts, and the private key decrypts. Use asymmetric keys when you need to distribute encrypted data to parties who cannot call KMS directly, or for digital signatures. For example, encrypt configuration files with the public key so any system with the private key can decrypt them.

Multi-Region Keys replicate a KMS key from one Region to another. The primary key and replica share the same key ID and material, allowing decryption with either key. Use multi-region keys for encrypting data that must be accessible across Regions, like global DynamoDB tables or cross-Region S3 replication.

AWS Managed Keys are created automatically by AWS services (e.g., aws/s3, aws/ebs). You cannot modify their key policies. Customer Managed Keys (CMKs) give you full control over policies, rotation, and lifecycle.

KMS access is controlled through key policies and grants. Every KMS key has a key policy that determines who can use and manage the key.

Key Policies are resource-based policies attached to each KMS key. The key policy specifies the key administrators (who can manage the key) and key users (who can use the key for encryption/decryption). The default key policy allows the account root full access.

A production key policy might look like:

{
  "Statement": [{
    "Sid": "Enable IAM User Permissions",
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
    "Action": "kms:*",
    "Resource": "*"
  }, {
    "Sid": "Allow use by DataTeam",
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:role/DataTeam"},
    "Action": ["kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey"],
    "Resource": "*"
  }]
}

Grants are an alternative to key policies for temporary or programmatic access. Grants allow a specific principal to use the key for specific operations. Grants are useful for giving temporary access without modifying the key policy. For example, grant a Lambda function kms:Decrypt access for a specific task, then revoke the grant when the task completes.

Key Policy Conditions restrict when keys can be used. Use kms:EncryptionContext to bind encryption to specific context values. For example, require encryptionContext:department:finance for the key to be usable, preventing the key from being used for unauthorized purposes.

KMS key rotation replaces the cryptographic material of a key without changing the key ID or ARN. This limits the amount of data encrypted with a single key version.

Automatic Rotation for symmetric KMS keys replaces the key material every year. KMS keeps the old key material to decrypt data encrypted with previous versions. The rotation happens transparently; no application changes are needed.

For example, if you enable automatic rotation in January 2024, KMS generates new key material in January 2025. Data encrypted in 2024 still decrypts because KMS retains the 2024 key material. New encryptions in 2025 use the new material.

Manual Rotation is useful when you need to rotate keys more frequently or on a specific schedule. Create a new key version, update applications to use the new key, and schedule deletion of the old key after all data encrypted with it is retired.

Key Deletion has a waiting period (7-30 days) to prevent accidental deletion. During the waiting period, the key is disabled but not yet deleted. Cancel the deletion if it was triggered in error. You cannot delete a key that is aliased or has pending deletions.

Key Lifecycle States:

• Enabled: Key is active and can be used
• Disabled: Key cannot be used for new encryptions but can decrypt existing data
• PendingDeletion: Key is waiting for deletion (7-30 day window)
• Unavailable: Key material is not available (happens during custom key store issues)

Plan key retirement by re-encrypting data with new keys before deleting old keys.

For workloads requiring dedicated hardware security modules and full control over cryptographic operations, AWS CloudHSM provides single-tenant HSM clusters.

CloudHSM runs on dedicated hardware that you control. Unlike KMS, where multiple customers share the underlying infrastructure, CloudHSM provides a single-tenant HSM. This is required for certain compliance standards like FIPS 140-2 Level 3.

For example, a bank processing payment card data requires FIPS 140-2 Level 3 validation. KMS provides Level 3 overall but Level 2 for individual HSMs. CloudHSM provides Level 3 for the individual HSM, meeting the bank's compliance requirement.

CloudHSM Cluster consists of one or more HSMs in an VPC. You manage the cluster, including creating HSMs, backing up keys, and managing user credentials. CloudHSM integrates with KMS through the CloudHSM-backed Custom Key Store, allowing KMS operations to use your CloudHSM key material.

External Key Stores (XKS) allow you to use an external key management infrastructure with KMS. The key material never enters AWS; KMS proxies cryptographic operations to your external HSM. This is useful when regulations require that key material never leaves your control.

CloudHSM vs KMS:

• KMS: Managed, scales automatically, integrates with all AWS services, shared infrastructure
• CloudHSM: Dedicated hardware, you manage everything, FIPS 140-2 Level 3, single-tenant

Choose CloudHSM when compliance requires dedicated HSMs or when you need to run custom cryptographic code on the HSM.