AWS Secrets Manager vs Parameter Store: which to use

AWS answers the "which one" question itself. On its page about Parameter Store policies, AWS writes: "If you manage credentials that require automatic rotation, cross-account access, or fine-grained audit logging, we recommend using AWS Secrets Manager." Parameter Store, a tool of AWS Systems Manager, is a store for configuration data that can also hold encrypted SecureString values, and its standard parameters cost nothing extra. Secrets Manager is purpose-built for credentials and charges per secret and per API call.

Both services encrypt with AWS KMS, both are reached through IAM, and both log calls to CloudTrail. The practical differences are price, size, rotation, sharing across accounts and throughput.

Who each one fits

AWS Secrets Manager fits credentials that should change on a schedule, such as database passwords, and secrets that several AWS accounts or Regions need. Managed rotation covers many AWS-managed secrets without a Lambda function, and a Lambda function handles the rest. Secrets can be replicated to other Regions and shared with other accounts through resource-based policies.

Parameter Store fits configuration and a modest number of secrets that change by hand. Standard parameters are free of additional charge, hold up to 4 KB each and cover up to 10,000 parameters per account and Region. Advanced parameters raise those limits and add parameter policies for a monthly fee. Parameter Store can also reference Secrets Manager secrets, so services that read parameters can read secrets too.

What it costs in practice

Parameter Store has two separate settings that affect the bill. The tier of each parameter, standard or advanced, controls its size limit, policies and monthly charge. Throughput, standard or higher, applies to Parameter Store as a whole and controls the request rate. AWS defines an API interaction as one request touching one parameter, so a single Get that returns ten parameters counts as ten interactions. With standard parameters and standard throughput, there is no additional charge at all.

Secrets Manager charges for every secret and every call. At the rates in AWS's worked examples, 50 secrets read 1,000 times a day in total cost about $20 a month, almost all of it for storage. Replicating those secrets to a second Region doubles the storage part, because each replica is billed as its own secret. New AWS customers get Free Tier credits that can be applied to Secrets Manager.

For a small team with a few dozen secrets that change by hand, Parameter Store standard parameters can be enough. The cost question changes once you need rotation, cross-account access or larger values.

Who can decrypt

Both services hold the keys for you. Secrets Manager "decrypts the secret value before returning it to the caller", and its secret names and descriptions are not encrypted.

Parameter Store uses AWS KMS "to encrypt and decrypt the parameter values of SecureString parameters", and its parameter names stay in plaintext. In both services, a customer managed KMS key lets you control through IAM who may use the key, but decryption still happens inside AWS for any principal your policies allow.

Where Secrets Manager is stronger

• Rotation. Managed rotation for many AWS-managed secrets, and Lambda-based rotation for the rest. Parameter Store has expiration policies and notifications, not rotation.
• Sharing and Regions. Resource-based policies for cross-account access on every secret, and replication across Regions.
• Larger values. Up to 64 KB per secret, compared with 4 KB or 8 KB.
• AWS's recommendation for credentials. AWS itself points credentials that need rotation, cross-account access or fine-grained audit logging to Secrets Manager.

Where Parameter Store is stronger

• Cost. Standard parameters and standard throughput carry no additional charge.
• One place for configuration. Plain settings and SecureString secrets live in the same hierarchy, read with the same API.
• Bridges to Secrets Manager. Parameter Store can reference Secrets Manager secrets, so services that already read parameters can read secrets without a new integration.
• Simple limits for small setups. Up to 10,000 standard parameters per account and Region, with no additional charge.

A third option: Crunu

Crunu, which wrote this page, is for teams whose secrets are shared between people, laptops and CI as well as servers, and who do not want any cloud service to decrypt them. Values are encrypted in the browser and the crunu agent, and the server stores only ciphertext; each environment has its own key, sealed to each person, machine and pipeline. Pipelines on GitHub Actions, GitLab CI or Bitbucket Pipelines use service tokens bound by OIDC. People can drag .env files and ~/.aws/credentials into an environment and run programs with crunu run. It is free during early access. The server still sees metadata such as names, email addresses and timestamps, as the limitations page explains.

Crunu is not a fit for workloads that should read secrets through IAM roles, need rotation of database credentials, or run on EKS: it has no IAM integration, no rotation of values at providers and no Kubernetes support. See Crunu vs AWS Secrets Manager for the full comparison, or HashiCorp Vault vs AWS Secrets Manager if you are weighing a self-run vault.