AWS Key Management Service (KMS)

AWS Key Management Service (KMS) is a managed service that lets you create, manage, and control cryptographic keys for encrypting data across AWS services and in your applications. Before KMS, customers had to manage their own encryption keys using on-premises hardware security modules (HSMs) or software-based key management systems. This was complex, expensive, and error-prone. Keys could be lost, stolen, or misconfigured, leading to data breaches or permanent data loss. KMS solves this by providing a centralized, highly available, and durable key management infrastructure that integrates with over 50 AWS services, including S3, EBS, RDS, and Lambda.

KMS uses FIPS 140-2 validated hardware security modules (HSMs) to protect your keys. The service is multi-tenant, meaning AWS manages the underlying HSMs, but your keys are isolated using cryptographic boundaries. KMS is region-specific: keys are created in a particular AWS region and never leave that region unless you explicitly replicate them.

At the heart of KMS are Customer Master Keys (CMKs). A CMK is a logical representation of a master key. It contains metadata (key ID, creation date, description, key state) and a reference to the actual cryptographic material stored in HSMs. CMKs can be symmetric (AES-256) or asymmetric (RSA or elliptic curve). Symmetric CMKs are used for encrypting data keys and for envelope encryption. Asymmetric CMKs are used for sign/verify or encrypt/decrypt operations where the public key can be shared.

CMKs come in two types: AWS managed and customer managed. AWS managed CMKs are created automatically by AWS services (e.g., S3, EBS, RDS) when you enable encryption for that service. You cannot manage these keys—AWS handles rotation, permissions, and deletion. Customer managed CMKs are created by you. You have full control over key policies, rotation, and deletion. There is also a third type: AWS owned keys, which are not visible to you and are used by AWS services for internal encryption.

When you create a customer managed CMK, you can choose the key spec (symmetric or asymmetric), the key usage (encrypt/decrypt or sign/verify), and the origin (AWS KMS or external key store). You can also enable automatic rotation (yearly for symmetric CMKs). The key material never leaves the HSMs; you interact with the CMK via API calls.

KMS uses envelope encryption to encrypt large amounts of data. Instead of encrypting your data directly with the CMK (which is limited to 1 MB per API call for symmetric encryption), you generate a data key from the CMK. A data key is a symmetric key (typically AES-256) that you use to encrypt your data locally. KMS returns two versions: a plaintext data key and an encrypted copy of the same key. You use the plaintext key to encrypt your data, then discard it. You store the encrypted data key alongside the encrypted data. To decrypt, you send the encrypted data key to KMS, which decrypts it using the CMK and returns the plaintext data key. You then use that to decrypt your data. This way, the CMK is never exposed, and you can encrypt arbitrarily large data.

Access to CMKs is controlled by key policies and IAM policies. Key policies are resource-based policies attached directly to the CMK. They define who can use the key and under what conditions. Every CMK must have exactly one key policy. IAM policies can also grant access to CMKs, but only if the key policy explicitly allows the root user to delegate access via IAM. This is a common exam trap: if the key policy does not allow IAM, IAM policies alone cannot grant access.

Grants are another way to delegate access. A grant is a one-time permission that allows a principal to use a CMK for a specific operation. Grants are used by AWS services (like S3) to encrypt/decrypt on your behalf. They are temporary and can be retired.

CMKs can be in several states: Enabled, Disabled, Pending Deletion, Pending Import, and Unavailable. An enabled key can be used for cryptographic operations. A disabled key cannot be used. When you delete a CMK, it enters a Pending Deletion state for a waiting period (default 30 days). During this time, you can cancel deletion. After the waiting period, AWS deletes the key material permanently. This is irreversible—any data encrypted with that key becomes unrecoverable. The exam loves to test that deletion is not immediate and has a waiting period.

KMS pricing is based on the number of CMKs you create and the number of API calls you make. Customer managed CMKs cost $1 per month per key (prorated hourly). AWS managed CMKs are free. API calls cost $0.03 per 10,000 requests (for symmetric encrypt/decrypt). Asymmetric operations cost more. There is a free tier: 20,000 requests per month for AWS managed CMKs. The exam may ask about this pricing model, especially the free tier.

On-premises key management requires purchasing HSMs, managing their lifecycle, ensuring high availability, and handling key rotation and backup. With KMS, you eliminate hardware costs, reduce operational overhead, and benefit from AWS's security posture. However, you give up control over the physical HSMs. If you need full control (e.g., for regulatory reasons), you can use AWS CloudHSM, which provides dedicated HSMs that you manage. CloudHSM is more expensive and complex but gives you single-tenant hardware.

Use KMS when you need centralized key management, integration with AWS services, and automatic key rotation. Use CloudHSM when you need FIPS 140-2 Level 3 (KMS is Level 2 overall, though some operations are Level 3) or when you need to store your own keys and manage them without AWS having access. Use the AWS Encryption SDK when you need client-side encryption with envelope encryption outside of AWS services. Use AWS Secrets Manager for managing secrets (passwords, API keys) rather than encryption keys.

A fintech company runs a critical application on EC2 instances with EBS volumes storing customer transaction data. They must encrypt all data at rest to comply with PCI DSS. They create a customer managed CMK and enable automatic rotation. When launching EC2 instances, they select 'Encrypt this volume' and choose their CMK. Behind the scenes, KMS generates a data key, encrypts the EBS volume with it, and stores the encrypted data key with the volume. The plaintext data key is sent to the EC2 instance's Nitro card (if using Nitro instances) or to the instance's memory (for older instances) to enable transparent encryption/decryption. The company also uses the same CMK to encrypt snapshots. Cost: $1 per month for the CMK plus API call costs. Misconfiguration: if they accidentally disable the CMK, the EBS volume becomes inaccessible, causing application downtime. They must ensure key policies allow the EC2 service to use the key via grants.

A healthcare startup stores patient records in S3. They need to encrypt objects at rest and control who can decrypt them. They enable default bucket encryption with SSE-KMS using a customer managed CMK. When a user uploads an object, S3 calls KMS to generate a data key, encrypts the object, and stores the encrypted data key as metadata. When the object is downloaded, S3 calls KMS to decrypt the data key and then decrypts the object. The company also attaches an S3 bucket policy that only allows users with specific IAM roles to decrypt. They enable CloudTrail to audit all KMS API calls. Cost: $1 per month for the CMK plus $0.03 per 10,000 requests. Pitfall: if the CMK is deleted, all S3 objects encrypted with it become permanently unreadable. They set a waiting period of 30 days and use multi-Region keys for disaster recovery.

A gaming company stores player data in DynamoDB. They want to encrypt sensitive attributes (e.g., email addresses) before sending them to DynamoDB. They use the AWS Encryption SDK to perform client-side encryption. They create a CMK in KMS and use the SDK to generate a data key, encrypt the attribute, and store the encrypted data key alongside the encrypted value. The SDK handles the envelope encryption logic. The plaintext data key is never persisted. When reading, the SDK decrypts the data key using KMS and then decrypts the attribute. This gives them end-to-end encryption where even AWS cannot see the plaintext. Cost: same KMS pricing plus SDK overhead. Misconception: some think they need CloudHSM for client-side encryption, but KMS works fine.