AWS Lambda is one of my favourite AWS services, which introduced me to the world of serverless. The service started growing, getting packed with a lot of great features. One such feature which was recently launched is Lambda MicroVM. This opens up a different kind of possibility for what we can build with Lambda, not just simple and short-lived functions. We can now think about running isolated per-user workloads on demand. We can deploy developer sandboxes, preview environments, and testing tools without having to deploy an ECS or EKS.
The ability of the microVMs to start instantly and be able to suspend and resume execution up to 8 hours is what made me think of an option to create an isolated browser session with the ability to choose the region to pick where we want that browser to be located.
What I built:
SafeBrowse is a small reference project that launches one Chromium session per user. The user signs in, selects a region, starts a session and gets an embedded browser inside the app.
Behind the scenes, that browser is running inside an AWS Lambda MicroVM.
The goal was not to build a production remote browser isolation product. The goal was to understand what Lambda MicroVMs make possible and how we can build real user-facing workloads around them.
Architecture overview:
At a high level, the architecture has two parts. The first part is the control plane. This is where the user signs in, creates sessions, views active sessions, and terminates them. The second part is the runtime. This is where the actual Chromium browser runs inside a Lambda MicroVM in the selected AWS region.
Why the Proxy Was Needed
One interesting problem came up while building this. The browser cannot directly talk to the MicroVM endpoint the way the backend can. The MicroVM endpoint expects specific headers for authorization and routing. A normal browser iframe cannot attach those headers when loading an external origin. So instead of exposing the MicroVM URL directly to the frontend, I used a CloudFront-based embed proxy. The frontend asks the backend for a short-lived embed token. Then the iframe loads a SafeBrowse-owned CloudFront URL. Lambda@Edge resolves the token, finds the right MicroVM endpoint, and injects the required headers server-side. So the browser only talks to a normal HTTPS URL. The MicroVM details stay behind the proxy.
User Flow:
The user flow is simple. The user signs in with Cognito. Then they select a region. Then they click launch. The backend creates a session record in DynamoDB and starts a Lambda MicroVM running Chromium. Once the session is active, the user opens the browser inside the app. When they are done, they terminate the session.
What Lambda MicroVMs Open Up
This is the part I found most interesting. Lambda MicroVMs make it possible to think about serverless in a new way. We are not limited to simple request-response functions anymore. We can start building isolated, temporary, user-specific compute environments.
For example, this pattern could be used for:
- remote browser sessions
- safe preview environments
- temporary developer sandboxes
- per-user automation workers
- browser testing tools
- short-lived data processing environments
- AI agent workspaces
- isolated execution environments for internal tools
The important idea is that each user or task can get its own isolated runtime.
You start it when needed. You use it for a short period. You shut it down when done. That is a very useful model.
What I Learned
The biggest learning was that the MicroVM itself was not the hard part.
The harder part was designing the access flow around it. How does the user reach the workload? How do we avoid exposing internal endpoints? How do we keep the frontend simple? How do we terminate sessions cleanly? How do we track ownership, status, region, and TTL?
That is where the control plane becomes important. Lambda MicroVMs give us the runtime. But we still need a clean control plane around it.
SafeBrowse started as a simple question. Can I launch a browser per user using Lambda MicroVMs and make it feel like part of a normal web app? The answer is yes.
The architecture is still simple, but the pattern is powerful. A serverless control plane can manage users, sessions, tokens, regions, and lifecycle. Lambda MicroVMs can run the isolated workload. CloudFront and Lambda@Edge can provide a clean browser-facing entry point. Together, this opens up a new category of serverless applications. Not just APIs. Not just background jobs. But real, temporary, isolated compute experiences that users can interact with directly.
SafeBrowse is not a production Remote Browser Isolation product. It is a reference architecture to explore how Lambda MicroVMs can run isolated, user-facing workloads on demand using a serverless control plane.
GitHub Repo: https://github.com/jayaganeshk/safebrowse
Top comments (0)