Hard-coding database passwords in environment variables is not a "startup shortcut" — it is a future incident. AWS gives you two main managed options for secrets: Secrets Manager and Systems Manager Parameter Store (SecureString). They overlap enough to confuse teams, but they are not interchangeable.
What AWS Secrets Manager does
Secrets Manager stores secrets as encrypted key/value pairs (or JSON documents) with fine-grained IAM access, CloudTrail auditing, and optional automatic rotation via Lambda functions. It integrates natively with Amazon RDS, Redshift, and DocumentDB for rotating database credentials without application downtime when implemented correctly.
Each secret can have:
- Multiple versions (AWSCURRENT, AWSPENDING during rotation)
- Rotation schedules (e.g. every 30 days)
- Resource policies for cross-account access
- Replication to other Regions for disaster recovery
Secrets Manager vs SSM Parameter Store
| Capability | Secrets Manager | Parameter Store (SecureString) |
|---|
| Automatic rotation | Built-in with Lambda templates | Manual / custom only |
| RDS integration | Native | Not native |
| Cost | Per secret + API calls | Standard parameters free tier; Advanced tier has fees |
| Max secret size | 64 KB | 8 KB (Standard), 8 KB Advanced |
| Cross-Region replication | Yes | No (use manual copy) |
| Audit & IAM | Yes | Yes |
When Secrets Manager is the right choice
- Database credentials that must rotate — compliance or security policy requires periodic rotation
- RDS / Aurora / Redshift — use the managed rotation templates instead of building your own
- Cross-account secret sharing with resource policies and clear ownership boundaries
- Multi-Region DR — replicate secrets so failover regions have current credentials
- Third-party API keys where rotation Lambdas are already standardized in your org
When Parameter Store is enough
- Static config values that rarely change (feature flags, non-rotating API keys in dev)
- Small secrets under 8 KB with no rotation requirement
- Cost-sensitive workloads with many low-churn values
- ECS/EKS/ Lambda already loading config via SSM paths you standardized on
Architecture patterns that work
ECS / EKS tasks
Tasks fetch secrets at startup via the task execution role (secretsmanager:GetSecretValue or ssm:GetParameter). Inject as environment variables or files — never bake into container images. Prefer IAM roles over access keys entirely.
Lambda
Retrieve secrets inside the handler with caching: load once per execution environment and reuse across warm invocations. Enable rotation-aware versioning so AWSCURRENT updates without redeploying the function.
Rotation without downtime
Rotation is a multi-step dance: create AWSPENDING, update the database user, test, then promote to AWSCURRENT. Use AWS-provided rotation Lambdas for RDS until you deeply understand the flow — custom rotation is where teams break production.
Security essentials (non-negotiable)
- Least-privilege IAM: one role per workload, access only to named secret ARNs
- Enable CloudTrail data events for secret access in regulated environments
- Use KMS CMKs when you need key policy control and cross-account encryption boundaries
- Never log secret values — redact in application logs and CI output
- Tag secrets (
Environment, Application, Owner) or cleanup becomes impossible
Common mistakes
- Storing secrets in Parameter Store to save money, then building fragile manual rotation scripts
- One "shared" secret for every microservice — blast radius equals the whole platform
- Forgetting rotation breaks apps that cache credentials forever
- Using Secrets Manager for non-secret config (pricing adds up fast with hundreds of keys)
Hands-on next step
Create an RDS instance, store its master password in Secrets Manager, enable automatic rotation, and connect an application using IAM authentication or retrieved credentials. When rotation flips AWSCURRENT, your app should keep working — if it does not, you found the bug before an auditor does.