Lambda Web FunctionsをHonoでも試してみた

Hono単体とHono＋ConnectRPCを、同じLambda Web Functionsの設定で検証しました。GET・POSTとRPCの正常系・入力エラーを、36回の実測とログで比べます。

Series: Try Lambda Web Functions (4 articles)

1
Lambda Web FunctionsでHTTP serverを動かしてみる
2
Lambda Web FunctionsをHonoでも試してみた This article
3
Lambda Web FunctionsでHonoの実用パターンと設定の境界を検証する

Shiro Seike

Senior Evangelist

Published Oct 13, 2026

Last modified Oct 13, 2026

Lambda Web Functionsで、Hono単体とHono＋ConnectRPCを試しました。GET・POSTのJSON応答と、RPCの成功・入力エラーを確認できました。
今回は「HonoのHTTP APIとRPCを、同じHTTP serverで動かせるか」を確かめます。検証は2026年10月13日に東京regionで行いました。
HonoをHTTP serverとして動かすWeb Functionsは、portで待ち受けるHTTP serverを動かします。 AWSの概要 にある通り、HTTPSと実行環境の管理をAWSへ任せます。アプリケーションはrouteと応答を持ちます。
Honoには、 Node.js Adapter を使いました。起動部分を示します。 createHonoApp と startServer は今回の共通処理です。
TypeScript
import { getRequestListener } from "@hono/node-server";
import { createHonoApp, startServer } from "./common.js";
﻿
const app = createHonoApp("hono-simple");
startServer(getRequestListener(app.fetch), "hono-simple");
 startServer は AWS_LAMBDA_HTTP_ENDPOINT のhost・portで待ち受けます。GET  /hello?name=Hono とPOST  /hello で {"message":"Hello, Hono!"} を返します。nameは1〜32文字の英数字・ _ ・ - に限定しました。
2つの構成を同じ条件で比べる構成ごとに別のWeb FunctionとコードZIPを用意しました。比較に使ったendpointの設定は同じです。
項目
両構成の設定
Region
ap-northeast-1
Runtime
nodejs24.x / 実際のNode.jsはv24.21.0、arm64
Endpoint
HomeRegion / IamAuth
環境内の同時処理上限
8
環境数の上限 / rateLimit
2 / 100 requests/s
Request timeout
3秒
Honoは4.13.13、 @hono/node-server は2.1.4です。Connectの両packageは2.2.0、Protocol Buffersのruntime・生成toolは2.16.0です。 runtime一覧 を確認し、SupportedのNode.js 24を選びました。
﻿
﻿
図は、環境内の同時処理上限を8にした2構成です。
ConnectRPCを組み込むConnectRPCは、schemaからRPC APIを作り、呼び出すライブラリ群です。Protocol Buffersで GreeterService.Greet を定義しました。1つの要求に1つの応答を返すunary RPCで、nameを受けてmessageを返します。
公式の Connect Node.js Adapter でRPCを先に処理し、未登録のpathは fallback からHonoへ渡します。同じNode.js HTTP serverで2つのAdapterをつなぎました。
 validName は、Honoと同じnameの規則を調べる自作関数です。RPC handlerでも、規則に合わない値を拒否します。
TypeScript
router.service(GreeterService, {
  greet: (request) => {
    if (!validName(request.name)) {
      throw new ConnectError("invalid name", Code.InvalidArgument);
    }
    return { message: `Hello, ${request.name}!` };
  },
});
抜粋では観測用ログを省きました。Adapterは connect: true 、 grpc: false 、 grpcWeb: false です。RPCはHonoのmiddlewareを通らないので、入力検査も別に置きます。
正常系と入力エラーをAWSで確認する両構成へ各入力を2回ずつ送りました。自動retryは使いません。RPCはPOST  /lab.v1.GreeterService/Greet へJSONを送り、 Connect-Protocol-Version: 1 を付けました。
入力
Hono単体
Hono＋ConnectRPC
GET /hello、name=Hono
200
200
POST /hello、name=Hono
200
200
GET /hello、空のname
400
400
POST /hello、壊れたJSON
400
400
未登録の/missing
404
404
RPC、name=Hono
404
200
RPC、空のname
404
400
RPC、壊れたJSON
404
400
healthの4回を含めて合計36回です。各ケースは2回とも同じstatusでした。成功したHTTP APIとRPCは Hello, Hono! を返しました。
﻿
﻿
 rest_get ・ rest_post が正常系、 rest_empty ・ rest_malformed が入力エラーです。 requests は各2回を示します。
﻿
﻿
RPCの空nameと壊れたJSONは、どちらも invalid_argument を含む400でした。前者はhandler、後者はConnectのJSON decodingで拒否します。Hono単体はRPCが未登録なので、どちらも404です。ログとclientのrequest IDも照合しました。
まとめHonoのHTTP routeを保ったままConnectRPCを加えられました。今回のHTTP APIだけならHono単体で作れます。RPCのschemaを共有したい場合はConnectを加える構成を検討できます。その分、schema・生成コード・RPCの入力検査を管理します。
ただし、 Web FunctionsのHTTP仕様 はHTTP/1.1です。native gRPCやstreaming RPCは試していません。HTTP/2が必須なら、入口の対応から別の構成を検討します。性能や費用の優劣も、この検証では判断できません。

項目	両構成の設定
Region	ap-northeast-1
Runtime	nodejs24.x / 実際のNode.jsはv24.21.0、arm64
Endpoint	HomeRegion / IamAuth
環境内の同時処理上限	8
環境数の上限 / rateLimit	2 / 100 requests/s
Request timeout	3秒

入力	Hono単体	Hono＋ConnectRPC
GET /hello、name=Hono	200	200
POST /hello、name=Hono	200	200
GET /hello、空のname	400	400
POST /hello、壊れたJSON	400	400
未登録の/missing	404	404
RPC、name=Hono	404	200
RPC、空のname	404	400
RPC、壊れたJSON	404	400