re:Invent 2025 - Supercharge Lambda with Hono: The lightweight web framework

Building a web API on Lambda is straightforward in concept, but teams frequently run into the same friction: the Lambda handler event shape doesn't match standard request-response patterns, routing logic has to be assembled manually, and the developer experience lags behind traditional web frameworks. Jo Matsuda, Prototyping Solutions Architect for Public Sector, Japan at AWS, presented session CNS374 at re:Invent 2025 to address exactly this gap. In this post, we'll walk through how Hono maps onto Lambda, how to structure a project for both local development and deployment, and which plugins cover the most common production requirements.

The traditional approach routes traffic through Amazon API Gateway to multiple single-purpose Lambda functions. This works well for teams with strong service boundaries and clear ownership, but for developers coming from Express or similar web frameworks, the mental model is a mismatch. Routing lives at the infrastructure layer, and logic is spread across functions rather than colocated in one place. The alternative is the Lambdalith pattern, where a single Lambda function handles all routing internally, often paired with Lambda Function URLs for a direct HTTPS endpoint. This feels closer to a traditional web server, but you still end up writing error handling, validation, and request parsing from scratch. Hono addresses all of these friction points without adding significant overhead.

Getting started with Hono on Lambda

Hono's API will feel immediately familiar if you have written any Express-style code. A minimal app defines routes using app.get and app.post, reads request bodies with c.req.json(), and sends responses with c.json(). The same app runs on Node.js, Deno, Bun, and AWS Lambda without code changes because Hono abstracts the runtime underneath. On Lambda specifically, the only change is two lines: import the handle function from the @hono/aws-lambda package and wrap the app with it to produce a standard Lambda handler export.

The project structure Jo recommends for teams that want to develop locally and deploy to Lambda keeps three small files. The first file, app.ts, contains domain logic and exports the Hono app object. The second file, handler.ts, imports the app and re-exports it as a Lambda handler using the adapter. The third file, index.ts, imports the same app and runs it as a Node.js server using the hono/node-server adapter. During local development, running tsx index.ts --watch starts a live server. At deploy time, the build tool points at handler.ts instead. This structure means you never maintain two versions of the same routing logic.

Because the Hono app itself is runtime-agnostic, teams that later want to move away from Lambda can point the index.ts entry point at a container runtime and deploy to Amazon Elastic Container Service (Amazon ECS) without touching app.ts. The routing and business logic travel with the app, not with the infrastructure adapter.

A rich ecosystem for production needs

Most production APIs need three things beyond basic routing: typed input validation, an OpenAPI (Application Programming Interface) specification, and a type-safe client for frontend code. Hono covers all three with first-party plugins.

The hono/zod-openapi plugin integrates with Zod, a popular TypeScript schema validation library, to generate an OpenAPI 3.x specification directly from your route definitions. Instead of the normal Hono class, you import OpenAPIHono and replace app.get with app.openapi, passing a route object created by createRoute that includes the path and request/response schemas. One call to app.doc registers the /openapi.json endpoint, and the spec is always in sync with what the server actually serves. You can feed this spec to code generators, documentation tools, or a large language model (LLM) to scaffold a frontend. Because the schema and the implementation live in the same place, there is no drift between documentation and behavior.

For interactive documentation, the @scalar/hono-api-reference plugin adds a single route that renders the OpenAPI spec as a browsable UI. From that UI, you can call the API directly in the browser and copy ready-to-use code snippets in Node.js, Python, PHP, and other languages. This removes the manual step of opening a separate tool like Postman to test a freshly deployed endpoint.

The most powerful feature Jo demonstrated is Hono RPC, also called Hono Client. With Hono RPC, you export the TypeScript type of your server-side routes and import it into the frontend. Passing that type to the hc (Hono client) function gives you a fully typed HTTP client with autocompletion: calling client.hello.get() shows only the routes that actually exist on the server. If you change a route parameter name or response shape on the server, TypeScript reports the mismatch in the frontend code before any network call happens. In a monorepo where the Lambda function and the frontend share a TypeScript project, this eliminates an entire category of runtime errors caused by mismatched API contracts.

Jo also briefly covered additional plugins available for common patterns: hono/oauth-providers handles authentication flows, and the hono/mcp plugin lets you build a Model Context Protocol (MCP) server with Hono routing directly. The MCP plugin is worth noting because it lets teams expose tools to LLM-based agents using the same framework they already use for REST APIs, without a separate service.

Bundle size and cold starts

One of the most frequent concerns about adding a framework to a Lambda function is the effect on cold start times. Lambda cold starts are directly influenced by how much code the runtime has to initialize, so bundle size matters. Hono's core is around 12 KB, and because it has no heavy dependencies, the final deployment artifact stays small. Jo compared this to the Lambda Web Adapter approach, where an existing application written in another language or framework is wrapped without code changes. If your team is starting a new TypeScript project, Hono on Lambda gives you a better developer experience and a smaller bundle. If you have an existing application you want to run on Lambda without rewriting it, Lambda Web Adapter is the practical path. The two tools address different starting points rather than competing directly.

Hono on Lambda removes the friction that teams face when building web APIs in a serverless environment. You get an Express-style routing experience, runtime portability that supports local development and container deployments, a type system that catches API contract errors at compile time, and a bundle small enough to keep cold start impact low. Jo's session showed that the gap between "familiar web framework" and "production Lambda function" is narrower than it looks, and most of it closes with two lines of adapter code.

To explore Hono for your own projects, start at hono.dev and check the @hono/aws-lambda package for the Lambda-specific adapter. The full session recording is available below.

Session recording: CNS374 - Supercharge Lambda with Hono: The lightweight web framework