Secret rotation and caching in serverless: the TTL trap

When a function caches a secret, a rotation does not take effect until the cache expires. In the AWS parameters and secrets Lambda extension the default cache time is 300 seconds. Align the cache lifetime with your rotation plan, and design rotation so the old and new values overlap briefly.

Why caching exists

Fetching a secret on every invocation adds latency and cost. AWS describes two approaches for Lambda: the parameters and secrets extension, and the Powertools parameters utility. Both keep a local cache. A request checks the cache first and returns the value if it exists and has not expired. Otherwise it fetches from Secrets Manager, caches it, and returns it.

The extension caches secrets for 300 seconds by default and can hold up to 1,000 of them. You can change both settings with environment variables, including the time to live for Secrets Manager values (maximum 300 seconds) and the cache size. Setting either to 0 disables caching.

The trap

You rotate a database password at noon. Some running execution environments hold the old value in their cache until it expires, so for up to five minutes by default some invocations use the old password. If the database already rejected it, those requests fail. If you rotated because the old value leaked, those environments are still using it until the cache clears.

Environment reuse adds to this. Execution environments live across many invocations, so a value read during initialization into a global variable can persist for the life of the environment, which may be hours. Only values you re-fetch within the TTL are refreshed.

AWS's two suggested fixes

1. Lower the cache lifetime. Setting the Secrets Manager TTL variable to 60 means the function never uses a value more than a minute old, at the price of more calls.
2. Request a specific version stage in the call, using the current or previous staging label, to get the version you want.

Design rotation for overlap

Because of caches and connection pools, a hard cutover is fragile. A safer pattern:

1. Create the new credential while the old one still works.
2. Switch the secret's current value to the new credential.
3. Wait at least the maximum cache lifetime, plus time for pooled connections to recycle.
4. Disable the old credential.
5. Watch error rates during the window.

In an incident rotation the logic differs: you want the old credential dead quickly. Shorten the TTL in advance for high risk secrets so the window is small, and accept the extra calls.

Do not forget connections

A function that opened a database connection with the old password may keep that session open. Whether it matters depends on the database. Check your own system's behavior rather than assuming.

A short runbook

• Record each secret's TTL next to its rotation schedule.
• Keep the TTL well under the rotation grace period.
• For a leaked secret, rotate, then disable the old one after the maximum TTL, and review logs for use of the old one.

Quick check

Sources

• Use Secrets Manager secrets in Lambda functions, AWS documentation
• Understanding the Lambda execution environment lifecycle, AWS documentation

Last reviewed: 19 October 2026.