🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Supercharge Lambda with Hono: The lightweight web framework (CNS374)
In this video, Jo Matsuda, a Prototyping Solutions Architect at AWS Japan, demonstrates how Hono, a TypeScript web framework, brings familiar web development patterns to AWS Lambda. He addresses common friction points when deploying web apps on Lambda, such as unfamiliar event shapes and routing complexity. Hono provides Express-like syntax, runtime abstraction across multiple environments, and requires only two lines of code to convert a Hono app into a Lambda handler. Key features include the Hono OpenAPI plugin for automatic schema generation from Zod, Hono RPC (Hono Client) for end-to-end type safety with IDE autocomplete, and a lightweight bundle size of around 12 kilobytes to minimize cold starts. The framework supports a monorepo structure with shared types between server and client, enabling TypeScript type checking before network calls. Matsuda recommends Hono for new TypeScript projects prioritizing developer experience, while suggesting Lambda Web Adapter for migrating existing applications in other languages.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Understanding the Challenge: Why Hono for AWS Lambda?
Hello, everyone. Thanks for joining "Supercharge Lambda with Hono." In the next 20 minutes, I'll show how Hono brings familiar TypeScript web patterns to AWS Lambda. I'll cover things like end-to-end type RPC, production-ready structure, and more. Let's get started.
This is my first time at re:Invent. Are there any first-time re:Invent attendees here? Thank you so much. Let me begin by introducing myself. I'm Jo Matsuda, Prototyping Solutions Architect for Public Sector, Japan, and the framework I'm about to introduce, Hono, is also made in Japan. Day to day, I work with customers to build and validate prototypes on AWS. I spend a lot of time with React, TypeScript, and Hono. What I'll share today comes directly from what our prototyping team does.
Here is the agenda for this talk about Hono for Lambda. First, I'll explain why Hono for Lambda. Second, I'll provide a quick overview of Hono, what it looks like, and how it runs on Lambda. Finally, I'll explain Hono's strengths. Please note that we won't cover the detailed architecture of Hono itself.
Let me begin with a sentence I hear again and again: "I want to deploy a web app or API on Lambda." Does this resonate with you, or have you heard the same from your teammates or customers? There are a couple of paths people take first. I'll walk through them so we can see where the friction comes from and how Hono helps.
First, there's the traditional approach, routing through API Gateway with multiple Lambda functions behind it. It's great for isolation and clear ownership. However, for teams coming from traditional web frameworks, this model can feel a bit foreign. Routing lives at the edge, and logic is split across multiple functions.
On the other hand, we increasingly see the Lambdalith pattern. Do you know the Lambdalith pattern? It's one Lambda that owns routing and multiple functionalities. This is often paired with Lambda Function URL. With Lambda Function URL, you can go even simpler with a direct HTTP endpoint. The right choice depends on your team boundary, team size, or scaling needs.
Regardless of the route you take, there's still some friction. Lambda's event shape is not familiar with the standard request-response pattern you expect. The routing and glue code, like error handling, often end up being built from scratch. Finally, there's the ecosystem gap. Even with great services like Lambda Powertools or API Gateway, it's not so common to build and run web applications on Lambda compared to container-based stacks. If that sounds familiar, you're in the right room.
To address the friction we just saw, I want to put Hono on the table. Hono gives us an Express-like request-response syntax you expect and an Express-like developer experience with TypeScript files. From here, I'll start with the minimal possible Hono setup and show how it runs on Lambda, how we structure the project, and which plugins cover production needs.
This is a minimal possible Hono app. You can see upload GET and upload POST. This API follows conventional web framework patterns like Express.
If you haven't used Express before and you have a web application, you can immediately guess what's happening. The response returns JSON, and the request JSON leads to the liquid body. Does it seem easy now? Why does Hono pair well with Lambda?
Hono's Core Strengths: Runtime Abstraction, Rich Ecosystem, and Type-Safe Development
Let me highlight three representative reasons, not an exhaustive list. First, runtime abstraction. Once you write one Hono app, it runs across multiple runtimes. Second, the ecosystem. Hono has many plugins and middlewares that cover production needs. Third, it's lightweight by default, which means you can keep your code bundle small. Especially for Lambda, you can reduce the cold start impact.
Let's check Hono's runtime abstraction. Hono's runtime abstraction looks like this: one Hono app at the top and underneath is the environment. Node.js, Deno, Lambda, and plenty more runtimes are supported with Hono. With the Node.js adapter, you can locally spin up the dev server and deploy it to container-based stacks like ECS. Of course, you can use the AWS Lambda adapter with AWS Lambda. Because the Hono app is the same everywhere, you don't need to fork or rewrite code per environment.
Let's check the code changes to run Hono on Lambda. The code change is tiny, just a few lines. You should import handle from the Hono AWS runtime package and wrap it up with it. Just adding two lines turns the Hono app into a Lambda handler. At this moment, your Hono app works as a first-class runtime on Lambda.
We've just seen that turning a Hono app into a Lambda handler takes just two lines. Building on that runtime abstraction, the project structure I recommend for debugging Lambda locally is like this. I actually use this for daily prototyping work. I keep three small files. First, in app.ts, I write the domain logic and expose the Hono app itself. The second file, handler.ts, imports the Hono app from app.ts and exports it as a Lambda handler with the Hono and Lambda package we just saw. Finally, index.ts also imports the Hono app from app.ts and runs it as a Node.js server with the Hono Node server plugin.
In day-to-day work, I just run tsx index.ts with watch, which gives me a local dev server. When it's time to ship, I point to handler.ts and pack it for deployment to Lambda.
Next is the Hono ecosystem. Hono's ecosystem covers the production needs most teams ask for. For documentation, there's Hono OpenAPI, which generates an OpenAPI schema from Zod. Zod is a very famous library for input validation in the TypeScript ecosystem. If you want end-to-end types, you can use Hono RPC, also called Hono Client, which generates a typed HTTP client from server-side code. If you just want to validate input data without an OpenAPI schema, you can use Hono validator for simple type-safe validation. If you need authentication, there are plenty of plugins available.
Lately, some people have expressed interest in building their own MCP server. With Hono, you can use the Hono MCP plugin and easily build an MCP server with Hono using this plugin. We'll dive deep into two plugins: Hono's OpenAPI and Hono Client.
First, let's check the Hono OpenAPI plugin. On this page, you can have an OpenAPI.json file. Let's look at the code diff. You import OpenAPI from Hono instead of normal Hono and use it as a Hono app instead of normal Hono. You should replace the app.get into OpenAPI and arrow root. Arrow root is a return value from the createRoot function, and it includes the path and the schema.
Publishing is simple. At a single place, you can have an OpenAPI.json file like this. This works out of the box, so you can use it with client SDK generators or documentation sites. Lately, you can even feed it to an LLM to spin up a simple front end. The key is that the schema is always in sync with what the server serves.
In the next slide, I'll introduce one more plugin: Scalar Hono API Reference. With this plugin, you can see the OpenAPI as an interactive UI provided by Scalar. You just add app.getScalar. In this UI, you can call the API directly, and you can copy hardcoded examples in Ruby, Node.js, PHP, Python, and so on. This allows you to test your API easily from here.
The next one is Hono RPC, also called Hono Client. This is a video clip I'll play once and rewind to the key moment. I type a constant and we call await client.hello.$get. The key moment is here. When I type client and hello, the IDE offers completion suggestions like hello or delegate. This is not a guess, but a contract.
Let's check how Hono RPC works. If you want to use Hono RPC, your project structure looks like this: the lambda directory has the server-side code and the frontend directory has the front-end code. You export the app type from app.ts, which is the server-side code. The type of routes means the type of all the app subroutes. The client.ts imports the app type and passes it to hc, which is the abbreviation for Hono Client. This is designed to be used in a monorepo structure. The autocomplete we just saw is not a guess, but a contract based on the shared types between server and client.
It works as a TypeScript type check. So if I pass a long parameter or request parameter, the ID or compiler catches it before any network calls. This is a great update for our daily development work.
Lightweight Performance and Practical Recommendations for Lambda Deployment
Finally, we just saw three things: Express-like friendly syntax, runtime abstraction, and a rich ecosystem. With all that, Hono is the right way. Of course, our final size depends on your code and your dependencies. The best Hono package is around 10 kilobytes.
Before we wrap up, let's address a potential question: a comparison with Lambda Web Adapter. The main differences are shown here. I won't read through them all, but if we want to prioritize developer experience or start building a new app with TypeScript, I recommend Hono with Lambda. On the other hand, if you have already built a web application running on other languages or other frameworks and you want to migrate it, I recommend you run the web adapter.
So, a quick wrap-up: with Hono on Lambda, you get a familiar developer experience with Express-like routing and web framework ergonomics. A Hono app is portable, so if we want to move away from Lambda, you can easily go to a container-based stack or EC2 or something like that. Hono has an abundant ecosystem. I just introduced two plugins, but there are plenty more, so I'm sure there's something you want. And it's still lightweight. A baseline bundle is around 12 kilobytes, so the cold-start impact stays small. You can try Hono Lambda after this session.
Thank you for joining us. Please complete the session survey in the mobile app. Thank you for joining.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)