2.3 Secrets Manager vs Parameter Store

The Core Trade-off

The exam repeatedly asks you to choose between AWS Secrets Manager and SSM Parameter Store. The deciding factor is almost always rotation vs cost.

• Need automatic rotation (especially database credentials) or cross-region replication → Secrets Manager.
• Just need to store config or a secret cheaply → Parameter Store (use a SecureString for sensitive values).

Watch the wording: phrases like "rotate every 30 days with no rotation code" or "replicate the secret to a DR Region" point to Secrets Manager; phrases like "lowest cost," "hundreds of config values," or "no rotation needed" point to Parameter Store.

Feature and Cost Comparison

Parameter Store Tiers

• Standard — up to 10,000 parameters per account/Region, 4 KB values, no additional charge, no parameter policies.
• Advanced — up to 100,000 parameters, 8 KB values, $0.05 per parameter per month, and supports parameter policies (expiration, expiration notification, no-change notification).
• Parameter types — String, StringList, and SecureString (KMS-encrypted). A SecureString gives you encrypted secret storage at standard-tier cost with no rotation.

Parameter Store can also reference Secrets Manager secrets by path (/aws/reference/secretsmanager/<name>), letting one SDK call (GetParameter) read either store — a handy integration point the exam occasionally mentions.

Rotation Versions in Secrets Manager

Secrets Manager uses staging labels so rotation is seamless. AWSCURRENT is the live secret, AWSPENDING is the new value being created and tested mid-rotation, and AWSPREVIOUS is the prior value (useful for rollback). A client that calls GetSecretValue without specifying a label always receives AWSCURRENT. The four-step rotation Lambda runs createSecret → setSecret → testSecret → finishSecret, then moves the AWSCURRENT label onto the new version.

Retrieving Secrets in Lambda

Do not fetch the secret on every invocation inside the handler body — that adds latency and per-call API cost.

1. Retrieve and cache the secret outside the handler (in the init phase / a module-level variable) so warm invocations reuse it.
2. Use the AWS Parameters and Secrets Lambda Extension, which runs a local in-memory cache and serves values over localhost:2773, cutting repeated GetSecretValue / GetParameter calls.
3. Grant the execution role only secretsmanager:GetSecretValue (or ssm:GetParameter) plus kms:Decrypt on the encrypting key — never paste secrets into plaintext environment variables.

Why Plaintext Environment Variables Fail the Exam

Lambda environment variables are encrypted at rest, but their values are visible in the console, in GetFunctionConfiguration API responses, and in CloudFormation/CDK templates and deployment logs. Any answer that says "store the database password in an environment variable" is wrong for a secret. Environment variables are appropriate only for non-sensitive configuration (a feature flag, a Region, a non-secret endpoint). For secrets, reference them at runtime from Secrets Manager or a Parameter Store SecureString.

Encryption and Permissions for Both Stores

Both services encrypt with KMS, so the retrieving principal needs two permissions: the read action (secretsmanager:GetSecretValue or ssm:GetParameter/GetParameters) and kms:Decrypt on the key that encrypted the value. Forgetting kms:Decrypt is a classic cause of an AccessDeniedException that mentions the KMS key rather than the secret — a detail the exam likes to bury in the answer options.

Decision Cheat Sheet

Use this quick mapping when a scenario appears:

• "Rotate RDS/Aurora/Redshift/DocumentDB credentials automatically" → Secrets Manager (managed rotation).
• "Replicate the secret to another Region for disaster recovery" → Secrets Manager (cross-region replication).
• "Store thousands of config values at the lowest cost" → Parameter Store standard.
• "Encrypt a sensitive value cheaply, no rotation" → Parameter Store SecureString.
• "Need value larger than 8 KB" → Secrets Manager (up to 64 KB) since Parameter Store caps at 4 KB standard / 8 KB advanced.
• "Reference a parameter that expires or notifies on no-change" → Parameter Store advanced (parameter policies).

Matching the one distinguishing requirement in the stem to the correct store is how these questions are scored — there is rarely a scenario where both are equally correct.

Versioning and Safe Reads

Secrets Manager keeps every secret value as an immutable version identified by a VersionId and labeled with staging labels; you can pin a read to AWSPREVIOUS to roll back instantly after a bad rotation. Parameter Store keeps incrementing numeric versions for each parameter and lets you read a specific version by appending :n to the name (for example /app/db/password:3), or read the latest by omitting it. For batch reads, GetParameters (plural) and GetParametersByPath fetch many values in one call, which lowers request count and latency — useful when an application loads a whole configuration tree at startup.

Pairing these batch reads with the Lambda extension's local cache gives you both fewer API calls and lower cost.