alt Hacker NewsAWS Lambda Web Functions
Comments
Looks pretty interesting. I presume the boom in cloudflare workers and other hosting platforms has been a forcing function to make running a web app more “normal” looking with their lambda offering.
Rust + Axum has sort of supported this with a middleware (https://github.com/lazear/axum-aws-lambda). Essentially you write your API as normal, and then when you build for lambda you enable a feature that does the special handler for you.
This + Function URL + Cloudfront, and you end up with an API entirely hosted in lambda. I have a backend that does is hosted like this that does pretty complex work (image/video uploads, image conversions, on top of the standard auth, database connections, etc). It even renders a frontend with HTMX/Alpine.
Even with all the bot traffic I receive, at almost 15 million requests per month the cost is under $10/mo (median latency is roughly 90ms). Cold starts are a non-issue with the Rust runtime.
I've built 2 applications using Lambdas as a backend and I love how simple and it is. It cost literally 0$ (the lambda part).
The frontend is hosted on cloudfront, the backend is a lambda and you basically just pay for the database and certificate.
I don't want to manage a server or even a docker image. I just want my code to exist there so I like the idea
Something very similar to this was already possible via serverless-express for node:
https://github.com/CodeGenieApp/serverless-express
This wraps Lambda's 'handler' function and allows express to run on top of it, essentially you get a node web server with no persistence between requests which usually isn't a good thing to rely on, but you can also kinda have that with persistent tcp connections.
Of course since this is not real HTTP, things like WebSocket aren't available, but it's good enough to build a CRUD backend or two.
Similar libs exist for other runtimes as well.
> a burst of incoming traffic can share warm environments instead of mapping each request to a new one
But cold starts could still occur, especially in a low-traffic environment where requests come in seldomly?
I strongly recommend never using functions as a service unless you genuinely have some client edge compute requirement that absolutely cannot be solved via some other means.
Everything about running software is made more difficult this way. You might think it would make certain infrastructure aspects easier, but it just changes the semantics of the same problem. It's the same quantity of mess to clean up, but now it's in these really weird piles that are often much harder to access.
> up to 128 concurrent requests per environment
I am fairly confident I could support more capacity with a single t3a.nano instance.
Jeeze, there's a lot of comments in this thread written by people who have no clue how any of this works lol
This sort of just feels like those “free PHP hosting” sites you would see in ~2004 now.
Not to say it’s “bad”, just interesting how things loop around.
Disappointed by the NodeJS-only requirement and the 128 req/env/sec ceiling.
NodeJS-only feels very pre-AI. Let me tell my agent to write my web service in Rust/C++/C/Go/Zig, and ship a statically-linked single binary that fits within a maximum binary size ceiling. I'd get much better performance, and make much more of the premium CPU/RAM pricing that I'm being asked to pay in exchange for scale-to-zero and fast autoscaling.
The rest is amazing. First-class support as a CloudFront origin. Easy multi-region and gradual deployment. Clearly, finally, a great response to Cloudflare. Just.... so close, and yet, so far. No way am I going back to Node as a web backend for greenfield projects in 2026.
I feel like we're in an age where a very small team of devs armed with enterprise LLM subscriptions could absolutely build and maintain an open source, reverse engineered, self-hosted implementation of all of Amazon's most high profile AWS offerings (S3, SQS, Lambdas, IAM, EC2, DynamoDB, etc.). All as a single, cohesive open source project.
Just feed it the API docs and loop.
In this thread: "If my grandma had wheels, she'd be a bike."
Yay ! Active CPU billing mean the same thing as Cloudflare ! But you still pay memory for as long as the function is up. Data transfer is not included, you have to take that into account. There is also the number of requests...
AWS should have understood by now that Cloudflare workers pricng is so much more legible, it's one of the reason of their success.
Being able to handle concurrent requests with one worker is nice. I hope this becomes available for Python too.
Finally Lambda without the adapter layer.. Now please add .NET and Java with those concurrent requests
I guess the event translation step is not needed but I don't see what this gives you over what many of us do today: shove Hono/Express/Fastify into a lambda with some shim/adapter.
It annoys me that when I started with Lambda (2019-ish?) it (at least seemed to) advised against this. I went down the "one function per route/method" path but always disliked it and it added a decent amount of complexity for packaging/deploying. A year or so ago I abandoned that and switched to Fastify (one function instead of 100+) and never looked back. It also makes it easier to test in dev/local and gives me more flexibility to move to a different host in the future.
Weird to see them come around on this but again, what does this give me over what I currently do? It looks like they are just making migrating an existing stack easier (it wasn't that difficult before IMHO).
This looks suspiciously like Vercel's fluid compute..
Lambda can have its place in some architectures. I am not a fan of them in general, I've seen enough giant webs of lambdas that become impossible to truly understand the full architecture as they are split across 100 repos, just a web of slop lambdas. This feels like a canary in a coal mine, if you need this, you really need to start migrating to a standalone service on a machine instead of a lambda, where you are using it wrong.
[flagged]
[dead]
I've written up how they work in practice: https://aws.amazon.com/blogs/compute/exploring-aws-lambda-we... We also have a selection of code samples to try it: https://serverlessland.com/patterns?services=lambda-web-func...