aws-lambda-web-functions

AWS Lambda Web Functions

サンドボックス化された実行と監査ログには、AWS MCP サーバーをおすすめします。

aws lambda-web が認識されない場合は、AWS CLI を更新してください（references/deployment.md を参照）。 コマンドが見つからない場合は、機能が利用できないのではなく、CLI が古いことを意味します。

AWS Lambda Web Functions で Node.js の HTTP アプリケーションを構築し、デプロイできるようユーザーを支援します。アプリはポートをリッスンし、HTTP をネイティブに処理して、グローバルに利用できる HTTPS URL を取得します。node index.js でローカル開発し、同じコードを AWS にデプロイできます。

Web Functions を使用する場合

• ユーザーが応答を待っているインタラクティブな HTTP トラフィック：Web アプリ、HTTP API、SSR サイト。
• アプリがすでにポートをリッスンする HTTP サーバー（Express、Fastify、Hono）であり、そのまま使用する必要がある場合。ハンドラーの書き換えやアダプターライブラリは不要です。
• ハンドラーが I/O バウンド（データベース、キャッシュ、別の API、モデルエンドポイント）であり、多数のリクエストが 1 つの実行環境を共有し、I/O 待ちの時間には CPU の課金が発生しない場合。
• レスポンスのストリーミングが重要な場合：SSE、チャンク転送、または生成された LLM トークンのプロキシ。
• CloudFront、API Gateway、Route53 を手作業で組み合わせることなく、1 つのホスト名でエンドポイントに世界中からアクセスできる必要がある場合。
• トラフィックが急増したり予測不能だったりするため、ゼロまでスケールする必要がある場合。

必須の前提条件

いずれかに「いいえ」が当てはまる場合、Web Functions は選択肢から外れます。適切なサービスを見つけるには、aws-serverless スキルを呼び出してください。

• ランタイムが Node.js（nodejs24.x）であること。Python、Java、Go、.NET、Rust はサポートされていません。呼び出し元に別のサービスを案内する前に、aws lambda-web help または AWS ドキュメントでサポート対象のランタイム一覧を確認してください。
• すべてのネイティブ依存関係に arm64（Graviton） ビルドがあること。
• 作業が、呼び出し元が応答を待つ HTTP リクエスト／レスポンス（またはストリーム）であること。キュー、イベントストリームソース（Kinesis、DynamoDB Streams）、スケジュール、イベントトリガーはサポートされていません。
• 1 つのリクエストが 900 秒（15 分）のリクエストタイムアウト内に完了すること。
• アプリが 512 MB のパッケージと、2 vCPU／2 GB の環境に収まること（サービスの制限を参照）。
• 環境がステートレスであること。どの環境でも、どのリクエストにも対応できる必要があります。エンドユーザーのセッションと特定の環境との間にアフィニティはありません。
• アプリが、同時リクエストと同じ環境を共有できること。リクエストごとの厳密な分離はサポートされていません。

ユースケース

「何を構築しているか」から、Web Functions での実現方法へ。

