AWS Secrets Manager vs Parameter Store: When to Use Which

Every application has secrets — database credentials, API keys, encryption keys, OAuth tokens — and configuration values — feature flags, endpoint URLs, timeout settings, environment-specific parameters. AWS provides two services for managing these: Secrets Manager and SSM Parameter Store. Both store key-value pairs securely, both integrate with IAM for access control, and both can be referenced from Lambda, ECS, EC2, and CloudFormation.

The overlap creates confusion. This guide provides clear decision criteria based on the features that actually differ.

Feature Comparison

When to Use Secrets Manager

Automatic Secret Rotation

Secrets Manager’s killer feature is built-in rotation. A Lambda function automatically rotates secrets on a schedule — no manual intervention, no downtime:

Schedule (every 30 days)
  → Secrets Manager triggers rotation Lambda
  → Lambda creates new credentials in the database
  → Lambda stores new credentials in Secrets Manager
  → Lambda verifies new credentials work
  → Applications automatically get new credentials on next retrieval

Supported rotations out of the box:

• RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server)
• Aurora
• Redshift
• DocumentDB
• Custom rotation (any secret via custom Lambda function)

For database credentials, Secrets Manager with rotation is the standard. Manually rotating database passwords is error-prone and creates security risk during the transition period. Rotation eliminates both problems.

Cross-Account Access

Secrets Manager supports resource-based policies that grant access to other AWS accounts:

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::222233334444:root" },
  "Action": ["secretsmanager:GetSecretValue"],
  "Resource": "*"
}

In a multi-account organization, this enables a central secrets account to share credentials with workload accounts without duplicating secrets.

Parameter Store does not support cross-account access natively. You must use IAM role assumption or replicate parameters across accounts.

Cross-Region Replication

Secrets Manager replicates secrets to multiple Regions for disaster recovery:

Primary Region (us-east-1) → Replica (us-west-2) → Replica (eu-west-1)

Applications in the DR Region access the local replica — same secret, same ARN pattern, no cross-Region API calls during failover.

Use Secrets Manager For

• Database credentials (with rotation)
• Third-party API keys that require periodic rotation
• OAuth client secrets
• Encryption keys managed outside KMS
• Secrets shared across AWS accounts
• Secrets replicated across Regions for DR

When to Use Parameter Store

Hierarchical Configuration

Parameter Store organizes parameters in a hierarchical path structure:

/myapp/production/database/host       = prod-db.cluster-abc.us-east-1.rds.amazonaws.com
/myapp/production/database/port       = 5432
/myapp/production/database/name       = myapp_prod
/myapp/production/feature-flags/dark-mode  = true
/myapp/production/feature-flags/new-ui     = false
/myapp/staging/database/host          = staging-db.cluster-def.us-east-1.rds.amazonaws.com
/myapp/staging/database/port          = 5432

Retrieve all parameters for an environment:

GetParametersByPath: /myapp/production/
→ Returns all production parameters in one API call

This hierarchical model maps naturally to application configuration — environment, service, and setting levels. Secrets Manager uses flat names without hierarchy.

Free Tier (Standard Parameters)

Standard parameters in Parameter Store are free — no per-parameter charge, no API call charges (within standard throughput). For applications with dozens or hundreds of configuration values, this saves significant cost compared to Secrets Manager ($0.40/secret/month).

Three Parameter Types

SecureString parameters are encrypted at rest with KMS and decrypted only when retrieved by authorized IAM principals. They provide the same encryption security as Secrets Manager — the difference is no built-in rotation.

Use Parameter Store For

• Application configuration (URLs, ports, timeouts, feature flags)
• Environment-specific settings
• Non-rotating secrets (API keys that change rarely)
• Large numbers of parameters (cost-sensitive)
• Hierarchical configuration that maps to app structure

Using Both Together

The best practice for most applications is to use both services for their strengths:

Secrets Manager:
  - Database credentials (with rotation)
  - Third-party API keys (with rotation)
  - OAuth secrets

Parameter Store:
  - Application configuration
  - Feature flags
  - Environment-specific URLs and settings
  - Non-sensitive parameters

CloudFormation example using both:

Resources:
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      Environment:
        Variables:
          # Configuration from Parameter Store
          DB_HOST: '{{resolve:ssm:/myapp/prod/database/host}}'
          DB_PORT: '{{resolve:ssm:/myapp/prod/database/port}}'
          # Secrets from Secrets Manager
          DB_PASSWORD: '{{resolve:secretsmanager:myapp/prod/db-password:SecretString:password}}'

