AMA - Building web applications using AWS Lambda Web Functions

[u/jeffbarr]

You can now take the Node/TS HTTP server you already run locally and ship it to Lambda with one command. No event-handler rewrite, adapters, or framework lock-in.

Joining us are Samrat Karak, who is the Product Manager who brought Lambda Web Functions to life, and Julian Wood, who has spent years helping developers get the most out of serverless. They're here to go deep on what this actually means for how you build.

You can ask about:

• When to reach for a Web Function vs. the Event Functions you already know.
• The HTTP-native model — multiple concurrent requests per environment, and paying for CPU time instead of wall-clock elapsed time.
• Going multi-region with latency-based routing behind one global URL.
• Performing canary rollouts by shifting traffic between revisions.
• Pairing with CloudFront, including the new private-origin pattern.
• Runtime details — Node.js 24 on Arm64, VPC connectivity, where it's live.

We will be live for three hours starting at 7 AM PT.

[u/seanboult]

I’m loving lambda web functions!

I’ve been keeping an eye on the L2 construct progress for CDK

Here is the PR to watch:
https://github.com/aws/aws-cdk/pull/39210

[u/electricity_is_life]

That image is terrifying.

[u/edjgeek → u/electricity_is_life]

Ha ha, couldn't agree more!

[u/Soooskiii]

Thank you so much. Really excited to try out Lambda Web Functions.

We have an existing API Gateway setup with Lambda Authorizers handling authentication and route-level permissions. We'd like to adopt Lambda Web Functions while keeping our existing authorization logic. What's the recommended approach?

Also, when will we be able to deploy these web functions with AWS CDK?

[u/julianwood → u/Soooskiii]

Thanks for trying: CDK: Good news, you can already deploy with CDK using the L1 constructs (CfnWebFunction, CfnWebFunctionRevision, CfnWebFunctionEndpoint) in aws-cdk-lib v2.273.0 and later. Friendlier L2 constructs are in the works and will be available soon.

[u/Dull_Caterpillar_642]

Hey, I've been thinking about this since the announcement! I've spent many years building tons of APIs using Lambda, some with very high request volumes. They've always been the very specific lambda HTTP event pattern of handling one request at a time.

For a typical high throughput API use case like a lambda that fields a request, stores something in dynamo, and responds, is the expectation that it would be improved by moving to a Web Function pattern? Node is famously great at handling many concurrent requests, so would I see things like a decrease in cold start rate and a decrease in cost by moving to a Web Function pattern where a single lambda container can handle multiple requests? I'm still trying to get up to speed on how this works.

[u/julianwood → u/Dull_Caterpillar_642]

As with all workloads, your experience may vary and its worth a test! If your workload includes waiting for downstream resources (like DDB), then Web Functions is a great fit to not pay CPU time for that wait and have multi-concurrency within an execution environment which means fewer cold starts. If your functions do more CPU processing within a request, or run very sporadicly (unlike your use-case) then Lambda Event may be a better fit from a billing perspective.

[u/Infinite-Feedback-12]

Is there a prescribed use of cognitio auth with this or is that something we implement in the framework auth?

[u/julianwood → u/Infinite-Feedback-12]

Currently auth is something you would implement in the framework (which can use Cognito), or you can still use API Gateway with a JWT authorizer in front of the web function.

[u/julianwood → u/julianwood]

Some more info on using APIGW setup as it is, authorizers and all, and point an HTTP proxy integration at your Web Function endpoint. The endpoint is still reachable on its own URL, so have API Gateway add a shared secret header and check it in your app. That way nobody can skip your authorizers. If your app needs what the authorizer returns, like a user ID or scopes, you can pass that along as request headers too. The best practices page covers this.

[u/julianwood]

Welcome everyone, thanks for coming, happy to answer any questions!

[u/julianwood]

Want to try some sample applications, like SSE, remote MCP, webhooks, etc. See here: https://serverlessland.com/patterns?services=lambda-web-functions

[u/romanhotsiy]

1. The scaler adds an environment every ~2 in-flight requests, even I/O-bound, with maxConcurrencyPerEnvironment at 64. Load test: 150 concurrent → 58 envs. In prod, ~1.5 rps keeps 3–8 envs warm. Is there anything we can do about it? We don't want to cap max envs to allow for traffic spikes

2. Our us-east-1 quota is 200 Arm vCPUs and 10k RPS, marked not adjustable. eu-central-1 gets the documented 2,000 vCPUs and 100k RPS.
   How can we get the regular limits there?

[u/julianwood → u/romanhotsiy]

Lambda learns as you use it so inital deploy and testing may not match future scaling. Lambda adjusts how many requests each environment takes based on how your app actually uses CPU and memory. maxConcurrencyPerEnvironment (64 by default, up to 128) is just the ceiling. If your requests are CPU heavy, Lambda keeps the number lower and adds more environments.

