icon/copy-url

favicon-32x32

logo-2x

IT Consulting | Outsourcing | Vietnam

Lambda changed more this year than most teams have noticed. Some changes add a new way to run code. Others move a limit that used to push a workload onto containers.

The numbers are AWS's, and each one links to the page it comes from. We have not run these features in production yet.

## Lambda Web Functions: an HTTP server with no adapter

On October 12, AWS launched [Lambda Web Functions](https://aws.amazon.com/blogs/aws/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere/). Your code starts an HTTP server on the address Lambda provides, and Lambda handles HTTPS in front of it. The [runtime docs](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-runtimes.html) say you need no Lambda Web Adapter or other event-to-HTTP wrapper. Event-driven work stays on Event Functions, according to the [Web Functions overview](https://docs.aws.amazon.com/lambda/latest/dg/web-functions.html).

At launch, only Node.js 24 runs (`nodejs24.x`), and Lambda patches it automatically. You cannot pin a patch version or turn patching off. Each execution environment has 2 GB of memory, and the V8 heap defaults to 1,024 MB. The server must listen within 10 seconds of starting. Each request times out between 3 and 900 seconds, with a default of 30.

An endpoint is `HomeRegion`, `MultiRegion` (latency-based routing, best effort) or `PerRegion`, and it authenticates with IAM or with your application, according to the [core concepts doc](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-how-it-works.html). On October 12, AWS also announced that [Amazon CloudFront supports Web Functions as an origin](https://aws.amazon.com/about-aws/whats-new/2026/10/cloudfront-lambda-web-functions-origin/).

### What Web Functions costs

The [Lambda pricing page](https://aws.amazon.com/lambda/pricing/) lists three rates for Web Functions in US East (N. Virginia), on Arm. Requests cost $0.30 per million. Active CPU costs $0.0000276944 per vCPU-second, metered at 1 ms. Memory costs $0.0000036667 per GB-second, and Lambda bills it for the whole life of each environment, including idle time.

Two points follow from that billing basis. Compute and memory are shared by the requests running in the same environment, so the memory cost spreads across them. A request that waits on a database uses little CPU, but the memory it occupies keeps accruing. A steady endpoint keeps its environments warm and pays for memory all day. A bursty endpoint pays less for idle memory, but the first request after a quiet period waits for a cold start.

The page lists no free tier for Web Functions and no x86 rates. A full comparison with EC2, Fargate, App Runner and Vercel depends on how many requests one environment serves at once and how long environments stay warm. AWS does not publish either, so we will cover that comparison in a separate post once we have measured both.

### How the scaling limits interact

Scaling runs on two axes. Environments scale with traffic, up to `maxEnvironments` if you set it. Requests inside each environment scale up to `maxConcurrencyPerEnvironment`, which defaults to 64.

The account-level quotas matter more than the per-endpoint settings. Per Region, an account gets 2,000 vCPUs and 100,000 requests per second, and each endpoint gets up to 10,000 requests per second. Each environment uses 2 vCPUs, so the vCPU quota caps a Region at about 1,000 environments across every endpoint in the account. [AWS's scaling doc](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-scaling.html) says endpoints in one account share that pool, so one busy endpoint can take capacity from another.

The bottleneck depends on how long each request takes. AWS's example uses 10 environments at 64 concurrent requests each, which holds about 640 requests in flight. At 200 ms per request, that tops out near 3,200 requests per second. At 10 ms per request, the endpoint hits a `rateLimit` of 8,000 requests per second long before it fills its environments. Raising `maxEnvironments` would not help in that case. Raising `rateLimit` would.

AWS also notes that `rateLimit` helps when a downstream dependency has its own limits, such as a database. It gives you a way to cap how much traffic the endpoint sends downstream, which concurrency alone does not do.

When an endpoint hits a limit, it returns HTTP 429. Lambda does not queue those requests, but it does queue requests while a new environment starts. Clients must retry 429 responses with exponential backoff and jitter, as the [scaling doc](https://docs.aws.amazon.com/lambda/latest/dg/web-functions-scaling.html) recommends.

Our [January guide](https://innomizetech.com/blog/serverless-vs-containers-2025-aws-lambda-managed-instances-decision-guide) answered "Long-running processes over 15 minutes? Containers were your only option." Web Functions changes the HTTP side of that comparison. Its 900-second request ceiling leaves the long-run answer where it was.

## Lambda MicroVMs: isolated environments for untrusted code

MicroVMs are a separate primitive. Each one runs in an isolated VM built on Firecracker, and AWS describes them as a compute primitive for user-generated or AI-generated code. The [Q2 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q2-2026/) states that state can be kept for up to 8 hours.

The [MicroVM guide](https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html) lists the use cases: interactive development environments, AI code sandboxes, notebooks, security scanning and multi-tenant CI/CD. A suspended MicroVM keeps its memory and disk, and it resumes when traffic returns.

Access works differently from Web Functions. Every request needs a [JWE token](https://docs.aws.amazon.com/lambda/latest/dg/microvms-networking.html) scoped to one MicroVM, a list of allowed ports, and an expiry time. Traffic goes to port 8080 unless a header picks another allowed port. HTTP/1.1, HTTP/2, WebSockets, gRPC and Server-Sent Events all work on the inbound endpoint.

Bandwidth grows with size. The [networking doc](https://docs.aws.amazon.com/lambda/latest/dg/microvms-networking.html) gives 1 MB/s for a 0.25 vCPU, 0.5 GB MicroVM and 16 MB/s for a 4 vCPU, 8 GB one. A MicroVM that handles large payloads may need more vCPUs than its computation needs. That makes bandwidth a sizing decision as much as a compute one.

Outbound traffic goes to the public internet by default. A VPC egress connector routes it through your VPC instead. Connectors are versioned, and the ARN you pass decides what a MicroVM follows. An unqualified ARN picks up the latest connector version. A qualified ARN pins the MicroVM to one version.

Private access is available through an interface endpoint for `lambda-microvm`, which keeps the HTTPS traffic inside your VPC.

MicroVMs fit untrusted or AI-generated code. An HTTP service you own is a Web Functions question.

## Managed Instances: 90-minute timeouts for async work

On September 9, AWS raised the timeout for asynchronous and event source mapping (ESM) invocations on Managed Instances to 90 minutes, from 15. The [announcement](https://aws.amazon.com/about-aws/whats-new/2026/09/aws-lambda-90-minute-function/) calls it a 6x increase and says it is available in every Region where Managed Instances runs. The [Compute Blog](https://aws.amazon.com/blogs/compute/announcing-90-minute-function-timeout-on-aws-lambda-managed-instances/) gives the operational detail.

Three limits stay the same. Synchronous invocations keep 15 minutes, the Init phase keeps 15 minutes, and Amazon MQ and Amazon DocumentDB event source mappings keep 15 minutes. The change applies to batch and event work, and it leaves API calls alone.

AWS says there is no extra charge for the longer timeout beyond standard Managed Instances pricing. The Compute Blog also lists what long runs need:

- SQS visibility timeouts of at least six times the function timeout, so retries have room during throttling.
- Tuned batching windows and parallelization factors for Kinesis and DynamoDB Streams.
- Partial batch failure reporting, so a retry covers only the failed records.
- Keep-alive traffic behind a NAT Gateway, because idle connections drop at 350 seconds.
- Temporary credentials that last the whole run, or a background refresh.
- Idempotent handlers, because Lambda does not guarantee exactly-once processing and longer runs widen the window for duplicates.

A 90-minute run that fails at the end uses six times the compute of one that fails at 15 minutes. That is the cost of skipping the checks above.

Managed Instances also grew in March. On March 27, AWS raised the limit to [32 GB of memory and 16 vCPUs](https://aws.amazon.com/about-aws/whats-new/2026/03/lambda-32-gb-memory-16-vcpus/), from 10 GB and about 6 vCPUs. You can pick a memory-to-vCPU ratio of 2:1, 4:1 or 8:1. Our January guide quoted the 10 GB ceiling, so that line is out of date now.

AWS also added scheduled scaling in May for predictable traffic, and tag propagation to the underlying EC2 resources in June. The [Q2 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q2-2026/) covers both.

## Durable Functions: more languages, your own SDK, your own key

Durable Functions run multi-step workflows as ordinary code. Each step checkpoints its progress, so a failed run resumes from the last checkpoint.

The [Q1 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q1-2026/) lists Python and TypeScript first, with a Java SDK in preview. The [Q2 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q2-2026/) says the Java SDK reached general availability in April, and that durable functions expanded to 16 more Regions.

On July 28, AWS added [custom Durable Execution SDKs](https://aws.amazon.com/about-aws/whats-new/2026/07/aws-lambda-durable-custom-sdk/). You can write one in any language, and AWS published open-source conformance tests to check it. The existing SDKs cover Node.js, Python, Java and C#/.NET.

On July 22, AWS added [customer managed keys for durable execution data](https://aws.amazon.com/about-aws/whats-new/2026/07/durablefunctions-cmk/). By default, Lambda encrypts execution state with a key AWS owns. A customer managed key replaces it, and the key stays separate from the function-level key. You control rotation and who can read execution history and state, without touching environment variables. Standard KMS charges apply to the key.

When invoked asynchronously, a durable execution can run for up to one year. Steps run at least once by default, so each step needs to tolerate a retry. Our [December 2025 post](https://innomizetech.com/blog/aws-lambda-s-biggest-update-in-years-what-it-means-for-your-architecture) compares Durable Functions with Step Functions. That comparison predates the changes above.

## Response streaming and event-source isolation

Response streaming is now available in all commercial AWS Regions, as of April, according to the [Q2 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q2-2026/).

In June, AWS added tenant isolation for event source mappings, according to the [Q2 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q2-2026/). SQS, Kinesis and EventBridge sources can run in isolated execution environments per tenant. That fits a multi-tenant product, where one function serves many customers and each tenant gets its own environment.

On October 9, AWS added [OAuth for self-managed Kafka ESMs](https://aws.amazon.com/about-aws/whats-new/2026/10/aws-Lambda-supports-oauth-kafka-esm/). Before this, Kafka ESMs supported only SASL/PLAIN, SASL/SCRAM and mutual TLS. The announcement covers self-managed Kafka and managed offerings such as Confluent Cloud, Aiven and Redpanda. It says you create a new ESM to use OAuth. It does not say whether an existing mapping can switch, so a migration plan has to answer that question first.

## Runtimes, storage and tooling

- **.NET 10** arrived in January as a managed runtime, per the [Q1 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q1-2026/).
- **Ruby 4.0** arrived in April, with advanced logging controls, per the [Q2 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q2-2026/).
- **S3 Files** (June) lets a function mount an S3 bucket as a file system, per the [Q2 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q2-2026/). Our [S3 Files deep dive](https://innomizetech.com/blog/amazon-s3-files-deep-dive-file-system-access-to-s3-buckets) covers how the storage model works.
- **Availability Zone ID** (March) lets a function read the AZ it runs in, for AZ-aware routing, per the [Q1 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q1-2026/).
- **AWS Transform custom** (June) uses AI to find breaking changes and generate code changes for runtime upgrades, per the [Q2 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q2-2026/).
- **SAM CLI BuildKit** (May) adds faster multi-stage container image builds, per the [Q2 recap](https://aws.amazon.com/blogs/compute/serverless-icymi-q2-2026/).

## Closing

Lambda's 2026 changes move several lines that teams drew for themselves. Web Functions runs a plain HTTP server, so the adapter layer can go. The 90-minute timeout moves batch and event work that used to need containers. MicroVMs give untrusted code its own VM, so the isolation question no longer depends on how far you trust the code.

Each of these comes with limits, and the limits decide the design. Concurrency, rate limits and account quotas set the real ceiling on an endpoint. Bandwidth sets the real ceiling on a MicroVM. A 90-minute timeout still needs idempotent handlers and credentials that last the run.

Before your next design review, check which of your Lambda functions sit closest to the old 15-minute line. Those are the ones where the 2026 changes will show up first.


AWS Lambda in 2026: The Changes You Cannot Miss

Similar articles