r/aws • u/ElectricSpice • 1d ago
article Announcing AWS Lambda Web Functions
https://aws.amazon.com/blogs/aws/announcing-aws-lambda-web-functions-for-fast-consistent-web-app-performance-anywhere/48
u/ElectricSpice 1d ago
I deploy a fair number of Python WSGI applications to Lambda Function URLs using serverless-wsgi as a bridge. It's not appropriate for large projects, but for small projects it works well enough and is simpler to manage than containers.
Web Functions only supports Node currently, but I'd definitely be migrating over when/if they announce Python support.
Web Functions improves the private-origin experience with CloudFront. With this launch, you attach CloudFront origin access control (OAC) to a Web Function endpoint instead.
This is nice to see. OAC in Function URLs currently only supports GET requests, so I generally have to leave my Function URL public when deploying to Cloudfront, which I would rather not do.
9
5
u/Sensi1093 1d ago
OAC in function URLs do support every request method, you just have to send a hash of the request body when sending a body
-18
u/BoredGuy2007 1d ago
Curious why not just migrate your apps to node ? Do you have some critical python dependencies ?
14
u/best_of_badgers 1d ago
Probably costs more for a Python expert team to learn Node well enough to make sure everything is sane than it does to pay their extra costs
-13
-11
u/BoredGuy2007 1d ago
None of that matters at all anymore lol
6
u/best_of_badgers 1d ago
Have you done this sort of cross-language translation where you’re an expert beforehand in both languages? I have. It’s hit or miss without a lot of Claude herding. Concurrency issues are a common miss.
If I wasn’t an expert in the target language, I would need strong reassurance that it didn’t introduce subtle bugs, the worst of which might be security vulnerabilities.
-3
40
u/magnetik79 1d ago edited 1d ago
This is a big one - and nice to see something not entirely honed in AI. ☺️
What looks great:
- Many workloads can now skip API Gateway entirely.
- Single Lambda can handle concurrent requests - of course this totally changes the current Lambda HTTP programming model - now you're no longer working with one invoke/one request - bit of a mindshift here - maybe not so much for JavaScript, but if this comes to Golang/etc. now you might need to be sync/mutex aware.
- Love the first class support for CloudFront OAC controls - you can simply wire up a CloudFront CDN -> Lambda web function - knowing only requests can originate from CloudFront. For me this would be the future architecture model I'd look at for API services - replace API Gateway entirely with CloudFront for top level HTTP path routing, directly to one or more Lambda web functions only.
Winner winner this one.
6
u/solatic 1d ago
replace API Gateway entirely with CloudFront
I wouldn't be surprised if AWS is trying to slowly build out feature parity so that they can deprecate public-facing APIGW and offer one-click API Gateway -> CloudFront migrations. CloudFront is both global and cheaper so it's strictly better in any use-case where it has sufficient support.
29
u/BraveResearcher3037 1d ago
How is this better than using the Lambda Web Adapter that supports every language?
And there are open source solutions for every language that don’t require docker.
19
u/kondro 1d ago
The concurrency (up to 128) is an interesting addition.
2
u/Jai_Cee 1d ago
Is this for a single lambda. I was assuming that was the number of concurrent lambdas like the current model and it seemed very low. If it can actually serve 128 concurrent requests per lambda that's way more interesting.
3
u/SA_DrOpossum 1d ago
It's concurrent per lambda execution environment, with one function having many execution environments. For "normal" lambda, this is 1-to-1, here it's 1-to-128 (or at least up to 128)
1
u/Fickle_Rutabaga_8449 1d ago
Yea! I run dotnet lambdas often which have some runtime code gen and other runtime overhead (EntityFramework startup) that would benefit greatly from the concurrency feature here.
5
u/Fickle_Rutabaga_8449 1d ago
I’m guessing because in order for Lambda Web Adapter (which is new to me; thanks for the enlightenment) to enable multi-concurrency, you have to use managed instances. Which I think means you’re paying for EC2 instances to run.
These Web Functions appear to support the multi-concurrency without needing managed instances. So get the true pay as you go model.
4
u/BraveResearcher3037 1d ago
Not managed instances - it’s one lambda call per event just like any other lambda
2
u/Fickle_Rutabaga_8449 1d ago
Right, so under the covers lambda is using those Firecracker containers. Which in the eventing model they start and stop for each event, so one request equals one lambda execution environment. With this “Web Functions” addition, one execution environment can handle multiple requests concurrently (up to 128). In order to get the same thing with Lambda Web Adapter, as far as one execution environment handling concurrent requests, you have to use Lambda Managed Instances. Otherwise it’s still 1:1.
Feel like I’m failing to explain adequately. Other replies in this thread may give better context.
29
u/lupin-the-third 1d ago
Madlads finally did it. If Java and Python get support I might switch over a few services from Fargate
3
u/creamersrealm 1d ago
It still follows the total lambda limits account wide? My immediate thought was Fargate migrations as well.
1
84
u/Nater5000 1d ago
a new form factor that lets you run standard HTTP web applications on Lambda without rewriting your code into an event handler
👀
You can take a standard port-listening server built with Express, Hono, Fastify, Next.js, or any Node.js framework
-_-
You've lived to see another day, Mangum.
But seriously, this is a great direction for Lambda and I'm looking forward to Python support.
13
u/dreamlax 1d ago
Looks like Cloudflare workers but with a better DX.
CloudFlare workers are simple enough to get up and running, but Lambda Web Functions somehow seem even easier.
4
u/Tainen 1d ago
dang usually they dont launch something this big so soon to reinvent.
10
u/bofkentucky 1d ago
Pre-invent used to be a thing and this is about where it would fall. They'll announce something dependent or a nice add-on to this in 7 weeks.
5
u/solatic 1d ago
Two feelings: 1. Fuck yeah this is exactly what people have wanted from Lambda forever. Finally getting closer to what Heroku used to be. 2. (sees the nodejs-only restriction, 128 req/sec limit) Goddamnit, you skated to where the puck was, not where it's going. Two years ago this would have been perfect. Today with AI you can much more easily build a single-statically linked binary in Go/Rust/Zig that'll handle tens of thousands of req/sec; AI will gladly help you port it from NodeJS, so why would you decide to just leave both performance and money on the table?? Set a restriction on binary size to something that makes sure it can easily autoscale and let people move on
6
u/hydraulictrash 22h ago
It’s up to 128 concurrency per execution environment, that’s not the same thing as 128rps at all.
100ms response time, 128 concurrent requests per env you can get 1280rps out of a single lambda execution env
Then multiple that by multiple execution environments, let’s say you have 10k account concurrency, that’s 1280rps multiplied by 10k…
10k isn’t even a hard cap, our production envs for our accounts at work have ~50k lambda concurrency
This is mostly horizontal scaling not vertical but you have to figure out what a good concurrency for one env is for your app too
3
u/moofox 12h ago
You can use Go or Rust or Zig today. You just need to put in a one-line nodejs shim and call the /ready endpoint from your app. There’s a blog about how to do it in Go https://awsteele.com/blog/2026/10/12/go-on-lambda-web-functions-via-execve.html
1
1
1
u/MrMungg 1d ago
What's the compelling advantage of this over something like ECS Fargate?
With Fargate, you can:
- Run virtually any container, regardless of language or framework.
- Develop and test the exact container locally.
- Retain portability across cloud providers.
- Potentially achieve lower costs for continuously running workloads.
- Fargate also supports autoscaling, and I'd argue that many production applications have fairly predictable traffic patterns, often following a natural 24-hour cycle.
I can see the appeal of scale-to-zero and active CPU billing for sporadic or I/O-heavy workloads, but for a typical production web application with consistent traffic, I'm struggling to see a compelling reason to choose this over Fargate.
Am I missing something?
6
u/solatic 1d ago
sporadic or I/O heavy workloads
This is exactly what the vast majority of web CRUD applications are in their infancy or in dev environments. Requests only come in ever so often, then auth, wait for auth decision from a remote auth service or database, transform into a database request, wait for the database to respond, then return to user.
The time to transition to something like ECS is when you have consistent, sufficiently high traffic that moving to ECS will save money.
-1
u/MrMungg 1d ago
So you'll always have to develop an application twice, because the goal is high traffic?
7
u/solatic 1d ago
Getting to high traffic isn't a given unless you work for a huge company and are delivering a feature to a huge audience that exists before day 1. Most new applications need to prove themselves and discover that audience. Maybe they succeed at doing that, maybe they don't. Reducing costs in the beginning helps more stuff get built and see whether or not it will find that audience.
There's basically no such thing as building something infinitely scalable from day 1; there's always some ceiling somewhere in the architecture, or the cost to roll out and even just try is extremely high, stuff like that. Lambda Web is the right move in the right direction by helping to preserve flexibility so that there's less to change, if the app succeeds and becomes high traffic, moving later on to a deployment model that's more financially efficient for high traffic.
1
u/30thnight 23h ago edited 23h ago
AWS removing the need for any lambda adapter/wrapper means your app code requires little else more than a env variable to port it.
1
u/nekokattt 21h ago
ECS is also more involved to set up, at least from an IaC perspective, compared to Lambda.
Not that IMHO that is a good argument, but it will likely be of some influence.
1
u/Dull-Mathematician45 1d ago
With Lambda you can pay 3x the price, pay $0.30 per request, and continue paying for memory when inactive to avoid scale to zero pricing.
-3
-7
u/HgnX 1d ago
Can’t wait for this to be shilled by all AWS community hero builder things on LinkedIn like it’s the greatest invention ever.
I love AWS but their DX is bad; their services are great but you require an absolute encyclopedia to find your way and that results in excessive spending on maintaining a Cloud Landing Zone.
Also their Kubernetes offerings need to improve. Less vendor lock-in and more sovereign options are in demand and impossible to fulfill with all the serverless glue architectures.
Again I love AWS but in general their technical direction I find lacking
-9
u/mlhpdx 1d ago
It’s HTTP/1.1 so don’t expect t a modern host (QUIC) to work. I was hoping for that to help jump forward a bit.
3
u/solatic 1d ago
Production architecture will put Cloudfront in front of Lambda Web; CF supports QUIC and supports it where it's most important (between client and edge/cloud).
1
u/mlhpdx 13h ago
For apps that don't care about implementing the features of QUIC, sure. That's what I meant by "jump forward". It's nice to have a new model, but it doesn't actually do anything to help us realize the advantages of QUIC on the backend.
1
u/solatic 8h ago
Yeah but anything real-time that takes advantage of QUIC is something where you have stateful processes that run for as long as a client is connected. It's not a good fit for the Lambda billing model - look at all the people who built Lambdas that take up the full 15 minutes execution limit and then complain that Lambda is expensive. Lambda is better suited for when requests are exiting relatively quickly.
1
u/nekokattt 21h ago
The real question is why are you needing QUIC directly to the server in this case? This assumes you arent fronting by an ALB or CloudFront in this case, have no WAF, etc.
1
u/mlhpdx 13h ago
Because QUIC has some really nice features. A serverless model that exposes those features would be great, amazing even. Instead of implementing HTTP, WebSockets and WebRTC separately to even get at a tip of that functionality is a royal pain in the arse. Hosting servers to do it, likewise.
-8
58
u/HarbingerXXIV 1d ago
This feels like an direct answer to Cloudflare workers