{"slug": "aws-lambda-microvms-alternative-agent-sandboxes-in-the-eu", "title": "AWS Lambda MicroVMs alternative: agent sandboxes in the EU", "summary": "AWS launched Lambda MicroVMs on 23 June 2026, offering isolated VMs for executing user- or AI-generated code, with up to 16 vCPUs, 32 GB memory, and 8 hours runtime. Orkestr, an EU-based competitor, offers similar Firecracker-based sandboxes with smaller resource limits but lower pricing, pay-per-use billing, and three EU regions compared to AWS's single European region. The key differentiators are resource ceiling, ecosystem integration, and jurisdictional control.", "body_md": "On 23 June 2026, AWS shipped [Lambda MicroVMs](https://aws.amazon.com/lambda/lambda-microvms/): isolated VMs you launch, suspend, resume and terminate through an API, built explicitly for \"workloads that execute user- or AI-generated code.\" Up to 16 vCPUs, 32 GB of memory, 8 hours of runtime, a dedicated HTTPS endpoint per VM.\n\nWe've been shipping that product for a while. So has E2B, so has Modal. The interesting thing about the launch isn't that AWS caught up - it's that the biggest infrastructure company in the world looked at agent sandboxes, agreed with the design, and then shipped it with **one European region and a price roughly three times ours per vCPU**.\n\nThat's the whole post. If you want an AWS Lambda MicroVMs alternative, \"can anyone else do this\" isn't the question - the isolation technology is literally the same on both sides. The questions are who operates the machine, where in Europe you can put it, and what it costs to leave running. AWS wins some of these outright, and we'll say where.\n\nPick Lambda MicroVMs if you're already deep in AWS, need more than 4 vCPUs or 8 GB in a single sandbox, or your agent has to reach private resources inside your VPC. The IAM integration and the size of the fleet are real advantages.\n\nPick [orkestr sandboxes](https://orkestr.eu/sandboxes) if you're an EU company that wants execution, snapshots and logs inside one EU legal entity, you want to pay for CPU you actually burned rather than CPU you reserved, and your sandboxes are small and numerous rather than huge.\n\nBoth products run on Firecracker. AWS says so on the docs page - \"Lambda MicroVMs deliver these core capabilities through Firecracker virtualization\" - and so do we. Each sandbox is a hardware-isolated VM with its own kernel and rootfs, not a container sharing the host kernel. That distinction matters exactly when an LLM is writing shell commands you haven't read yet.\n\nThe lifecycle is the same too. Create, exec, read and write files, pause, resume, terminate. Here's ours:\n\n``` python\nfrom orkestr import Sandbox\n\nwith Sandbox.create(template=\"python-3.12\") as sbx:\n    sbx.files.write(\"/workspace/main.py\", \"print(sum(range(1_000_000)))\")\n    result = sbx.exec(\"python /workspace/main.py\")\n    print(result.stdout)   # 499999500000\n```\n\nSame primitive, different jurisdiction and different economics. Everything below follows from that.\n\n**Ceiling.** Lambda MicroVMs go to 16 vCPU / 32 GB / 32 GB of disk, with 4x vertical burst above your configured baseline. Our largest sandbox is 4 vCPU / 8 GB. If one sandbox has to compile a large C++ tree or hold a 20 GB dataframe in memory, we're the wrong answer and you can stop reading here.\n\n**Ecosystem.** IAM, VPC attachment, S3, CloudWatch - if your agent needs to reach private AWS resources, a Lambda MicroVM sits inside your account and ours doesn't. AWS even published a guide for [using Lambda MicroVMs as a sandbox for Claude Managed Agents](https://docs.aws.amazon.com/lambda/latest/dg/microvms-integrations-claude-managed-agents.html). We don't have that kind of first-party integration and won't pretend to.\n\n**Scale you will never test.** AWS runs Firecracker under 15 trillion+ Lambda invocations a month. If your load pattern is \"10,000 sandboxes at 09:00 on Monday,\" they've proven that and we haven't.\n\n**Three EU regions instead of one.** AWS gave Lambda MicroVMs five regions and exactly one is European. We run sandboxes in Germany, Finland and France. That's a latency and blast-radius fact, not a compliance one: put the sandbox near the user waiting on it, and don't bet the product on a single region.\n\n**Who operates the machine.** Ireland is in the EU. Running your sandboxes there is legal, it isn't a GDPR violation, and anyone telling you otherwise is selling something - the EU-US Data Privacy Framework adequacy decision stands, having survived a challenge in the General Court in September 2025 (it's under appeal).\n\nThe fact that actually stalls procurement reviews is a different one. The US CLOUD Act (18 U.S.C. §2713) obliges a US provider to produce data in its \"possession, custody, or control\" *regardless of where that data is stored*. The city isn't the test. Corporate control is. An EU region on a US hyperscaler keeps your data in Europe. It doesn't put it beyond a US warrant. We're an EU entity with no US parent, and if that has never come up in a deal you're closing, weight this section at zero.\n\n**The 8-hour ceiling.** Lambda MicroVMs cap total runtime at 8 hours. Ours run up to 24. For a long-lived coding agent or a CI executor chewing through a monorepo, that gap is the difference between one sandbox and a stitching problem.\n\n**State that outlives the VM.** AWS suspends a MicroVM with memory and disk intact, which is good, and then termination \"releases all resources.\" We have [persistent volumes](https://dev.to/sandbox-persistent-volumes-roubaix-region/): an ext4 volume mounted at `/persist`\n\n, checkpointed to EU object storage, that survives termination and re-attaches to a completely different sandbox later. An agent picks up the workspace it left behind last week. The caveat: the object-storage copy is only as fresh as the last checkpoint, so losing a box can lose writes since the last upload.\n\n**The CPU you don't burn is free.** Lambda MicroVMs bill the baseline rate for the whole time the VM is running, and charge extra only for burst above baseline. We split the bill in two and meter each per second: **CPU on real on-CPU time**, RAM on memory actually held. Your sandbox's provisioned size is never multiplied by a rate anywhere in our billing code.\n\nThat matters because of what an agent session does with an hour. It runs a command for ninety seconds, then sits there while the model thinks, then runs another. The CPU is idle most of the wall clock - and idle CPU costs you nothing:\n\n```\nOne hour on a 1 vCPU / 1 GiB agent sandbox, billed two ways\n\n                0              15             30             45             60 min\n                |              |              |              |              |\n sandbox        ###........###............####..............###.............\n                # = running a command      . = idle, waiting on the model\n                13 min of real work. The other 47 min the CPU sits idle.\n\n AWS Lambda     ############################################################   ~$0.155\n MicroVM        baseline rate, charged for all 60 minutes                      per hour,\n                Running is running. Idle costs the same as work.               idle or not\n\n orkestr        two meters, both per second\n   CPU          ###........###............####..............###.............   EUR 0.010\n                charged on the same four bursts, nothing in between            13 min billed\n   RAM          ############################################################   EUR 0.015\n                held the whole hour, so charged the whole hour                 60 min billed\n                                                                              ------------\n                                                                               ~EUR 0.025\n                                                                               per hour, all in\n```\n\n*Lambda bills the baseline straight through the idle gaps. We bill CPU only when it runs - but the RAM meter keeps ticking, and on an idle sandbox that's most of what you pay.*\n\nRead that bottom row carefully, because the honest version is less flattering than the pitch. Idle CPU really is free: 13 minutes of work bills 13 minutes of CPU, not 60. RAM is a different story. We meter the memory the guest is actually holding, and a VM that has touched its GiB goes on holding it whether it's working or not, so the RAM meter runs at close to full rate for the entire hour. In this example that's €0.015 of a €0.025 bill - **the majority of what you pay for an idle sandbox is RAM**, and no amount of doing nothing makes it go away.\n\nIt's still 6x cheaper than the same hour on Lambda. It is not \"an idle sandbox is nearly free,\" and you'd have found that out on your first invoice.\n\nIdle isn't the exception in an agent workload. It's most of the session.\n\n**Building an image.** On Lambda you package code plus a `Dockerfile`\n\ninto a zip, upload it to S3, call the API to build an image, and wait a couple of minutes. Ours is a list of shell steps:\n\n``` python\nfrom orkestr import Template\n\nTemplate.create(\n    name=\"agent-py\",\n    base_template=\"python-3.12\",\n    recipe=[\n        \"apt-get update && apt-get install -y ripgrep\",\n        \"pip install pandas duckdb\",\n    ],\n)\n```\n\nThe root filesystem is writable at runtime too, so `apt-get install`\n\ninside a live sandbox just works. (It lands in a RAM-backed overlay, so it counts against the VM's memory and vanishes on terminate. That's the tradeoff.)\n\n| AWS Lambda MicroVMs | orkestr sandboxes | |\n|---|---|---|\n| EU regions | Ireland only | Germany, Finland, France |\n| Operating entity | US parent (CLOUD Act reach) | EU, no US parent |\n| Max size | 16 vCPU / 32 GB | 4 vCPU / 8 GB |\n| Max runtime | 8 hours | 24 hours |\n| Suspend / resume | yes, no compute charge | yes, paused up to 7d free / 30d paid |\n| State after terminate | released |\n`/persist` volume survives |\n| vCPU price | ~$0.123 / vCPU-hour (x86, Ireland) | €0.045 / vCPU-hour |\n| RAM price | ~$0.016 / GB-hour | €0.015 / GiB-hour |\n| Billed on | provisioned baseline while running | actual CPU + RAM used, per second |\n| Egress control | VPC / public internet | per-sandbox domain allowlist (up to 50) |\n| To start | AWS account, IAM, S3 | email, €10 credit, no card |\n\nAWS rates are from the Lambda price list for `eu-west-1`\n\n; ours are the published [pay-as-you-go rates](https://orkestr.eu/pricing). RAM is near parity. vCPU is roughly 2.5x.\n\nMake it concrete. A 1 vCPU / 2 GB agent sandbox, live 8 hours a day, 22 working days - 176 hours:\n\nHalf the price, and that's the pessimistic version: it assumes the CPU is pinned for all 176 hours. It won't be. Bill the CPU on what it actually burns and the real number lands lower - though the RAM half keeps ticking regardless, so don't expect it to fall through the floor.\n\nSandboxes are their own product, not a plan add-on. Verify your email and you get €10 of credit with no card; add a card and it's €100. Free tier includes 10 GB of stored volumes. Base images are `python-3.12`\n\n, `python-3.12-bare`\n\n, `node-22`\n\nand `debian-12`\n\n(a real Debian bookworm, so `apt-get`\n\nworks), and there's an MCP server if you want to hand sandboxes straight to Claude Code or Cursor.\n\n```\npip install orkestr\n```\n\nIf you're comparing more than one option, we've also written up [orkestr vs E2B](https://dev.to/e2b-alternative-eu/) and [an EU alternative to Vercel Sandbox](https://dev.to/vercel-sandbox-alternative-eu/). Where they're better, we say so there too.\n\n**Which regions do Lambda MicroVMs run in?**\n\nUS East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland) and Asia Pacific (Tokyo) at launch. Ireland is currently the only European one. orkestr sandboxes run in Germany, Finland and France.\n\n**Is running agent code on Lambda in Ireland a GDPR problem?**\n\nNo. Ireland is in the EU and the EU-US Data Privacy Framework adequacy decision currently stands, so this is legal and compliant. The narrower concern - the reason some EU buyers still rule it out - is that the US CLOUD Act reaches data held by a US company regardless of which region it sits in. That's a question about the operator, not about the country the disk is in.\n\n**What's the real difference between Lambda MicroVMs and Lambda functions?**\n\nFunctions are stateless handlers: 15-minute ceiling, frozen between invocations, no way to address a specific execution environment. MicroVMs are addressable machines you launch, suspend and resume, with a persistent disk while they live. They're different products that happen to share an isolation technology.\n\n**Can I run untrusted, AI-generated code in an orkestr sandbox?**\n\nThat's what it's for. Every sandbox is its own VM with its own kernel, network egress defaults to off, and you can pin a per-sandbox allowlist of up to 50 domains when you do need it out.\n\n**How long can a sandbox live?**\n\nUp to 24 hours running. Paused sandboxes keep their memory and disk snapshot for 7 days on the free tier, 30 days with a card on file.", "url": "https://wpnews.pro/news/aws-lambda-microvms-alternative-agent-sandboxes-in-the-eu", "canonical_source": "https://dev.to/ianqqu/aws-lambda-microvms-alternative-agent-sandboxes-in-the-eu-3b8h", "published_at": "2026-07-14 18:27:47+00:00", "updated_at": "2026-07-14 18:59:43.251345+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-agents", "developer-tools"], "entities": ["AWS", "Lambda MicroVMs", "Orkestr", "Firecracker", "E2B", "Modal", "Claude Managed Agents"], "alternates": {"html": "https://wpnews.pro/news/aws-lambda-microvms-alternative-agent-sandboxes-in-the-eu", "markdown": "https://wpnews.pro/news/aws-lambda-microvms-alternative-agent-sandboxes-in-the-eu.md", "text": "https://wpnews.pro/news/aws-lambda-microvms-alternative-agent-sandboxes-in-the-eu.txt", "jsonld": "https://wpnews.pro/news/aws-lambda-microvms-alternative-agent-sandboxes-in-the-eu.jsonld"}}