- Blog post • 6 min read
AWS Secrets Manager vs. Parameter Store: Which Should You Use?
- Published on
AWS gives you two different places to store a value you don't want sitting in plain text in your code: Secrets Manager and Systems Manager Parameter Store. Both will hold a string securely, both integrate with the same AWS services, and both show up in the same "where do I put this" moment in secrets management. The difference isn't security, it's what each one is built to do beyond storage: rotation, access control, and price scale very differently once you're running more than a handful of values.
The difference between AWS Secrets Manager and Parameter Store
Parameter Store is part of AWS Systems Manager and was built as a general-purpose configuration store: feature flags, connection strings, and yes, secrets, with a Secure String type that encrypts the value through KMS. Secrets Manager was purpose-built for one job: storing credentials that need automatic rotation and tight access control.
| AWS Secrets Manager | Parameter Store | |
|---|---|---|
| What it's for | Credentials and secrets that need rotation | General configuration values, with optional encryption for sensitive ones |
| Size limit | Up to 64 KB per secret | 4 KB (standard tier), 8 KB (advanced tier) |
| Rotation | Built-in, with native Lambda templates for RDS, Aurora, Redshift, and DocumentDB | None built in. Rotation has to be scripted yourself |
| Cross-account access | A resource policy on any secret shares it directly with another AWS account | Only advanced-tier parameters can be shared cross-account, and only through a separate AWS Resource Access Manager (RAM) resource share, not a policy on the parameter itself |
| Pricing | $0.40 per secret per month, plus $0.05 per 10,000 API calls | Standard parameters carry no storage charge (default account limit of 10,000, raisable on request). Advanced parameters cost $0.05 per parameter per month. API calls are free at standard throughput on either tier, and $0.05 per 10,000 calls if you opt into higher throughput |
The pricing gap is the real decision driver
For a handful of values, the price difference is noise. It stops being noise once an organization is running hundreds or thousands of secrets across environments and accounts. Standard Parameter Store is free, and Secrets Manager bills per secret per month — and AWS is far from the only vendor whose pricing model shifts once you scale past a handful of secrets. Teams that put every configuration value and every credential into Secrets Manager by default often end up paying for rotation and cross-account features they aren't using on most of those values.
The hybrid pattern most teams land on
Given the price gap and the different feature sets, most teams don't pick one service, they split the work: non-sensitive or low-risk configuration (feature flags, endpoints, region names) goes in Parameter Store, and anything that actually needs automatic rotation or has to be shared across AWS accounts goes in Secrets Manager. This isn't a compromise, it reflects what each service is actually built for. Using Secrets Manager for a feature flag is paying for rotation infrastructure a flag will never use. Using Parameter Store for a database credential means building and maintaining your own rotation Lambda, something Secrets Manager already ships for the most common databases.
When to use each, and when to use both deliberately
- Parameter Store alone fits configuration values and secrets where you control rotation manually or don't need it, and you're not sharing the value across accounts.
- Secrets Manager alone fits credentials that need scheduled rotation, especially against RDS, Aurora, Redshift, or DocumentDB, or that need to be shared with another AWS account through a resource policy, no tier requirement to unlock it.
- Both, deliberately, is the common end state: Parameter Store for the bulk of configuration, Secrets Manager reserved for the smaller set of values where rotation or cross-account sharing actually matters.
This tends to track org size too. A small team often starts with everything in Parameter Store because it's free and simple, and only reaches for Secrets Manager when a specific database or compliance requirement demands rotation. A larger org with dozens of accounts usually has already drawn the line: Parameter Store for config, Secrets Manager for anything a security or compliance review would call a credential.
When AWS-native tooling isn't enough
Splitting values across two AWS services solves the AWS-native version of this problem, but it creates a new one: nobody has a single view of every secret and configuration value across environments and accounts, and the split itself has to be maintained and audited by hand. A few triggers show up repeatedly once this starts to hurt:
- Infrastructure that spans more than one cloud or includes on-premises systems, where Parameter Store and Secrets Manager only cover the AWS half.
- A security or compliance team that wants one audit trail instead of two AWS services with different access models to review separately.
- A growing number of accounts, where deciding "which service does this value belong in" becomes its own recurring judgment call instead of a one-time architecture decision.
Neither AWS service did anything wrong here. The problem outgrew what two AWS-native stores, built for different jobs, were ever meant to unify on their own.
Where Infisical fits
Infisical doesn't ask a team to choose between Parameter Store and Secrets Manager, or to migrate away from either. It syncs to both, and it can also handle rotation itself for values that end up in either destination, instead of leaving that to AWS Lambda templates.
AWS Secrets Manager Sync and AWS Parameter Store Sync
Infisical runs as the source of truth for secrets and configuration, then mirrors values out automatically to AWS Secrets Manager, AWS Parameter Store, or both at once, depending on where a given value needs to land for the services that read from it. This means the "which AWS service does this belong in" decision stops being an organization-wide policy that has to be maintained by hand, and becomes a per-value sync destination configured once. Teams already invested in the Parameter Store or Secrets Manager split can keep it. They just stop being the ones auditing and reconciling it manually across every account.
The short version
Use Parameter Store for configuration and secrets you don't need to rotate automatically. Use Secrets Manager when rotation or cross-account sharing is a real requirement, not a nice-to-have. Once that split is spread across enough accounts and environments to become its own maintenance burden, that's the point to look at a layer that manages both instead of picking one.
