Secrets Manager

Securely store, rotate, and access secrets like database credentials and API keys

AWS Secrets Manager securely stores, rotates, and retrieves secrets such as database credentials, API keys, and OAuth tokens. Unlike SSM Parameter Store, it is designed specifically for secrets with built-in automatic rotation using Lambda functions. It is the recommended way to manage dynamic credentials in AWS workloads.

How Secrets Manager Stores and Retrieves Secrets

Secrets are stored as encrypted blobs (using KMS) with a name, a version ID, and optional version labels. The most recent version is tagged AWSCURRENT. During rotation, the new version is staged as AWSPENDING before being promoted to AWSCURRENT.

bash

# Store a secret (JSON key-value)
aws secretsmanager create-secret \
  --name prod/myapp/db \
  --secret-string '{"username":"admin","password":"s3cr3t"}' \
  --kms-key-id alias/my-key

# Retrieve the current value
aws secretsmanager get-secret-value \
  --secret-id prod/myapp/db

# Retrieve in application code (Python)
import boto3, json
client = boto3.client('secretsmanager')
response = client.get_secret_value(SecretId='prod/myapp/db')
secret = json.loads(response['SecretString'])
password = secret['password']

💡

Cache secret values in your application (with a short TTL like 5 minutes) rather than calling Secrets Manager on every request. The AWS SDK for Python, Java, and .NET include a caching client. Without caching, a Lambda function at scale can easily hit the default 10,000 requests/second API limit.

Automatic Rotation: How It Works

Rotation is the most important differentiator between Secrets Manager and Parameter Store. When rotation is enabled, Secrets Manager invokes a Lambda function on a schedule to generate a new secret value and update the backing service.

Rotation step	Lambda function event	What it does
createSecret	Create the new credential in the service	Generates new password, creates new user or updates password in the DB
setSecret	Store the new credential in Secrets Manager	Stores the new value as AWSPENDING version
testSecret	Verify the new credential works	Makes a test connection to the DB with the new password
finishSecret	Mark the new version as current	Labels AWSPENDING as AWSCURRENT, old version becomes AWSPREVIOUS

AWS provides managed rotation Lambda functions for RDS (MySQL, PostgreSQL, Oracle, SQL Server), Redshift, and DocumentDB. For other secrets you write a custom Lambda following the same four-step interface.

⚠️

During rotation there is a brief window where two valid passwords exist (current and pending). Applications must handle database authentication failures gracefully by refreshing the cached secret and retrying. A hard-coded credential cache that never refreshes will break during rotation.

Secrets Manager vs SSM Parameter Store

Feature	Secrets Manager	SSM Parameter Store
Primary use case	Dynamic secrets (DB credentials, API keys)	Config values, feature flags, non-rotating secrets
Automatic rotation	Yes, built-in with Lambda	No (must build custom rotation)
Pricing	$0.40/secret/month + $0.05 per 10,000 API calls	Free for Standard; $0.05/advanced parameter/month
Cross-account access	Yes, via resource-based policy	Limited (requires workarounds)
Versioning	Full version history with labels	Up to 100 versions
Secret replication	Multi-region replication built-in	Not supported natively
Max size	65,536 bytes per secret	4,096 bytes (standard), 8,192 bytes (advanced)

💡

Use Secrets Manager for anything that rotates or requires fine-grained resource-based access policies. Use Parameter Store (SecureString) for static configuration values that you want to keep alongside your non-sensitive app config. The cost difference adds up: at 100 secrets, Secrets Manager costs $40/month vs $0 for SSM Standard tier.

Cross-Account Secret Access

A resource-based policy on a secret can grant access to principals in other AWS accounts. This is a common pattern in multi-account architectures where a shared services account holds all secrets.

bash

# Resource policy on the secret (in account A)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/AppRole"
      },
      "Action": [
        "secretsmanager:GetSecretValue",
        "secretsmanager:DescribeSecret"
      ],
      "Resource": "*"
    }
  ]
}

# The role in account B also needs:
# secretsmanager:GetSecretValue on the secret ARN
# kms:Decrypt on the KMS key used to encrypt the secret

⚠️

Cross-account access to a KMS-encrypted secret requires permissions in BOTH places: the Secrets Manager resource policy AND the KMS key policy. Forgetting the KMS key policy is the most common cause of "Access Denied" errors in cross-account secret sharing.

🎯

Interview Focus Points

1How does Secrets Manager automatic rotation work? Walk through the four Lambda lifecycle events.
2What is the difference between Secrets Manager and SSM Parameter Store? When would you choose one over the other?
3How would you give an application in account B access to a secret stored in account A?
4What happens to running applications during a secret rotation? How do you prevent downtime?
5How do you avoid Secrets Manager API throttling in a high-scale Lambda architecture?
6What KMS permissions are required to access an encrypted secret cross-account?
7How would you audit who has accessed a specific secret over the last 30 days?
8What is the pricing difference between Secrets Manager and Parameter Store at scale?