What is AWS Lambda Security?

AWS (Amazon Web Services) Lambda is a serverless compute service that manages infrastructure so clients can run code in response to events without provisioning servers. Its ephemeral nature means that each instance is stateless and disposed of after execution — but what does that mean for organizational security? We’re talking about best practices and how to balance the ephemeral environment with persistent security for AWS Lambda clients.

What is AWS Lambda?

As a serverless function-as-a-service (FaaS), Lambda is designed to execute code in response to events, handling infrastructure on-demand and scaling automatically. AWS Lambda might provide computing power when a user clicks a button, uploads an image, or updates a database. 

That comes with benefits for organizations, such as: 

• Reduced operational overhead with no need to provision, patch, and maintain servers themselves
• Automatic workload adjustment to spiking or unpredictable use patterns
• Faster time to market and improved innovation, as teams can deploy individual pieces of an application quickly and independently
• Improved reliability, with AWS’ high availability and fault tolerance
• Offloaded infrastructure security, as AWS handles security patch and infrastructure management for their servers

Lambda fundamentally shifts the operational model, decoupling compute from infrastructure provisioning, scaling, and patching. That frees teams to focus on code and on managing their application security rather than the security needs of the infrastructure.

So What Is AWS Lambda Security?

Lambda introduces unique security dynamics: each execution environment is isolated in AWS-managed micro-VMs (virtual machines), which are stateless and ephemeral, meaning the function and any associated state are destroyed after execution. 

This model minimizes attack surfaces but also limits forensic capabilities. Therefore, organizations must adopt new security practices, like rigorous code auditing, dependency management, and strict identity and access management (IAM) configurations, as traditional, server-focused controls don’t apply.

Lambda’s event-driven architecture can increase agility and efficiency, but the stateless design and highly transient environment necessitate a new approach. So, while Lambda may enhance security by shifting team attention off infrastructure management, it also introduces new security requirements at the application level.

Lambda Security Challenges — And Security Best Practices to Overcome Them

In the past, deploying code on servers meant that teams could apply controls at the operating system (OS), network, and infrastructure levels. And with persistent servers, security patches were also persistent. However, in Lambda’s serverless model, the consistent infrastructure layer is gone and replaced by short-lived environments that are spun up only when code needs to be executed.

Threats are evolving and the amount of exposure is greater than it’s ever been. Security leaders are continuously being asked by regulators, boards, and their own business to be more secure.

— Joshua Burgin I CPO, Upwind

The threat landscape is evolving and requires new security measures, even in an environment as agile as Lambda’s serverless approach. Let’s break down some of the challenges that emerge in this landscape:

Ephemeral Execution Environments

Lambda’s stateless, ephemeral execution model reduces persistence-based attack surfaces but complicates visibility and monitoring. AWS CloudWatch provides logging, but logs alone can’t capture real-time malicious behavior or anomalies that could occur during short-lived function executions. Without continuous monitoring of these micro-VMs, critical threats can go undetected.

How so? For an e-commerce application using Lambda for transaction processing, undetected threats can compromise customer data before logging tools can capture it. 

Dependency Security

Serverless functions rely heavily on third-party libraries to operate. Lambda doesn’t natively address dependency vulnerabilities, and while tools like Amazon Inspector help identify some issues, they don’t provide ongoing, execution-level monitoring. That’s bad news when vulnerabilities in dependencies only surface during specific executions or under certain data conditions. They can be mitigated with effective cloud vulnerability management.

For instance, imagine a Lambda function that uses third-party libraries for data parsing. That function could expose sensitive data in industries like financial services if vulnerabilities in those libraries aren’t caught in real time.

IAM Complexity and Least Privilege Access

Lambda functions require tightly scoped IAM roles to ensure least-privilege access, but designing roles that balance function needs with strict security isn’t always simple. That’s because AWS IAM provides permissions management, but misconfigurations are common and can lead to overprivileged roles. Further, Lambda’s dynamic nature makes managing permissions at scale difficult, as each function needs its own unique permissions.

Challenges can lead to unacceptable risks: in the healthcare industry, for example, an application using multiple Lambda functions might unintentionally expose patient records if permissions aren’t carefully controlled per function.

Data Security in Transit and At Rest

Lambda supports encrypted environment variables and storage. However, sensitive data handling remains challenging due to statelessness and rapid instantiation. And encrypted data can still be vulnerable if not handled correctly across functions. 

AWS Key Management Service (KMS) assists with encryption, but every function call must properly implement it, increasing the risk of misconfigurations. While not unique to Lambda, this cloud concern can be made more challenging to enforce due to Lambda’s ephemeral nature.

In an IoT context, a Lambda function processing sensor data may unintentionally expose unencrypted payloads if the encryption isn’t consistently enforced across all function calls.

Event Injection Risks

Lambda functions can be triggered by various events (e.g., application programming interface (API) calls, S3 changes), which, if not properly validated, open the door to event injection attacks. Native services like AWS WAF (Application Web Firewall) provide some protection, but event injection isn’t always preventable at the Lambda level, especially with complex event sources, from API Gateway requests to S3 bucket changes. 

Because Lambda functions execute code based on whatever input they receive, there is limited control over how each event source validates its data before it reaches Lambda. And as stateless applications, Lambda functions need to assess the validity of each event on its own, without prior context. That can increase the chances of a single-event infection going undetected.

Here’s an example: for a content platform, Lambda functions that automatically process user uploads from S3 can be vulnerable to malicious payloads if they’re not detected before function execution.

Lambda Security vs Other Cloud Services

When assessing AWS Lambda alongside other services like EC2 instances and ECS/Kubernetes, organizational leaders weigh security needs alongside their computing requirements.

