Day 19: AWS KMS and Secrets Manager – Protecting Data and Secrets
Day 19 of my 90-day AWS challenge: how AWS KMS manages encryption keys, how Secrets Manager stores and rotates passwords and API keys, and why credentials should never be hard-coded in an application.
Recap of Day 18
Yesterday I automated builds and deployments with CI/CD, and I noted that secrets must stay out of the repository. Today I'm learning where they should live: AWS KMS protects data with encryption keys, and AWS Secrets Manager stores passwords and API keys safely.
Encryption in two places
- At rest: data stored on disk, such as S3 objects, EBS volumes, and RDS databases
- In transit: data moving over the network, protected with TLS/HTTPS
AWS KMS (Key Management Service)
KMS creates and controls the encryption keys used across AWS. The key material never leaves KMS in plain form, and every use of a key can be logged.
Types of keys
| Type | Who manages it |
|---|---|
| AWS owned keys | AWS, behind the scenes, with no visibility for you |
| AWS managed keys | AWS creates them in your account for a service, e.g. aws/s3 |
| Customer managed keys | You create and control them, including the key policy, rotation, and deletion |
Key concepts
- Key policy: decides who can use and manage a key (together with IAM from Day 2)
- Envelope encryption: KMS encrypts a small data key, and the data key encrypts the actual data, which is fast even for large files
- Automatic rotation: customer managed keys can rotate on a schedule that you control
- Deletion waiting period: keys are not deleted immediately, and you choose a waiting period of 7 to 30 days so mistakes can be undone
Where it is used
S3 (SSE-KMS), EBS, RDS, DynamoDB, SQS, Lambda environment variables, and Secrets Manager all integrate with KMS.
AWS Secrets Manager
Secrets Manager stores credentials such as database passwords, API keys, and tokens, encrypted with KMS. Applications fetch the secret at runtime instead of keeping it in code or configuration files.
Key features
- Automatic rotation: it can change a secret on a schedule, with built-in support for RDS databases (Day 6)
- Fine-grained access: IAM policies control who or what can read each secret
- Auditing: access is logged for review
- Versioning: keeps the current and previous versions during rotation
Reading a secret from Java
1
2
3
SecretsManagerClient client = SecretsManagerClient.create();
GetSecretValueResponse response = client.getSecretValue(r -> r.secretId("prod/db/credentials"));
String secret = response.secretString();The application's IAM role needs permission to read that secret, so no password ever appears in the code.
Secrets Manager vs. Parameter Store
| Secrets Manager | Systems Manager Parameter Store | |
|---|---|---|
| Best for | Credentials that need rotation | Configuration values and simple secrets |
| Automatic rotation | Yes | No built-in rotation |
| Cost | Per secret per month, plus API calls | Standard parameters are free |
How it connects to earlier days
- Day 2: IAM roles decide who can use a key or read a secret
- Day 4: S3 buckets can be encrypted with a KMS key
- Day 6: RDS storage can be encrypted, and its password can be rotated by Secrets Manager
- Day 18: a build or pipeline should read secrets from Secrets Manager, not from the repository
What I practiced today
- Created a customer managed KMS key and looked at its key policy
- Created an S3 bucket that uses SSE-KMS with that key
- Stored a test secret in Secrets Manager
- Retrieved the secret value from the console
- Cleaned up by deleting the secret and scheduling the key for deletion
Key takeaways
- Never hard-code passwords or keys in code, config files, or a Git repository
- Use customer managed keys when you need control over access, rotation, and auditing
- Let Secrets Manager rotate credentials instead of changing them by hand
- Keys and secrets are billed per month, so delete the ones you only created for practice
Up next: Day 20
Security monitoring: AWS CloudTrail, AWS Config, and Amazon GuardDuty.
Learning AWS too? Follow along and share what you're building. #90DaysOfAWS
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article