AWS Secrets Manager vs Parameter Store for secrets governance

At a glance

What this is: AWS Secrets Manager and Parameter Store both store sensitive values, but they serve different governance needs for rotation, cross-account access, and scale.

Why it matters: IAM, PAM, and NHI teams need to separate low-risk configuration from credentials that require lifecycle control, or they end up managing secret sprawl by hand.

By the numbers:

• Standard parameters carry no storage charge, but Advanced parameters cost $0.05 per parameter per month.
• Secrets Manager bills $0.40 per secret per month, plus $0.05 per 10,000 API calls.

👉 Read Infisical's analysis of AWS Secrets Manager vs Parameter Store

Context

Secrets management is not just about encrypting a value at rest. The governance question is whether the platform can support rotation, access control, sharing, and auditability for the kind of identity that owns the secret, especially when those identities are non-human.

AWS gives teams two different services for this problem, but they are not interchangeable. One is designed for credentials with lifecycle needs, the other is a broader configuration store that can also hold sensitive values, which means the architectural choice shapes how much manual governance the team inherits.

Key questions

Q: How should teams decide whether a value belongs in Secrets Manager or Parameter Store?

A: Use Secrets Manager for values that need automatic rotation, tighter access control, or direct cross-account sharing. Use Parameter Store for configuration values and lower-risk secrets where you can manage rotation manually or do not need it. The decision should be driven by lifecycle, access scope, and audit needs rather than by default platform preference.

Q: Why do secret stores become a governance issue at scale?

A: Because the number of values grows faster than the team’s ability to track ownership, rotation, and access boundaries by hand. Once hundreds or thousands of secrets are spread across environments and accounts, the problem is no longer storage. It is inventory accuracy, policy consistency, and whether the organisation can prove who can access what.

Q: What breaks when Parameter Store is used for credentials that need rotation?

A: The team inherits the rotation workload itself. Without built-in rotation, every change depends on scripts, schedules, and custom logic that must be maintained, tested, and audited. That increases the chance of stale credentials, inconsistent revocation, and gaps between the secret’s intended lifecycle and its actual exposure window.

Q: Who should own the control model for non-human secrets?

A: Ownership should sit with the identity or security team that governs lifecycle and access policy, not only with the application team consuming the secret. When ownership is unclear, rotation and offboarding become optional behaviour. The better model is a shared control plane with clear accountability for placement, rotation, and cross-account access.

Technical breakdown

Secrets Manager vs Parameter Store: storage is not the real distinction

Both services keep values out of plain text, but their control model differs. Parameter Store is a general-purpose Systems Manager component with encrypted strings, so it suits configuration data and low-risk secrets where lifecycle handling is external. Secrets Manager is purpose-built for secrets that need rotation and tighter access control, so it embeds credential-centric assumptions into the service itself. That means the decision is less about secrecy and more about whether the value has a lifecycle that the platform should actively manage.

Practical implication: classify values by lifecycle need before deciding where they live.

Rotation and cross-account sharing drive the operational split

Secrets Manager includes built-in rotation and native templates for common AWS databases, while Parameter Store requires custom scripting for rotation. Cross-account access also differs materially: Secrets Manager supports direct resource policies on a secret, while Parameter Store cross-account sharing is limited to advanced parameters through AWS RAM. In practice, the service you choose determines whether governance is policy-driven or hand-built, and that affects auditability as environments multiply.

Practical implication: use the service that matches the rotation and sharing pattern, not the one already familiar to the team.

Price scale changes the governance decision at volume

The article's core point is that pricing becomes a governance signal once teams manage hundreds or thousands of values. Secrets Manager charges per secret and per API call, while Parameter Store offers a free standard tier and a paid advanced tier for larger or more complex parameters. At that point, the question is whether premium features are being used for every value or only for the smaller set that truly needs them. Cost pressure often reveals poor secret classification more quickly than security review does.

Practical implication: build a value-by-value inventory so cost does not hide unnecessary placement in premium secret stores.

Threat narrative

Attacker objective: The objective is to exploit weak secret governance and expand the blast radius of exposed or poorly managed credentials.

1. Entry occurs when sensitive values are placed in the wrong AWS store for their lifecycle, such as credentials kept in a general configuration system without native rotation.
2. Escalation follows when manual rotation, cross-account sharing, and auditing become inconsistent across environments and accounts, creating a fragmented control surface.
3. Impact is governance drift, where teams lose a reliable view of where secrets live, how they are rotated, and who can access them.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secrets placement is now an identity governance decision, not a storage decision. The article shows that the functional gap between these services is lifecycle management, not encryption. Once teams treat every sensitive value as interchangeable, they blur the line between configuration and credentials, which makes review, rotation, and offboarding inconsistent. The practitioner conclusion is that secret classification must be tied to governance intent, not convenience.

