How Aikido Security improved AI AutoFix speed by 6x using AWS Lambda tenant isolation mode
Discover how AWS Lambda's tenant isolation mode helped Aikido Security achieve 6x faster vulnerability remediation while maintaining complete isolation.
by Milo Oostergo, Ayush Kulkarni and Frederick Ryckbosch
When you build multi-tenant SaaS applications that process tenant-specific code or data, maintaining isolation across tenants is critical for security. In practice, achieving this isolation can impact performance. Now, with Lambda's support for tenant isolation, you can meet strict per-tenant isolation requirements without sacrificing application performance.
This blog post shows how Aikido Security achieved 6x faster performance for their vulnerability remediation capability — reducing patch delivery time from 30 seconds to 5 seconds — while maintaining complete tenant isolation using AWS Lambda .
Overview of Aikido's security platform
Aikido Security provides security for application code, cloud infrastructure, and runtime environments, within a single platform.
In 2025, Aikido launched AI AutoFix , a capability that remediates security vulnerabilities automatically. AutoFix generates patches to address security vulnerabilities identified in open-source dependencies, application code, infrastructure as code, and container images.
Developers using AutoFix select the security findings they want fixed through their IDE or the Aikido webapp. Aikido then retrieves the relevant code from the linked Git repository and starts the AutoFix process in an isolated compute environment. Once the code is fixed, AutoFix creates a pull request for the developer to review and merge in their source control repository.
Figure 1. Aikido AI AutoFix generated security patch preview.
AutoFix uses an agentic approach for generating security patches: it gathers the relevant code context, formulates a remediation plan, and then applies a fix designed to be easy to read and review. To generate reviewable patches for open-source dependencies, application code, infrastructure as code, and containers, Aikido leverages Large Language Models hosted on Amazon Bedrock for its AutoFix capability.
The Challenge: achieving environment isolation
To ensure patches have been correctly applied, Aikido executes the auto-patched code. Code executions take place in an isolated compute environment for each tenant or end-user. This is critical - as Aikido is a multi-tenant platform, Aikido treats each tenant's code as untrusted and maintains compute environment isolation when executing it. This is essential to prevent incorrect or malicious code from impacting other tenants or the Aikido platform itself.
This untrusted code can also include unaudited third-party dependencies and malicious code designed to exploit the compute environment. Running this code requires isolation to prevent it from accessing other customers' data or affecting concurrent workloads. To illustrate this, consider that when a single compute environment is used to execute code on behalf of multiple tenants or end-users, incorrect or malicious code may access other users’ data or modify the shared execution environment, impacting other customers’ workloads. To achieve isolated code execution for individual tenants, multi-tenant systems like Aikido launch a separate virtual machine for each end-user session or code submission.
Aikido initially used Amazon Elastic Container Service (Amazon ECS) with AWS Fargate to meet these strict isolation requirements. Each Fargate task runs within an isolated virtual environment that does not share network interfaces, ephemeral storage, CPU, or memory with other tasks. With this architecture, Aikido launched a separate task for each end-user or autofix code submission.
Figure 2. Aikido AI AutoFix using AWS Fargate
While this architecture solved Aikido's strict isolation requirements, they sought to optimize the total execution time of 30s (from launching a Fargate task to validating the fix) to deliver a faster experience for their end-users.
Solution: AWS Lambda’s tenant isolation mode
For Aikido's AI AutoFix feature, AWS Lambda offered compelling advantages. Lambda's fast cold start times and responsive scaling made it well-suited for delivering faster security vulnerability fixes to end-users.
Lambda runs your function code in secure execution environments that leverage Firecracker virtualization to provide isolation. These execution environments never share or reuse virtual resources (such as vCPU, disk, or memory) across functions, or even across different versions of the same function. However, Lambda can reuse execution environments for multiple invocations of the same function version, as these execution environments are fully set-up and can therefore deliver faster request processing for your functions. For Aikido AutoFix, which requires strict tenant isolation, environment reuse creates a security risk: another tenant's code in a subsequent invocation could potentially access temporary files, environment variables, or cached data from a previous tenant's execution.
In November 2025, AWS Lambda announced support for a new tenant isolation mode. With this mode, customers can process function invocations in separate execution environments for each individual tenant invoking the same Lambda function. This capability simplifies building secure multi-tenant SaaS applications as Lambda manages creating, maintaining, and routing requests to tenant-specific execution environments.
Figure 3. With the new tenant isolation capability, Lambda creates separate execution environments per tenant for a single function.
Using Lambda's tenant isolation mode, Aikido reduced the time to produce security vulnerability patches from 30s down to 5s, a 6x improvement enabling near real-time vulnerability remediation.
With the new architecture, the Aikido backend invokes an AutoFix Lambda function, passing the unique identifier for the end-user or tenant submitting the AutoFix request. Lambda uses this identifier to route the invocation to a dedicated execution environment for that specific tenant, ensuring complete isolation from other customers' workloads.
Figure 4. Aikido AI AutoFix with Lambda tenant isolation
As AutoFix grows to handle tens of thousands of daily requests, Lambda automatically scales execution environments to handle increased demand while maintaining strict tenant isolation. Each tenant's environments scale independently based on their usage patterns, ensuring consistent performance across all customers.
Conclusion
Lambda tenant isolation mode solved a critical bottleneck for Aikido. With patches now delivered 6x faster - in 5 seconds as compared to 30 seconds - Aikido's end-users can now remediate security vulnerabilities in near real-time.
Lambda tenant isolation is designed for multi-tenant applications that process tenant-specific code or data with strict isolation requirements across tenants. To get started with Lambda tenant isolation:
- Review your Lambda functions to find those that process tenant-specific code or data requiring strict isolation between tenants.
- Create new Lambda functions with tenant isolation mode enabled. Existing functions cannot be modified to enable this feature; you must deploy new functions specifically configured for tenant isolation.
- Update your function invocations to include a tenant identifier parameter. Lambda uses this identifier to route requests to dedicated execution environments.
- Visit the AWS Lambda pricing page to estimate costs for your architecture. Lambda creates a new tenant-isolated execution environment for each unique tenant identifier or when available execution environments for a specific tenant are unavailable. You are charged when Lambda creates a new tenant-isolated execution environment to serve a request. Existing execution environments are only re-used to serve invocations from the tenant they are associated with.
About the authors
Ayush Kulkarni - Ayush is a Senior Product Manager at AWS, with a focus on core compute capabilities for AWS Lambda.
Frederick Ryckbosch - Frederick is Head of AutoFix at Aikido Security.
Milo Oostergo - Milo is a Principal Solution Architect for AWS Startups team in Amsterdam.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article