AWS Lambda Web Functions

Original Article ↗ Hacker News Discussion ↗

AWS has introduced Lambda Web Functions, a new way to run traditional HTTP web apps directly on Lambda with support for concurrent requests, scale-to-zero, and CPU-based billing, positioning it as an answer to platforms like Cloudflare Workers, Vercel, and Cloud Run. Commenters debate trade-offs between functions-as-a-service and container-based approaches, focusing on cold starts, pricing transparency, complexity of distributed architectures, and runtime limitations such as current Node.js-only support. Many see it as an overdue move toward more “normal” web hosting on AWS, while noting that alternatives like Cloud Run and Azure Container Apps already offer similar capabilities with containers.

Cold starts, scaling & concurrency

  • Lambda Web Functions still scale to zero; first request after idle is a cold start.
  • New multi-concurrency model allows up to ~128 concurrent requests per environment; bursts amortize cold starts for subsequent requests.
  • Some see this as “absolute tail” latency only after idle; others warn that cold starts and scaling limits can still cause multi‑second delays, especially without provisioning.

Comparison to other platforms

  • Widely read as a response to Cloudflare Workers, Vercel, Cloud Run, Azure Container Apps, App Engine.
  • Similarities: scale-to-zero, concurrency per instance, no adapter for standard web apps, request-based billing.
  • Differences: built on Firecracker microVMs vs Cloudflare’s V8 isolates. Some argue isolates are more disruptive but harder for big clouds to adopt.
  • Several comments emphasize Cloud Run / Container Apps as prior art: deploy any container, get autoscaling, often with simpler DX than classic Lambda.

Runtime, language support & roadmap

  • Currently Node.js-only; commenters want Rust/Go/.NET/Java and generic containers or WASM.
  • SnapStart can reduce cold starts, but support varies by runtime and is seen as complex.
  • AWS roadmap (linked in thread) shows container-image support for Web Functions as “coming soon,” viewed as a potential killer feature.

Pricing & billing semantics

  • New “active CPU” billing is likened to Cloudflare Workers and Vercel Fluid: you don’t pay while just waiting on I/O.
  • Memory is still billed for the life of the warm environment; data transfer and per-request charges also matter.
  • Some feel Cloudflare’s simpler pricing remains more understandable.

Architectural debate: FaaS vs containers/VMs

  • Critics: FaaS makes systems harder to reason about, encourages over-fragmented microservices, complicates dev/debug/monitoring, and has awkward scaling semantics.
  • Supporters: Lambdas are trivial to use with IaC, ideal for sparse or highly bursty workloads, and can be very cheap or effectively free for small apps.
  • Several advocate monolithic Lambdas or serverless containers (Cloud Run/Container Apps/Fargate-style) over many small functions.

Developer experience

  • Many welcome “Lambda without the adapter layer,” especially compared to prior patterns (API Gateway + adapters for Express/Fastify, etc.).
  • Others note this was already achievable with shims, so the main benefit is first-class support and concurrency, not entirely new capability.