AWS KMS and Encryption Key Management

Encryption is the process of scrambling data so that only someone with the correct key can read it. Think of it like a locked box. You put your message inside, close the lock, and only the person who has the matching key can open it. AWS Key Management Service (KMS) is a fully managed service that creates and stores those lock-and-key sets for you. It handles all the hard parts — key generation, secure storage, rotation, and access control — so you do not have to write complicated code or manage physical hardware.

When you use KMS, the first thing you do is create a Customer Master Key (CMK). A CMK is the top-level key in KMS. It never leaves the service. You can use this CMK to encrypt and decrypt small amounts of data — up to 64 kilobytes per request — or you can use it to generate other keys called data keys. Data keys are actual cryptographic keys that you can use to encrypt large amounts of data outside of KMS, such as files stored in Amazon S3 or messages placed in Amazon SQS.

Here is the key point: KMS never gives you the CMK itself. When you request a data key, KMS returns two copies — a plaintext copy that you use immediately to encrypt your data, and an encrypted copy that you save alongside your encrypted data. The plaintext copy is used once and then you are told to discard it (your application should never store it). The next time you need to decrypt the data, you send the encrypted copy back to KMS, which decrypts it using the CMK and returns the plaintext key. This process is called envelope encryption.

Why does this matter? Imagine you have a million files in Amazon S3 that you want to encrypt. If you used the CMK directly on each file, you would hit KMS request limits and pay a lot of money. With envelope encryption, you only call KMS once to generate a data key, and then you use that data key locally on all your files. You can even generate a new data key for each file, which is the most secure approach.

KMS also handles key rotation automatically. You can configure your CMK to rotate every year, meaning AWS generates a new cryptographic backing key for the same CMK. Your old data stays encrypted with the old key, but any new encryption uses the new key. KMS keeps the old keys so you can still decrypt older data. This reduces the risk if a key is ever compromised.

Access control is managed through AWS Identity and Access Management (IAM). You create policies that say which users, roles, or services can use which CMKs and under what conditions. For example, you can allow the Lambda service to use a CMK to decrypt environment variables, but only if the request comes from a specific Virtual Private Cloud (VPC). Every API call to KMS is logged in AWS CloudTrail, giving you a full audit trail.

Finally, KMS integrates with many other AWS services like S3, EBS (Elastic Block Store), RDS (Relational Database Service), and Secrets Manager. When you enable encryption on an S3 bucket, you can choose to use a KMS key. The S3 service then calls KMS on your behalf to encrypt and decrypt objects. You do not need to write any code — it is all handled by the service.

What problems does KMS solve that developers used to struggle with? - Key storage: Before KMS, developers had to store encryption keys in their application code or in files on disk. If an attacker got access to the server, they got the keys. With KMS, keys are stored in a hardened service and never exposed to the application. - Key rotation: Manually rotating keys across thousands of files is nearly impossible. KMS automates rotation. - Audit trails: Without KMS, it was hard to know who used which key and when. KMS logs every request. - Compliance: Many regulations (like PCI DSS and HIPAA) require strong key management. KMS is certified to meet these standards.

In summary, KMS is the central keymaster for your AWS account. It does not do the encryption itself for large data — it gives you the tools to do it securely, and it controls access with granular IAM policies. For the DVA-C02 exam, you need to understand how to create CMKs, use envelope encryption, manage key policies, and know which AWS services can use KMS automatically.

Imagine you work for a healthcare start-up called HealthTrack that stores patient medical records in Amazon S3. You need to ensure that all data is encrypted at rest, and you must be able to prove to auditors that only authorised staff can decrypt the data. Here is how you would use AWS KMS in a real project.

Step one: You log into the AWS Management Console and navigate to KMS. You create a Customer Master Key (CMK) with a friendly alias like 'healthtrack-production-key'. You choose the key type — symmetric (one key for both encrypt and decrypt) because that is the most common for S3 encryption. You then define a key policy that grants the IAM role used by your application (say, a Lambda function) permission to use the key. You also add an admin IAM user to manage the key.

Step two: You configure your S3 bucket to use server-side encryption with KMS (SSE-KMS). In the S3 bucket properties, you select 'Encryption' and choose 'AWS KMS' as the encryption type. You enter the ARN (Amazon Resource Name) of your CMK. From this point forward, every object uploaded to the bucket is automatically encrypted by S3 using KMS. You do not need to write any encryption code.

Step three: Your application needs to read patient records. When a user requests a record, your Lambda function reads the encrypted object from S3. S3 automatically calls KMS to decrypt the object using your CMK. The Lambda function must have IAM permissions that allow it to use the kms:Decrypt action on the key. The user never sees the key.

Step four: For more complex needs — like encrypting a large CSV file that you generate on the fly — you might use envelope encryption in your code. Your application calls the KMS API to generate a data key. It receives a plaintext data key and an encrypted data key. It uses the plaintext key to encrypt the CSV file locally, then discards the plaintext key. It stores the encrypted data key alongside the encrypted file in S3. When reading the file, it retrieves the encrypted data key, calls KMS to decrypt it, and then uses the plaintext data key to decrypt the file. This is more flexible than SSE-KMS because you control exactly when and how encryption happens.

Step five: Auditors request a report of all key usage. You enable AWS CloudTrail (which is on by default in most accounts) and look at the KMS events. CloudTrail shows every call to CreateKey, Encrypt, Decrypt, GenerateDataKey, and more. For each event, you can see the IAM principal (who made the call), the source IP address, the key ID, and the timestamp. You export this to an S3 bucket for long-term storage.

What happens if a key is compromised? KMS supports key deletion only after a waiting period (7 to 30 days). During that waiting period, you can cancel the deletion. Once deleted, all data encrypted with that key becomes permanently unrecoverable. So you must be careful. A better practice is to disable the key rather than delete it, so you can still decrypt old data.

In a real team, you would also set up automatic key rotation — either yearly (KMS managed) or on a custom schedule using a scheduled Lambda function. You would monitor CloudWatch metrics for KMS usage, such as number of calls or throttling errors, and set up alarms if usage spikes unexpectedly.

The day-to-day tasks of an IT professional using KMS include: creating and managing CMKs via the console or AWS CLI, writing IAM policies that grant least-privilege access to keys, configuring services (S3, RDS, Lambda) to use KMS encryption, troubleshooting access denied errors (often due to missing kms: permissions), and reviewing CloudTrail logs for security investigations.