AWS Parameter Store vs Secrets Manager: When the Free Tier Wins

Parameter Store vs Secrets Manager: The Quick Decision

AWS has two services for storing config and secrets, and the docs explain what they each do without explaining when each wins. The honest answer: Parameter Store Standard tier is free for the first 10,000 parameters and is the right pick for config that happens to be sensitive (database connection strings, API endpoints, feature flags). Secrets Manager is the right pick when you need automatic rotation, especially for RDS / DocumentDB / Redshift databases where AWS provides pre-built rotation Lambdas. Costs $0.40/secret/month — pays for itself when rotation matters, otherwise burns money. Many teams default to Secrets Manager for everything; the cost lever is real if you have 100+ secrets.

Dimension	Parameter Store	Secrets Manager
Pricing (Standard)	$0 (10K parameters, 4 KB each)	$0.40/secret/month + $0.05/10K API calls
Pricing (Advanced)	$0.05/parameter/month (8 KB)	—
Max value size	4 KB Standard / 8 KB Advanced	64 KB
Automatic rotation	No (build your own)	Yes (built-in, RDS native)
Cross-region replication	Manual	Built-in
Cross-account access	Resource policies	Resource policies
KMS encryption	Yes (Standard or customer-managed)	Yes (always)
Versioning	Up to 100 historical versions	AWSCURRENT / AWSPENDING / AWSPREVIOUS
SDK pattern	ssm.get_parameter()	secretsmanager.get_secret_value()
IaC support	CloudFormation, CDK, Terraform native	Same — both fully supported

Last updated: April 2026 — verified pricing on AWS Systems Manager and AWS Secrets Manager pages, free-tier limits, and rotation Lambda support for RDS / DocumentDB / Redshift.

Parameter Store: The Free Tier Most Teams Underuse

