AWS Lamda Security
Master AWS Lambda security: implement least-privilege IAM, isolate VPC networks, secure secrets, and protect serverless code across the shared responsibility model.
Series: Cloud Security (4 articles)
- …
- 4AWS Lamda Security This article
AWS Lambda abstracts away underlying servers, operating system patching, and hardware management. However, serverless architectures do not eliminate security responsibilities; they redefine them. Under the AWS Shared Responsibility Model, AWS manages the security of the cloud (physical facilities, virtualization layer, runtime OS, and hardware isolation via Firecracker microVMs), while the user remains accountable for security in the cloud—specifically application code, configuration, data protection, and access permissions.
1. Identity & Access Management (IAM): Principle of Least Privilege
IAM is the primary security boundary for serverless computing. Because Lambda functions are ephemeral and horizontally scalable, over-privileged roles pose significant lateral movement risks.
- One Dedicated Role Per Function: Avoid sharing catch-all IAM execution roles across multiple functions. Grant each Lambda function its own role scoped strictly to the actions it performs.
- Resource-Level Scoping: Restrict wildcard resource definitions (
Resource: "*"). Instead of allowing access to all S3 buckets or DynamoDB tables, specify the exact Amazon Resource Names (ARNs):
1
2
3
4
5
6
7
8
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:PutItem"
],
"Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/Orders"
}
- Resource-Based Policies (Function Policies): If external accounts, AWS services (such as S3, SNS, or EventBridge), or public API callers invoke your function, inspect the resource-based policy. Never use wildcards (
*) for cross-account execution without conditional checks (aws:SourceArnoraws:SourceAccount).
2. Secure Configuration and Secrets Management
Hardcoding database credentials, third-party API keys, or tokens in function code is a critical vulnerability.
- Secrets Manager vs. Parameter Store: Retrieve sensitive parameters dynamically at runtime using AWS Secrets Manager (ideal for automated database credential rotation) or AWS Systems Manager Parameter Store (SecureString types using AWS KMS).
- Environment Variable Encryption: Lambda environment variables are encrypted at rest with an AWS Key Management Service (AWS KMS) key by default. For highly sensitive values, use KMS Customer Managed Keys (CMKs) and client-side encryption helpers before deployment.
- Avoid Leaking Secrets in Logs: Ensure application exceptions and debugging statements do not print authorization headers, tokens, or entire event payloads to standard output (which streams directly to Amazon CloudWatch Logs).
3. Network Isolation and VPC Placement
By default, Lambda functions run inside a multi-tenant VPC managed by AWS with direct outbound Internet access. While this configuration works for purely cloud-native public API integration, enterprise environments often require private network controls.
- Private Subnet Placement: Deploy functions inside private subnets of a custom VPC when they need access to private resources (such as Amazon RDS clusters, internal microservices, or on-premises networks).
- AWS PrivateLink (VPC Endpoints): When a function is placed in a private subnet and requires access to AWS services (e.g., S3, DynamoDB, Secrets Manager), use Interface or Gateway VPC Endpoints. This keeps API traffic entirely on the private AWS network backbone without routing through public NAT Gateways.
- Security Groups: Enforce strict egress rules on Lambda security groups. Limit outbound communication exclusively to the necessary target ports and CIDR ranges/security groups.
4. Execution Environment and Ephemeral Storage Risks
Lambda execution environments are reused across multiple invocations of the same container instance to minimize cold starts. This model introduces internal state considerations:
- Ephemeral Storage Hygiene (
/tmp): The/tmpdirectory (configurable up to 10 GB) persists across invocations within the same execution context. Never assume/tmpis wiped clean between sequential invocations. Always sanitize or delete sensitive temporary files upon invocation completion. - In-Memory State: Global variables and client singletons initialized outside the handler persist between warm invocations. Avoid caching per-user sensitive data or authorization tokens in global memory.
- Execution Timeout Limits: Set timeouts defensively. Do not default to the maximum 15-minute timeout; instead, configure realistic limits (e.g., 5 to 30 seconds) to prevent Denial-of-Wallet attacks or runaway hung processes from exhausting your concurrency limits.
5. Application-Layer Security and Supply Chain Integrity
A serverless infrastructure remains susceptible to traditional software-level exploits, including SQL/NoSQL injection, insecure deserialization, and malicious dependency tampering.
- Input Validation & API Gateways: Front Lambda endpoints with Amazon API Gateway and configure request validation models to reject malformed payloads before they trigger compute runtime. Pair API Gateway with AWS WAF (Web Application Firewall) to block common OWASP Top 10 exploits, rate-limit abusive clients, and mitigate bot traffic.
- Code Signing for AWS Lambda: Configure Code Signing to ensure only trusted, cryptographically signed code artifacts and layers from authorized signing profiles can be deployed into your AWS accounts.
- Automated Dependency Auditing: Use tools like Amazon Inspector (for Lambda standard and container image scanning) alongside CI/CD-integrated software composition analysis tools (e.g., Snyk, SonarQube) to catch vulnerable third-party packages before deployment.
6. Observability, Detection, and Incident Response
Visibility is critical for detecting anomalous activity within short-lived compute environments.
| Service | Security Role |
|---|---|
| AWS CloudTrail | Audits control-plane API calls (e.g., UpdateFunctionCode, CreateFunction, DeleteFunction) to detect unauthorized modifications. |
| Amazon GuardDuty | Monitors Lambda invocation activity and network logs for unauthorized behavior, such as malware execution, crypto-mining, or suspicious outbound connections. |
| Amazon CloudWatch & Alarms | Tracks invocation spikes, unhandled exceptions, and high error rates that may indicate brute-force attempts or service degradation. |
| AWS Security Hub | Continuously audits function configurations against the CIS AWS Foundations Benchmark and AWS Foundational Security Best Practices. |
Adopting a defense-in-depth approach—combining strict IAM boundary controls, secure secrets handling, private networking where appropriate, and continuous automated scanning—ensures serverless architectures remain both agile and resilient against modern threats.
Series: Cloud Security (4 articles)
- …
- 4AWS Lamda Security This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article