Integration Patterns

Lambda

Both services provide Lambda extensions that cache values locally, reducing API calls and latency:

Lambda invocation → Check local cache → Cache hit → Return value (0ms)
                                      → Cache miss → API call → Cache value → Return (50-100ms)

Lambda extension cache TTL: 300 seconds by default. Adjust based on how frequently your configuration changes.

Environment variables vs runtime retrieval:

• Environment variables — Set at deployment time. Simple but requires redeployment to change values.
• Runtime retrieval — Read from Parameter Store or Secrets Manager during execution. Changes take effect without redeployment (after cache TTL expires).

Recommendation: Use environment variables for values that change only with deployments (database host, table names). Use runtime retrieval for values that change independently (feature flags, rate limits).

ECS/Fargate

ECS natively injects secrets and parameters into container environment variables:

{
  "containerDefinitions": [
    {
      "secrets": [
        {
          "name": "DB_PASSWORD",
          "valueFrom": "arn:aws:secretsmanager:us-east-1:123456789:secret:prod/db-password"
        },
        {
          "name": "API_KEY",
          "valueFrom": "arn:aws:ssm:us-east-1:123456789:parameter/myapp/prod/api-key"
        }
      ]
    }
  ]
}

ECS retrieves the values at container startup and injects them as environment variables. The container never sees the Secrets Manager or Parameter Store API — the integration is transparent.

EC2

Use the SSM Agent (pre-installed on Amazon Linux) to retrieve parameters at boot:

DB_HOST=$(aws ssm get-parameter --name /myapp/prod/database/host --query Parameter.Value --output text)
DB_PASS=$(aws secretsmanager get-secret-value --secret-id myapp/prod/db-password --query SecretString --output text | jq -r .password)

For EC2 instances, prefer IAM instance profiles for authentication — never hardcode credentials in user data scripts.

Security Best Practices

Encryption

• Secrets Manager: All secrets are encrypted with KMS (mandatory). Use a customer-managed key for audit trail and independent access control.
• Parameter Store: Use SecureString type for any sensitive value. Specify a customer-managed KMS key for production secrets.

Access Control

Apply least-privilege IAM policies:

{
  "Effect": "Allow",
  "Action": ["ssm:GetParameter", "ssm:GetParametersByPath"],
  "Resource": "arn:aws:ssm:*:*:parameter/myapp/production/*"
}

This grants access to production parameters only — not staging, development, or other applications. Scope access by path prefix, not by wildcard.

Audit Logging

Both services log API calls to CloudTrail. Monitor for:

• Unauthorized access attempts (failed GetSecretValue or GetParameter calls)
• Unusual access patterns (new IAM principals accessing secrets)
• Bulk parameter retrieval (potential data exfiltration)

Set CloudWatch alarms for failed secret access attempts.

Rotation Policy

Common Mistakes

Mistake 1: Secrets in Environment Variables

Storing secrets directly in CloudFormation template parameters, ECS task definition environment variables, or Lambda environment variables as plaintext. These values are visible in the console, CLI, and API responses. Always reference Secrets Manager or Parameter Store SecureString — never embed plaintext secrets.

Mistake 2: Using Secrets Manager for All Configuration

Storing 200 application configuration values in Secrets Manager at $0.40/secret/month costs $80/month. Parameter Store standard is free. Use Secrets Manager for secrets that need rotation or cross-account access. Use Parameter Store for everything else.

Mistake 3: No Rotation

Credentials that never rotate are ticking time bombs. A compromised credential remains valid indefinitely. Enable rotation on all database credentials and rotate API keys on a schedule.

Mistake 4: Overly Broad Access

Granting secretsmanager:GetSecretValue on * gives access to every secret in the account. Scope access to specific secret ARNs or name prefixes. Use Parameter Store path-based policies for hierarchical access control.

Getting Started

Secrets and configuration management is a foundational security practice. Secrets Manager provides the rotation and cross-account capabilities that production secrets require. Parameter Store provides the hierarchical organization and cost-effectiveness that application configuration needs. Use both for their strengths.

For secrets management architecture, security hardening, and DevOps pipeline integration, talk to our team.

Contact us to secure your application secrets →