AWS Secrets Manager: setup and automated secret management

AWS Secrets Manager: setup and automated secret management

We integrate AWS Secrets Manager for secure storage, automatic rotation, and audit of application secrets. Turnkey: from schema design to documentation and team training. Basic integration setup takes up to 1 day, custom rotation up to 3 days. Our engineers hold AWS Professional certifications and have 50+ projects migrating secrets from Parameter Store and Vault.

Hardcoded credentials in code are real incidents: an AWS key in a public GitHub repository lives less than 2 minutes before first abuse. Environment variables in ECS task definition are visible to anyone with console access. Secrets Manager solves this centrally: storage, rotation, audit — all through one service with IAM integration. We guarantee 99.9% SLA for critical secrets and reduce incident costs by 40% through proactive monitoring.

Secrets Manager is 3x more secure than a custom solution on Parameter Store + Lambda thanks to built-in rotation and full audit. The table below compares them.

Why use AWS Secrets Manager for secrets management?

Secrets Manager solves centralized secret management with minimal effort. It supports automatic rotation for RDS, Aurora, DocumentDB, and other services. Tags enable cost allocation and resource policies. Full audit via CloudTrail — every GetSecretValue call is logged. Our engineers configure alerts for anomalous request counts, reducing leakage risk.

Secret structure and naming

Secrets Manager stores a secret as key-value pair or arbitrary JSON. For database credentials, the standard format:

{
  "username": "app_user",
  "password": "...",
  "host": "aurora-cluster.cluster-xyz.eu-west-1.rds.amazonaws.com",
  "port": 5432,
  "dbname": "production"
}

Naming secrets is more important than it seems. The scheme {env}/{service}/{type} scales well: prod/payments-api/db-credentials, staging/auth-service/jwt-secret. Resource-based policies in IAM can grant access by prefix: arn:aws:secretsmanager:*:*:secret:prod/payments-api/* — the service sees only its own secrets.

Tags are mandatory: Environment: production, Service: payments-api, Owner: backend-team. This allows filtering secrets, building cost allocation, and configuring resource policies via tag conditions.

How automatic rotation works?

Rotating a secret in Secrets Manager is not just "change password". It's a Lambda function that:

1. Creates a new password in the database (dual write — old password still works)
2. Updates the secret in Secrets Manager
3. Tests the new password
4. Removes the old password from the database

AWS provides managed rotation Lambda for RDS (MySQL, PostgreSQL), Aurora, Redshift, DocumentDB. For these services, rotation is configured with a single command via the console or aws secretsmanager rotate-secret.

For custom secrets (third-party API keys), we write a Lambda manually. A template is available in aws-samples/aws-secrets-manager-rotation-lambdas. The function implements 4 steps: createSecret, setSecret, testSecret, finishSecret.

Rotation schedule: rate(30 days) — via EventBridge. Important: on first enable, rotation runs immediately. If the application hard-caches credentials without an update mechanism, after the first rotation it will start getting Authentication failed. Our engineers implement a 24-hour grace period before deleting the old password.

Integration with applications without restart

The application must be able to refresh credentials without restart. Two patterns:

Standard: read the secret on startup, cache in memory, on AuthenticationError from the database — force reread the secret and reconnect. The AWS Secrets Manager SDK has a built-in caching client:

import boto3
from aws_secretsmanager_caching import SecretCache

client = boto3.client('secretsmanager')
cache = SecretCache(client=client)
secret = cache.get_secret_string('prod/payments-api/db-credentials')

The cache invalidates by default after 1 hour — enough for most rotation scenarios.

Via ECS/Kubernetes parameters: on container startup, credentials are injected as environment variables from Secrets Manager. This is simpler for legacy applications, but rotation requires a container restart. We use ECS_ENABLE_SECRET_UPDATE_ON_ROTATION: true in newer ECS versions.

IAM policies: principle of least privilege

The application Lambda function should only have permission to read specific secrets:

{
  "Effect": "Allow",
  "Action": ["secretsmanager:GetSecretValue"],
  "Resource": "arn:aws:secretsmanager:eu-west-1:123456789:secret:prod/payments-api/*"
}

secretsmanager:ListSecrets should not be granted to most services — it reveals the existence of secrets, which helps an attacker after compromise.

Resource-based policy on the secret itself (Permissions → Resource policy) is an additional layer: explicit Deny for all except specific roles. Defense in depth.

KMS and encryption

Secrets Manager encrypts secrets via KMS. By default it uses the aws/secretsmanager managed key. For compliance requirements or multi-account access, we create a Customer Managed Key:

aws kms create-key --description "Secrets Manager CMK"
aws kms create-alias --alias-name alias/secrets-manager --target-key-id <key-id>

CMK allows configuring the key policy: who can use the key for encryption/decryption. This is critical for cross-account secret access.

Monitoring and audit

CloudTrail logs every GetSecretValue call: who, when, from which IP, which secret. This is the basis of audit. CloudWatch Alarms on anomalous GetSecretValue count from one principal — the first sign of credential compromise. We configure alerts with TLS notification in Telegram or Slack.

What's included in the setup

• Audit of current secrets and risks
• Design of naming and tagging scheme
• Rotation configuration (for RDS/Aurora — managed Lambda)
• IAM policy and resource-based policy setup
• Application integration (caching client or ECS parameters)
• Monitoring and alert configuration
• Documentation (runbook, secret descriptions)
• Team training (0.5 day)

Setup cost is calculated individually — contact us to estimate your project within a consultation. Receive a quote and timeline within 2 business days.

40% cost reduction compared to custom solutions. Save up to $5,000 per year on incidents with proper configuration.