---
title: "Lambda Web Adapterの使い方｜WebアプリをLambdaで動かす手順とv1.1.0のSnapStart対応"
url: "https://www.issoh.co.jp/tech/details/1917/"
published: 2024-02-06
updated: 2026-10-13
categories: ["AWS"]
publisher: "株式会社一創"
---

# Lambda Web Adapterの使い方｜WebアプリをLambdaで動かす手順とv1.1.0のSnapStart対応

Lambda Web Adapter（LWA）を使うと、Express・FastAPI・Spring BootなどのWebアプリを、Lambda専用のハンドラー関数に書き換えずにAWS Lambdaで動かせます。コンテナ配布ならDockerfileに1行、Zip配布ならレイヤーと環境変数を足すだけです。Node.jsのWebアプリであれば、2026年10月に一般提供が始まったLambda Web FunctionsでLWAを外して動かす選択肢もあります。手順と東京リージョンの料金は[Lambda Web Functionsとは？Expressをそのまま動かす手順と東京リージョンの料金](https://www.issoh.co.jp/tech/details/18319/)で解説しています。

2026年9月にLambda SnapStartがコンテナイメージに対応し、同月18日にはLWA v1.1.0がSnapStart用のフックを追加しました。コンテナイメージで配る関数もSnapStartの対象になり、「起動を速くしたければZipで配る」という選び方は不要になりました。本記事では2026年10月12日時点の公式リポジトリとAWSドキュメントをもとに、2つの配布方法の手順、v1.1.0で増えた設定、Lambdaに載せられないWebアプリの境界値を整理します。

## まとめ：Lambda Web AdapterでWebアプリを動かす要点

- **仕組み**：LWAはLambda拡張として動き、Lambdaのイベントを通常のHTTPリクエストに変換してアプリへ転送します。HTTP/1.1か1.0を話すアプリなら言語を問いません。
- **コンテナ配布**：Dockerfileに `COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:1.1.0 ...` の1行を足します。AWS以外のベースイメージでも動きます。
- **Zip配布**：レイヤー `LambdaAdapterLayerX86:30`（Arm64も30）を付け、`AWS_LAMBDA_EXEC_WRAPPER=/opt/bootstrap` と起動スクリプト（例 `run.sh`）をハンドラーに指定します。
- **SnapStart**：Java 11以降・Python 3.12以降・.NET 8以降で、ZipでもコンテナでもLWAと併用できます。v1.1.0のフックで、スナップショット前に接続を閉じ、復元後に張り直せます。
- **載せられない条件**：同期の要求・応答はそれぞれ6MB、実行は最大900秒です。大きな応答はレスポンスストリーミング（最大200MB）に切り替えます。
- **移行時の注意**：環境変数は `AWS_LWA_` 接頭辞が正です。旧名はv2.0で削除予定で、公式のSpring Boot Zip例はまだ旧名を使っています。

## Lambda Web Adapterの仕組みと動くWebアプリの条件

通常、Lambdaで動くコードは「イベントのJSONを受け取り、レスポンスのJSONを返すハンドラー関数」の形をとります。LWAはこの変換を肩代わりするRust製のバイナリで、[公式リポジトリのREADME](https://github.com/aws/aws-lambda-web-adapter)は対象を「Express.js、Next.js、Flask、SpringBoot、ASP.NET、LaravelなどHTTP 1.1/1.0を話すもの」と書いています。API Gateway（REST API・HTTP API）、Lambda関数URL、Application Load Balancer（ALB）のどれから呼んでも使えます。ただしALB経由では、Lambdaへ渡せる要求本文と、Lambdaが返す応答JSONがそれぞれ1MBまでです。リポジトリは2026年10月時点で `aws/aws-lambda-web-adapter` にあり、AWSドキュメント側のリンクは旧 `awslabs` のままの箇所があります。

### 拡張機能としてHTTPへ変換する経路

LWAは `/opt/extensions` に置かれたLambda拡張として、アプリと同じ実行環境で起動します。起動後はアプリのポート（既定8080）へreadiness check（既定パス `/`）を送り、正常とみなすステータス（既定100〜499）の応答が返った時点で、初期化完了をLambdaへ伝えます。以降はイベントをHTTPリクエストに組み直して `127.0.0.1` のアプリへ転送し、返ってきたHTTPレスポンスをLambdaの応答形式に戻します。アプリ側から見ると、前段にリバースプロキシがいるのと同じです。

このため、同じイメージをEC2・Fargate・手元のDockerでもそのまま実行できます。LambdaでしかテストできないコードをアプリのなかにLambda用の分岐として持たずに済む点が、serverless-expressやServerless Java Containerのような言語別ライブラリとの一番の違いです。

### serverless-expressとの性能差の実測値

間にプロキシが1段挟まる分の遅れは小さいと実測されています。AWSの[builders.flashの検証記事](https://aws.amazon.com/jp/builders-flash/202301/lambda-web-adapter/)では、200msのスリープを入れたExpressアプリを同時実行1,000で約3分間叩き、3構成を比べています。

| 構成                               | 平均レイテンシ | p99レイテンシ | コールドスタート平均 |
| -------------------------------- | ------- | -------- | ---------- |
| serverless-express（Node.jsランタイム） | 203.8ms | 221.7ms  | 226.7ms    |
| serverless-express（コンテナ）         | 203.8ms | 222.6ms  | 306.9ms    |
| LWA（コンテナ）                        | 204.6ms | 226.1ms  | 279ms      |

LWAによる上乗せは平均で0.8ms、p99で3.5ms程度でした。コールドスタートの差は「Zipかコンテナか」で生じており、LWAを入れたこと自体による増加は見られていません。ただしこれは2022年11月時点の実装とExpress（us-east-1）での値です。Spring Bootのように起動の重いフレームワークでは、コールドスタートの大半はアプリ自身の初期化が占めるため、次に述べるSnapStartの有無の方が効きます。

## コンテナイメージで動かす手順

コンテナ配布でLWAを組み込む作業は、Dockerfileに1行足すだけです。イメージのビルドとECRへのプッシュ、関数の作成は通常のコンテナLambdaと同じで、SAMなら `sam build` と `sam deploy --guided` のあと、出力されたURLにアクセスして応答を確かめます。以下はLWAリポジトリの公式例 `examples/fastapi-snapstart` のDockerfileで、AWS提供ではない `python:3.12-slim` をベースにしています。[README](https://github.com/aws/aws-lambda-web-adapter)によると、Runtime Interface ClientをLWAが兼ねるため、AWS以外のベースイメージでも動きます。

```
FROM public.ecr.aws/docker/library/python:3.12-slim
COPY --from=public.ecr.aws/awsguru/aws-lambda-adapter:1.1.0 /lambda-adapter /opt/extensions/lambda-adapter
ENV PORT=8000
WORKDIR /var/task
COPY requirements.txt ./
RUN python -m pip install -r requirements.txt
COPY *.py ./
CMD exec uvicorn --port=$PORT main:app
```

2行目がLWAの追加です。x86\_64とarm64の両方を含むマルチアーキテクチャイメージなので、Graviton（arm64）の関数でも同じ行で済みます。Expressなら `CMD ["node", "index.js"]`、Spring Bootなら `java -jar` の起動コマンドに置き換えるだけで、残りはいつものDockerfileです。アプリは環境変数 `PORT`（または `AWS_LWA_PORT`）で指定したポートで待ち受けてください。Uvicornの待受アドレスは既定で `127.0.0.1` で、同じ実行環境にいるLWAからは届きますが、同じイメージをFargateやローカルのDockerで外へ公開するときは `--host 0.0.0.0` を足す必要があります。FastAPI自体の書き方は[FastAPIとは｜最短で動かす手順とasync/defの使い分け【2026年版】](/tech/details/3859/)で解説しています。

コンテナ配布はイメージ10GBまで入るため、ネイティブライブラリやブラウザエンジンを抱えるアプリに向きます。一方、コールドスタートはZipより長くなりやすく、上の実測ではLWA（コンテナ）の279msがNode.jsランタイムのZip構成（226.7ms）より52.3ms遅れました。

## Zip配布とレイヤーで動かす手順（Spring Bootの例）

Zip配布ではマネージドランタイム（java21やpython3.12など）を使い、LWAをレイヤーとして足します。手順は3つです。

1. レイヤー `arn:aws:lambda:${AWS::Region}:753240598075:layer:LambdaAdapterLayerX86:30`（arm64は `LambdaAdapterLayerArm64:30`）を付ける
2. 環境変数 `AWS_LAMBDA_EXEC_WRAPPER` に `/opt/bootstrap` を設定する
3. ハンドラーにアプリの起動スクリプト（例 `run.sh`）を指定する

Spring Bootの公式例 `examples/springboot-zip` の起動スクリプトは次の1行です。

```
#!/bin/sh

exec java -cp "./:lib/*" "com.amazonaws.demo.petstore.Application" "--server.port=${PORT}"
```

### 公式のSpring Boot Zip例をそのまま使わない理由

この公式例は、2026年10月時点でそのまま写すと古い構成になります。`pom.xml` はSpring Boot 2.4.4・`java.version` 1.8のままで、`template.yaml` はAmazon Linux 2版の `java17` ランタイムと、接頭辞なしの環境変数（`READINESS_CHECK_PATH`・`REMOVE_BASE_PATH`）を使っています。[Lambdaランタイムの一覧](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)では、AL2版の `java17`・`java11`・`java8.al2` は2027年6月30日に廃止予定、`java21`・`java25`・`java17.al2023` は2029年6月30日です。ランタイムをjava21に上げるには、アプリ側もSpring Boot 2.4系からJava 21に対応した版へ上げ、依存ライブラリを含めてビルドが通ることを先に確かめる必要があります。そのうえでテンプレートを書き直すと次の形になります。

```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
  WebAppFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: run.sh
      CodeUri: app/
      Runtime: java21
      MemorySize: 2048
      Timeout: 30
      AutoPublishAlias: live
      SnapStart:
        ApplyOn: PublishedVersions
      Environment:
        Variables:
          AWS_LAMBDA_EXEC_WRAPPER: /opt/bootstrap
          PORT: 8000
          AWS_LWA_READINESS_CHECK_PATH: /actuator/health
          AWS_LWA_READINESS_CHECK_HEALTHY_STATUS: 200-399
          AWS_LWA_REMOVE_BASE_PATH: /v1
      Layers:
        - !Sub arn:aws:lambda:${AWS::Region}:753240598075:layer:LambdaAdapterLayerX86:30
      Events:
        Root:
          Type: HttpApi
          Properties:
            Path: /v1
            Method: ANY
        Proxy:
          Type: HttpApi
          Properties:
            Path: /v1/{proxy+}
            Method: ANY
```

`PORT` は旧名ですが廃止対象ではなく、`AWS_LWA_PORT` が未設定のときの代替として今後も読まれます。readiness checkに `/actuator/health` を使う場合はspring-boot-starter-actuatorが必要です。公開設定は[Spring Boot Actuatorの使い方｜エンドポイント公開設定と監視・診断を実装する](/tech/details/1931/)を参照してください。

## v1.0〜v1.1.0で変わった環境変数と移行の確認点

LWAは2026年3月27日のv1.0.0でGAとなり、5月28日のv1.0.1を経て、9月18日に[v1.1.0](https://github.com/aws/aws-lambda-web-adapter/releases/tag/v1.1.0)が出ました。0.x系の設定を引き継いでいる場合は、次の3点を確認します。

### AWS\_LWA\_接頭辞への改名と削除済みの設定

| 旧名（v2.0で削除予定）              | 新名                                   |
| -------------------------- | ------------------------------------ |
| READINESS\_CHECK\_PORT     | AWS\_LWA\_READINESS\_CHECK\_PORT     |
| READINESS\_CHECK\_PATH     | AWS\_LWA\_READINESS\_CHECK\_PATH     |
| READINESS\_CHECK\_PROTOCOL | AWS\_LWA\_READINESS\_CHECK\_PROTOCOL |
| REMOVE\_BASE\_PATH         | AWS\_LWA\_REMOVE\_BASE\_PATH         |
| ASYNC\_INIT                | AWS\_LWA\_ASYNC\_INIT                |

旧名は今も動きますが、v2.0で消えます。`AWS_LWA_READINESS_CHECK_MIN_UNHEALTHY_STATUS` はv1.0で削除済みで、`AWS_LWA_READINESS_CHECK_HEALTHY_STATUS=100-399` のように「正常とみなす範囲」で書き直します。

### v1.1.0で挙動が変わったベースパス除去とCookie

v1.1.0のリリースノートは、利用者側で確認が必要な変更を2つ挙げています。1つは `AWS_LWA_REMOVE_BASE_PATH` で、先頭の1回だけ、パスの区切り位置でのみ取り除くようになりました。`/api` を指定した場合、`/api/api/order` は `/api/order` になり、`/apiorder` は変わりません。以前の繰り返し除去や部分一致に頼っていたルーティングは壊れます。

もう1つは依存ライブラリの更新に伴うもので、API Gateway v2の `cookies` 配列が複数あるとき、連結の区切りが `;` から `; `（セミコロンと空白）に変わりました。Cookieヘッダーを `;` だけで分割している自前の処理は、先頭に空白が残ります。

## SnapStartを併用する設定とv1.1.0のフック

[SnapStartのドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html)は、対象をJava 11以降・Python 3.12以降・.NET 8以降のマネージドランタイムと、それぞれのAWSベースイメージとし、「ZIPとコンテナイメージの両方の配布形式」で使えると明記しています。SnapStartの仕組みと料金そのものはLambda SnapStartとは？対応ランタイム・料金とコンテナイメージ対応後の使い方で扱い、ここではLWAと組み合わせるときの条件に絞ります。

### LWAと組み合わせられる構成と使えない機能

Zip配布なら、java21やpython3.12のランタイムにLWAレイヤーを付けた構成がそのまま対象です。Node.jsとRubyのマネージドランタイム、OS専用ランタイム（provided.al2023）は対象外なので、ExpressをZipで配る構成ではSnapStartを使えません。

コンテナ配布で独自ベースイメージを使う場合、[コンテナ向けの手順](https://docs.aws.amazon.com/lambda/latest/dg/snapstart-runtime-hooks-custom.html)は、ランタイム側が `/runtime/restore/next` を呼ぶか、Dockerfileに `LABEL com.amazonaws.lambda.feature.snapstart="Allow"` を書くことを求めています。どちらも無いとバージョンの発行に失敗します。LWA v1.1.0はこのライフサイクルに参加するため、公式例 `fastapi-snapstart` はLABELなしの `python:3.12-slim` でSnapStartを有効にしています。公式に動作例があるのはFastAPIだけなので、Node.jsなど他言語のイメージで使うときは本番前に発行と復元を自分で確認してください。

どの構成でも、プロビジョンド同時実行、Amazon EFS、Amazon S3 Files、512MBを超えるエフェメラルストレージとは併用できません。有効化できるのは発行済みバージョンとそれを指すエイリアスだけで、`$LATEST` には効きません。リージョンはニュージーランドと台北を除く全商用リージョンです。

### 接続と乱数を作り直す2つのフック

スナップショットに含まれた状態は、そこから復元されたすべての実行環境で共有されます。初期化時に張ったDB接続は、復元後も使える保証がありません。初期化時に作った乱数生成器の状態や一意IDは、スナップショットごと複製されるため、全環境で同じ値から始まります。LWAはアプリを別プロセスとして動かすため、アプリはSnapStartのフックを直接受け取れません。v1.1.0はこの溝を、アプリへのHTTP呼び出しで埋めます。

```
import random
from fastapi import FastAPI, Response

app = FastAPI()

@app.post("/snapstart/before")
async def before_checkpoint():
    # スナップショット前：持ち越せない接続を閉じる
    pool.close()
    return Response(status_code=200)

@app.post("/snapstart/after")
async def after_restore():
    # 復元後：乱数の種を作り直してから接続を張り直す
    random.seed()
    pool.connect()
    return Response(status_code=200)
```

関数の環境変数に `AWS_LWA_SNAPSTART_BEFORE_CHECKPOINT_PATH=/snapstart/before` と `AWS_LWA_SNAPSTART_AFTER_RESTORE_PATH=/snapstart/after` を設定すると、LWAがそれぞれの時点で空のPOSTを送ります（上のコードは公式例 `fastapi-snapstart-zip` からフック部分だけを抜き出したもので、単独では動きません。`pool` の定義と初期化は公式例の `ConnectionPool` クラスを参照してください）。運用で押さえる点は4つです。

- 応答が2xx以外か接続失敗なら、その段階（スナップショット前は初期化、復元後は復元）が失敗します。壊れた状態のまま配信は始まりません。
- 復元フェーズ全体は10秒で打ち切られ、`Lambda.SnapStartTimeoutException` になります。復元後フックとその後のreadiness checkはこの10秒を分け合います。
- API GatewayやALBからフックのパスに来た外部リクエストは、LWAが403で止めます。ただしECSやローカルのDockerでLWAを通さずに動かすと、このパスは認証なしで開いたままになります。
- v1.1.0から、SnapStart下では `AWS_LWA_ASYNC_INIT` が無視されます。readiness checkの待ち時間を区切るなら `AWS_LWA_READINESS_CHECK_TIMEOUT_SECONDS` を使いますが、この値は初回の初期化にも効くため、Spring Bootの起動時間より短くするとバージョンの発行が失敗します。

料金も言語で分かれます。Javaのマネージドランタイムでは追加料金はありません。Pythonと.NETでは、発行した各バージョンのスナップショットのキャッシュ料金（最低3時間）と、復元のたびの復元料金がかかります。`AutoPublishAlias` でデプロイのたびにバージョンが増えるので、使わない古いバージョンは削除してください。

## Lambdaに載せられないWebアプリの境界値

LWAはLambdaの上限を外すものではありません。次の表は[Lambdaのクォータ一覧](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)のうち、Webアプリの移行可否に直結するものです。

| 項目              | 上限           | 影響する処理             |
| --------------- | ------------ | ------------------ |
| 同期の要求・応答        | 各6MB         | ファイルのアップロード・ダウンロード |
| ストリーミング応答       | 200MB        | CSV出力・生成AIの逐次応答    |
| 要求行＋ヘッダー合計      | 1MB          | 大きなCookie          |
| 実行時間            | 900秒         | 長い集計・バッチ           |
| メモリ             | 128〜10,240MB | 1,769MBで1vCPU相当    |
| Zip（展開後・レイヤー込み） | 250MB        | 依存の多いJava・Python   |
| コンテナイメージ        | 10GB         | ネイティブライブラリ同梱       |
| 実行環境あたりの帯域      | 既定625Mbps    | 大容量転送              |

### 6MBを超える応答とレスポンスストリーミング

帯域の625Mbpsは既定値で、VPCに接続していない関数はService Quotasから増枠を申請でき、承認後はメモリ2,048MBから比例して増え、10,240MBで最大3,000Mbpsになります。

6MBを超える応答はそのままでは返せません。[レスポンスストリーミング](https://docs.aws.amazon.com/lambda/latest/dg/configuration-response-streaming.html)をネイティブに使えるのはNode.jsのマネージドランタイムだけで、他の言語についてAWSは「カスタムランタイムかLambda Web Adapterを使う」と名指ししています。LWAでは関数の環境変数 `AWS_LWA_INVOKE_MODE=response_stream` で切り替えます。関数URL経由で返す場合は、関数URL側の `InvokeMode: RESPONSE_STREAM` も合わせて設定します。公式のストリーミング例（FastAPI・Next.js・Spring Boot）はいずれもこの関数URL構成です。

最初の6MBは帯域制限がなく、それを超えた分は最大2MBpsに絞られます。100MBのファイルなら残り94MBに約47秒かかる計算で、大きなファイルはS3の署名付きURLで直接渡す方が速く済みます。VPC内では関数URL経由のストリーミングは使えません。API Gatewayでは[REST APIの応答転送モードSTREAM](https://docs.aws.amazon.com/apigateway/latest/developerguide/response-transfer-mode.html)がストリーミングに対応しており（REST APIのみ・最長15分・アイドルはリージョン別エンドポイントで5分、エッジ最適化で30秒）、HTTP APIは対象外です。CloudFrontを前段に置いて関数URLを保護する構成は[CloudFront×API Gateway×Lambdaの連携構成｜設定手順と403の原因・直アクセスの遮断方法](/tech/details/6799/)で扱っています。

### 同時実行と接続数が効く処理

既定のLambdaでは、1つの実行環境が同時に処理するリクエストは1件です。100件の同時アクセスには100個の実行環境が立ち上がり、それぞれが接続プールを持ちます。Spring BootのHikariCPを既定の最大10接続のまま載せると、DB側から見た接続数は最大で実行環境数×10に膨らみます。1リクエストで必要な接続数を見積もって小さな値から検証を始め、「実行環境の最大数×プール上限」がDBの接続上限に収まるかで決めます。収まらなければ接続数を束ねる仕組みを前段に置きます。WebSocketのように接続を張りっぱなしにする通信や、レスポンスを返した後にスレッドで続ける処理も、実行環境が凍結されるため既定のLambdaでは成り立ちません。

## readiness checkと認証ヘッダーでつまずく設定

LWAの設定項目のうち、移行直後の不具合につながりやすいのは次の3つです。

- **readiness checkの判定範囲**：`AWS_LWA_READINESS_CHECK_HEALTHY_STATUS` の既定は100〜499で、404も「起動済み」とみなされます。逆に、DB未接続で503を返すヘルスチェックを指定すると、初期化が終わらないまま待ち続けます（待ち時間は既定で無制限）。
- **認証ヘッダーの付け替え**：関数URLをIAM認証にすると、`Authorization` ヘッダーはSigV4の署名で埋まります。アプリ用のトークンを別ヘッダーで送り、`AWS_LWA_AUTHORIZATION_SOURCE` にそのヘッダー名を指定すると、LWAが `Authorization` に置き換えて渡します。
- **5xxを失敗として扱う**：既定では、アプリが500を返してもLambdaの呼び出し自体は成功扱いです。`AWS_LWA_ERROR_STATUS_CODES=500,502-504` のように指定すると、そのステータスで呼び出しを失敗にでき、Lambdaのエラーとして数えられます。

初期化に時間のかかるアプリでは、`AWS_LWA_ASYNC_INIT=true` で約9.8秒後にreadiness checkを打ち切り、初期化の続きを最初の呼び出しに回せます。先に述べたとおり、SnapStartとプロビジョンド同時実行の下ではこの設定は無視されます。

## Lambda・Lambda Managed Instances・Fargateの選び分け

LWAで載せたアプリは、同じイメージのままFargateやLambda Managed Instancesにも移せます。どこで動かすかは、負荷の形と上限で決めます。

| 観点       | Lambda（既定）       | Lambda Managed Instances   | Fargate      |
| -------- | ---------------- | -------------------------- | ------------ |
| 同時処理     | 1環境1リクエスト        | 1環境で多重実行                   | アプリ次第        |
| アイドル時    | ゼロまで縮む           | 最小環境数を維持                   | タスクが動き続ける    |
| 課金       | リクエスト数＋実行時間      | EC2料金＋オンデマンド料金の15%＋リクエスト料金 | タスクのvCPU・メモリ |
| コールドスタート | あり（SnapStartで短縮） | なし                         | タスク起動時のみ     |
| 実行時間     | 900秒             | 非同期は最大90分                  | 制限なし         |

夜間や週末にほぼアクセスが無い社内ツール・管理画面・プロトタイプは、アイドル時の課金がゼロになる既定のLambdaを第一候補にします。最終的には、日中の実行時間×メモリの料金とFargateのタスク料金を同じ月間リクエスト数で試算して比べます。[Lambda Managed Instances](https://docs.aws.amazon.com/lambda/latest/dg/lambda-managed-instances.html)は一定量の負荷が常にあるAPI向けで、LWAも多重実行に対応しています。ただし複数リクエストが同じプロセスで並行に走るので、リクエスト単位の状態をグローバル変数に置いているアプリはそのままでは移せません。詳細は[Lambda Managed Instancesとは？料金の実額・90分実行・標準Lambdaとの使い分け【2026年9月】](/tech/details/17767/)、ECS・EKSを含めた比較は[AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順](/tech/details/17869/)を参照してください。

WebSocketを常用する、15分を超える処理を同期で返す、6MB超のアップロードをアプリ本体が直接受ける必要があり署名付きURLでS3へ逃がせない、といった要件が1つでもあれば、LWAで無理に載せずにFargateを選ぶべきです。既存アプリのどこまでをLambdaに寄せるかの判断や、移行後の監視設計を含めた構築は[AWSを含むクラウドのインフラ構築支援](/service/system/aws/)でも承っています。

## よくある質問

### Lambda Web Adapterとは何ですか？

AWSが公開しているオープンソースのツールで、HTTPで動く通常のWebアプリを、Lambda専用のハンドラー関数に書き換えずにAWS Lambdaで動かすためのものです。Lambda拡張として動き、Lambdaのイベントと通常のHTTPリクエスト・レスポンスを相互に変換します。ライセンスはApache-2.0です。

### Lambda Web Adapterのデメリットは？

LWA自体の上乗せは、AWSの実測で平均0.8ms程度と小さいものです。制約になるのはLambda側の上限で、同期の要求・応答は各6MB、実行は900秒までです。また1環境1リクエストのため、同時アクセス数だけDB接続が増えます。アプリをハンドラー形式に書き換えない分、API Gatewayのリクエストコンテキストなどは `x-amzn-request-context` ヘッダー経由で受け取ることになります。

### SnapStartはコンテナイメージでも使えますか？

使えます。2026年9月からSnapStartはJava 11以降・Python 3.12以降・.NET 8以降について、ZipとコンテナイメージのどちらでもOKになりました。独自ベースイメージでは `/runtime/restore/next` の実装かDockerfileのLABELが必要で、LWA v1.1.0を入れたイメージはLABELなしで有効にできることが公式例で示されています。

### LambdaとFargateはどう違いますか？

既定のLambdaはリクエストが無ければゼロまで縮み、リクエスト数と実行時間で課金されます。Fargateはコンテナを動かし続け、確保したvCPUとメモリに課金されます。Lambdaには900秒・6MBの上限がありますが、Fargateにはありません。LWAを使えば同じコンテナイメージをどちらでも動かせるので、まずLambdaで始め、負荷が定常化したらFargateへ移す順序が取れます。

### AWS Lambdaのサービスは終了しますか？

AWS Lambdaそのものの終了は発表されていません。終了するのは言語ごとのランタイムで、たとえばAmazon Linux 2版の `java17`・`java11`・`python3.11` は2027年6月30日に廃止予定です。廃止後は新規作成から順に止まるため、`java21` や `java17.al2023` などAmazon Linux 2023版への切り替えを先に済ませてください。

## 関連記事

- [AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説](/tech/details/15407/)
- [Lambda Managed Instancesとは？料金の実額・90分実行・標準Lambdaとの使い分け【2026年9月】](/tech/details/17767/)
- [AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順](/tech/details/17869/)
- [CloudFront×API Gateway×Lambdaの連携構成｜設定手順と403の原因・直アクセスの遮断方法](/tech/details/6799/)

---

出典: [Lambda Web Adapterの使い方｜WebアプリをLambdaで動かす手順とv1.1.0のSnapStart対応](<https://www.issoh.co.jp/tech/details/1917/>)（株式会社一創）