In practice, many organizations opt for a combination of AWS Lambda, EC2 instances, and ECS/Kubernetes containers to address different needs within their infrastructure. Each service offers unique advantages, and together, they enable a flexible, efficient architecture — though this multi-service approach adds complexity to security requirements.

Examining these services individually highlights the distinct benefits and challenges of each and where a mixed approach is often the most effective solution.

	AWS Lambda	EC2 Instances	ECS/Kubernetes Containers
Best Use Cases	Event-driven workloads, automation tasks, lightweight microservices	Long-running, stateful applications, custom databases, legacy apps	Scalable microservices, APIs, containerized apps that need frequent updates
Server Management	Fully managed (serverless). Allows quick deployments. Limits exposure due to ephemeral instances.	User-managed. Ideal for custom environments. Allows full security configuration.	Partially managed. Modular, containerized applications with isolated environments
Statefulness	Stateless, ephemeral, and optimized for lightweight, short-lived tasks	Stateful, persistent storage for long-running applications. Control over OS patching.	Configurable for stateful or stateless. Encrypted persistent volumes are possible.
Scaling	Auto-scaling and ideal for fluctuating workloads	Manual or policy-driven. Predictable for steady workloads.	Customizable scaling
Pricing Model	Pay-per-use, for intermittent workloads	Hourly, for stable, long-term applications	Scales with resource use
Runtime Management	Managed runtime for faster deployments	Full control over OS and configurations	Repeatable environments with containerization for consistency
Integration with AWS Events	Native	Requires setup	Configurable but needs setup for event-based tasks

In addition to features, each service brings distinct security considerations based on their architectures and use cases. Comparing key security differences can help teams make informed choices in order to balance flexibility with security.

Security Concern	AWS Lambda	EC2 Instances	ECS/Kubernetes Containers
Isolation and Multi-Tenancy	Isolated micro-VMs, multi-tenant risks	Full tenant isolation, ideal for sensitive data	Container sharing, needs extra isolation
Vulnerability Management	AWS patches OS, manage dependencies	Full responsibility for OS and app patches	Scan containers and host OS for vulnerabilities
IAM and Access Control	Fine-grained IAM per function	IAM, network controls, flexible	IAM, role-based access control (RBAC), complex, container-specific control
Network Security	Limited, virtual private cloud (VPC) adds complexity	Full VPC control, robust traffic rules	VPC, security groups, Kubernetes network policies
Secrets Management	Use AWS Secrets Manager/KMS	Secrets Manager, custom options available	Base64 secrets by default, needs extra tools
Monitoring and Logging	Limited to CloudWatch, ephemeral logs	Full logging, custom agents allowed	CloudWatch, Prometheus, distributed, complex
Supply Chain Security	High dependency on secure libraries	Full control, custom software vetting	Container image scanning essential

These differences mean that choosing the right service requires balancing each model’s security trade-offs with an organization’s specific needs. Matching your application’s requirements to the right service architecture can enhance security and simplify management — though as organizations scale, they may rely on multiple services and need comprehensive visibility and security tools, like CNAPPs, that eliminate gaps.

Upwind is Rethinking Security

Upwind’s advanced runtime monitoring, powered by eBPF sensors, provides real-time insight into function behavior, detecting anomalies and potential threats as they occur. It also strengthens dependency security, monitoring for unexpected behaviors in third-party libraries so organizations can manage risks associated with Lambda’s high reliance on external code. And with added IAM controls and data security monitoring, applications deployed on Lambda are safer than ever.

To learn more about Upwind’s security for AWS Lambda, schedule a demo.

FAQ

What exactly does AWS Lambda do?

Lambda lets users upload code, and then executes that code in response to events. Set specific triggers (events), and Lambda will handle the rest. Lambda is an event-driven architecture, which means that it is ideal for tasks like data processing or automation in response to user actions, especially those integrated with other AWS services like S3, Dynamo DB, and API Gateway.

Can S3 Trigger a Lambda?

Yes, Amazon S3 can trigger a Lambda function. Set up an S3 bucket to work with Lambda, and configure it to automatically invoke a Lambda function in response to certain events like file uploads, file deletions, “PUT” or “POST” operations, etc.

How does AWS Lambda secure my code?

AWS Lambda secures code with several layers of security including:

• Isolated micro-VMs for each Lambda function, even within the same account
• Automatic encryption for data at rest and in transit
• Use of AWS IAM to restrict functions by setting which users, roles, and services can access them
• Storing sensitive data in environment variables which can be encrypted with AWS KMS
• Treating each Lambda deployment as a code version 
• Logging events and monitoring API calls via CloudWatch

Does AWS Lambda provide encryption?

Yes, Lambda provides encryption for data both at rest and in transit. For data at rest, there’s automatic code encryption, sensitive data in environment variables, and function logs. For data in transit, Lambda uses Transport Layer Security (TLS) to encrypt data sent between Lambda and other AWS services. For external connections, users can implement HTTPS to ensure encrypted connections. 

Does Lambda have a security group?

Lambda can be assigned a security group when configured to run in a VPC. 

By default, Lambda functions run outside a VPC and don’t need a security group. However, if teams need a Lambda function to access resources within a VPC (like RDS databases or private subnets), they can configure it to run inside the VPC. 

Once Lambda is configured to run in a VPC, teams can assign one or more security groups to it. These security groups act as virtual firewalls that control the inbound and outbound traffic for the Lambda function. This setup allows teams to restrict the function’s network access to only specific IP addresses, ports, or AWS resources within the VPC. Users can set both inbound and outbound rules.