Best Practices for AWS Lambda Security
Instruction: What are the best practices for securing AWS Lambda functions?
Context: Assess function hardening across execution and invocation permissions, input authorization, managed secrets, dependency hygiene, network access and verification.
Updated
Official answer
Harden the function at several independent boundaries:
- Limit the execution role to the actions and resource scopes required by the handler. Separately restrict service/caller invocation permission and validate application-level authorization.
- Validate event schemas, sizes and identifiers before using them. Parameterize database queries, constrain outbound destinations and avoid executing untrusted input as code or commands.
- Store credentials in a managed secret store such as Secrets Manager. Use non-secret environment settings or secret identifiers, and test rotation. At-rest encryption does not prevent plaintext access inside authorized code.
- Maintain supported runtimes and dependencies. Scan and test immutable build artifacts, and restrict who may change code, layers, configuration and permissions.
- Configure VPC connectivity only where required for private resources or network policy. Scope routes and security groups; VPC attachment does not authenticate a caller.
- Redact logs, protect failure destinations, and configure the required audit events and alarms. Test denied access, malformed input, dependency failure and an attempted cross-tenant request.
For a document processor, verify that an authenticated caller cannot submit an object identifier belonging to another tenant, even if the execution role can technically read both objects. Infrastructure permissions and business authorization address different risks.
IAM security practices, secret guidance, invocation policies