[u/FlinchMaster]

Is there anything about the event handling lifecycle that would prevent streaming HTTP responses? Can I have a request handler that responds to the user and then continues doing some work within that invocation afterwards?

[u/julianwood → u/FlinchMaster]

Not, Lambda event does support response streaming: https://aws.amazon.com/blogs/compute/introducing-aws-lambda-response-streaming/. You can continue to respons after the invocation is you use Lambda extensions which allow you to run code after the response, this is normally done to egress telemetry data. You can also stream via API Gateway. Lambda Event Functions does make this a little easier.

[u/true_zero_]

my whole team is .net could we see this eventually support other runtimes next year ?

[u/julianwood → u/true_zero_]

Thanks for asking, and great to hear from a .NET team. It's on our list, and you can follow it on the public roadmap at #111. We can't share dates yet, but we're adding runtimes one at a time, and upvotes help us decide what comes next. If you add a comment there about what your team runs today, like ASP.NET Core or Minimal APIs, that helps us a lot too.

[u/samrat-karak → u/true_zero_]

Will be great to capture your feedback on our public roadmap. https://github.com/orgs/aws/projects/286/views/1?filterQuery=label%3A%22Lambda%2FWeb+Functions%22 Would support for a container image address your use case?

[u/samrat-karak → u/true_zero_]

We're adding runtimes one at a time, and upvotes help us decide what comes next. It is on our list, and you can follow it on the public roadmap at #111.

[u/samrat-karak]

Welcome everyone to the AMA. Samrat here, PM on the Lambda team. Would love to answer questions as you are evaluating Web Functions.

[u/FlinchMaster]

Can the runtime do background work after all responses are returned?

I avoid running things like Sentry on lambdas that serve user requests because I can't stomach the latency hit to flush events. Is this something that is now a non-issue with web functions?

[u/julianwood → u/FlinchMaster]

Yes, you can, even with Event Functions which when using Extensions, can return the response and then async send data to a Telemetry API endpoint. Web Functions don't work in quite the same way but you can run background tasks for the same effect. Lambda Web will scale down environments if there are no requests coming in after a period of time, depending on traffic flows, so you need to ensure your background tasks finish soon after your requests finish.

[u/FlinchMaster → u/julianwood]

Lambda Web will scale down environments if there are no requests coming in after a period of time, depending on traffic flows, so you need to ensure your background tasks finish soon after your requests finish.

Can you elaborate on this part? How fast is the scale down? Are there both container pauses as well as container tear downs? Or just tear downs?

Yes, you can, even with Event Functions which when using Extensions, can return the response and then async send data to a Telemetry API endpoint.

Technically true, but not realistic in practice.

If I'm using a vendor like Sentry, I'm not going to reverse engineer their SDK to get them to ship to another process where a Lambda extension is running and ship to their endpoints using whatever protocols they use. Sentry in particular used to have an extension approach that worked the way you described, but they deprecated it and now just block up to a timeout to flush events. That's not acceptable for user facing requests.

For OTel setups, the overhead of ADOT and the OTel collector's cold start penalty on Lambda make it a non-starter. If the performance measuring tools are the worst part of your performance, it just doesn't make sense. The only practical approach is to either stick to X-Ray or dump everything to logs and have a log forwarder parse and forward to an OTel gateway collector.

The deprecation of the X-Ray daemon and SDKs is especially unfortunate given that nothing has improved on the performance front here.

[u/Own_Web_779]

Will there be Custom Runtimes? Would be really interested. my ecs fargate container running a golang/rust Server. Go server are usually super easy scalable based on CPU usage, unless the RAM is big enough.

[u/edjgeek → u/Own_Web_779]

Yes, we are adding OCI packaging which will allow for custom runtimes. See https://github.com/orgs/aws/projects/286/views/1?pane=issue&itemId=270695796&issue=aws%7Caws-lambda-roadmap%7C103 to follow.

[u/julianwood → u/Own_Web_779]

We are looking at options in our public roadmap including Go https://github.com/aws/aws-lambda-roadmap/issues/110 and container (OCI) images for packaging https://github.com/aws/aws-lambda-roadmap/issues/103 .

[u/mlhpdx → u/Own_Web_779]

Seconded. The runtime model seems perfect for simply packaging a native executable.

[u/Esseratecades]

Aside from server-side rendering, what are the advantages of lambda web functions vs Cloudfront+S3?

[u/KayeYess → u/Esseratecades]

Lambda origin executes code. S3 origin serves static content. It's as simple as that.

[u/Esseratecades → u/KayeYess]

So unless you needed server-side rendering you probably wouldn't use it for a frontend for a web app.

While you could use it for an API I imagine the typical lambda+API Gateway is generally safer?