ユーザーが構築しているもの	Web Functions での構成
JSON HTTP API または REST バックエンド	Express または Hono ルーター、I/O 待ちのハンドラー、その背後に DynamoDB または RDS → architecture-patterns.md
サーバーサイドレンダリングのサイトまたはアプリ	index.js からリクエストごとに HTML をレンダリングします。JSX を記述する場合を除き、バンドラーは不要です → architecture-patterns.md
ブラウザーにトークンをストリーミングする LLM または AI ゲートウェイ	SSE またはチャンク化レスポンスを使用します。最初の 1 バイトだけでなく、ストリーム全体を処理できるように timeoutSeconds を延長します → architecture-patterns.md
Webhook レシーバー（Stripe、GitHub、Slack）	ペイロードに対する処理を行う前に、Secrets Manager の署名シークレットを使って送信元の署名を検証します。その後、すぐに応答して処理を完了します。環境は実行を継続します → architecture-patterns.md
複数のサービスを集約するモバイルまたは Web のバックエンド・フォー・フロントエンド	1 つの環境から複数のリクエストを並行して送信します。待機にかかる時間は CPU 使用料として課金されません
1 回のデプロイで提供するシングルページアプリとその API	バンドルには express.static を、クライアントルートには /*splat フォールバックを使用します → static-assets.md
内部サービス間 HTTP エンドポイント	authType: IamAuth を指定し、SigV4 署名付きの呼び出し元だけがアクセスできるようにします → iam-and-security.md
単一のホスト名で、世界中から低レイテンシーでアクセスできるエンドポイント	MultiRegion エンドポイントと、リージョンに依存しないアプリを組み合わせます → domains-and-routing.md
RDS、ElastiCache、その他のプライベート VPC リソースを呼び出すアプリ	リビジョンから参照するエグレス用ネットワークコネクターを使用します。エンドポイントはパブリックのままです → networking.md

ワークフロー

まずは aws lambda-web CLI を使用してください。最も手早く進められます。ユーザーが 1 つのコマンドを求めている場合、またはすでにこれを使ってデプロイしていると述べた場合は、aws lambda-web deploy を使用します。このコマンドは、プロジェクトディレクトリをパッケージ化、アップロードし、作成または更新します。また、--hello-world を指定すると、スターターアプリを生成してデプロイします（下記の「デプロイ（CLI）」を参照）。それ以外の場合は、既存の関数の更新も含め、以下の手順を使用します。ユーザーが Infrastructure as Code や再現可能な本番環境スタックを求めている場合は、CloudFormation、CDK、SAM、または Terraform を使用します（references/infrastructure-as-code.md を参照）。

1. スキャフォールド - Express の例は以下にあります。Hono または Fastify の場合は、references/frameworks.md を参照してください
2. エンドポイント認証を選択 — デプロイ前にユーザーに確認します（以下を参照）。IamAuth を選択しない限り、エンドポイントはパブリックです
3. ローカルでテスト — node index.js
4. パッケージ化 — 本番環境用の依存関係を含めて ZIP 化します（最大 512 MB）
5. デプロイ — aws lambda-web create-web-function
6. 検証 — エンドポイント URL を取得し、curl を実行します
7. 反復 — 新しいリビジョンを作成します

デフォルトではパブリックです。 ApplicationManaged エンドポイントは、URL を知っているインターネット上の誰もがアクセスできます。AWS レイヤーでの認証も、組み込みの WAF もなく、URL は秘密情報ではありません。デプロイ前に、どちらを希望するかユーザーに確認してください。

• ApplicationManaged（パブリック）— アプリ側で認証・認可、入力検証、レート制限を実装する必要があります。
• IamAuth（内部向け）— 有効な IAM 認証情報（SigV4 署名付き）を持つ呼び出し元だけがアクセスできます。

エンドポイントがパブリックの場合、アプリ側でセキュリティを担います。セキュリティチェックリスト（認証、入力検証、レート制限、WAF/CloudFront、最小権限のロール、シークレット）については、references/iam-and-security.md を参照してください。

クイックスタート（Express）

// index.js
import express from 'express';
import helmet from 'helmet';
import { fileURLToPath } from 'url';
import { dirname, join } from 'path';

const __dirname = dirname(fileURLToPath(import.meta.url));
const app = express();
// The runtime probes this exact host:port for readiness.
const [HOST, PORT] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || '0.0.0.0:3000').split(':');

app.use(helmet());
app.use(express.static(join(__dirname, 'public')));
app.use(express.json({ limit: '10mb' }));
app.get('/api/health', (req, res) => res.json({ status: 'ok' }));
app.listen(PORT, HOST, () => console.log(`Listening on ${HOST}:${PORT}`));

{
  "name": "my-web-app",
  "type": "module",
  "scripts": { "start": "node index.js", "dev": "node --watch index.js" },
  "dependencies": { "express": "^5.0.0", "helmet": "^8.0.0" }
}

helmet は、ここではどの AWS レイヤーも設定しないセキュリティレスポンスヘッダー（HSTS、CSP、X-Content-Type-Options、X-Frame-Options、Referrer-Policy）を設定します。ApplicationManaged エンドポイントでは、これらを設定できるのはアプリだけです。そのため、後から追加するのではなく、スキャフォールドに含めておきます。

リソースの命名

すべてのリソースはプロジェクトごとにスコープが設定されます。関数名から名前を導出してください。

リソース	デフォルトのパターン	例
関数	{name}	my-api
IAM ロール	{name}-web-role	my-api-web-role
S3 バケット	{name}-web-{account}	my-api-web-1234567890
S3 キー	{name}/function.zip	my-api/function.zip
DynamoDB	{name}-{purpose}	my-api-items

関数名はアカウント内のすべてのリージョンで一意でなければなりません。同じ名前を 2 つのリージョンで使用することはできず、名前が重複すると作成時に競合エラーが発生します。

ユーザーに S3 の利用方法の希望を確認してください。

• プロジェクトごとに個別のバケット（デフォルト） — 完全に分離でき、簡単にクリーンアップできます
• プロジェクト間で共有するバケット（例：{account}-web-code） — リソースを減らし、キーのプレフィックスで分離します
• カスタム — ユーザーが独自のバケット名とキーのプレフィックスを指定します

aws lambda-web deploy は、独自のロール（awscli-lambdaweb-{name}）とバケット（awscli-lambdaweb-{account}-{region}-an）を命名します。

デプロイ（CLI）

aws lambda-web CLI が、主要なサポート対象の方法です。デフォルトではこれを使用してください。手順は、最初に一度だけ S3 コードバケットを作成し（バージョニングと Lambda の読み取りアクセスを設定）、その後 npm ci --omit=dev → zip → aws s3 cp → --revision-config と --endpoint-config を指定して aws lambda-web create-web-function を実行し、エンドポイントが Active になるまで待機します。プロジェクトにビルド手順がある場合は、プルーニングの前に実行してください。npm ci --omit=dev によってバンドラーが削除されます。

ユーザーが 1 つのコマンドを求めている場合、またはすでにこのコマンドでデプロイしている場合は、aws lambda-web deploy --name {name} --code . --create --auth-type {auth-type} を使用します（認証タイプをユーザーに確認してください）。このコマンドは ZIP 化、アップロード、関数、コードバケット、ロール、および dev エンドポイントの作成を行います。変更を反映するには、--create を付けずに再実行します。先に依存関係をインストールしてください。

すべてのコマンド、EndpointConfig と RevisionConfig のフィールドのルール、パッケージ化、タイムアウト、同時実行数、環境変数、ログ設定、および deploy のすべてのフラグについては、references/deployment.md を参照してください。初回のセットアップ（バケット、実行ロール、初回デプロイ）については、references/getting-started.md を参照してください。CloudFormation、CDK、または SAM については、references/infrastructure-as-code.md を参照してください。

マルチリージョン

マルチリージョンに対応しています。MultiRegion エンドポイントは、Route53 が各リクエストを最寄りのリージョンにルーティングし、1 つのホスト名で複数のリージョンからリビジョンを提供します。PerRegion では、各リージョンに個別のドメイン名も割り当てられます。どちらの場合も autoDeploymentMode: Disabled が必要です。また、アプリはリージョンに依存しない設計でなければなりません。同じクライアントからの連続したリクエストが異なるリージョンに到達する場合があるため、状態は複製されたストアに保持し、実行環境や /tmp には決して保持しないでください。

エンドポイントの種類、ドメイン、トラフィックルーティング、マルチリージョンのセットアップコマンドについては、references/domains-and-routing.md を参照してください。

VPC エグレス

デフォルトでは、リビジョンは IPv4 経由でパブリックインターネットに接続できますが、プライベートなリソースには接続できません。VPC に接続するには、バージョンが指定されたエグレスネットワークコネクター ARN（aws lambda-core create-network-connector、コンピューティングタイプは WebFunction）をリビジョンの serviceConfig.egressNetworkConnectorArn に設定し、HomeRegion エンドポイントから提供して、各リビジョンの作成後にこのフィールドを読み戻してください。references/networking.md、またはコネクターとリビジョンを 1 つのスタックで宣言する場合は references/infrastructure-as-code.md を参照してください。

検証

aws lambda-web get-web-function-endpoint \
  --function-name {name} --endpoint-name default --region {region}

# curl the domainName from the response
curl https://{domainName}/api/health

起動に失敗したリビジョンも Active になるため、デプロイのたびに実際のルートに対して curl を実行してください。aws lambda-web deploy はエンドポイントを endpointUrl として出力し、最初のエンドポイントには dev という名前を付けます。

ポーリングループや sleep よりも、ウェイター（aws lambda-web wait ...）を優先してください。利用可能なウェイター：web-function-active、web-function-revision-active、web-function-endpoint-active、web-function-endpoint-updated、web-function-endpoint-deleted、web-function-deleted

コードの更新

zip -r function.zip index.js package.json node_modules/ public/ \
  -x "*.test.*" -x ".git/*" -x ".env" -x "node_modules/.cache/*"
aws s3 cp function.zip s3://{bucket}/{name}/function.zip

aws lambda-web create-web-function-revision \
  --function-name {name} \
  --build-config '{
    "codeConfig": {"s3Object": {"bucket": "{bucket}", "key": "{name}/function.zip"}},
    "runtimeConfig": {"runtime": "nodejs24.x"}
  }' \
  --service-config '{"executionRoleArn": "arn:aws:iam::{account}:role/{name}-web-role"}' \
  --region {region}

サービスの制限

変更される場合があります。正式な値については、 Lambda のクォータページ を確認してください。

スコープ	リソース	制限
アカウント	リージョンの vCPU 制限	2,000
アカウント	リージョンのアカウントレート制限	100,000 RPS
アカウント	リージョンのエンドポイントごとの最大レート制限	10,000 RPS
関数ごと	エンドポイント	10
関数ごと	保持されるリビジョン	50（参照されていない最も古いリビジョンは自動的に削除されます）
関数ごと	環境変数	合計 32 KB
関数ごと	デプロイパッケージ	512 MB
関数とエンドポイントごと	名前	64 文字
エンドポイントごと	エンドポイントのレート制限	リージョンのエンドポイントごとの最大レート制限（上記）に制限されます。ユーザーは throttleConfig.rateLimit を使って、個々のエンドポイントにより低いレート制限を任意で設定できます
エンドポイントごと	アクティブなリビジョン	2
環境ごと	vCPU	2
環境ごと	メモリ	2 GB
環境ごと	同時実行数	1～128 リクエスト（scaling-and-concurrency.md を参照）
環境ごと	ネットワーク帯域幅	1 Gbps
環境ごと	/tmp	512 MB
環境ごと	ファイルディスクリプター	1,024
環境ごと	プロセスとスレッド	1,024
環境ごと	初期化タイムアウト	10 秒
リクエストごと	タイムアウト	3～900 s（デフォルトは 30 s）
リクエストごと	ヘッダー数	6,300

コストモデル

課金対象は 4 つの要素です：CPU、メモリ、リクエスト、データ転送。現在の料金は Lambda の料金ページで確認してください。料金を記憶だけで引用しないでください。アーキテクチャを決めるのは、請求額の傾向です。

• 課金対象は壁時計時間ではなく、アクティブな CPU 時間です。 データベース呼び出し、別の API、モデルエンドポイントなど、I/O 待ちでリクエストがブロックされている時間は CPU として課金されません。一方、イベント関数は壁時計時間に基づく GB 秒で課金されるため、同じハンドラーでも課金額は異なります。
• メモリはプロビジョニング時の設定値ではなく、消費量に基づいて課金されます。 環境は 2 vCPU、2 GB で（「サービスの制限」を参照）、メモリを調整する設定はありません。そのため、メモリを増やして実行時間を短縮するというイベント関数でおなじみの方法は、ここでは使えません。
• 同時実行数が密度を左右します。 1 つの環境で最大 maxConcurrencyPerEnvironment 件のリクエストを処理できるため、I/O バウンドのアプリは各リクエストに 1 つずつ環境を割り当てるのではなく、1 つの環境で多くのリクエストを同時に処理し続けられます。

計画時に考慮すべき点が 2 つあります。

• I/O バウンドのワークロードが最もコスト効率の高いケースです。 ネットワーク待ちに大半の時間を費やし、他のリクエストと環境を共有するハンドラーは、呼び出しごとに壁時計時間で課金される同じハンドラーよりも、ここでは低コストです。
• CPU バウンドのワークロードでは、その優位性が失われます。 負荷の高いレンダリング、画像処理、暗号処理は、実行場所にかかわらず課金対象の CPU を消費します。また、環境には 2 vCPU が割り当てられますが、シングルスレッドの Node プロセスが使うのは 1 つだけです（「アンチパターン」を参照）。特に確約利用割引が適用される、継続的かつ大量の CPU 処理では、aws-lambda-managed-instances と比較してください。

エンドポイントのスケーリング制御 scalingConfig.maxEnvironments と throttleConfig.rateLimit を使って、潜在的なコストを抑えられます。ユーザーが上限を求めた場合に限り、これらを設定してください。詳細は scaling-and-concurrency.md を参照してください。

IAM のセットアップ

信頼ポリシーのプリンシパル：lambda.amazonaws.com

IAM アクションでは、lambda: プレフィックスを使用します。リソース ARN：arn:aws:lambda:{region}:{account}:web-function/{name}

アクション名は API オペレーションと一致します — lambda:CreateWebFunction、lambda:CreateWebFunctionRevision、lambda:CreateWebFunctionEndpoint、lambda:UpdateWebFunctionEndpoint、および Get*、List*、Delete* の各バリアントです。完全なポリシーについては、references/iam-and-security.md を参照してください。

エンドポイント／リビジョンの操作では、リソース ARN に /* ワイルドカードを含める必要があります。

"Resource": ["arn:aws:lambda:{region}:{account}:web-function/{name}", "arn:aws:lambda:{region}:{account}:web-function/{name}/*"]

呼び出し元にも、（実行ロールだけでなく）コードバケットに対する s3:GetObject と s3:GetObjectVersion が必要です。

ポリシーの完全な例については、references/iam-and-security.md を参照してください。

アンチパターン

どのような状態か → 失敗する理由 → 代わりに何をするか。

アンチパターン	失敗する理由	代わりに
CPU バウンドのハンドラーが環境全体を使えると期待する	実行環境には 2 vCPU が割り当てられますが、Node はシングルスレッドであるため、1 つのプロセスが使うのはそのうち 1 つだけで、もう 1 つはアイドル状態になります	CPU バウンドの処理には worker_threads（または cluster）を使い、両方を稼働させます。I/O バウンドのハンドラーはシングルスレッドのままにします。CPU に制約される処理ではありません
x86 マシン（ノート PC または x86 CI）でビルドした node_modules を zip 圧縮する	実行環境は arm64 であるため、x86 のネイティブバイナリは読み込めません。sharp、canvas、bcrypt などのパッケージやその他のネイティブアドオンは、アーキテクチャごとにビルドを提供しています	arm64 上でインストールしてビルドします。arm64 CI ランナー、Graviton ホスト、または --platform linux/arm64 を指定して実行するコンテナを使い、その後 zip 圧縮します
リクエストボディのアップロード中にレスポンスのバイト列を書き込む（全二重ストリーミング）	リクエスト経路は半二重です。レスポンスが読み取られる前にリクエストボディ全体が転送されるため、交互のレスポンスを期待する大容量アップロードはタイムアウトまで停止します。小さなボディはソケットバッファーに収まって動作しているように見えるため、テスト時に問題が隠れます	リクエストを最後まで読み取ってから、レスポンスをストリーミングします。サーバーからクライアントへの方向のストリーミングを維持します
ハンドラーアダプター（serverless-express、@vendia/serverless-express、aws-lambda-fastify）でアプリをラップする	エクスポートするハンドラーはありません。ランタイムは index.js を読み込み、HTTP サーバーがリッスン状態になることを期待しますが、アダプターはポートをバインドしないため、準備完了にならず、環境を利用できません	アダプターを削除し、ホストとポートに AWS_LAMBDA_HTTP_ENDPOINT の値を使って app.listen(...) を呼び出します
app.listen(3000) をハードコードする、または localhost／127.0.0.1 にバインドする	ランタイムは通知された正確なアドレスをプローブします。ポートが一致しない場合やループバックのみへのバインドでは、そのプローブに応答できません	AWS_LAMBDA_HTTP_ENDPOINT を解析し、そのホストとポートにバインドします
モジュールレベルの可変状態にリクエストごとのデータ（currentUser、リクエストスコープのキャッシュ、カウンターなど）を保持する	1 つの実行環境では、1 つのプロセスで複数の同時リクエストを処理するため、各リクエストが互いの値を読み取ってしまいます。これはパフォーマンスの問題ではなく、正確性とデータ漏えいの問題です	リクエストごとのデータはリクエストスコープ内に保持し、モジュールレベルで共有するのは不変の設定と SDK クライアントのみにします
セッションやアップロードの状態を /tmp に書き込み、次のリクエストでも使えると期待する	/tmp は環境ごとに存在し、同時リクエスト間で共有されます。次のリクエストは別の環境、またはマルチリージョンエンドポイントでは別のリージョンに届く場合があります	状態は DynamoDB、S3、または ElastiCache に保存し、本当に一時的なファイルには一意のファイル名を使います
エンドポイント URL をアクセス制御として扱う（「このドメインを知っている人はいない」）	ApplicationManaged エンドポイントは、URL を知っていれば誰でもインターネット経由で到達できます。AWS レイヤーの認証はなく、組み込みの WAF もなく、URL は秘密ではありません	アプリで認証を実装するか、IamAuth を使います。CloudFront のみアクセスできるようにするには、CloudFront OAC とリソースベースのポリシーで IamAuth を使用します → domains-and-routing.md。L7 保護のために WAF を追加します → iam-and-security.md
serviceConfig.environmentVariables にシークレットを設定する	get-web-function-revision は、リビジョンの読み取りアクセス権を持つすべてのユーザーに環境変数をプレーンテキストで返します	シークレットは Secrets Manager または SSM に保存し、その名前またはパスのみを渡して、実行時に取得します
ビルド手順の前に npm ci --omit=dev を実行する	devDependencies の削除によってバンドラーも削除されるため、その後のビルドは esbuild: command not found で失敗します	先にビルドし、その後で不要な依存関係を削除します。または、バンドル済みの出力を zip 圧縮します → deployment.md
Event Functions の場合と同様に、ランタイムに @aws-sdk/* が含まれると期待する、または外部としてマークする（externalModules、--external:@aws-sdk/*）	Web Functions ランタイムには AWS SDK が含まれないため、起動時にインポートが失敗し、すべてのリクエストが 502 を返します	インポートする @aws-sdk/* クライアントを、他の依存関係と同様にパッケージに含めます → deployment.md
update-* の呼び出しでコード、ランタイム、タイムアウト、環境変数、または同時実行数をインプレースで変更できると期待する	これらはすべて不変のリビジョンに属します	新しいリビジョンを作成します。インプレースで更新できるのはエンドポイントレベルの設定（認証、ウェイト、スケーリング、スロットリング）のみです
同じ S3 キーに再アップロードして、再デプロイされると期待する	リビジョンはオブジェクトのバージョンに固定されているため、CloudFormation は「デプロイする変更はありません」と報告します	新しいキーを使うか、新しい versionId を渡します
aws lambda-web がないため、この機能は存在しないと結論づける	見つからないのは CLI が古いためであり、機能が存在しないわけではありません	AWS CLI を更新します → deployment.md
2 つのリージョンで同じ関数名を再利用する	関数名はアカウント内のすべてのリージョンで一意であるため、2 回目の作成は競合して失敗します	リージョンのサフィックスを付けるか、MultiRegion エンドポイントを持つ 1 つの関数を使います
Express 5 で SPA のフォールバックに app.get('*', ...) を使う	path-to-regexp v8 は裸の * を拒否して起動時に例外をスローするため、アプリは起動しません	'/*splat' を使います → static-assets.md

トラブルシューティング — まずはこちらをご確認ください

初回デプロイの失敗の大半を占める5つのケースです。症状 → 原因 → 修正の詳しい表は troubleshooting.md をご覧ください。

症状	原因	修正	確認方法
エンドポイントが Active にならず、状態が Failed になる	アプリが指定されたホストとポートにバインドされておらず、レディネスチェックに合格しない	AWS_LAMBDA_HTTP_ENDPOINT のホストとポートにバインドする	get-web-function-endpoint で Active と表示された後、domainName に curl を実行する
Cannot find module '/var/task/index.js' という500エラーが発生する	エントリポイントが index.js ではない — .mjs、server.js、または dist/ 内にネストされている	aws lambda-web deploy --entry-point {file} でデプロイするか、ZIP のルートにあるエントリポイントを index.js に変更する	unzip -l function.zip で最上位に index.js が表示される
10分以上 Pending のままになる	実行ロールの信頼ポリシーのプリンシパルが lambda.amazonaws.com ではない	信頼ポリシーを修正してから、新しいリビジョンを作成する	aws iam get-role に正しいプリンシパルが表示される
create-web-function-revision がメッセージなしで500を返す	実行ロールではなく、呼び出し元にコードバケットへの s3:GetObject / s3:GetObjectVersion 権限がない	呼び出し元のポリシーに両方を追加する	リビジョンが Active になる
invalid choice: 'lambda-web'、または Unknown parameter "BuildConfig" が表示される	AWS CLI が古い、または JSON キーが PascalCase になっている	CLI を更新し、camelCase（buildConfig、codeConfig）を使用する	aws lambda-web help に Web 関数のコマンドが表示される

移行

既存の Node.js HTTP アプリをこちらに移行する作業の大半は、コードを削除することです。アダプター、ハンドラーのエクスポート、API Gateway の接続設定がすべて不要になり、ルーター自体は変更されません。

4種類のソース構成それぞれについて、手順に沿った移行方法、事前確認チェックリスト、同等の機能がない機能、トラフィック切り替え手順を説明しています。対象は、アダプターでラップされたアプリ、API Gateway + Lambda プロキシ、Lambda 関数 URL、Fargate、App Runner、または EC2 上のコンテナです。 migration.md をご覧ください。

参照ファイルを読み込むタイミング

正確な文言ではなく、意味に基づいて照合してください。各行にあるトリガーワードのいずれかに一致した場合、そのファイルを読み込みます。

こちらを読む	トリガーワード
getting-started.md	初回デプロイ、始め方、セットアップ、前提条件、hello world、--hello-world、スターターアプリ、新しいプロジェクト、ゼロから、S3 コードバケット、実行ロール、ブートストラップ、初めての Web 関数
frameworks.md	Express、Fastify、Hono、TypeScript、.ts、型ストリッピング、ESM、type: module、スキャフォールド、プロジェクト構成、エントリーポイント、index.js、ルーター、ミドルウェア
deployment.md	デプロイ、再デプロイ、リリース、CLI、aws lambda-web、aws lambda-web deploy、1 つのコマンド、リビジョン、エンドポイント、パッケージ化、ZIP、npm ci、タイムアウト、環境変数、環境変数、カナリア、ブルー／グリーン、トラフィックの重み、ロールバック、versionId
scaling-and-concurrency.md	スケーリング制御、同時実行数、maxConcurrencyPerEnvironment、scalingConfig、maxEnvironments、throttleConfig、rateLimit、スロットリング、RPS 制限、vCPU クォータ、負荷テスト、Platform.EndpointMaxEnvThrottle
infrastructure-as-code.md	CloudFormation、CFN、CDK、CfnResource、エスケープハッチ、SAM、Terraform、HashiCorp、HCL、Infrastructure as Code、IaC、テンプレート、スタック、AWS::Lambda::WebFunction、AWS::Lambda::NetworkConnector、スタック内の VPC エグレス、AWS::Lambda::ResourcePolicy、再現可能なデプロイ、パイプライン
static-assets.md	静的ファイル、静的アセット、CSS、JS バンドル、画像、favicon、public/、express.static、SPA、シングルページアプリ、クライアントサイドルーティング、フォールバックルート、バンドル化、esbuild、Vite、キャッシュヘッダー
domains-and-routing.md	マルチリージョン、マルチリージョン、グローバル、レイテンシールーティング、Route53、ドメイン、カスタムドメイン、ホスト名、HTTPS、TLS、エンドポイントタイプ、HomeRegion、MultiRegion、PerRegion、CORS、認証タイプ、ApplicationManaged、IamAuth、CloudFront、OAC、オリジンアクセス制御、リソースベースポリシー
iam-and-security.md	IAM、ポリシー、権限、ロール、信頼ポリシー、PassRole、最小権限、AccessDenied、セキュリティ、認証、認証、認可、パブリックエンドポイント、WAF、DDoS、レート制限、シークレット、KMS、暗号化、セキュリティヘッダー、helmet
observability.md	ログ、ロギング、ロググループ、ログレベル、CloudWatch、メトリクス、モニタリング、アラーム、トレース、CloudTrail、監査、構造化ロギング、ヘルスチェック、どのリージョンが処理したか、本番環境でのデバッグ
architecture-patterns.md	SSR、サーバーサイドレンダリング、React、JSX、ストリーミング、SSE、サーバー送信イベント、LLM、AI ゲートウェイ、トークンストリーミング、長時間接続、Webhook、バックグラウンドタスク、ファイア・アンド・フォーゲット、API バックエンド、DynamoDB、コネクションプーリング、スレッドセーフ、同時実行モデル
troubleshooting.md	エラー、失敗する、失敗中、壊れている、動作しない、500、502、403、404、ECONNREFUSED、ERR_MODULE_NOT_FOUND、モジュールが見つからない、停止した、Pending、Failed、アクティブにならない、AccessDenied、ParamValidation、ログがない、デバッグ、なぜ〜しないのか
networking.md	VPC、プライベートサブネット、RDS、Aurora、ElastiCache、プライベートリソース、VPC エンドポイント、PrivateLink、ネットワークコネクタ、エグレス、egressNetworkConnectorArn、lambda-core、NAT ゲートウェイ、セキュリティグループ、プライベート DNS、プライベートホストゾーン、IPv6、DualStack、静的アウトバウンド IP
migration.md	移行、移行する、移動する、移植する、切り替える、変換する、〜からの移行、置き換える、serverless-express、アダプター、ラッパー、ハンドラーのエクスポート、関数 URL、API Gateway プロキシ、Fargate、App Runner、コンテナ化、リフト＆シフト

ガードレール — このスキル自体のファイルの保存場所（MCP とローカルインストール）

このスキルは 2 通りの方法で読み込めます。どちらの方法で読み込まれたかによって、スキルに同梱されているファイル（references/ ドキュメント）の参照先が異なります。リファレンスを読む前に、スキルがどの方法で読み込まれたかを確認してください。

• AWS MCP の retrieve_skill ツール呼び出しを通じて読み込まれた場合。 スキルはローカルファイルシステムにインストールされていません。そのため、リファレンスファイルはディスク上に存在しません。各リファレンスは、file パラメーターを指定して同じ retrieve_skill ツールから必ず取得してください（例：file="references/deployment.md"）。これらのパスをローカルディレクトリまたは作業ディレクトリから file_read したり、ファイルシステム内で検索したりしないでください。ファイルはそこには存在せず、たまたま同じ名前のローカルファイルが見つかっても、このスキルとは無関係です。
• ローカルにインストールされている場合（スキルが .claude/skills/aws-lambda-web-functions/、~/.claude/skills/aws-lambda-web-functions/、.kiro/skills/aws-lambda-web-functions/ などのローカルスキルディレクトリにある場合）。このドキュメント全体に記載されている相対パスを使い、ローカルのスキルディレクトリからリファレンスを読み込んでください。

この区別は、スキル自体にパッケージされているファイルにのみ適用されます。ユーザーのアプリケーションコード（index.js、package.json、public/、ビルドする function.zip）は、スキルの読み込み方法にかかわらず、常にユーザーの作業ディレクトリから読み込み、そこに書き込みます。retrieve_skill を通じて顧客データを取得したり書き込んだりしないでください。

重要なルール

1. Node 24 のみ — nodejs24.x だけが使用可能なランタイムです。ランタイムのサポート状況は変わることがあるため、新しいバージョンが利用できないと決めつける前に、aws lambda-web help または AWS ドキュメントで確認してください
2. エントリーポイントは index.js — ランタイムは .mjs ではなく /var/task/index.js を読み込みます。エントリーファイルの名前が別の名前（server.js、app.mjs など）の場合、aws lambda-web deploy がそれを検出するか、--entry-point を受け取り、インポートする小さな index.js を同梱します。自分で作成する ZIP では、ルートに index.js が必要です
3. AWS_LAMBDA_HTTP_ENDPOINT のホストとポートにバインドする — ランタイムはそのアドレスをそのままプローブするため、一致しないポートをハードコードしたり、ループバックのみにバインドしたりすると、レディネスチェックに失敗し、環境を使用できません。PORT 環境変数はありません
4. package.json に "type": "module" を指定する — index.js から ESM インポートを使うには必須です
5. ハンドラーをエクスポートしない — アプリは HTTP サーバーです
6. スレッドセーフなコードを書く — 1 つの実行環境で多数のリクエストを同時に処理します。グローバルな可変状態は避けてください
7. コード、ランタイム、タイムアウト、環境変数、同時実行数はすべてリビジョンに属する — いずれかを変更するには、インプレース更新ではなく、新しいリビジョンが必要です
8. バックグラウンドタスクはネイティブに動作する — レスポンスの後も環境は実行を継続します
9. ストリーミングはネイティブに対応 — チャンク転送エンコーディングと SSE を標準で利用できます
10. TypeScript はネイティブに動作する — Node 24 の型ストリッピングを使い、index.js シムと import type を使用してください
11. コードの提供元は S3 内の ZIP のみ — deploy がビルドしてアップロードします。それ以外の場合は、codeConfig.s3Object を通じて指定し、共有コードをパッケージに含めてください。コンテナイメージやレイヤー相当の機能が利用可能だと決めつけず、aws lambda-web create-web-function-revision help または API リファレンスで確認してください