So far we have talked about limits, compliance, threats, and centralized vision. Now let's go down to a more concrete level: data protection through encryption. We have mentioned encryption many times (encrypted databases, encrypted state, HTTPS...), but where are the keys that encrypt and decrypt stored? That is the mission of KMS (Key Management Service), AWS's key management service.

Encrypting is transforming readable data into unreadable data, using a key. Only those who have the key can read them again (decrypt them). It is the fundamental protection of data:

If someone steals your encrypted data but does not have the key, they only see useless noise. That's why you encrypt: sensitive information (customer data, passwords, backups) must be encrypted both at rest (stored) and in transit (traveling over the network, remember HTTPS, subchapter 16.3).

Encryption is only as strong as the protection of the keys. If you store the key next to the encrypted data, it's like leaving the key taped to the lock: it's useless. And managing keys by hand is very difficult:

• Where do you store them securely?
• How do you control who can use them?
• How do you rotate them (change them periodically) without breaking anything?
• How do you avoid losing them (which would make your data unreadable forever)?

KMS exists to solve all of this.

KMS (Key Management Service) is AWS's service to create, store, and manage encryption keys in a centralized and secure way. The "master" keys never leave KMS unencrypted; AWS protects them in specialized and highly secure hardware.

Analogy: KMS is like the bank's vault for keys, guarded by security. You don't take the master keys home (where they could be stolen): they stay in the vault. When you need to open something, the bank uses the key for you, inside the vault, and logs who requested to open what and when. The keys never leave the vault unprotected.

The best thing about KMS is that it integrates with almost all AWS services and makes encryption practically transparent. Remember all the times we said "enable encryption" in the book:

• S3 (Chapter 5): encrypt the objects in a bucket.
• RDS (Chapter 8): encrypt the database.
• EBS (EC2 disks): encrypt the storage.
• Terraform state (subchapter 20.1): encrypt = true.

In all those cases, KMS is managing the key behind the scenes. You just say "encrypt this with this KMS key," and AWS takes care of encrypting and decrypting automatically when needed, without your application having to handle the keys.

A key piece: who can use each key is controlled with IAM (Chapter 7) and the key's policies. This is very powerful, because it adds a second barrier:

Even if someone has access to some encrypted data, if they do not have permission to use the KMS key that decrypts it, they cannot read it. It's an extra layer of protection: you separate "accessing the data" from "being able to decrypt it."

Apply least privilege (subchapter 7.2): only those who really need to decrypt certain data should have permission on that key.

A good security practice is to rotate keys periodically: change them every so often, so that if a key were compromised, its "window of usefulness" for an attacker is limited. Doing this by hand would be a huge mess (you'd have to re-encrypt everything with the new key).

KMS offers automatic rotation: you can enable a key to rotate itself (for example, once a year) without you having to do anything and without breaking access to already encrypted data. KMS manages key versions underneath in a transparent way.

KMS logs every use of every key (integrated with CloudTrail). This way you can know who decrypted what and when, which is essential for investigating incidents and for compliance. If there were unauthorized access to sensitive data, the trail is there.

Real world example: a hospital stores medical records in AWS, encrypted with KMS. By law, they must protect that data and be able to prove who accesses it. With KMS: the data is encrypted, only authorized personnel have permission on the key that decrypts it, the keys are rotated automatically every year, and every access is logged. If an employee tried to decrypt records without authorization, they couldn't (they don't have permission on the key) and the attempt would be logged. The hospital complies with regulations and protects its patients.

• Encryption protects data (at rest and in transit) by making it unreadable without the key; but encryption is only as strong as the protection of the keys (it's useless to "leave the key in the lock").
• KMS (Key Management Service) is AWS's key vault: it creates, stores, and manages them ultra-securely; master keys never leave unprotected.
• It integrates with almost all services (S3, RDS, EBS, Terraform state...) making encryption transparent: you say "encrypt with this key" and AWS encrypts/decrypts automatically.
• Access to keys is controlled with IAM (least privilege): even if someone accesses the encrypted data, without permission on the key they cannot read it (extra barrier).
• It offers automatic key rotation (no manual work or interruptions) and auditing of every use (who decrypted what and when), essential for regulated environments.

In the last subchapter of the chapter, we will see where to store your application's secrets (passwords, API keys): Secrets Manager and Parameter Store.