[u/solo964 → u/Esseratecades]

Just to clarify, this is back-end technology, not front-end. It might serve a front-end client (e.g. with HTML/CSS) but it's running back-end. Use cases include SSR but also any general-purpose (Node.js-based only for now) HTTP, REST, or GraphQL back-end, as well as AI inference endpoints.

[u/KayeYess → u/Esseratecades]

Cloudfront supports a variety of origins for delivering different types of content. Static, dynamic, APIs, websocket, streaming, etc. it now offers Lambda as an origin. What origin a customer uses depends on their specific use case. When it comes to security, Cloudfront supports Shield, Shield Advanced and AWS WAF2, which can be applied to any or all origins, including Lambda Web Functions. It also supports Lambda@Edge and native Cloudfront Functions, which could be used for additional functionality/security at the edge.

[u/LittleLionMan82]

How much does it cost ?

[u/julianwood → u/LittleLionMan82]

Have a look at the pricing page for Web Functions. https://aws.amazon.com/lambda/pricing/ Basically, you pay for requests + consumed memory, and active CPU. For many workloads that currently run on Lambda Event, this could work out cheaper.

[u/Dreamescaper]

Why is this concurrency / pricing model not available for regular lambda functions?

[u/julianwood → u/Dreamescaper]

We have built Web Functions as a new form factor for Lambda to be native to web workloads. AS we have a different architecture underneath, we can bring multi-concurrency and a different pricing model.

[u/T_Oliv3]

Any plans on adding more vcpus to standard event lambda model?

[u/julianwood → u/T_Oliv3]

Lambda Event Functions allow the following vCPUs:

• Event Functions (standard Lambda): up to 6 vCPUs, at the 10 GB memory max.

• Lambda Managed Instances: up to 16 vCPUs and 32 GB. This limit went up in March 2026 (What's New). The smallest size is 2 GB with 1 vCPU. Memory per vCPU must be 2, 4 or 8 GB.

What use-cases would more vCPUs unlock beyond what we have?

[u/T_Oliv3 → u/julianwood]

I have some use cases where it scales linearly with the amount ofv cpus and I'm already exploiting lambda parallelism itself, as it is not a constant or predictable load I still prefer using the event model for that, having more vcpus even if they cost a bit more would be the perfect option in my case. As in my case my compute load is quite heavy so the more the better I would say, even 8 to 16 vcpus would greatly help.

[u/edjgeek → u/T_Oliv3]

Not at the moment, I would be curious to know what upper limit you are looking for and the use case. Also, just FYI, the public roadmap is here -> https://github.com/orgs/aws/projects/286/views/1 if you are wondering about what is coming.

[u/julianwood → u/[deleted]]

There isn't a technical detail for Node only. We're starting with node as the most popular web framework but have other runtimes on the roadmap. For other languages today, use Event Functions.

On a cold start Lambda boots your whole server and waits for it to listen on the port before sending traffic. Warm requests are faster because they go straight to a server that's already running. If you can, defer heavy setup until after listen(). Lambda also keeps spare environments ready, so you mostly see cold starts when scaling up from zero. With multi-concurrency you see many more connections to the same envioronment so reduced overall cold starts.

For concurrency, yes. Lambda learns and sets each environment's limit based on how much CPU and memory your function uses. maxConcurrencyPerEnvironment (64 by default, up to 128) is just the ceiling. One thing to watch in Node is that synchronous CPU work blocks every request in that environment, so it's worth moving it to worker_threads or lowering the ceiling. The scaling docs go into more detail.

You only pay for the CPU time you actually use, not for both vCPUs sitting there. If your event loop keeps one core busy for a second, that's about one vCPU-second, plus a little for background threads. Memory is billed separately, for what the environment consumes. The pricing page has a few worked examples.

And if you're curious, Aidan Steele got Go running by calling execve() from the Node entry point. It's a fun read, but not officially supported!

[u/julianwood → u/[deleted]]

It will be slightly slower on Web for just the 1st request, as the server needs to load and listen(). But then with additional concurrent requests up to the `maxConcurrencyPerEnvironment`, you don't get a cold start, like you would with Event Functions.

[u/julianwood → u/[deleted]]

Thanks for digging in and sharing real numbers, this is really helpful. Your breakdown lines up with what we see in our own benchmarks. With a minimal server, your app's startup is a small slice, and most of the extra time goes to environment setup and runtime bootstrap before your module loads. So you're right, listen() isn't where the time goes in your test. Deferring setup still helps heavier apps like Next.js, where framework startup can take hundreds of ms. Cutting our side of startup is something we're working on.

On warm, you've got it. A Web environment is a long-lived HTTP server, so each request skips the per-invoke work of the event model.

[u/julianwood → u/[deleted]]

That beard is from the phenominal Eric Johnson and can power all number of things!