Differences between Secrets Manager and Parameter Store, explained for beginners

Conclusion

AWS Secrets Manager and AWS Systems Manager Parameter Store can both manage application configuration values and secret information.

However, their strong areas differ.

• Use AWS Secrets Manager for secrets that need rotation, such as database passwords and API keys
• Use Parameter Store for environment variables, endpoint URLs, and lightweight configuration values
• Parameter Store is also a candidate when handling lightweight values encrypted with SecureString

On AWS exams, when "automatic rotation" appears in a question, AWS Secrets Manager is the first candidate.

Comparison table

Explanations for beginners

AWS Secrets Manager is a service for managing secret information.

Lambda
↓ Retrieve at runtime
Secrets Manager
↓
DB password / API key

The application code does not contain the password; it is retrieved at runtime instead.

Parameter Store is a feature for managing configuration values.

Lambda
↓ Retrieve at runtime
Parameter Store
↓
/prod/api/base-url
/prod/app/log-level

Per-environment configuration values can be managed in a hierarchical structure.

Points that appear on the exam

Cases where AWS Secrets Manager tends to be the correct answer

• Storing database credentials
• Storing API keys securely
• Automatic rotation of secrets is required
• Removing hard-coded credentials
• Retrieving secret information at AWS Lambda runtime

Cases where Parameter Store tends to be the correct answer

• Storing application configuration values
• Managing per-environment parameters in a hierarchy
• Managing URLs, ARNs, and environment names
• Using lightweight encrypted parameters via SecureString
• Referencing configuration values from AWS CloudFormation or AWS Lambda

When to use each in practice

Managing a DB password

Use AWS Secrets Manager.

RDS password
↓
Secrets Manager
↓
Lambda / ECS / EC2

It fits secret information that needs automatic rotation and auditing.

Managing an API base URL

Use Parameter Store.

/prod/api/base-url = https://api.example.com
/dev/api/base-url = https://api-dev.example.com

It fits configuration values that are not secrets but change per environment.

Positioning in this project

In the MVP of this project, secret information is not hard-coded into the source.

The frontend uses .env.local, but it is not committed to Git.

If external API keys or JWT_SECRET need to be handled in production in the future, AWS Secrets Manager or Parameter Store will be considered.

Common misunderstandings

Mistake 1: Putting everything into AWS Secrets Manager

AWS Secrets Manager is strong at managing secret information, but putting plain configuration values in as well makes cost and operations heavier.

Separating configuration values into Parameter Store and secrets into AWS Secrets Manager keeps things organized.

Mistake 2: Assuming Parameter Store is safe for anything

Parameter Store's String and StringList types hold plaintext configuration values.

For secret information, either use SecureString or consider AWS Secrets Manager.

Mistake 3: Hard-coding secrets in environment variables

Local development sometimes relies on .env.local.

However, production operations require a design that keeps secrets out of code and GitHub.

Related terms

• AWS Secrets Manager
• AWS Systems Manager
• AWS Key Management Service
• AWS Lambda
• AWS Identity and Access Management

Related practice questions

• CLF practice questions

Summary

AWS Secrets Manager and Parameter Store are easier to choose between when separated by purpose.

• AWS Secrets Manager: secret information, credentials, automatic rotation
• Parameter Store: configuration values, environment variables, lightweight SecureString

On SAA-C03, this comparison is asked from both the security design and the operations design angle.