On this page · 11 sections
- What actually shipped
- The quota split is 4 regions against 6
- The API rate limit, not the memory quota, is the real ceiling
- What it costs, region by region
- Suspend is cheap, but the docs read as though it is free
- Who this affects, and how to tell if that is you
- India-specific considerations
- What is still unknown
- FAQ
- How eCorpIT can help
- References
Summary. AWS added Lambda MicroVMs to Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Europe (Frankfurt) and Europe (Stockholm) on 19 August 2026, taking the total to 10 regions. The AWS pricing API now carries MicroVM rates in exactly those 10. Only 4 of them get the 1,024 GB account memory quota: N. Virginia, Ohio, Oregon and Tokyo. The other six, including Europe (Ireland), which has been generally available since 22 June 2026, sit on 400 GB, and get 5 concurrent image builds instead of 10. On AWS's own published 100-developer sandbox example, the same workload costs $12.41 per developer per month in N. Virginia, $12.54 in Mumbai, $15.63 in Singapore and $15.73 in Frankfurt.
That last number is the one to check before you pick a region for data residency. A 26.8% compute premium in Frankfurt is not a rounding error on a platform that runs thousands of concurrent sandboxes.
What actually shipped
Lambda MicroVMs went generally available on 22 June 2026 in five regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland) and Asia Pacific (Tokyo). It is a separate API surface from Lambda Functions, running on ARM64 only, with up to 16 vCPUs, 32 GB of memory and 32 GB of disk per MicroVM.
The model is image-then-launch. You upload a zip containing a Dockerfile and your artifacts to Amazon S3, call create-microvm-image, and Lambda executes the Dockerfile, starts your application and captures a Firecracker snapshot of the initialised memory and disk state. Every later run-microvm call restores from that snapshot instead of booting cold.
Micah Walter, Sr. Solutions Architect at Amazon Web Services, drew the boundary this way in the launch post: "Lambda Functions remain the right choice for event-driven, request-response workloads, and Lambda MicroVMs is purpose-built for multi-tenant applications that need to hand each end user or session their own isolated environment to execute user- or AI-generated code."
The 19 August 2026 announcement added five regions and nothing else. No new quotas, no price change, no new API. The interesting part is what the quota and pricing tables say about those five.
The quota split is 4 regions against 6
The Lambda quotas page splits the MicroVM account memory quota by region, and the split does not follow launch order.
| Quota | N. Virginia, Ohio, Oregon, Tokyo | Ireland, Mumbai, Singapore, Sydney, Frankfurt, Stockholm | Adjustable |
|---|---|---|---|
| Memory across all MicroVMs, per account per Region | 1,024 GB | 400 GB | Yes |
| MicroVMs at 2 GB configured memory | 512 | 200 | Yes |
| Concurrent image builds | 10 | 5 | Yes |
| MicroVM images per account per Region | 100 | 100 | Yes |
| Versions per MicroVM image | 50 | 50 | Yes |
| Maximum execution duration per MicroVM | 8 hours (28,800 seconds) | 8 hours (28,800 seconds) | No |
At the default 2 GB baseline, the 400 GB regions hold 200 concurrent MicroVMs before you hit ServiceQuotaExceededException. The quota is burstable to four times its value and is adjustable through Service Quotas, so this is a lead-time problem rather than a wall. But the AWS What's New entry frames the five new regions as a way to "meet latency and data residency requirements", and a team that reads that and moves an EU workload to Frankfurt inherits 2.5 times less headroom and half the build concurrency than the same account has in Ohio. File the quota increase before the migration, not after.
The 8-hour maximum execution duration is the one number that is not adjustable anywhere. maximumDurationInSeconds accepts a range of 1 to 28,800 seconds, and Lambda terminates the MicroVM when it is exceeded, whether the MicroVM is running or suspended.
The API rate limit, not the memory quota, is the real ceiling
For a sandbox platform, the binding constraint is usually launch rate rather than total memory. The MicroVM API rate limits are per account, per Region:
| API operation | Rate (TPS) | Burst |
|---|---|---|
| RunMicrovm | 5 | 5 |
| ResumeMicrovm | 5 | 5 |
| SuspendMicrovm | 2 | 2 |
| TerminateMicrovm | 10 | 10 |
| GetMicrovm | 100 | 100 |
| CreateMicrovmAuthToken | 50 | 50 |
| CreateMicrovmShellAuthToken | 5 | 5 |
Five launches per second, with a burst of five, is the default. A CI platform that fans out 300 isolated jobs when a monorepo merges will spend a minute just calling run-microvm, and SuspendMicrovm at 2 TPS is slower still. All of these are adjustable, which means they are a support ticket rather than a redesign, but they are not defaults you can plan a launch around.
Per-MicroVM throughput is fixed and not adjustable: 8 concurrent connections at 1 vCPU, 16 at 2 vCPU, 32 at 4 vCPU, 64 at 8 vCPU and 128 at 16 vCPU. Requests per second per MicroVM are 40 at 4 vCPU / 8 GB and 160 at 16 vCPU / 32 GB. The default 2 GB / 1 vCPU environment accepts 8 concurrent connections, which is fine for one developer at one IDE and wrong for a shared preview environment.
What it costs, region by region
MicroVM compute is billed per second on two dimensions, vCPU-seconds and GB-seconds, with CPU allocated in a 2:1 memory-to-CPU ratio. The default baseline is 2 GB / 1 vCPU and it scales vertically to 4x that baseline with no action from you. You pay the baseline rate while the MicroVM runs, and pay for the extra memory and vCPU only for the seconds it is actually consumed above baseline. Snapshot storage, snapshot data read on launch or resume, and snapshot data written on suspend are billed separately.
AWS publishes a worked example on the Lambda pricing page: 100 developers, 20 days a month, one 2 GB environment each per day, 2.5 hours of use split 75% at the 2 GB / 1 vCPU baseline and 25% at an 8 GB / 4 vCPU peak, 6 suspend and resume cycles per day, five 2 GB images. In US East (N. Virginia) that totals $1,241.22 a month, or $12.41 per developer.
Rerunning the same arithmetic against the unrounded rates the AWS pricing API returns for each of the 10 regions gives the following. The N. Virginia figure lands at $1,241.07 rather than $1,241.22 because AWS rounds the snapshot rates to $0.0038 and $0.00155 in its published example.
| Region | vCPU-second rate | Cost per developer per month, AWS 100-developer example |
|---|---|---|
| US East (N. Virginia), US East (Ohio), US West (Oregon) | $0.0000276944 | $12.41 |
| Europe (Stockholm) | $0.0000277090 | $12.50 |
| Asia Pacific (Mumbai) | $0.0000276940 | $12.54 |
| Asia Pacific (Sydney) | $0.0000279960 | $12.63 |
| Europe (Ireland) | $0.0000291572 | $13.09 |
| Asia Pacific (Tokyo) | $0.0000322421 | $14.52 |
| Asia Pacific (Singapore) | $0.0000346700 | $15.63 |
| Europe (Frankfurt) | $0.0000349960 | $15.73 |
Two things stand out. Frankfurt and Singapore charge about 26% more than N. Virginia for identical work, and Frankfurt is 20% above Stockholm, its nearest new EU sibling. If your only requirement is that data stays in the EU, Stockholm is the cheaper of the two new European regions by a wide margin.
The second is Mumbai. Its vCPU-second rate of $0.0000276940 is fractionally below N. Virginia's $0.0000276944, and its memory rate of $0.0000036670 per GB-second is within a rounding error of the same. Compute in ap-south-1 is at parity with us-east-1, which is not the usual AWS pattern. The entire 1.0% Mumbai premium in the table comes from snapshots: $0.0912 per GB-month of snapshot storage against $0.08 in N. Virginia, and correspondingly higher read and write rates.
Suspend is cheap, but the docs read as though it is free
The MicroVM lifecycle table in the developer guide describes the SUSPENDED state as "State is preserved. No compute charges accrue." That is accurate and incomplete. The pricing page charges snapshot storage for the whole time a MicroVM sits suspended, plus a per-GB write on every suspend and a per-GB read on every resume.
AWS's own example makes the size of it clear. Across 100 developers, 12,000 suspend and resume cycles a month cost $91.20 in snapshot writes and $37.20 in snapshot reads, against $6.20 for the 2,000 cold launches. Suspend and resume traffic is 95% of the $134.60 snapshot line, and the storage for 100 suspended 2 GB environments idling 5.5 hours a day is $2.44. Snapshot storage also has a one-week minimum retention period on MicroVM image storage, so short-lived image versions bill for seven days regardless.
A maxIdleDurationSeconds set aggressively low will therefore raise your bill rather than lower it, because you pay 2 GB of write and 2 GB of read on every flap. The real cost of a suspend policy is the churn, not the idle time.
Who this affects, and how to tell if that is you
You are exposed if you run any workload where each end user or job needs its own kernel: AI coding assistants, hosted notebooks, vulnerability scanners, multi-tenant CI runners, or agent evaluation harnesses. The pattern is the same one covered in AI coding agent sandbox isolation and in agent sandbox patterns on Kubernetes, and MicroVMs is now a third option alongside both.
Three checks before you commit:
- Count your peak concurrent environments and multiply by configured memory. If that exceeds 400 GB in any region outside N. Virginia, Ohio, Oregon or Tokyo, raise the Service Quotas request now.
- Measure your launch rate at peak. Above 5 per second you need a
RunMicrovmincrease, and the same again forResumeMicrovmif you rely on auto-resume.
- Check snapshot compatibility. Every MicroVM launched from one image version shares identical initial state, including any IDs, secrets or entropy generated during the build. Move that generation into the
/runlifecycle hook. Applications using OpenSSL should build onpublic.ecr.aws/lambda/microvms:al2023-minimal, which carries the AWS-patched snapsafe OpenSSL.
Inbound access is worth planning too. Every request to a MicroVM endpoint needs a JWE token in the X-aws-proxy-auth header, created with create-microvm-auth-token, scoped to a set of allowed ports and an explicit expiry. Requests to a port outside the token's allowedPorts get a 403. Traffic routes to port 8080 unless you set X-aws-proxy-port or a lambda-microvms.port.{N} WebSocket subprotocol.
India-specific considerations
For Indian teams, ap-south-1 is now a genuine first-choice region for this workload rather than a compliance compromise. Compute is at parity with us-east-1 to ten decimal places, the only premium is on snapshot storage at $0.0912 per GB-month against $0.08, and keeping user code and its snapshots inside India removes a cross-border transfer question under the Digital Personal Data Protection Act 2023. The trade is the 400 GB account quota, which is 2.5 times smaller than the Ohio ceiling, and 5 concurrent image builds rather than 10. Both are adjustable, and both need the request raised before you cut over. The same regional cost discipline applies here as in any cloud FinOps programme for Indian teams.
What is still unknown
AWS has not published a MicroVM free tier, and none appears in the pricing API. There is no stated latency figure for launch or resume beyond "near-instant" in both the developer guide and the launch post, so the only way to size a user-facing session is to measure it in your own region. The Lambda quotas page does not say whether the 400 GB regions will move to 1,024 GB as capacity builds, and the 19 August announcement is silent on it. Nothing in the docs commits to a region roadmap beyond the current 10.
If you are weighing MicroVMs against a Lambda Function-based design for long-running work, the durable execution comparison in Lambda durable execution against Step Functions covers the other half of that decision, and the trade-offs in an event-driven serverless architecture still hold.
FAQ
How eCorpIT can help
eCorpIT builds and operates multi-tenant AWS workloads for teams shipping AI products, including the isolation, quota and cost modelling this launch changes. Our senior engineering teams size MicroVM baselines against real concurrency, file the Service Quotas increases before a region cutover, and model the snapshot read and write churn that suspend policies create. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified. To review your sandbox architecture or a region choice, contact us.
References
Last updated: 22 August 2026.
