AWS Secrets Manager vs Parameter Store: Which One to Use and When

April 12, 2026 — Nick Allevato

Every AWS architecture eventually needs to store secrets: database passwords, API keys, OAuth tokens, TLS certificates. The two obvious options are AWS Secrets Manager and AWS Systems Manager Parameter Store. They overlap enough to cause confusion, and choosing wrong creates either unnecessary cost or security gaps.

Here’s the practical breakdown.

What they share

Both services store strings (and Parameter Store stores SecureString values encrypted with KMS). Both integrate natively with Lambda, ECS task definitions, EKS via CSI driver, EC2 instance profiles, and CloudFormation. Both support fine-grained IAM access control. Both can be encrypted with customer-managed KMS keys.

For a basic use case — store a database password, retrieve it in your application — either works.

The differences emerge at scale and at the edges.

Parameter Store: the practical details

SSM Parameter Store comes in two tiers:

Standard tier (free):

  • Up to 10,000 parameters per account per region
  • Maximum value size: 4KB
  • No additional charge for storage or API calls (beyond standard API rate limits)
  • No built-in rotation

Advanced tier ($0.05/parameter/month + $0.05 per 10,000 API interactions):

  • Up to 100,000 parameters
  • Maximum value size: 8KB
  • Parameter policies (expiration, notification)
  • Higher API throughput limits

SecureString parameters are encrypted with KMS. You pay KMS API call costs ($0.03 per 10,000 calls for customer-managed keys). For high-frequency reads (Lambda invocations, ECS task launches), this adds up — though caching in your application reduces it significantly.

What Parameter Store is good at:

Configuration management. It was designed for config, not just secrets — environment-specific settings, feature flags, infrastructure state, AMI IDs, endpoint URLs. Hierarchical paths (/app/prod/db_host, /app/prod/db_password) make it natural for organizing an entire application’s configuration alongside its secrets.

Cost efficiency for high-volume simple secrets. A single database password used across 50 Lambda functions that each read it 1,000 times per day: Parameter Store with application-side caching (cache for 5 minutes) = near-zero cost. Secrets Manager would cost $0.40/month just for the secret, plus API call charges.

What it lacks: Native secret rotation. You can build rotation using Lambda + EventBridge, but you’re building and maintaining that pipeline yourself.

Secrets Manager: the practical details

AWS Secrets Manager charges $0.40 per secret per month + $0.05 per 10,000 API calls.

For an application with 100 secrets, that’s $40/month baseline — before API calls. For a large microservices deployment with thousands of unique secrets (per-service database credentials, per-environment API keys), this becomes significant.

What Secrets Manager adds:

Native rotation. This is the primary reason to choose Secrets Manager over Parameter Store. Built-in rotation support for:

  • Amazon RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB)
  • Amazon Redshift
  • Amazon DocumentDB
  • Amazon ElastiCache
  • Rotation via custom Lambda function (for anything else)

Rotation works by generating a new credential, updating the secret, and optionally updating the dependent resource. For RDS specifically, Secrets Manager uses a Lambda rotation function that:

  1. Generates a new password
  2. Creates a new user (or updates the existing one) in the database
  3. Updates the secret value
  4. Tests that the new credential works
  5. Removes the old credential (if using the alternating-users strategy)

This is automated, audited, and doesn’t require your application to restart — as long as your application retrieves the secret at invocation time rather than caching it indefinitely.

Cross-account access. Secrets Manager secrets support resource-based policies, enabling direct cross-account secret sharing:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT-B-ID:role/application-role"
      },
      "Action": ["secretsmanager:GetSecretValue"],
      "Resource": "*"
    }
  ]
}

Parameter Store SecureString values require cross-account KMS key sharing to achieve similar cross-account access — more moving parts.

Replication. Secrets Manager supports cross-region secret replication for multi-region architectures. Parameter Store has no native replication.

SOC 2 and HIPAA positioning. Both services appear in AWS’s HIPAA eligibility list. The difference is rotation: auditors increasingly expect automated rotation for database credentials and privileged access credentials. If you’re working toward SOC 2 Type II or HIPAA, native rotation documentation from Secrets Manager is easier to present than a custom rotation Lambda you built yourself.

The decision framework

Use Parameter Store when:

  • You’re storing non-rotating configuration values (endpoints, feature flags, AMI IDs, environment names)
  • You have many parameters (100+) with low per-parameter value
  • You need hierarchical config organization across environments
  • Cost is a constraint and the secrets are relatively stable
  • You don’t need cross-account secret sharing

Use Secrets Manager when:

  • Database credentials that should rotate (RDS, Redshift, DocumentDB)
  • You’re building toward SOC 2 or HIPAA and need demonstrable automatic rotation
  • Cross-account secret access is required
  • Multi-region architecture requires secret replication
  • Third-party API keys with rotation support via custom Lambda

