Managing Secrets in an AWS Serverless Application
Where API keys and database credentials should live in a serverless AWS app. Secrets Manager vs SSM Parameter Store, fetching secrets at runtime from Lambda, and the habits (least-privilege IAM, KMS encryption, rotation, never logging secrets) that keep them safe.
Serverless makes secret management harder in a specific way. Functions are ephemeral and scale on demand, so there's no long-lived host to bake credentials into, and stuffing them in Lambda environment variables puts them in plaintext in the function config. This piece lays out the safer options on AWS and the habits that go with them.
The main recommendation is AWS Secrets Manager, with SSM Parameter Store as the lighter-weight alternative. Both are backed by KMS for encryption at rest and gated by least-privilege IAM roles. The Lambda pulls the secret at runtime with the SDK (secretsManager.getSecretValue()) rather than holding it in config. Access gets watched through CloudTrail, with GuardDuty for anomaly detection.
Key takeaways
- Don't put real secrets in Lambda env vars: visible in the function config; pull from Secrets Manager or Parameter Store at runtime
- Scope the IAM policy to specific secret ARNs, encrypt with KMS, automate rotation so a leaked credential has a short shelf life
- Never log a secret or put one in an error message; audit access with CloudTrail; logging discipline is part of the threat model
Who this is for
Serverless developers on AWS Lambda who have credentials to manage and want a concrete, current picture of the options and trade-offs. It assumes you're comfortable with Lambda and IAM basics. The guidance is at the service and SDK level. There's no Serverless Framework config in the original.
The full write-up, with the runtime-fetch Lambda example and all seven practices, is on DEV.to.