Yes, AWS Lambda can run user-submitted code without running that code on your VPS—but Lambda is an execution boundary, not a guarantee that arbitrary code is safe. The design still depends on how you invoke the function, what its IAM role can access, whether execution environments are reused, and how you limit the workload. For multi-tenant submissions, AWS Lambda tenant isolation offers a tenant-specific execution environment model; ordinary Lambda functions do not automatically provide that same per-tenant routing.
What “keeping the VPS out of it” actually means
Your VPS can accept a submission and send it to Lambda for execution, so the submitted program runs in a Lambda execution environment rather than as a process on the VPS. That can keep untrusted code off the VPS, but it does not remove the VPS or the rest of your AWS account from the trust boundary: your application still handles the submission and invocation, and your configuration determines what the function can reach.
As an Amazon Associate I earn from qualifying purchases.
AWS documents Firecracker virtualization as the workload-isolation boundary for Lambda execution environments. That describes AWS’s infrastructure design; it is not a promise that application bugs, exposed credentials, overly broad permissions, or account misconfiguration are impossible. See AWS’s tenant isolation documentation and overview of how Lambda works.
Free tools Windows power users keep installed
One-click scans. No signup required.
Choose the Lambda isolation model that matches your tenants
“Lambda” can refer to different execution and isolation models. Decide whether the workload needs ordinary function-level isolation or a separate execution environment for each end user or tenant, then verify current feature support and cost before building around that choice.
#1 Best Overall
| Model | Isolation and reuse | What to keep in mind |
|---|---|---|
| Ordinary Lambda function | Lambda uses Firecracker virtualization for workload isolation. An execution environment may be reused for later invocations of the same function. | Do not assume each invocation gets a fresh process or filesystem. Protect against residual state, and scope the function’s role to the task. |
| Lambda tenant isolation | The caller supplies a tenant identifier. Lambda routes requests to an execution environment associated with that tenant; AWS says environments are not reused across different tenants, while invocations from the same tenant may reuse one. | AWS specifically identifies execution of end-user-supplied code as a use case. The feature has limitations, region constraints, and additional pricing. Its documented service limit is 2,500 tenant-isolated execution environments per 1,000 configured concurrent executions; confirm current limits and availability in the feature documentation. |
| Lambda Managed Instances | Functions run in containers on customer-owned instances; AWS says containers are not a security boundary between untrusted workloads. | Do not treat this as interchangeable with ordinary Lambda isolation. AWS advises using separate capacity providers for workloads that are not mutually trusted. See Managed Instances security guidance. |
| Lambda MicroVMs | A separate product and resource model that builds a Firecracker snapshot and captures disk and memory state, with lifecycle hooks. | Its configuration and billing semantics should not be assumed to match ordinary Lambda functions. See AWS’s MicroVM core concepts and MicroVM best practices. |
Tenant isolation is the relevant Lambda feature when the security requirement is to keep one tenant’s execution environment from being reused for another tenant. It does not eliminate the need to isolate your application’s data access, limit permissions, and validate the caller-supplied tenant identity.
Design for reused environments and leftover state
Lambda may keep an execution environment after an invocation and reuse it for a later invocation of the same function. AWS warns: “To avoid potential data leaks across invocations, don’t use the execution environment to store user data, events, or other information with security implications.” Read the full Lambda best practices.
For code execution, state is not limited to variables in the handler. Consider module globals, subprocesses, cached files, open sockets, and temporary files. Decide what must be isolated by tenant, what can safely persist, and what needs cleanup. Treat cleanup and unique per-job work directories as implementation precautions, not as guarantees that Lambda resets the environment between invocations.
Recommended Free Tools
Handle /tmp as temporary, not automatically cleared
Each execution environment has its own /tmp storage. AWS lets you configure it from 512 MB to 10,240 MB in 1-MB increments, and says stored data is encrypted at rest with an AWS-managed key. Those figures describe Lambda’s published configuration range; they do not establish that files are cleared between invocations. Use unique work directories, avoid retaining sensitive submissions unnecessarily, and clean up files your handler creates. See Lambda ephemeral storage configuration.
Choose a tenant lifecycle deliberately
If mutable state cannot safely be kept in handler-local memory, AWS’s best-practices guidance suggests a separate function or function version per user. That is one possible design, not a universal requirement; assess it against your tenant count, operational model, and isolation needs. Tenant isolation is another option when its feature limits and regional availability suit the workload.
Limit what submitted code can access
A Lambda execution role is an IAM role whose permissions are associated with a function. AWS’s guidance is to grant only the permissions needed for the task. For an untrusted-code function, start from the smallest useful role rather than attaching the broader permissions used by your application or deployment system. The exact policy depends on the AWS APIs the workload must call. See AWS’s Lambda overview.
- Keep application, deployment, and execution permissions separate where practical; do not give the submitted program access to privileges it does not need.
- Keep secrets out of the submitted program’s environment and files it can read. Consider what the handler, runtime, and execution role expose to the child process.
- Restrict network access and destinations if the workload does not need unrestricted outbound connectivity; otherwise, a submission may be able to make external requests or cause side effects.
- Validate inputs and set application-level limits for request size, concurrency, repeated submissions, and permitted operations. These are controls you design around Lambda, not protections supplied automatically by the function timeout.
AWS’s separate Lambda MicroVM guidance discusses separating build and execution roles and using short-lived authentication tokens in that product context. Those recommendations do not establish a configuration recipe for ordinary Lambda functions; use the documentation for the specific product you deploy.
Set workload limits beyond the timeout
AWS documents a maximum execution time of 15 minutes per invocation for ordinary standard Lambda functions. This can rule out jobs that need longer uninterrupted execution, but it does not cap the total work from repeated invocations, aggregate concurrency, external side effects, or the bill. Add quotas and monitoring appropriate to your service rather than treating the invocation timeout as a complete resource limit. See the Lambda execution environment lifecycle documentation.
Best Value
Memory, timeout, and ephemeral storage are function configuration choices. The documented /tmp range does not tell you what CPU, memory, network egress, or concurrency settings fit a particular language and workload. Determine those from the runtime, expected job profile, and threat model; the relevant configuration cannot be selected responsibly from a generic “untrusted code” recipe.
A practical decision path
- Define the boundary. Decide whether you need code to run off the VPS, whether tenants must be isolated from each other, and what data or services the code must reach.
- Select the execution model. For per-tenant Lambda routing and environment separation, review Lambda tenant isolation’s current regional support, limitations, pricing, and service limits. Do not substitute Managed Instances or MicroVMs without evaluating their distinct models.
- Minimize authority. Give the execution function a narrowly scoped IAM role and avoid passing secrets or broad application credentials into the code’s environment or reachable files.
- Plan for reuse. Assume ordinary Lambda environments may persist and be reused. Decide how process state and
/tmpcontents are separated or cleared, and avoid storing sensitive tenant data in reusable state. - Enforce workload policy. Add input validation, per-user quotas, controlled concurrency, network restrictions, and cost monitoring where needed; test the limits against realistic submissions.
- Keep invocation safe. Ensure your application authenticates and authorizes submissions, supplies the correct tenant identity where applicable, and does not expose an invocation path that lets users bypass those checks.
When Lambda may not be the right fit
Ordinary standard Lambda’s 15-minute invocation ceiling is unsuitable for jobs that require longer uninterrupted execution. A workload that needs extensive mutable shared state, specialized runtime behavior, or resource guarantees not established by the configuration you can choose also needs a different design assessment. Managed Instances should not be used as a container-based shortcut for isolating mutually untrusted jobs; AWS explicitly cautions that containers are not a security boundary there. Evaluate an alternative execution service against the same questions: tenant separation, state lifecycle, least-privilege access, network exposure, workload limits, and operating cost.
What this architecture can and cannot promise
Moving execution to Lambda can keep submitted programs from running directly on your VPS, and Lambda documents a Firecracker-based workload-isolation boundary. Tenant isolation can provide tenant-specific environment routing and prevent environments from being reused across different tenants. Neither choice makes the complete system safe by itself: your invocation path, IAM role, secrets, network reach, state handling, and workload controls remain part of the security design.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
