はじめに
こんにちは、ニシグチです。
今回は Lambda Web Adapter（LWA） について調べてみました。
私はこの機能について知らなかったので自分の理解を深めることを兼ねて記事を書きます。
Lambda Web Adapterとは？
Lambda Web Adapter（以下、LWA）とは、Express.js、Next.js、Flask、FastAPI、SpringBoot、ASP.NET、Laravel など、HTTP 1.1/1.0 に対応した既存のWebアプリケーションをコード変更なしでそのままAWS Lambda上で実行できるようにするツールです。
従来の課題：LambdaとWebフレームワークの「形式のズレ」
例えば、FastAPIで以下のようなエンドポイントを作成したとします。
Python
# FastAPIの例
@app.get("/")
def read_root():
return {"message": "Hello"}
一見すると単なる辞書データ {"message": "Hello"} を返しているように見えますが、裏側ではWebサーバー（Uvicornなど）やフレームワークが自動的に以下のような標準的なHTTPレスポンス形式に変換して返しています。
HTTP
HTTP/1.1 200 OK
Content-Type: application/json
{"message": "Hello"}
しかし、AWS Lambdaが求めているレスポンス形式はこれとは異なります（JSONオブジェクトで statusCode や headers、body を持つ特定の構造が必要）。そのため、Webフレームワークで作ったアプリを単純にLambda上に持ってきてもそのままでは動作しません。
従来の解決策とそのデメリット
そこで以前は、フレームワークとLambdaの間に入って入出力を相互変換してくれるライブラリを使っていました。
- Express.jsの場合：serverless-express
- FastAPIの場合：Mangum
これらを使うことでLambda上で動かせるようになりますが、「Lambda専用のコード」になってしまい、ポータビリティ（可搬性）が失われるというデメリットがありました。将来的にECSや他のクラウド、オンプレミス環境へ移行しようとした際、コードの書き換えが発生してしまうためです。
LWAが解決すること
ここで登場するのが Lambda Web Adapter（LWA） です。
LWAは、Lambdaの拡張機能（Lambda Extension）として動作し、アプリ側に専用ライブラリを組み込むことなく、HTTPリクエスト/レスポンスとLambdaのイベント構造を自動で透過的に変換してくれます。
LWAを使うメリット
1. アプリケーションコードの書き換えが不要
Lambda固有のライブラリ（serverless-express や Mangum など）に依存しなくなります。コードの変更が不要になるため、他環境へのポータビリティが保たれ、保守性も向上します。
2. ローカル開発・デバッグが非常に楽になる
SAM CLIのエミュレータ（sam local start-api など）を無理に使う必要がなくなります。ローカル環境で通常通りサーバー（uvicorn や npm run dev など）を起動すれば良いため、VS Code等で普通にブレークポイントを貼ってデバッグを実行可能です。
LWAの導入方法
導入方法は主に2パターンあります。
パターン1：Dockerコンテナで動かす場合
Dockerfile に以下の1行を書き足すだけで適用できます。
Dockerfile
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:1.1.0 /lambda-adapter /opt/extensions/lambda-adapter
パターン2：Zipパッケージで動かす場合
-
Lambdaレイヤーを追加する
- AWSコンソールなどから対象リージョンのLWAレイヤーARNを登録します
-
例 (東京 / x86_64):
arn:aws:lambda:ap-northeast-1:753240598075:layer:LambdaAdapterLayerX86:24
-
環境変数を設定する
-
AWS_LAMBDA_EXEC_WRAPPER:/opt/bootstrap（LWAを起動プロセスに割り込ませる） -
PORT:8080（アプリがリッスンするポート番号）
-
-
通常通りHTTPサーバーを起動する
- コード側は何も変えず、ローカル開発時と同様に
app.listen(8080)などでサーバーを動かすだけで、LWAが自動的にリクエストを仲介してくれます
- コード側は何も変えず、ローカル開発時と同様に
デメリットと注意点（使いどころ）
便利に見えるLWAですが、アーキテクチャ設計時には以下の注意点があります。
-
API Gatewayの29秒制限
- 前段にAPI Gatewayを配置する場合、API Gateway自体のタイムアウト制限（29秒）を受けます。長時間の処理には向きません
-
長時間処理・生成AIアプリとの相性
- 前段に Lambda関数URL（Function URLs） を使用した場合、Lambdaの上限である 最大15分 までの処理が可能になります
- LWAは レスポンスストリーミング（Response Streaming） にも対応しているため、ChatGPTのような生成AIのリアルタイム回答出力（Streaming）を行うWebアプリとも非常に相性が良いです
何でもかんでもLWAでLambda化するのではなく、バックエンドの処理時間や要件に応じて適切に採用するのが良さそうです。
おわりに
今回Lambda Web Adapterについて調べてみて、既存アプリをクラウドネイティブ化する際の障壁が大きく下がっていることを実感しました。AWSにはまだまだ知らない便利機能がたくさんあるので、引き続き勉強を頑張ります！