Cross-account access changes the accountability model for non-human identities. Secrets Manager supports direct resource policies on a secret, while Parameter Store depends on a different sharing model for advanced parameters. That difference matters because access boundaries are easier to audit when the secret itself carries the policy. The practitioner conclusion is that account-spanning NHI access should be designed around the narrowest shareable unit, not the broadest store.

Secret sprawl is often a policy failure disguised as a tooling choice. The article's hybrid pattern is common because organisations eventually split configuration from credentials to control cost and lifecycle. The real governance risk appears when that split is maintained informally, with no authoritative inventory showing which values require rotation and which do not. The practitioner conclusion is that inventory discipline matters more than the storage product name.

Hybrid secret stores create a control-plane problem once scale crosses a threshold. Using two AWS-native services can be sensible, but the split creates duplicated audit trails and judgment calls unless the organisation standardises placement rules. That is where NHI governance becomes continuous rather than transactional. The practitioner conclusion is that teams should measure how many secrets are being managed by policy versus by exception.

Storage without lifecycle controls leaves NHIs exposed to the same persistence problems seen in broader secret breaches. The article reinforces a familiar pattern: values that are easy to store are not automatically easy to govern. When rotation, offboarding, and sharing are separate decisions, credentials survive longer than their intended trust context. The practitioner conclusion is to align secret location with the identity lifecycle, not with team preference.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader view of secret exposure patterns, see the Guide to the Secret Sprawl Challenge, which maps how sprawl turns into operational risk.

What this signals

Secret governance is drifting from a technical choice to a lifecycle discipline. As organisations split configuration from credentials, the control question becomes whether placement rules are enforced consistently across teams and accounts. The practical signal is that inventory and ownership need to be explicit, or the secret store itself becomes a source of policy drift.

The article also reinforces a broader NHI pattern: the easiest place to store a secret is rarely the safest place to govern it. For practitioners, that means the roadmap should focus on placement standards, rotation triggers, and exception review, not just on consolidating tools.

For practitioners

• Separate configuration from credentials explicitly Define placement rules so feature flags, endpoints, and other low-risk values stay in the general configuration store, while credentials that require rotation move to the dedicated secret store.
• Inventory values by lifecycle requirement Tag each secret or parameter by rotation need, access scope, and cross-account sharing requirement so teams can decide where it belongs without relying on tribal knowledge.
• Standardise cross-account access patterns Use the narrowest sharing model that fits the use case and document every exception, especially where another AWS account needs direct access to a secret.
• Measure manual rotation burden and audit drift Track how many values still depend on scripts, ad hoc approvals, or separate audit trails, because those are the first signs that the split between services is becoming ungovernable.

Key takeaways

• AWS secret storage is a governance problem because the two services solve different lifecycle needs, not the same one.
• At scale, the real risk is not where a value sits, but whether rotation, sharing, and audit controls remain consistent across accounts.
• Teams need placement rules and inventory discipline, or the split between configuration and credentials turns into secret sprawl.

Key terms

• Secret Manager: A secret manager is a control that stores and sometimes rotates credentials such as tokens, keys, and certificates. It reduces exposure of sensitive material, but it does not by itself establish ownership, entitlement context, or revocation accountability, which means governance can still fail even when storage is secure.
• Parameter Store: AWS Systems Manager Parameter Store is a general-purpose configuration store that can also hold sensitive values using encryption. It works well for feature flags, endpoints, and low-risk secrets, but it does not provide the same native rotation or credential-first governance model.
• Cross-account secret sharing: Cross-account secret sharing is the practice of allowing another AWS account to read a sensitive value without copying it manually. It changes the accountability model because access must be governed at the secret boundary, and the sharing mechanism determines how clearly that access can be audited.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• A practical decision matrix for choosing between Secrets Manager and Parameter Store by value type, lifecycle need, and account boundary.
• The exact cost implications of running hundreds or thousands of secrets across environments, including when the pricing gap starts to matter.
• How the AWS-native split changes rotation operations when teams need to script what Secrets Manager can automate.
• The hybrid sync pattern for mirroring values into AWS services without forcing every team to manage placement by hand.

👉 Infisical's full post covers the rotation, sharing, and pricing details behind the service split.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.