AWS Secrets Manager

1. Plain-English Mental Model

AWS Secrets Manager stores and manages sensitive secrets.

A secret can be a database password, API key, OAuth credential, third-party token, or any sensitive value an application needs at runtime. Secrets Manager stores the value encrypted, controls access with IAM and resource policies, records access through CloudTrail, and can rotate supported secrets.

The simple model is:

application -> Secrets Manager -> encrypted secret -> downstream service credential

The point is not only hiding a string. The point is secret lifecycle: create, retrieve, rotate, audit, restrict, replicate, and eventually delete.

Secrets Manager is closely related to KMS because secrets are encrypted with KMS keys. It is also often compared with Systems Manager Parameter Store. Parameter Store can hold configuration and secure strings; Secrets Manager is stronger when rotation and secret-specific lifecycle features matter.

2. Why This Service Exists

Secrets leak when teams treat them like normal configuration.

Passwords end up in source code, AMIs, user data, environment variables, deployment scripts, CI logs, or shared documents. Even if a secret is encrypted once, rotation often becomes manual and rare.

Secrets Manager exists to make secret storage and rotation part of the architecture.

For AWS Solutions Architect Associate exam (SAA-C03), Secrets Manager appears in questions about storing database credentials, automatic rotation, retrieving secrets from Lambda or ECS, RDS integration, avoiding hardcoded credentials, cross-account secret access, and encryption with KMS.

The important exam distinction is this: if the question emphasizes managed rotation of credentials, Secrets Manager is usually stronger than Parameter Store.

3. The Naive Approach And Where It Breaks

The naive design stores credentials in application configuration:

DATABASE_PASSWORD=plain-text-password

This breaks when developers copy the config, logs print environment variables, AMIs preserve old secrets, or credentials need rotation without redeploying every service.

Another naive design stores an encrypted secret in S3 but builds custom retrieval and rotation logic. That can work, but it creates extra code and weak audit trails compared with a managed secret service.

Another mistake is using Secrets Manager but never rotating secrets, never scoping IAM, or giving broad read access to every workload.

Secrets Manager solves storage and lifecycle. It does not make every principal safe to trust with every secret.

4. Core Primitives

A secret is the managed resource that stores secret value and metadata.

Secret versions allow rotation and staging labels. Common staging labels include AWSCURRENT, AWSPREVIOUS, and AWSPENDING.

Rotation updates the credential in Secrets Manager and the downstream service. For many managed database secrets, Secrets Manager supports managed rotation. For custom secrets, rotation can use a Lambda rotation function.

KMS keys encrypt secret values. The caller needs Secrets Manager permissions and may need KMS permissions depending on key and access path.

Resource policies can grant cross-account access to a secret.

CloudTrail records Secrets Manager API activity.

Client-side caching libraries can reduce repeated API calls and latency.

5. Architecture Use Cases

Use Secrets Manager for RDS, Aurora, Redshift, DocumentDB, and other database credentials that need managed or automated rotation.

Use it for API keys and third-party credentials that applications need at runtime.

Use it with Lambda, ECS, EC2, and Kubernetes workloads so secrets are fetched at runtime rather than baked into images or AMIs.

Use resource policies for cross-account secret sharing when a central security account owns secrets and workload accounts need controlled access.

Use replication when secrets must be available in multiple Regions.

Use Parameter Store instead when the value is non-secret configuration or when a simpler low-cost secure string is enough and rotation is not required.

7. Security Model

Secrets Manager uses IAM permissions, resource policies, and KMS.

Applications need permission to read only the specific secrets they require. Avoid wildcard access to all secrets.

Administrators who can update secret resource policies or KMS key policies can expand access, so separate administrative roles from application reader roles.

If a secret uses a customer managed KMS key, the key policy must allow the required principals and Secrets Manager service path.

Rotation functions need permission to read and update the secret and update the downstream service credential.

Use CloudTrail to audit access. Monitor unusual secret reads.

Do not log secret values.

8. Reliability And Resilience

Secrets Manager is managed, but applications should handle retrieval errors gracefully.

Cache secrets in memory for reasonable periods to reduce latency and avoid hard dependency on every request, but respect rotation and security requirements.

Rotation can break applications if the downstream service update fails or if clients do not refresh credentials correctly.

Test rotation. A configured rotation schedule that no one has tested can become an outage generator.

Use multi-Region replication for secrets needed by disaster recovery workloads in another Region.

Protect deletion. Secrets can be scheduled for deletion; accidental deletion can break applications.

9. Performance And Scaling

Do not call Secrets Manager on every user request if the secret changes rarely. Use caching with controlled refresh.

Lambda functions can retrieve secrets during initialization, but cold starts and rotation behavior must be considered.

High-frequency secret retrieval can add latency and cost.

Rotation schedules should avoid overloading databases or dependent systems.

For ECS and Lambda, understand whether the secret is injected at startup or fetched dynamically by application code. Startup injection may require task or function restart to pick up changes.

10. Cost Model

Secrets Manager cost includes monthly secret storage and API calls. Rotation Lambda functions and related services can add cost.

Parameter Store can be cheaper for simple configuration or lower-complexity secure values.

The cost of leaking or failing to rotate production credentials is much higher than the storage charge for important secrets.

Use caching to reduce API call cost and latency.

Avoid storing many short-lived or non-secret values as Secrets Manager secrets when Parameter Store or application config fits better.

12. SAA-C03 Exam Signals

"Store and automatically rotate database credentials" points to Secrets Manager.

"Avoid hardcoding credentials in Lambda or ECS" points to Secrets Manager or Parameter Store, with Secrets Manager favored when rotation matters.

"Rotate RDS credentials" points to Secrets Manager.

"Encrypt secret with customer managed key" points to KMS integration.

"Cross-account access to secret" points to resource policy plus KMS permissions.

"Simple hierarchical configuration value" may point to Parameter Store instead.

13. Common Exam Traps

Do not store secrets in AMIs, user data, or source code.

Do not confuse encryption with rotation. A secret can be encrypted and still stale.

Do not grant every application access to every secret.

Do not forget KMS permissions for customer managed keys.

Do not assume rotation is safe without testing the downstream service update.

Do not use Secrets Manager for every non-sensitive config value by default.

15. Related Topics

Review AWS Key Management Service, AWS Systems Manager, Amazon RDS, and IAM Foundations.

Official AWS references:

• Manage secrets with AWS Secrets Manager
• Rotate AWS Secrets Manager secrets
• Rotation schedules