Run Existing Web Apps on AWS Lambda With Almost No Refactoring
The Lambda Web Adapter, published by AWS as a public‑facing open‑source project, acts as a thin HTTP proxy that translates Lambda invocation events into ordinary HTTP requests for the underlying application. By copying the binary from the public.ecr.aws/awsguru/aws-lambda-adapter:1.0.1 image into a custom container (e.g., public.ecr.aws/lambda/nodejs:24) and exposing the app on a port defined by AWS_LWA_PORT, developers can deploy a Node, Python, or other language service without refactoring its request handling. The article demonstrates a minimal Dockerfile that builds a production‑ready image, adds the adapter to /opt/extensions, and runs the app directly. Packaging options remain flexible: a simple ZIP (max 250 MB unzipped), an S3‑hosted ZIP for larger bundles, or a full Docker image up to 10 GB for complex OS‑level dependencies. Once deployed, the function can be exposed via a Lambda Function URL for quick, cost‑free HTTPS access, or via an HTTP API Gateway when custom domains, throttling, or authorizers are needed. The write‑up stresses Lambda’s per‑invocation billing, generous free tier, and the need to keep images lean to mitigate cold‑start latency, while noting that provisioned concurrency and reserved concurrency can be used to smooth traffic spikes.
This approach reflects a broader industry push to lower the barrier for serverless adoption. By allowing container‑style packaging and preserving existing web frameworks, AWS blurs the line between traditional VM‑based deployments and fully managed functions‑as‑a‑service. Competitors such as Azure Functions and Google Cloud Run have offered similar “run any container” capabilities, but AWS’s explicit adapter layer simplifies the translation step and leverages its massive Lambda ecosystem (including Function URLs introduced in 2022). The move also aligns with the trend of “micro‑VM” runtimes that aim to combine the isolation of containers with the rapid scaling of serverless, encouraging developers to migrate idle or spiky workloads without rewriting business logic.
The main risks lie in Lambda’s inherent limits: a maximum execution time of 15 minutes, single‑request concurrency per reserved slot, and potential cold‑start penalties for large images. Teams must monitor concurrency quotas to avoid throttling, especially when using the adapter in high‑throughput APIs. Additionally, the adapter adds a layer that could surface debugging complexity if HTTP semantics are altered. Future watch points include AWS’s roadmap for extending the adapter to support WebSockets or larger payloads, and how pricing for Function URLs and API Gateway evolves as serverless usage scales.
Key Takeaways
The Lambda Web Adapter enables existing FastAPI, Express, Django, and Fastify apps to run on Lambda with only a container‑level change, no source‑code rewrite.
Packaging flexibility ranges from 250 MB ZIP files to 10 GB Docker images, letting teams choose the simplest method that meets their dependency needs.
Function URLs provide instant HTTPS endpoints, while API Gateway adds features like custom domains and throttling for production‑grade services.
Developers must keep container images small and manage concurrency settings to avoid cold‑start delays and request throttling under Lambda’s execution limits.
About the Source
This analysis is based on reporting by HackerNoon. Here is a short excerpt for context:
You can deploy your async app to AWS Lambda without refactoring using the AWS Lambda Web Adapter, a small proxy that translates events into HTTP requests.Read the original at HackerNoon
