What's changed: In-scope service coverage (axis B): added Systems Manager (Parameter Store) and AppConfig config/feature-flag externalization definitions, roles, and selection criteria to s3.
3.3Encryption and Secrets (KMS, Secrets Manager)
Understand key management and encryption at rest with AWS KMS, and securely storing/fetching/rotating secrets with Secrets Manager / SSM Parameter Store.
Encrypt sensitive data, and store passwords/API keys securely—never in code. On AWS, KMS (keys) and Secrets Manager (secrets) are key.
3.3.1Keys and secrets
- AWS KMS: centrally manages keys for encryption at rest of S3, EBS, RDS, etc.; key usage is auditable via CloudTrail.
- Secrets Manager: stores DB creds/API keys encrypted with automatic rotation; fetched at runtime via the SDK.
- SSM Parameter Store: stores config/secrets (SecureString encrypted with KMS); no built-in rotation but cheaper.
- Envelope encryption: encrypt data with a data key, then encrypt that data key with a KMS master key.
Security separates key management from secret management. AWS KMS centrally manages encryption keys for encryption at rest of S3, EBS, RDS, etc. Under the hood it uses envelope encryption: data is encrypted with a data key, and that data key is encrypted with a KMS master key (CMK). Key usage is auditable via CloudTrail. Separately, secrets like DB passwords and API keys go in Secrets Manager—encrypted, auto-rotated, fetched at runtime via the SDK (never plaintext in code or env vars). For config or small secrets that don’t need rotation and should be cheap, SSM Parameter Store SecureString (KMS-encrypted) fits. Decide by requirement: "auto-rotation" → Secrets Manager; "cheap config/small secret" → Parameter Store.
| Requirement | Use |
|---|---|
| Manage keys for encryption at rest | AWS KMS |
| Store DB creds + auto-rotate | Secrets Manager |
| Cheap config/small secrets | SSM Parameter Store (SecureString) |
| Audit key usage | KMS + CloudTrail |
KMS keys come in types. AWS managed keys are auto-managed by the service and easy, but you can’t finely control rotation cadence or key policy. Customer managed keys (CMK) let you define your own key policy, enable annual automatic key rotation, and set a waiting period before deletion. Who can encrypt/decrypt with which key is decided by the key policy + IAM policy combination, and grants can delegate permissions temporarily. In app code, rather than encrypting large data directly with KMS, the standard pattern is envelope encryption: get a data key (GenerateDataKey), encrypt locally, and store only the encrypted data key (avoiding KMS call counts and size limits). Secrets Manager uses KMS under the hood to encrypt secrets and achieves automatic rotation via a Lambda integration.
Scenario: a Lambda connects to RDS. Instead of hard-coding the DB password, store it in Secrets Manager with auto-rotation enabled; the Lambda fetches it at runtime under a least-privilege execution role. Encrypt RDS storage at rest with a KMS key and audit key usage via CloudTrail.
Q. Secrets Manager vs. Parameter Store? The former supports auto-rotation (pricier); the latter is cheap but has no built-in rotation. Q. What does KMS do? Manages encryption keys for encryption at rest (envelope encryption). Q. Where do secrets go? In a dedicated service—not code or plaintext env vars.
Watch the mix-ups: (1) Never put secrets in code/plaintext env vars. (2) Auto-rotation needed = Secrets Manager; cheap/no rotation = Parameter Store. (3) KMS handles "keys," Secrets Manager handles "the secrets themselves"—don’t swap their roles.
Common on DVA: key management / encryption at rest = KMS, store DB creds + auto-rotate = Secrets Manager, cheap config/secret store = SSM Parameter Store. Putting secrets in code or plaintext env vars is wrong.
3.3.2Externalizing config and feature flags (Systems Manager, AppConfig)
Beyond secrets, externalize configuration values (endpoints, thresholds, feature toggles) instead of hard-coding them. AWS Systems Manager (SSM) is a suite for operating servers and apps; within it, Parameter Store stores configuration values and secret references cheaply under hierarchical keys, encrypting SecureString entries with KMS. To change configuration without redeploying, use AWS AppConfig. AppConfig manages feature flags and dynamic configuration, validates them (schema or Lambda validators), rolls them out gradually, and auto-rolls back on a CloudWatch alarm. Rule of thumb: store static config/secret references = Parameter Store; safely deliver dynamic config/feature flags to a running app = AppConfig; auto-rotating secrets = Secrets Manager.
| What you want | Choice |
|---|---|
| Cheap hierarchical store of config/secret refs | AWS Systems Manager Parameter Store |
| Dynamic config/feature flags without redeploy | AWS AppConfig |
| Auto-rotating secrets | AWS Secrets Manager |
3.3.3Section summary
- KMS = keys/encryption at rest / Secrets Manager = secrets + auto-rotation
- Keep secrets out of code/plaintext; manage them with dedicated services
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to store database credentials securely with automatic rotation. Which service fits best?
Q2. Which AWS service centrally manages keys for encryption at rest of S3/EBS?
Q3. You want to store small config/secrets cheaply, optionally KMS-encrypted (SecureString). What do you use?