Encrypting Data with AWS KMS: A Detailed Hands On Journey

Cloud security is more than theory—it’s a practice. To grow my skills, I built a project around AWS Key Management Service (KMS), applying it directly to encrypt and protect a DynamoDB table. This document is a detailed walkthrough of how I created a Customer Managed Key, integrated it with DynamoDB, faced permission challenges, and resolved them step by step.

Step 1 — Creating a Customer Managed Key

I began by creating a symmetric Customer Managed Key (CMK) in the AWS KMS console. The setup process required me to define an alias for easy reference, choose the type of key, and configure administrators. Administrators can change policies and manage the key, but do not automatically gain permission to use it. This distinction between administrators and users was one of my first big takeaways about KMS—it forces clear separation of duties.

Landing on AWS KMS console.

Configuring administrators and usage permissions for the CMK.

Reviewing and editing the key policy.

Step 2 — Creating and Preparing a DynamoDB Table

Next, I created a DynamoDB table which would serve as my test environment for encryption. At first, the table was encrypted with AWS-owned keys, but I wanted full control, so my goal was to switch it to the CMK I had just created. This step was straightforward, but it set the stage for the critical encryption configuration.

DynamoDB table successfully created.

Step 3 — Applying Customer Managed Encryption

When editing the table, I navigated to encryption settings and changed the option from the default AWS-owned key to a Customer Managed Key. This is where the key alias came into play, allowing me to easily select the key I created earlier. From this point forward, all writes and reads to this table would require KMS permission checks in addition to DynamoDB permissions.

Switching DynamoDB encryption to a customer managed key.

Selecting the specific KMS key alias for encryption.

Step 4 — Writing and Reading Data

I inserted a simple test item into the DynamoDB table and then ran a scan. The process worked smoothly under my main account, showing that data was being written and retrieved with encryption in place. This step confirmed that the integration between DynamoDB and my CMK was working. The real challenge appeared when I tried to access the data with a separate IAM user.

Adding a test item into DynamoDB.

Step 5 — The AccessDenied Roadblock

As soon as I attempted to scan the table with a test IAM user, I was hit with an AccessDenied error. Even though the user had DynamoDB permissions, KMS blocked the operation because the user was not authorized to perform the `kms:Decrypt` action on my CMK. This was the pivotal lesson: data encryption is enforced by both service permissions and key policies.

Encountering AccessDenied error – kms:Decrypt not allowed.

Step 6 — Fixing Key Policies and Users

To resolve the issue, I returned to the KMS console. First, I explicitly added the test IAM user as a key user. Then, I edited the key policy to grant the necessary permissions, including `Encrypt`, `Decrypt`, `ReEncrypt*`, `GenerateDataKey*`, and `DescribeKey`. Once these changes were applied, the test user could access the DynamoDB table without errors.

Updating key policy with required KMS actions.

Step 7 — Final Confirmation

With policies fixed, I re-scanned the table using the test user. This time, the operation succeeded. Not only did this confirm that my CMK was functioning correctly, but it also proved that I understood how to balance IAM and KMS policies to achieve secure, working encryption.

Final confirmation – encrypted reads/writes working.

Conclusion and Lessons Learned

This project taught me that encryption on AWS is not just about creating a key. It is about understanding the layers of permissions—IAM policies, key policies, and service integrations. By going through the full cycle—creating a key, applying it, hitting errors, and resolving them—I gained hands-on clarity that theory alone cannot provide. The key lessons: - Separate administrators from users to enforce least privilege. - Always remember that key policies override IAM. - Test with multiple identities to uncover hidden permission gaps. This hands-on journey deepened my confidence in securing data at rest on AWS.