Use both (the common pattern):

Most well-designed AWS architectures use both. Parameter Store for configuration and stable values; Secrets Manager for credentials that rotate or require cross-account access.

/app/prod/
  db_host           → Parameter Store (endpoint, not a secret)
  db_name           → Parameter Store
  feature_flag_x    → Parameter Store
  
Secrets Manager:
  /app/prod/db-credentials    → RDS password (rotating every 30 days)
  /app/prod/stripe-api-key    → Stripe key (rotated manually or via custom Lambda)

Retrieval patterns

Lambda: Native integration via AWS_SECRETS_MANAGER_SECRET_ID or direct SDK call. For Parameter Store, use the ssm:GetParameter call at cold start and cache in the execution environment.

ECS Task Definitions: Both services support the secrets field in ECS task definitions:

{
  "secrets": [
    {
      "name": "DB_PASSWORD",
      "valueFrom": "arn:aws:secretsmanager:us-east-1:123456789:secret:prod/db-credentials"
    },
    {
      "name": "APP_ENV",
      "valueFrom": "/app/prod/environment"
    }
  ]
}

ECS fetches these at task launch and injects them as environment variables. Note: this means the secret value at task launch time is what the container sees. If Secrets Manager rotates the secret while the task is running, the container doesn’t see the new value until it restarts. Design your rotation window accordingly.

Kubernetes (EKS): The AWS Secrets and Configuration Provider (ASCP) mounts secrets from both services as Kubernetes volumes or environment variables using the Secrets Store CSI Driver.

Application-side caching: For high-frequency reads, cache the secret value in-process. The AWS SDK’s caching client (aws-secretsmanager-caching-java, botocore-session patterns) handles TTL and refresh. A 5-minute cache on a secret that changes every 30 days is appropriate — during the rotation window, your application picks up the new value at the next cache expiry.

IAM: least-privilege patterns

For both services, scope permissions to the specific secrets your service needs:

{
  "Effect": "Allow",
  "Action": ["secretsmanager:GetSecretValue"],
  "Resource": "arn:aws:secretsmanager:us-east-1:123456789:secret:prod/myapp-*"
}

Never "Resource": "*" for secret retrieval. If a Lambda function is compromised, that permission boundary is the difference between one secret and every secret in your account.

For Parameter Store, use path-based restrictions:

{
  "Effect": "Allow",
  "Action": ["ssm:GetParameter", "ssm:GetParametersByPath"],
  "Resource": "arn:aws:ssm:us-east-1:123456789:parameter/app/prod/*"
}

Also require KMS decrypt permission for SecureString parameters if using a CMK:

{
  "Effect": "Allow",
  "Action": ["kms:Decrypt"],
  "Resource": "arn:aws:kms:us-east-1:123456789:key/your-key-id"
}

Common mistakes

Hardcoded secrets in environment variables. Environment variables in ECS task definitions or Lambda function configurations appear in CloudTrail logs, are visible in the console, and persist in revision history. Use the secrets field (which fetches from Secrets Manager/Parameter Store at launch) rather than environment for sensitive values.

No rotation policy. If you’re using Secrets Manager and haven’t enabled rotation, you’re paying the premium without the primary benefit. Enable rotation on every RDS credential as a baseline.

Caching too aggressively during rotation. If your application caches a secret for 24 hours and rotation happens in a 10-minute window, there’s a 10-minute period where the cached credential is invalid. Use the dual-user rotation strategy (which keeps the old credential valid until all caches have expired) rather than single-user rotation.

Using Secrets Manager for everything. At $0.40/secret/month, a large application with hundreds of configuration values becomes expensive fast. Use Parameter Store for configuration, Secrets Manager for credentials.

The compliance conversation

For teams preparing for SOC 2 Type II, HIPAA, or PCI DSS, the secrets management evidence package typically includes:

  • What stores credentials and sensitive configuration
  • How credentials are rotated and on what schedule
  • Who has access to retrieve secrets (IAM audit)
  • Audit log of secret access (CloudTrail)

Secrets Manager makes this cleaner: rotation logs, CloudTrail GetSecretValue events, and resource policies are straightforward to present. The custom rotation Lambda approach (Parameter Store + Lambda) can satisfy the same requirements, but requires more documentation work.

Getting this right

Secrets management sits at the intersection of security, operational reliability, and compliance. Getting the architecture right matters, and it’s one of the things I consistently review in AWS infrastructure audits. If you want a second opinion on your secrets posture, reach out.

Nick Allevato is an AWS Certified Solutions Architect Professional with 20 years of infrastructure experience. He runs Cold Smoke Consulting, an independent AWS consulting practice.