Migrating credentials into AWS Secrets Manager is a common first step teams take toward better secrets hygiene — and it's also where a lot of teams stop, treating "stored in Secrets Manager" as equivalent to "properly managed." Storage without rotation just moves a static credential from an .env file into a managed service; it's more secure in transit and access-controlled, but it's still the same long-lived secret sitting there indefinitely unless something actively rotates it.
Why Rotation Doesn't Happen by Default
Secrets Manager supports automatic rotation, but it doesn't rotate anything out of the box — rotation requires a Lambda function that knows how to talk to the specific credential's owning system (a database, a third-party API, an internal service) and execute the four-step rotation lifecycle Secrets Manager expects: create a new secret version, set it pending, test it, and finalize it as current. Teams that enable Secrets Manager but skip writing rotation Lambdas end up with well-organized static secrets — better than scattered plaintext, but not actually rotating.
The Rotation Lambda Pattern for RDS/Aurora
For database credentials, AWS provides rotation Lambda templates as a starting point, but production use almost always needs customization for connection pooling behavior and application-side credential refresh:
def lambda_handler(event, context):
step = event["Step"]
secret_arn = event["SecretId"]
token = event["ClientRequestToken"]
if step == "createSecret":
create_pending_secret(secret_arn, token)
elif step == "setSecret":
set_secret_in_database(secret_arn, token)
elif step == "testSecret":
test_new_credentials(secret_arn, token)
elif step == "finishSecret":
finalize_secret_version(secret_arn, token)
The part that trips teams up in practice isn't the Lambda logic itself — it's making sure application connection pools pick up the rotated credential without requiring a full restart. For RDS with connections managed through RDS Proxy, this is largely handled for you since the proxy manages the underlying connection and can transparently pick up the new secret. Without a proxy in front, applications need to either re-fetch the secret on a TTL or handle a connection-failure-triggered secret refresh, or rotation creates a brief window of failed connections at cutover.
The Harder Case: Third-Party API Keys
Database rotation has well-established tooling because the "test" step is straightforward — attempt a connection. Third-party API key rotation is more varied because it depends entirely on what the third-party's own API supports for credential rotation. Some providers offer a native "generate new key, keep old key valid for N days" pattern that maps cleanly onto Secrets Manager's four-step lifecycle. Others only support a single active key with no overlap window, which means rotation Lambdas for these providers need a brief coordinated cutover rather than a graceful overlap — and that constraint needs to be documented per-integration since it changes the operational risk profile of rotating that specific secret.
What "Rotated" Should Mean for an Audit
For SOC 2 evidence purposes, the artifact that matters is a rotation history showing each secret's actual rotation events over time (Secrets Manager tracks this natively via DescribeSecret), cross-referenced against your documented rotation policy — proving secrets are rotating on the interval you claim, not just that rotation is theoretically enabled.
Where This Fits Relative to Workload Identity Federation
Rotation is the right answer for credentials that genuinely can't be eliminated — a managed database password, a required third-party API key. For credentials that can be eliminated entirely (CI/CD pipelines authenticating to AWS, service-to-service auth within your own infrastructure), workload identity federation removes the standing secret altogether rather than just rotating it faster. The two approaches aren't competing — rotation handles what federation can't reach, and federation reduces how much needs rotating in the first place.
This rotation pattern is one piece of our AWS cloud infrastructure capability, alongside the broader approach covered in secrets management in AWS production environments.
Talk to us about your credential elimination pilot: 907-841-8407 or contact@rutagon.com.
Talk to us about your credential elimination pilot →
Frequently Asked Questions
Does enabling Secrets Manager automatically rotate credentials?
No — Secrets Manager provides the rotation framework and scheduling, but nothing rotates until a rotation Lambda specific to that credential type is deployed and attached to the secret.
How do applications avoid downtime when a database credential rotates?
Using RDS Proxy in front of the database is the most reliable approach, since it manages the underlying connections and can transparently switch to the new credential; without a proxy, the application needs its own logic to refresh credentials rather than caching them indefinitely.
Can every third-party API key be rotated this way?
It depends on whether the provider supports issuing a new key with an overlap window before invalidating the old one. Providers without an overlap window require a coordinated cutover rather than a graceful rotation, which changes the operational risk.
How often should credentials actually be rotated?
This depends on your compliance framework and risk tolerance — 90 days is a common baseline for credentials that can't be eliminated, though shorter intervals are increasingly common for higher-sensitivity secrets.
Is rotation enough on its own for SOC 2 compliance, or do we need workload identity federation too?
Rotation satisfies the control for credentials that must remain static-but-managed; federation is the stronger answer wherever it's technically possible, since it removes the standing credential rather than rotating it on a schedule. Most mature environments use both, depending on the system.