Deploy a Hono backend on AWS Lambda without an adapter layer

Moving a Hono backend to AWS Lambda Web Functions simplifies deployment by allowing the app to run a Node.js web server directly without an adapter layer. However, not all Lambda apps are suitable for this deployment model. Before moving a SaaS backend, thoroughly evaluate factors such as the app's startup behavior, endpoint authentication, available regions, and the impact of CPU work, waiting, memory, and data transfer on costs.

A traditional Lambda Event Function operates around an invocation handler, receiving an event, running the handler, and returning a response. In contrast, a Web Function runs a standard Node.js HTTP server listening on a port, using the AWS_LAMBDA_HTTP_ENDPOINT environment variable to obtain the endpoint address. The application can retain its framework's routing and middleware, eliminating the need for request translation.

AWS supports Node.js 24 on Arm64 for Web Functions, with Express, Fastify, and Hono able to run without adapters. Next.js in standalone mode requires a small entry file to set its host and port. The service manages immutable revisions of code and configuration, along with one or more endpoints that route traffic to revisions, making the endpoint and revision crucial deployment elements.

Before packaging the web server, inspect the app's entry point to ensure it starts a single server process and listens on a port, rather than relying on development-only commands, local reverse proxies, or platform-specific adapters. Verify that the server uses the runtime-provided address at runtime, rather than binding to a fixed port or host.

Run the production build locally, confirming the app starts with the intended runtime and environment variables. Test routes that involve streaming, long-lived connections, large request bodies, file handling, and database access. While a basic "hello world" endpoint can confirm the endpoint responds, it may not validate the behavior of the real API.

Measure concurrency by testing paths that create the most contention, such as routes that hold database connections, perform CPU-intensive transformations, or stream responses, and gradually increase load while monitoring latency percentiles, errors, open database connections, and environment count. Ensure per-request state remains isolated, avoiding mutable module-level state that can be shared across concurrent requests.

When estimating costs, consider charges based on requests, active CPU time, memory consumed over the environment's lifetime, and data transfer. Waiting on databases or APIs consumes little CPU but contributes to memory usage. Build a cost worksheet based on representative periods, accounting for request volume, CPU-active time, memory configuration, environment lifetime, and data transfer.

Include retries, background work, and streaming duration if applicable. Compare the total cost with your existing host using the same user load and response behavior. Remember that long-lived or mostly idle processes, large memory settings, high request counts, and outbound traffic can significantly influence costs. Finally, decide how users will reach the endpoint, considering AWS provides authentication types such as ApplicationManaged or IamAuth.

Choose the appropriate authentication method based on the callers, as an HTTPS URL does not guarantee private access.