Secrets Manager vs Parameter Store: Where Secrets Belong

Parameter Store SecureString for most secrets, Secrets Manager for the few that need rotation, cross-account access, or multi-Region replication. That is the split we apply on the AWS estates we review, from single-account products to multi-account organizations. Parameter Store's standard tier stores KMS-encrypted values with no storage charge; Secrets Manager bills per secret and per call. That monthly line is worth paying only when you use the lifecycle features it funds.

What does the Parameter Store standard tier give you for free?

The standard tier stores up to 10,000 parameters per Region with no storage charge, including SecureString values encrypted with a KMS key you control. Values are capped at 4 KB, read throughput is deliberately modest by default, and there is no native rotation: when a credential must change, something you build has to change it.

Reads at standard throughput carry no Parameter Store charge, though decrypting a SecureString goes through KMS, which has its own per-request cost shape. The AWS managed key works at first, but a customer managed key gives you key policy control and cleaner audit trails. Enable higher throughput and billing switches to a per-interaction shape for that Region. The Parameter Store documentation details the limits and the Systems Manager pricing page keeps the current figures; we quote shapes here because figures move.

What do you actually pay for with Secrets Manager?

Secrets Manager bills a flat monthly amount per stored secret plus a metered amount per batch of API calls; the official pricing page has the current numbers. In exchange you get native rotation, resource policies for cross-account access, multi-Region replication, and a 64 KB size ceiling per secret.

Rotation is the feature that usually decides the question: managed rotation handles RDS, Redshift, and DocumentDB credentials without custom code, and a Lambda function you own can rotate anything else on a schedule. Version staging labels keep consumers working mid-rotation. A resource policy lets another account read a secret directly, with no credential copies and no cross-account IAM gymnastics. Replication keeps a secret synchronized into other Regions for failover. Both cost components grow with usage, which is exactly why the caching pattern below matters.

When does the Parameter Store advanced tier make sense?

The advanced tier raises the value limit to 8 KB, lifts the per-Region parameter ceiling, and adds parameter policies such as expiration dates and no-change notifications. Its cost shape, a monthly charge per advanced parameter plus per-interaction API billing, places it between the free standard tier and Secrets Manager.

Advanced parameters can also be shared across accounts through AWS RAM, which closes part of the gap. What never arrives is rotation: an expiration policy tells you a value is stale, it does not change the value. Teams that accumulate advanced parameters to imitate Secrets Manager tend to end up with a comparable bill and fewer features. We reserve the advanced tier for large configuration payloads and treat it as a configuration tool, not a secret lifecycle tool.

How do you avoid an API call on every Lambda invocation?

Cache inside the execution environment. The AWS Parameters and Secrets Lambda Extension runs as a layer, serves both services over a local HTTP endpoint on port 2773, and caches responses with a configurable TTL. After the first read, a secret costs your function local latency and adds nothing to the API bill.

import os, json, urllib.request

# The extension listens inside the sandbox; the token header is mandatory
def get_secret(name):
    url = "http://localhost:2773/secretsmanager/get?secretId=" + name
    req = urllib.request.Request(url, headers={
        "X-Aws-Parameters-Secrets-Token": os.environ["AWS_SESSION_TOKEN"]
    })
    with urllib.request.urlopen(req) as r:
        return json.loads(r.read())["SecretString"]

The same endpoint serves Parameter Store under /systemsmanager/parameters/get. Tune SECRETS_MANAGER_TTL and SSM_PARAMETER_STORE_TTL to your rotation window, and treat one authentication failure as a signal to refresh, since a rotated secret reaches the cache only at TTL expiry. The extension documentation covers setup; our article on Lambda best practices covers the surrounding execution-environment patterns.

Our default: Parameter Store first, promote secrets that earn it

We store configuration and static secrets as SecureString parameters in the standard tier, and move a secret to Secrets Manager the day it needs rotation, cross-account access, or replication. Only that secret moves, not the whole estate. The bill then tracks real lifecycle requirements instead of habit.

Parameter hierarchies such as /app/prod/db give you path-based reads and per-prefix IAM, which Secrets Manager only approximates with naming conventions. The split keeps policies legible: ssm:GetParameter on a prefix for configuration, secretsmanager:GetSecretValue on specific ARNs for the sensitive handful. When we review account structures during an AWS architecture engagement, misplaced secrets show up in both directions: monthly fees paid for static values, and hand-rotated database credentials that managed rotation would handle better.

Side by side: cost, rotation, limits, sharing

The table compresses the decision. Read the last row first: most estates need both services at once, for different secrets, and nothing prevents the mix within one account or one application. Prices move and quotas get revised, so we compare cost shapes and behaviors rather than figures.

Decision checklist

Run each secret, not each application, through these questions:

• Needs automatic rotation? Secrets Manager.
• Read from another account? Secrets Manager, or advanced tier via AWS RAM if rotation is not required.
• Must exist in several Regions, synchronized? Secrets Manager replication.
• Static configuration or a rarely changed secret under 4 KB? Parameter Store SecureString, standard tier.
• Read by Lambda on every invocation? Add the extension and a TTL before changing services.