Free tools Windows power users keep installed
One-click scans. No signup required.
You can run a compatible legacy web application on AWS Lambda without changing its application source by using the AWS Lambda Web Adapter. It bridges Lambda invocations to the app’s existing HTTP server. The AWS Lambda Web Adapter User Guide describes this as running web applications on Lambda “with zero code changes,” but that means no application-code edits—not zero packaging, deployment, or configuration work.
Which connection method fits a legacy application?
Start with the interface the application already uses. An HTTP server, a Lambda handler, and a queue or stream consumer need different integration paths; API Gateway alone does not turn an arbitrary legacy executable into a Lambda-compatible function.
As an Amazon Associate I earn from qualifying purchases.
| Path | Best fit | What stays unchanged | What you add or configure | Main trade-off |
|---|---|---|---|---|
| AWS Lambda Web Adapter | An existing application that serves HTTP | Application source code, if the app fits the adapter’s runtime and deployment model | Packaging or container setup, adapter extension, startup/readiness and port configuration, and Lambda deployment | Keeps the HTTP app model but introduces Lambda and adapter configuration requirements. AWS Lambda Web Adapter User Guide |
| API Gateway proxy integration | A Lambda handler that can process API Gateway events | The client-facing HTTP request can remain conventional | Route and method integration, invoke permission, and a handler that accepts the event and returns the expected response format | Less mapping configuration, but the function must meet API Gateway’s event and response contract. API Gateway proxy integration documentation |
| API Gateway custom integration | A Lambda handler whose expected input or output differs from the API request or response | The client API shape can be retained | Explicit request and response mappings | More control over translation, with additional mapping configuration. API Gateway Lambda integration documentation |
| Queue or stream event source mapping | Background work initiated by messages or stream records | The producer/consumer boundary can avoid a synchronous HTTP call | Source integration, batch and error/retry settings, and idempotent processing | Delivery is at least once, so duplicate processing must be safe. Lambda event source mapping documentation |
How the Lambda Web Adapter connects an HTTP app
Lambda invokes functions through its own invocation mechanism; a traditional web server expects HTTP requests. The Lambda Web Adapter runs as a Lambda extension, starts alongside the application, checks whether the application is ready, forwards incoming Lambda events to it as HTTP requests, and converts the app’s HTTP response into a Lambda response. This bridge is why a compatible HTTP application can keep its source code unchanged. See the adapter’s introduction.
Recommended Free Tools
“Zero code changes” does not mean “drop the app into Lambda and do nothing else.” The application still needs to be packaged and deployed in a compatible way, and its startup, readiness behavior, and listening port must be configured for the adapter. Lambda permissions, networking, timeouts, and other operational settings also remain deployment concerns. The available adapter guidance does not establish compatibility for every framework, operating-system dependency, architecture, or state model.
#1 Best Overall
When API Gateway is the right bridge
API Gateway is appropriate when an HTTP API should invoke a Lambda handler. It passes request information to Lambda in an event representation; it does not directly host or adapt a standalone legacy HTTP server. AWS also requires permission for API Gateway to invoke the function. See AWS’s API Gateway invocation guidance.
Proxy integration
With proxy integration, API Gateway passes request details in a structured event. The Lambda handler must consume that event and return the response format API Gateway expects. A legacy HTTP server that only listens for HTTP requests does not automatically satisfy this handler contract; it needs a bridge or adaptation layer. Details are in the proxy integration documentation.
Custom integration
Custom integration lets you define mappings that translate the incoming API request for the function and translate the function’s output into the API response. Choose it when the handler’s input or output shape differs from the API’s, and account for the additional mapping configuration. The Lambda integration guide describes both integration approaches.
How to choose and prepare the integration
- Identify how the application receives work. For an existing HTTP server, evaluate the Lambda Web Adapter. For a Lambda handler called through an HTTP API, evaluate API Gateway. For background work arriving through a supported queue or stream, evaluate an event source mapping.
- Define “without changing code.” Confirm that source edits are off limits but packaging, adding an adapter extension, configuring infrastructure, and changing deployment settings are acceptable. The adapter’s zero-code-change claim concerns application code, not the surrounding deployment.
- Match the API Gateway integration to the handler. Use proxy integration if the handler can process the documented event and return the required proxy response. Use custom integration if request and response mappings are needed.
- Design asynchronous processing for duplicates. If a queue or stream invokes the function, make processing idempotent before migration. Event source mappings deliver records at least once, so an event may be processed more than once. Consult AWS’s event source mapping guidance.
- Validate the specific application in its target deployment. Check runtime and dependency compatibility, startup and readiness, port behavior, state assumptions, network access, permissions, and timeout needs. The cited guidance does not certify any particular legacy application or workload.
What “no code changes” does—and does not—promise
For a compatible HTTP application, the adapter offers a path to preserve application source while Lambda handles invocation through an HTTP bridge. It does not establish that every legacy app can run unchanged, nor does it eliminate the need to package, configure, deploy, and operate the function. If the application instead exposes a Lambda handler or consumes queue/stream events, use the integration path that matches that interface rather than assuming an HTTP adapter is appropriate.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
