Environment variables are fine for non-sensitive configuration such as a log level or a bucket name. For database credentials, API keys and tokens, AWS recommends Secrets Manager instead. The variables are encrypted at rest, but they are visible to anyone with configuration read access and they do not rotate on their own.
What Lambda does for you
Lambda stores environment variables encrypted at rest. You can configure a different encryption key, encrypt values on the client side, or set them from a CloudFormation template that pulls from Secrets Manager. The total size of all variables cannot exceed 4 KB, which is a hint that this is meant for small settings, not payloads.
When you publish a function version, the variables are locked for that version along with the other version-specific configuration. That is useful for consistency, and it means a changed secret needs a new version or a configuration update.
Where they fall short
The AWS documentation carries a note recommending Secrets Manager over environment variables for database credentials and other sensitive information like API keys or authorization tokens. Reasons that follow from how the feature works:
- Anyone allowed to read the function configuration can read the values.
- The runtime exposes them to every process in the execution environment, including extensions. Permissions, credentials and variables are shared between the function and its extensions.
- Rotation means a configuration change, not a background process.
- Secret values often end up in logs when someone prints the environment while debugging.
The alternative and its trade-off
With Secrets Manager, the function fetches the secret at runtime. AWS describes two routes: the AWS parameters and secrets Lambda extension, and the Powertools parameters utility. Both keep a local cache so the function does not call Secrets Manager on every invocation. The extension defaults to a five minute cache for secrets.
The cost is an extra permission on the execution role (secretsmanager:GetSecretValue scoped to the specific secret), a little latency on a cold fetch, and the cache behaviour you now have to understand. If you rotate often, lower the cache lifetime so the function does not hold an old value.
A simple decision rule
- Is the value harmless if it appears in a log? Use an environment variable.
- Would leaking it let someone reach data or spend money? Use a secrets service.
- Does it need to rotate? Use a secrets service with a short cache.
- Is the credential for another AWS service? Skip stored credentials and use the execution role instead.
The last point is the biggest win. Many functions carry an access key for an AWS service when the role already provides temporary credentials.
Quick check
Are Lambda environment variables encrypted?
Yes, at rest. Encryption at rest does not hide them from someone with permission to read the function configuration, which is why AWS still recommends a secrets service for credentials.
Does the secrets extension call Secrets Manager every time?
No. It caches. By default the cache lifetime is 300 seconds, and you can lower it with an environment variable.
For the code you ship alongside those secrets, Safeguard's dependency scanning and the free scan at gold.safeguard.sh/scan can show which packages in a function bundle carry known vulnerabilities.
Sources
- Working with Lambda environment variables, AWS documentation
- Use Secrets Manager secrets in Lambda functions, AWS documentation
- Understanding the Lambda execution environment lifecycle, AWS documentation
Last reviewed: 19 October 2026.
