AWS Services
Secrets Manager vs Parameter Store
Compare AWS Secrets Manager and Systems Manager Parameter Store for secrets, configuration, SecureString values, rotation, hierarchy, cross-account sharing, throughput, cost, and SAA-C03 traps.
After this, you will understand
This comparison helps learners avoid both extremes: putting rotating database credentials in basic config storage, or paying secret-management complexity for ordinary app settings.
Use Secrets Manager for managed secret lifecycle and rotation; use Parameter Store for hierarchical configuration and simpler SecureString values.
Learners treat every config value as a secret, or treat rotating credentials like normal parameters.
Classify the value first: secret with lifecycle, lightweight encrypted value, non-secret config, deployment reference, or dynamic app configuration.
Think before readingWhich service is usually the better fit for automatic RDS credential rotation?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- AWS Secrets Manager
- Systems Manager Parameter Store
- SecureString parameters
- Secret rotation
- KMS encryption
- Hierarchical configuration
- Parameter tiers
- Cross-account sharing
- Application retrieval patterns
- SAA-C03 secrets traps
1. Plain-English Mental Model
Secrets Manager and Parameter Store both store values an application can retrieve at runtime, but they are optimized for different lifecycles.
Secrets Manager is for secrets that need secret-specific lifecycle management: rotation, versions, staging labels, auditability, and credential workflows.
Parameter Store is for configuration values and lightweight encrypted parameters organized by name and hierarchy.
The short model is:
Secrets Manager = secret lifecycle and rotation
Parameter Store = configuration hierarchy and simple parameters
The exam usually gives the answer through the word "rotation."
2. Why This Service Exists
Applications need values that should not be hardcoded.
Some values are normal configuration: environment name, log level, bucket name, table name, service URL, AMI ID, or feature environment setting.
Some values are secrets: database password, API key, OAuth token, or credential that must be protected and rotated.
Parameter Store exists to centralize parameters and configuration so values are not scattered across code, AMIs, deployment scripts, or instance user data.
Secrets Manager exists to manage sensitive credentials throughout their lifecycle, especially when rotation matters.
For SAA-C03, the distinction matters because both services can store encrypted values, but only one is purpose-built for secret rotation workflows.
3. The Naive Approach And Where It Breaks
The naive approach is:
secret string -> store it anywhere encrypted -> done
That misses lifecycle.
A database password that never rotates is a long-term liability. If changing the password requires redeploying every client, teams postpone rotation. Secrets Manager is designed to make retrieval and rotation part of the architecture.
The opposite mistake is putting every non-sensitive value into Secrets Manager. That adds cost and secret-management complexity where a normal parameter or AppConfig might fit better.
Another mistake is storing highly dynamic feature flags or operational levers in Parameter Store when AWS AppConfig would better support validation, gradual rollout, and rollback behavior.
4. Core Primitives
Secrets Manager primitives include secrets, secret versions, staging labels such as AWSCURRENT, rotation schedules, managed rotation, Lambda rotation functions, KMS encryption, resource policies, and CloudTrail auditing.
Parameter Store primitives include parameters, parameter names, hierarchy paths, parameter types, versions, labels, standard and advanced tiers, parameter policies for advanced parameters, KMS-backed SecureString values, and retrieval APIs such as GetParameter and GetParametersByPath.
Secrets Manager can rotate supported secrets and custom secrets.
Parameter Store can store SecureString values encrypted by KMS, but it is not the same as full secret lifecycle management.
Both services require IAM permissions. Both can involve KMS permissions when customer managed keys are used.
5. Architecture Use Cases
Use Secrets Manager for database credentials, third-party API keys, OAuth tokens, and secrets where rotation, secret versions, or cross-account secret policies matter.
Use Secrets Manager for RDS or Aurora credentials that should rotate automatically.
Use Parameter Store for non-secret configuration:
/prod/orders/table-name
/prod/orders/log-level
/prod/network/vpc-id
/amis/al2023/latest
Use Parameter Store SecureString for simpler encrypted values that do not need managed rotation.
Use Parameter Store public parameters for current AMI IDs when launching EC2 instances.
Use AppConfig instead when the value is dynamic application configuration that needs staged rollout, validation, or rollback.
7. Security Model
Secrets Manager and Parameter Store both depend on IAM and KMS.
Grant applications read access only to the exact secrets or parameter paths they need.
For Secrets Manager, resource policies can support cross-account access. Rotation functions need permissions to update both the secret and the downstream system.
For Parameter Store, path-based IAM can be useful but must be designed carefully. Access to a broad path can reveal many child parameters.
For SecureString, KMS permissions matter. A principal may be allowed to call ssm:GetParameter but still fail to decrypt the value if KMS denies access.
Never log retrieved secret or parameter values.
8. Reliability And Resilience
Applications should not retrieve secrets or parameters on every user request if the value changes rarely. Cache values in memory with a refresh strategy.
Secrets Manager rotation can break clients if the downstream credential update succeeds but clients do not refresh, or if the rotation workflow is not tested.
Parameter changes can break deployments if the value is missing, renamed, or overwritten.
Use versioning, labels, controlled updates, and rollback plans for important parameters.
For disaster recovery, ensure required secrets and parameters exist in the target Region and accounts. Secrets Manager supports replication patterns; Parameter Store values may need deployment or sharing strategy.
9. Performance And Scaling
Secrets Manager retrieval adds an API call and can add latency. Use caching libraries or controlled refresh.
Parameter Store has throughput considerations and tiers. Standard parameters fit many low-scale configuration retrieval patterns. Higher throughput and advanced parameters can add cost.
Bulk retrieval by path can simplify application startup, but broad paths can expose more than intended if IAM is too loose.
For Lambda and ECS, understand whether values are injected at startup or fetched by code. Startup injection may not pick up changes until a restart.
Rotation frequency should be realistic. Overly frequent rotation can stress dependent databases or services.
10. Cost Model
Secrets Manager charges for stored secrets and API calls. Rotation may use Lambda and related services unless using managed rotation paths that avoid custom Lambda.
Parameter Store standard parameters can be a lower-cost option for many configuration values. Advanced parameters, high throughput, and parameter policies can add charges.
KMS customer managed keys and KMS requests can add cost for both services.
Do not choose Parameter Store only because it is cheaper if the requirement is managed credential rotation. Do not choose Secrets Manager for ordinary non-sensitive configuration just because it sounds more secure.
The right cost answer comes from lifecycle fit.
12. SAA-C03 Exam Signals
"Automatically rotate database credentials" points to Secrets Manager.
"Store API keys and retrieve at runtime" often points to Secrets Manager.
"Hierarchical application configuration" points to Parameter Store.
"SecureString" points to Parameter Store with KMS, not necessarily Secrets Manager.
"Reference latest AMI ID" often points to public parameters in Parameter Store.
"Simple non-secret app setting" points to Parameter Store or AppConfig depending on rollout needs.
"Dynamic feature flags with validation and deployment strategy" points away from both and toward AppConfig.
13. Common Exam Traps
Do not confuse encryption with rotation.
Do not use Parameter Store as the default answer when the wording emphasizes managed credential rotation.
Do not use Secrets Manager for every ordinary config value.
Do not forget KMS decrypt permissions for SecureString or customer-managed encrypted secrets.
Do not retrieve secrets on every request without caching.
Do not store AWS access keys as application secrets when IAM roles or temporary credentials should be used.
Do not store encryption keys in Secrets Manager when KMS is the right key-management service.
15. Related Topics
Review AWS Secrets Manager, AWS Systems Manager, AWS Key Management Service, and KMS Key Policies vs IAM Policies.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.