Introduction

In any application or system, we must have safeguards in place to prevent cross-customer data exposure. Our software is developed using a range of approaches, from human-written code to AI-assisted generation and regardless of how code is produced, the risk of unintended data exposure remains a critical concern.

Developers, Engineering Managers, and Security teams should be aware of potential data exposures and the additional controls which can be put in place as preventive measures.

Once data is exposed or lost, it cannot be undone. Consequently, a data breach may result in serious impacts, including financial loss and reputational harm.

Background

Ensuring data security is a fundamental requirement for applications, both internal and externally exposed. A traditional three-tier architecture is composed of a presentation layer (web tier), an application layer (application tier), and a database layer (database tier).

Any code execution within the application layer more often than not retrieves data from the database layer and returns it to the consumer. The database layer will be the most secure area, with data access tightly controlled and very limited in scope.

Understanding this architecture is important context before exploring how serverless compute and AWS Lambda specifically introduces a unique set of considerations around how application code is executed and how memory is managed between invocations.

Multi-tenant

A multi-tenant application is a software architecture commmonly used in Software as a Service (SaaS) where a single applcation instance services multiple customers while keeping each customers data logically isolated.

Multiple tenants use the same application layer and access to data is controlled using identifiable information obtained during authentication. A unique identifier such as such as a Company ID, Tenant ID or another identifier would be used to aid in only retrieving data in scope for that user.

Even though logically, data is isolated at source, the same application code in the same instance can be executed repeatedly. APIs generally do not restart or spin up independent environments as this would become expense. While using the same execution environment, generally the same same memory address space will be reused to store STATIC and variable data.

Challange

Many SaaS companies host their offerings across Cloud providers such as AWS, utilising serverless compute like as Lambda. There are many articles and documentation that deep dive into Lambda, though at a high level, Lambda is a service which allows code to run without the need to manage servers.

A Lambda execution environment lifecycle can be grouped into 3 phases

The Invoke phase is where the core business logic executes, code queries data from the database, performs actions against it and returns data to the consumer.
Post invoke phase, the Lambda execution environment may or may not shutdown, or remain running waiting for the next invocation.

When a Lambda function is initialised for the first time, its execution environment is fresh; variables are empty and no prior state exists. However, AWS Lambda reuses warm execution environments for subsequent invocations as a performance optimisation. This means that residual data from a previous invocation; such as values held in temporary variables or files written to the ephemeral file system (/tmp); may still be present when the next invocation begins. Without proper hygiene practices in place, this leftover data carries a significant risk of being inadvertently exposed to the next request or customer.

Multi-tenant function?

Lambda runs your code inside execution environments.
Small, secure Firecracker microVMs that handle an invocation and then sit warm, waiting for the next one. That's efficient until you realise those environments get reused across invocations. Your function serves a request from Tenant A, caches some config or credentials in memory, and then the next request comes in from Tenant B, potentially landing in the same environment, with access to whatever Tenant A left behind.

If your code is perfect, that's fine. In practice, it isn't. One oversight in your data handling and you have a cross-tenant data exposure incident.

Mitigation

It is worth noting that under certain conditions, residual data may never actually reach another invocation. Factors such as environment load, the rate at which execution environments are initialised and torn down, and whether Provisioned Concurrency is configured can all influence how long a warm environment persists. In high-churn scenarios where environments are frequently recycled, leftover data may be naturally cleared before it has the opportunity to be exposed. However, this should never be relied upon as a security control; it is an unpredictable side effect of infrastructure behaviour, not a guarantee.

Approaches

Variable initialisation or more specifically explicit initialisation

The first approach is to run a Lambda function per business process, such as an APi Resource which returns data per customer based of their identity supplied during authentication. Ensure code correctly cleanses the environment at the start of invocation where the practice of deliberately setting variables to a known, clean state before any logic executes, rather than assuming they are empty.

Per-tenant Lambda function 1-2-1

The highest degree of isolation would be to create a Lambda function per tenant. Each tenant would have its own dedicated function assigned exclusively to them for code execution. While this approach maximises data cleanliness, it is difficult to maintain at scale; API limits when updating many functions simultaneously, complex CI/CD pipelines, monitoring and alerting sprawl across a large number of Log Groups, and considerably longer deployment times all become significant operational burdens. For most organisations, the overhead of managing this model outweighs the isolation benefits it provides.

Lambda tenant isolation mode

Tenant isolation mode exists for a specific scenario: you're running a single Lambda function that serves multiple end-users or tenants, and you need hard guarantees that their execution environments never bleed into one another.

Two situations make this non-negotiable.
First, if your tenants execute their own code. Isolated environments limit the blast radius when that code misbehaves, whether through bugs or something more deliberate. Second, if you're processing sensitive, tenant-specific data. Shared environments create exposure risk; isolation removes it.

With tenant isolation mode enabled, you pass a tenant identifier with each function invocation. Lambda uses that identifier to route requests to underlying execution environments, ensuring that an environment associated with one tenant is never used to serve requests from another.

Limitations

Tenant isolation mode is not supported with functions that use function URLs, provisioned concurrency, or SnapStart. You can send requests to a tenant-isolated function using synchronous invocations, asynchronous invocations, or by using Amazon API Gateway as an event-trigger.

Bottom line

Tenant isolation mode eliminates the need for custom isolation logic or separate per-tenant functions, letting you focus on business logic while AWS handles the complexities of tenant-aware compute environment isolation. For SaaS builders running sensitive workloads or executing user-supplied code, that's a significant operational and security improvement, it was a long time coming.