Published on

Lambda secrets: env vars vs runtime fetch

Authors
  • avatar
    Name
    Edwin Popham
    Twitter
FacebookShare

Working in serverless feels a bit like coaching the Warriors: everyone has hot takes about what "best practice" really is, and half the time they contradict each other.

Lambda secrets management

Option 1: Bake secrets into env vars at deploy

  • How it works: CloudFormation/CDK resolves your {{resolve:ssm:...}} at deploy and writes the value into Environment.Variables. Your TypeScript just reads process.env.DB_PASSWORD and gets on with life.
  • Security upside: Lambda encrypts env vars at rest with KMS, and you can plug in your own CMK if you're feeling fancy.
  • Security downside: Anyone with permission to read Lambda config and decrypt with that KMS key can see the secret. That might be half your platform team.
  • Performance: No network calls, no caching logic. The secret is already in memory when the container boots.
  • Operational downside: Rotating secrets means updating function configuration and letting AWS spin up new containers. Forget to redeploy and you're hitting prod with a stale password.

Option 2: Fetch from Parameter Store / Secrets Manager at runtime

  • How it works: On the first invocation in a container, your Lambda calls Parameter Store or Secrets Manager, grabs the secret, and stashes it in a module-level variable. Warm invocations just reuse that value.
  • Security upside: Secrets stay in a dedicated store with audit logs, fine-grained IAM and proper rotation workflows. Your Lambda role gets permission to one parameter or secret, not the whole zoo.
  • Security nuance: The secret still ends up in memory inside the Lambda container, but fewer people and systems can read it out-of-band.
  • Performance cost: The first call in a cold container pays a network round-trip to AWS. After that, cached reads are basically free.
  • Operational upside: You can rotate secrets in the store and either rely on TTL-based caching or force new containers, without touching the function code.

Note: It's not that Lambda environment variables are "insecure". Used with KMS and least-privilege IAM, they're fine for low-to-medium risk secrets like feature flags or internal API tokens. High-value credentials (payment gateways, production databases) deserve a proper secrets service.

FacebookShare