SSM Parameter Store has been around since 2016 and remains one of the most underused free AWS services. Standard tier supports up to 10,000 parameters of up to 4 KB each, KMS-encrypted, with versioning, hierarchical paths, and full IAM integration. Zero cost for parameters; pay only for the KMS encryption operations (which are often within KMS's own free tier).

Real cost math at scale

Scenario	Parameter Store	Secrets Manager	Difference
10 secrets, 100K reads/mo	$0	$4 + $0.50 = $4.50/mo	$54/year
50 secrets, 500K reads/mo	$0	$20 + $2.50 = $22.50/mo	$270/year
200 secrets, 2M reads/mo	$0 (still in free tier)	$80 + $10 = $90/mo	$1,080/year
500 secrets, 5M reads/mo	$0 (still in free tier)	$200 + $25 = $225/mo	$2,700/year
10,000 secrets, 50M reads/mo	$0 (at the limit)	$4,000 + $250 = $4,250/mo	$51,000/year

The cost gap is dramatic at scale. For organizations with 100+ secrets, Parameter Store can save thousands of dollars per year if rotation isn't required. The catch: at 10,001 parameters Standard tier blocks you, and Advanced tier is $0.05/parameter/month — which is cheaper than Secrets Manager's $0.40 but no longer free.

Secrets Manager: When the $0.40 Pays Off

The single most defensible reason to pay for Secrets Manager: built-in rotation for RDS / DocumentDB / Redshift / Aurora databases. AWS ships pre-built rotation Lambdas that handle the multi-step credential dance (create new password, update database, verify, promote, retire old). Setting this up yourself in Parameter Store is a 200-300 line Lambda + custom-built error handling.

Other reasons Secrets Manager wins:

• Cross-region replication built-in: one API call configures multi-region availability. Parameter Store requires a custom solution.
• 64 KB value size: holds full TLS certificate chains, OAuth client configs with multiple keys, large JSON blobs. Parameter Store's 4 KB cap pinches.
• Native integration with RDS/Aurora console: the "Manage password in Secrets Manager" checkbox creates the integration automatically.
• AWSPENDING / AWSCURRENT / AWSPREVIOUS staging: makes blue-green credential rotation cleaner than Parameter Store's version-only model.

The general secret management primer covers when the rotation story matters. The Vault vs Secrets Manager comparison covers the broader landscape if AWS-native isn't enough.

The Hybrid Pattern: Parameter Store for Config, Secrets Manager for Credentials

Many mature AWS deployments use both. Parameter Store holds:

• Database connection strings (host, port, db name) — cluster endpoints rarely change
• Feature flags ("/myapp/feature-newcheckout" = "true")
• API endpoints to upstream services
• Per-environment configuration (timeouts, batch sizes, log levels)
• Public values that aren't secret but are sensitive (S3 bucket names, encryption ARNs)

Secrets Manager holds:

• Database passwords (with auto-rotation)
• Third-party API keys (Stripe, SendGrid, Datadog) — rotation matters for compromise response
• OAuth client secrets
• Service-to-service auth tokens that need staged rotation

The same boto3 SDK call pattern works for both:

import boto3
import json

ssm = boto3.client('ssm')
sm = boto3.client('secretsmanager')

# From Parameter Store (free, for config)
db_host = ssm.get_parameter(Name='/myapp/prod/db/host')['Parameter']['Value']

# From Secrets Manager (paid, for credentials)
secret = sm.get_secret_value(SecretId='myapp/prod/db')
db_password = json.loads(secret['SecretString'])['password']

Many teams write a thin wrapper that abstracts the source — your code calls get_config('db.host') and the wrapper decides whether it's a Parameter Store or Secrets Manager lookup based on the path or annotation.

Pro tip: Use Parameter Store hierarchical paths to organize at scale: /myapp/{env}/{service}/{key}. get_parameters_by_path with recursion fetches a whole subtree in one API call. This is dramatically faster than per-parameter lookups when an app needs many config values at startup.

The "Secret Cache" Pattern

Both services charge per API call (Parameter Store at high request rates; Secrets Manager always). For high-traffic apps that read secrets on every request, build a local cache:

from functools import lru_cache
from datetime import datetime, timedelta
import boto3

ssm = boto3.client('ssm')

class CachedConfig:
    def __init__(self, ttl_seconds=300):
        self._cache = {}
        self._ttl = timedelta(seconds=ttl_seconds)

    def get(self, name):
        now = datetime.utcnow()
        if name in self._cache:
            value, expires = self._cache[name]
            if expires > now:
                return value
        value = ssm.get_parameter(Name=name, WithDecryption=True)['Parameter']['Value']
        self._cache[name] = (value, now + self._ttl)
        return value

config = CachedConfig(ttl_seconds=300)
db_host = config.get('/myapp/prod/db/host')

For Lambda specifically, AWS provides the Parameters and Secrets Lambda Extension that runs as a sidecar and caches automatically — drop it in via the Lambda layers UI and it eliminates per-invocation API calls. Cost reduction can be 10-100x for high-frequency Lambda secret reads.

Migration Patterns

Secrets Manager → Parameter Store

Right move for cost optimization when rotation isn't needed. Process:

# 1. Read existing secret
aws secretsmanager get-secret-value --secret-id myapp/prod/db | jq -r '.SecretString' > /tmp/secret.json

# 2. Push to Parameter Store
aws ssm put-parameter --name '/myapp/prod/db' \
  --value "$(cat /tmp/secret.json)" \
  --type SecureString --tier Standard

# 3. Update app code: change boto3 client and key path
# 4. Deploy and verify
# 5. Delete from Secrets Manager (after verification): aws secretsmanager delete-secret --secret-id myapp/prod/db

Parameter Store → Secrets Manager

Right move when you discover you need rotation. Reverse the above. Test the rotation Lambda in staging first; rotation failures can lock you out of production databases.

Pitfalls to Avoid

1. Hitting the 10,000 parameter Standard-tier limit: at scale, Advanced tier becomes mandatory. Plan for it; the migration to Advanced is online but not free.
2. Forgetting WithDecryption=True: SecureString parameters return ciphertext if you forget the flag. Easy bug, hard to debug.
3. Per-invocation Secrets Manager calls in Lambda: at high invocation rates, this adds up. Use the Parameters and Secrets Lambda Extension or build a cache layer.
4. Mixing Parameter Store and Secrets Manager paths in IAM policies: granting ssm:* doesn't grant access to Secrets Manager and vice versa. They're separate services with separate IAM verbs.
5. Not tagging at scale: tag both Parameter Store parameters and Secrets Manager secrets for cost attribution. AWS Cost Explorer can show per-tag spend, useful when proving the migration ROI.

Decision Matrix: Pick X If...

• Pick Parameter Store if: under 10,000 secrets, no rotation needed, values fit in 4-8 KB, AWS-only deployment, want zero cost.
• Pick Secrets Manager if: you need automatic rotation (especially RDS), values larger than 8 KB, multi-region replication is required, or compliance demands native rotation logging.
• Use both: most mature AWS deployments do. Parameter Store for config; Secrets Manager for credentials needing rotation. Common patterns ship a thin abstraction layer.
• Look beyond AWS-native if: multi-cloud, want self-hosting, need dynamic secrets — see the 8-tool alternatives roundup.

Frequently Asked Questions

Default to Parameter Store, Pay for Secrets Manager When You Need Rotation

Most AWS teams default to Secrets Manager for everything and pay $40-200+/month they could save. The honest answer: Parameter Store handles 70-80% of secret-storage needs at zero cost. Pay for Secrets Manager when you specifically need rotation (RDS native integration alone justifies it), values over 8 KB, or cross-region replication. The hybrid pattern — Parameter Store for config, Secrets Manager for credentials — is the right architecture at scale and saves real money on AWS bills.