aws-serverless

AWS Serverless

概要

このスキルは、AWS のサーバーレス作業におけるルーターです。アプリケーションの各コンポーネントと、提示された各判断軸（フォームファクター＋キャパシティプロバイダー＋オーケストレーション＋機能の選択肢）に対して、方針を明確にした推奨事項を 1 つずつ示し、その構成に必要なすべての専門スキルに引き継ぎます。複数のコンポーネントで構成されるアプリケーションを、無理に 1 つのフォームファクターにまとめないでください。このスキルでは、専用のスキルがない共通の Lambda リファレンス資料のみを扱います。

AWS MCP サーバー（https://docs.aws.amazon.com/aws-mcp/）と併用すると最も効果的です。サンドボックス化されたコマンド実行と監査ログ記録におすすめです。標準の AWS CLI アクセスを使う場合にも、すべてのガイダンスが適用されます。

このスキルの使い方： ステップ 0 で開始地点（新規作成、最適化、移行）を確定します。ステップ 1 では、テクノロジーがすでに指定されているコンポーネントを適切なスキルに振り分けます。ステップ 2 では、各コンポーネントについて、フォームファクターとキャパシティプロバイダーが確定するまで、コンピューティングの判断フロー（ティア 1 → 3）に沿って進みます。ティア 4 の特殊なケースについては、compute-decision-edge-cases.mdで詳しく説明しています。ステップ 3～5 では、リクエストで必要性が示された場合に限り、オーケストレーション、イベント処理、HTTP の入口を決定します。詳しい比較は、orchestration.mdとapi-gateway.mdに記載されています。その後、該当するすべての専門スキルに引き継ぎ、専用のスキルがない内容についてはこのスキルの共通リファレンスを参照してください。

振り分け先のスキルを利用できない環境でも、ここで行った判断は変わりません。以下の判断フローと共通リファレンスに基づいて回答し、推奨するフォームファクターと、そのフォームファクターを担当するスキルを明記してください。ドキュメントを見つけやすいという理由で、別のフォームファクターに切り替えてはいけません。特に、Lambda Web Adapter は、Node.js の HTTP アプリにおける Web Functions の代替ではありません。これは、Node.js 以外のランタイム、コンテナイメージ、または既存の API Gateway 統合向けの Event Functions の経路です。

ルール（すべての推奨に適用）

1. コンポーネントごと、および解決済みの判断項目ごとに明確な推奨を示します。 *「X を使ってください。理由は……です」*と述べます。要件の異なるコンポーネントに、同じサービスを無理に適用しないでください。また、中立的な比較表を回答として提示しないでください。決定済みの判断項目では、最も有力な代替案が適合しない理由を示す一節を加えます（たとえば、Event Functions と Web Functions には eBPF を使用するための OS レベルのアクセスがない、Durable Functions には Glue または ECS ジョブを開始して完了を待つためのネイティブな .sync 統合がない、など）。他のスキルやドキュメントを参照した後も、最終回答には推奨とその理由を残してください。

2. 提起されたコンポーネントと判断項目を、それぞれ独立して解決します。 フォームファクター、キャパシティプロバイダー、オーケストレーション、機能上の制約はそれぞれ別の判断項目です。1つを解決しても、他の判断項目は解決しません。コンポーネントごとに異なるフォームファクターを使うことも、1つのコンポーネントでコンピューティングのフォームファクターとオーケストレーションレイヤーを組み合わせることもできます。

3. 境界を推測せず、事実を推測します。回答する前に、提起された各判断項目を分類します。

   • 決定済み — リクエストに候補を分ける事実（ランタイム、トリガー、明示された期間やサイズ、「すべてのステップが Lambda 関数」「継続的に実行」など）が示されています → その判断項目を確定し、質問はしません。
   • 傾向あり — リクエストには定性的なヒント（「突発的」「不均一」「夜間は低負荷」「大きな依存関係」「信頼できない」「数千件の短時間タスク」「時間がかかる」など）だけが示されており、候補の選択を左右する観測可能な事実が未提示です → 暫定的な選択とその理由を先に示し、未確認の事実についてユーザーに直接質問します（文末は「？」にします）。また、どの回答で選択が変わるかを伝えます。回答が変わる条件を示すだけでは、質問の代わりになりません。ヒントは暫定的な推奨の根拠にはなりますが、決定に必要な事実の代わりにはなりません。
   • 未決定 — 使えるヒントがありません → その階層の絞り込み用の質問を使います。
   • 未提起 — リクエストでその判断項目について尋ねておらず、判断材料となる情報もありません → 質問せず、デフォルトを適用します（たとえば、トラフィック、実行時間、インスタンスタイプ、料金に関する情報がないイベントトリガーの関数には、Event Functions · On-Demand を適用します）。

   未提起または決定済みの判断項目を再び持ち出さないでください。質問は全体で3〜4問までとし、質問だけの回答はしないでください。数値のしきい値によって選択が決まる場合は、ユーザーがメトリクスから回答できるよう、質問にそのしきい値を明記してください（たとえば、5〜10分間のピーク値と平均値の比率が 2 未満なら Managed Instances、Tier 3 など）。

4. 情報に応じて見直します。 新しい情報があれば、影響する階層を再評価し、推奨を更新します。

5. 事実を推測しないでください。 制限、ランタイム、料金、タイムアウトについては、以下の共通リファレンスを根拠とし、精度が重要な場合は最新の AWS ドキュメントで確認してください。

6. 重複せず、適切なスキルに案内します。 専門スキルを選択したら、ここで内容を再導出せず、そのスキルに従ってください。

ステップ 0 — 起点：ユーザーは何をしていますか？

不明な場合は、一度だけ尋ねます。「新しく何かを始めるところですか、既存のワークロードを調整しているところですか、それとも既存のワークロードをサーバーレスに移行しようとしていますか？」

コンテキスト	手がかり	パス
新しいアプリケーション	「構築する」「開始する」「新しいプロジェクト」「グリーンフィールド」、既存のコンピューティング環境の指定がない	ステップ 1、続いてステップ 2 の判断フロー
既存環境の最適化	「請求額が高すぎる」「コールドスタート」「遅すぎる」「遅延」、現在の Lambda 構成の指定	ステップ 2 の Tier 3〜4（キャパシティ、コールドスタート、スループット）、続いて lambda.md、concurrency.md、troubleshooting.md
再プラットフォーム化／移行	「EC2／ECS から移行」「コンテナ化」「サーバーから脱却」「モダナイズ」	ランタイム、実行時間、パッケージングを最初の制約としてステップ 2 に進み、その後に最適化

ステップ 1 — 直接ルート（リクエストでテクノロジーがすでに指定されている場合）

ルート先	リクエストで名前が挙がっている、または明確に示されている内容	次の場合はルートしない
Event Functions — このスキル：lambda.md、event-sources.md	イベントソースまたはトリガー（SQS、Kinesis、Kafka、S3、DynamoDB Streams、EventBridge、SNS、API Gateway、ALB、IoT、Function URL）によって呼び出される Lambda 関数、Node.js 以外のランタイムで動作する HTTP ハンドラー、コンテナイメージ、Lambda レイヤー	ポートで待ち受ける Node.js HTTP サーバー（Web Functions）、顧客管理環境（MicroVM）、またはまだ決まっていないコンピューティング方式 — ステップ 2 を参照してください。Tier 3 で引き続き容量プロバイダーを決定します
aws-lambda-web-functions	Lambda Web Functions、aws lambda-web、Lambda 上にデプロイする Node.js HTTP サーバー（Express、Hono、Fastify）、CloudFront を前段に置く Node.js アプリ、マルチリージョン HTTP エンドポイント、アクティブ CPU 時間に基づく課金、ネイティブ HTTP レスポンスストリーミング	Node.js 以外のランタイム、コンテナイメージ、イベント駆動型トリガー（SQS、Kinesis、S3、DynamoDB Streams） — これらは Event Functions です
aws-lambda-microvms	Lambda MicroVM、Firecracker microVM イメージ、launch/suspend/resume/terminate、スナップショットから再開できる環境、VM レベルの分離、信頼できないコードや AI が生成したコードの実行、やり取りをまたいで保持されるファイルやプロセス、OS アクセス（FUSE、eBPF）、カスタムポートで動作する gRPC または WebSocket サーバー、最大 8 時間のセッション	通常のリクエスト／レスポンスやイベントハンドラーについて、「分離」だけが条件の場合。Event Functions は関数ごとの分離がデフォルトです。環境を呼び出し元専用にする必要がある場合は、テナント分離モードを使用してください
aws-lambda-managed-instances	Lambda Managed Instances（LMI）、容量プロバイダー、CapacityProviderConfig、PerExecutionEnvironmentMaxConcurrency、EC2 ベースの Lambda、Lambda 向け Savings Plans／Reserved Instances、関数に特定のインスタンスタイプを指定すること、最大 90 分の非同期実行または ESM 実行	インスタンスタイプやコミットメント要件がなく、ゼロまでスケールするバースト性の高いトラフィック
aws-lambda-durable-functions	耐久実行、チェックポイントとリプレイ、context.step／context.wait／context.invoke、withDurableExecution、durable-execution-sdk、Lambda 上でコードとして記述する Saga、LocalDurableTestRunner	ビジュアルワークフロー／ASL、Distributed Map、または AWS サービスと Lambda 以外のコンピューティングを広くオーケストレーションする場合 — ステップ 3 を参照してください
aws-step-functions	ステートマシン、Amazon States Language（ASL）、JSONata、Distributed Map、.sync／waitForTaskToken、ECS/Fargate、Glue、SageMaker、Batch のオーケストレーション	Lambda アプリケーションコードで管理するコードファーストのオーケストレーション — ステップ 3 を参照してください
amazon-eventbridge-event-bus	新しい EventBridge カスタムイベントバス（eventsv2）、独自のアプリケーションイベントを発行する新しいワークロード（単一アカウントを含む）、パブリッシュ／サブスクライブ、独立したサブスクライバー、コレオグラフィー、チーム／アカウント間で共有される中央バス、イベントグループ単位の順序付き配信、リプレイ、保持、重複排除、オープン形式（CloudEvents、Avro、Protobuf）に対応したスキーマレジストリ、または従来のカスタムバスからこれらの機能への移行	ルールとターゲットを使った既存の従来型カスタムバスの運用、EventBridge Scheduler、Pipes、Global Endpoints、単独の Schema Registry、API Destinations、Connections — これらはこのスキルの対象です（ステップ 4 と orchestration.md を参照）

ステップ 2 — コンピューティング方式の判断フロー

各アプリケーションコンポーネントについて、各 Tier を個別に実行します。前の Tier でそのコンポーネントに対する確信度の高い一致が得られなかった場合にのみ、次の Tier に進みます。まずフォームファクターを確定し（Tier 1～2）、Tier 3 で Event Functions の容量プロバイダーを決定し、ステップ 3 でオーケストレーションを決定します。コンポーネントを特定するにはプロンプトが曖昧すぎる場合は、次のように質問してください。「何を構築しようとしていますか？」

Tier 1 — ワークロードを実行形態に対応させる

Lambda には Event Functions、Web Functions、MicroVMs の 3 つの実行形態があります。リクエストに照らして以下のシグナルを確認してください。キャパシティプロバイダー（On-Demand と Managed Instances）は Tier 3 で別途判断します。

実行形態	リクエストに次の条件がある場合	代表的なユースケース
Event Functions	イベントソースまたはトリガー（SQS、Kinesis、Kafka、S3、DynamoDB Streams、EventBridge、SNS、API Gateway、ALB、IoT、Function URL）、HTTP ハンドラーに Node.js 以外のランタイムを使用、コンテナイメージ、Lambda レイヤー、イベントのファンアウト、リトライ／DLQ／冪等性のセマンティクス	イベント駆動型処理、キュー／ストリームのコンシューマー、サービス間の連携、API Gateway のバックエンド
Web Functions	ポートをリッスンする Node.js HTTP サーバー（Express、Hono、Fastify）、処理時間の大半をネットワーク待ちに費やす I/O 負荷の高いリクエスト／レスポンス、ネイティブのレスポンスストリーミングまたは SSE、長時間維持される接続／ロングポーリング接続、1 つのサンドボックス内での複数同時リクエスト、前段に CloudFront を配置、マルチリージョンのエンドポイント、「アクティブな CPU 使用時のみ課金」	Node.js のウェブアプリや REST バックエンド、AI レスポンスのストリーミング、下流サービスへの並列呼び出しをファンアウトしてレスポンスを組み立てる Node.js バックエンド
MicroVMs	お客様が管理するサンドボックスのライフサイクル（起動／一時停止／再開／終了）、セッションをまたいで保持する必要がある状態（メモリ、ディスク、プロセス）、信頼できないコードまたは LLM が生成したコード、OS へのアクセス（FUSE、eBPF）、カスタムポート、セッション単位またはテナント単位の VM 分離、最大 8 時間のセッション	AI エージェントのコードサンドボックス、ブラウザー IDE やノートブック、CI／ビルドランナー、セキュリティスキャナー、一時的な開発環境

リクエストに複数のコンポーネントが記載されている場合は、複数の行が該当することがあります。行どうしをアプリケーション全体で排他的なものとして扱うのではなく、各コンポーネントを個別に振り分けてください。たとえば、Web Function のコントロールプレーン API と MicroVM のセッションワーカーを組み合わせます。

判断が分かれる場合の制約：Web Functions と MicroVMs は On-Demand でのみ実行できます。Managed Instances は Event Functions のキャパシティプロバイダー（Tier 3）であり、実行形態ではありません。Durable Functions は Event Functions（On-Demand または Managed Instances）でのみ実行されます。Web Functions は Node.js のみ対応です（zip のみで、コンテナイメージ、イベントソースマッピング、Provisioned Concurrency、SnapStart は使用できません）。実行時間の上限は、On-Demand では 1 回の呼び出しあたり 15 分、Web Functions では 15 分、Managed Instances の同期呼び出しでは 15 分です。Managed Instances の非同期呼び出しまたは ESM 呼び出しでは 90 分、MicroVM のセッションでは 8 時間です。これを超える時間が必要な場合は、Lambda の対象外です。

絞り込みの質問（Tier 1 でリクエストからコンポーネントを分類できない場合のみ。すでに明らかな情報は尋ねないでください）：

1. Functions と MicroVMs の比較 — 次のように尋ねます。「このコンポーネントは個々のリクエスト／イベントを処理するだけですか。それとも、セッションごとに、やり取りの合間もファイル、メモリ、プロセスを保持する環境が必要ですか？」 → 環境を保持する／お客様がライフサイクルを制御する場合は MicroVMs（各セッションが 8 時間以内であることを確認）。個々の実行の場合は Functions → Q2。
2. Event と Web の比較 — 次のように尋ねます。「このコンポーネントはキュー、ストリーム、イベントソース、または Lambda の HTTP 統合経由で呼び出されますか。それとも、ポートをリッスンする Node.js HTTP サーバーですか？」 → イベント／ハンドラー統合の場合は Event Functions → Tier 3。Node.js HTTP サーバーの場合は Web Functions の候補 → Tier 2。

耐久性は実行形態を決める問いではありません。クラッシュ後も存続する必要がある複数の協調ステップとして処理を実行するのか、タイマー、コールバック、承認を待ってから再開するのかは、実行形態とキャパシティプロバイダーが決まった後、Step 3 で判断します（Durable Functions は、対応するいずれかのキャパシティプロバイダーである On-Demand または Managed Instances を使用して Event Functions 上で実行されます）。

Tier 2 — Web Functions と Event Functions の比較

Web Functions が候補になる場合、または Tier 1 で Web Functions と Event Functions を区別できなかった場合は、コンポーネントごとにこの Tier を実行します。まず、リクエストまたはプロジェクトからランタイム、パッケージング、既存の統合を推測し、ルートを決めるうえで必要な情報が不足している場合に限り、最初の不足情報を確認します。

#	質問	回答 → 判定
Q1	アプリのランタイムは何ですか？	Node.js 以外 → Event Functions（例：API Gateway、ALB、または Function URL の背後で動作する Flask／Django／Spring／.NET。必要に応じて Lambda Web Adapter 経由）。Node.js → Q2
Q2	コンテナイメージでのデプロイが必要ですか？	はい → Event Functions。いいえ → Web Functions
Q3	（統合がすでに導入されている場合のみ）現在、アプリは何と統合していますか？	CloudFront → Web Functions。API Gateway → Event Functions（既存の統合には実際の移行コストが伴うため、計画的に移行してください）

結果：Web Functions → aws-lambda-web-functions に進みます（オンデマンドのみ。プロビジョンドコンカレンシー、SnapStart、マネージドインスタンスは適用されません）。このスキルが読み込まれていない場合に必要な基本情報：Node.js サーバーはハンドラーを書き換えることなく、ポートで待ち受け続けます。aws lambda-web create-web-function による ZIP デプロイ（lambda-web コマンドが認識されない場合は、AWS CLI が古い状態です）。多くの同時リクエストが 1 つの実行環境を共有し、課金対象は CPU の稼働時間とメモリです。そのため、I/O 待ちでブロックされている時間は CPU の課金対象になりません。ネイティブのレスポンスストリーミング（SSE、LLM トークン）に対応しています。オプションでマルチリージョン配信を利用でき、CloudFront を前段に配置できるグローバル HTTPS エンドポイントです。Event Functions → Tier 3。

Tier 3 — 容量プロバイダー（Event Functions のみ）

Event Functions は、2 種類の容量プロバイダーのいずれかで実行されます。オンデマンドはゼロまでスケールし、アイドル期間が十分にある、急増するトラフィックや予測しにくいトラフィックに適しています。Lambda Managed Instancesは、お客様のアカウント内の EC2 インスタンスで関数を実行し、継続的に利用されるトラフィック（5～10 分以内のピーク対平均比が 2 未満）、特定の EC2 インスタンスタイプが必要な場合、Savings Plans／Reserved Instance の料金を利用する場合、または最大 90 分の実行（非同期または ESM 呼び出しのみ）に適しています。Managed Instances が適する一般的なワークロードには、常時稼働するストリームコンシューマー、API Gateway の背後で常に高負荷の API、長時間実行される非同期バッチジョブがあります。

リクエストやメトリクスからトラフィックのパターンを推測します。情報がなく、その情報によって判断が変わる場合は、観測可能な条件を使って一度だけ質問します。「ピークトラフィックは、5～10 分のいずれの時間枠でも平均の 2 倍未満（ピーク対平均比が 2 未満）に収まりますか。それとも、それより大きく急増したり、ゼロまで下がって十分な時間アイドル状態になったりしますか。コミットメントベースの料金や特定のインスタンスタイプが必要ですか？」

• トラフィック、実行時間、インスタンスタイプ、料金に関する情報がない → 容量について質問せず、Event Functions · オンデマンドを推奨します（Rule 3、Unraised）。
• 急増やアイドル期間があり、インスタンス／コミットメントの要件がない → Event Functions · オンデマンド。
• 継続的に利用される、またはインスタンス／コミットメントの要件がある → Event Functions · Managed Instances → aws-lambda-managed-instances に案内します。

Managed Instances は関数の作成時に選択します。容量プロバイダーに関連付けた新しい関数を作成し、トラフィックをその関数に移します。既存のオンデマンド関数で設定を切り替えることとして説明してはいけません。

1 回の実行に 15 分を超え、最大 90 分かかる場合も Managed Instances を選択します（非同期または ESM 呼び出しのみ。同期呼び出しは、どちらのプロバイダーでも 15 分が上限です）。インスタンスタイプや料金を尋ねるためだけに、明示された継続的／常時高負荷のシグナルを再確認しないでください。リクエストに「安定している」とだけある場合は、実際に継続して実行されるのか、長時間のアイドル期間があるのかを尋ねます。「急増する」「負荷が軽い」「むらがある」「長時間静かな状態が続く」といった語はオンデマンドを示唆しますが、Managed Instances も検討されている場合は Leaning のヒントとして扱います（Rule 3）。オンデマンドを暫定的に推奨し、ピーク時に同時実行される呼び出し数と、トラフィックが実際にゼロまで下がるかを尋ねます（Managed Instances は、複数の同時実行呼び出しを 1 つの実行環境にまとめます。そのため、同時実行される場合にのみ効果があります）。短時間のタスクが多数並列実行されることだけでは、Managed Instances を選ぶ根拠になりません。作業が、ゼロまで処理しきる単発または定期的なバッチ（オンデマンド）なのか、継続的なストリーム（Managed Instances）なのかを尋ねます。

Tier 4 — エッジケース（フォームファクターと容量を確定した後）

概要レベルの判断を示します。質問内容、しきい値、注意事項については compute-decision-edge-cases.md を参照してください。リクエストでこれらの項目が問題になる場合は、必ず内容を確認してください。

• 実行時間 — 耐久性のあるワークフロー全体の実行時間と、1 回のアクティブな呼び出しの実行時間は別々の上限として扱います。上限が明記されていない場合、それは値ではありません。「長時間実行される」「15 分を大幅に超える」などの表現は、90 分超を意味するものではありません。15 分を超えることは分かっているものの、最大時間の記載がない非同期呼び出しまたはイベントソースマッピングの呼び出しには、暫定的に Managed Instances を推奨し、次のように尋ねます。「1 回の呼び出しのうち、最も長いものの最大実行時間はどのくらいですか？」 90 分以下 → Managed Instances、90 分超 → aws-containers ／ aws-compute。顧客管理のサンドボックスまたはステートフルセッションには、最大 8 時間まで MicroVMs を使用します。MicroVM セッションが 8 時間を超える場合 → aws-compute。同期 Event Function が 15 分を超える場合 → aws-containers ／ aws-compute。複数の連携する Lambda タスク → Durable Functions（ステップ 3）。
• ストリームまたはキューの遅延（バックログ、ApproximateAgeOfOldestRecord の増加）→ イベントソースマッピングのプロビジョニングモード（最小／最大ポーラー数）。Provisioned Concurrency ではバックログは解消されません — concurrency.md。
• オンデマンド時の初回リクエストのレイテンシー → まず無料でできる対策（デプロイパッケージの縮小、レイヤーの数やサイズの削減、遅延初期化、適切なメモリサイズの設定 — lambda.md）を行い、その後、次の 3 つの対策から選択します。環境の起動が遅延の原因で、数十ミリ秒のオーバーヘッドが求められる場合は Provisioned Concurrency、Java、Python、または .NET の重い初期化コードが原因で、サブ秒のレイテンシーが許容される場合は SnapStart（zip または任意のコンテナイメージ）、トラフィックが途切れることなく一定の最低水準を保つ場合は Managed Instances を選びます。「常時ビジー」または継続的なトラフィックという明示的なシグナルがあれば、すでに決定済みです → Managed Instances。レバーについて質問する必要はありません。トラフィックが波状に発生する、または「静かになる」という情報だけでは、トラフィックがゼロになるかどうかは分かりません。暫定的な対策を提示し、トラフィックがゼロまで下がるか、ランタイムは何か、遅延の原因が環境の起動か初期化コードかを尋ねます。
• パッケージングと容量は別々に判断します — zip とコンテナイメージのどちらにするかはアーティファクトのサイズで決まり（zip の上限を超える場合はコンテナイメージ、lambda.md）、容量プロバイダーはトラフィックの形状で決まります。ネイティブバイナリや大きな依存関係について言及があり、サイズが不明な場合は、zip の上限を超えるならコンテナイメージを使うオンデマンドを推奨し、パッケージのサイズを尋ねます。
• コールドスタートをなくすために、安定した、または「常時ビジー」なトラフィックが挙げられている場合 → Managed Instances（ウォーム状態の、複数の同時実行に対応したインスタンスによりコールドスタートがなくなります）。
• 信頼できないコード、またはユーザーが送信したコード → 暫定的に MicroVMs を推奨します（VM レベルのセッション分離、OS へのアクセス、顧客管理のライフサイクル下で保持される状態）。そのコードが敵対的な可能性があるか、より高い権限の OS アクセスやカスタムポートが必要か、実行をまたいで状態を保持するかがリクエストに記載されていない場合は、質問し、両方の選択肢を示します。認証済みユーザーによる、テストされていないものの敵対的ではないコードの短時間かつステートレスな実行は、Event Functions · On-Demand でも可能です。各実行環境は一度に 1 件の呼び出しを実行し、関数間で共有されることはありません。
• テナント分離 → 呼び出し元ごとに専用の実行環境が必要なイベントハンドラーには、Event Functions · On-Demand の テナント分離モードを使用します。これは呼び出しごとに新しい VM を作成するものではありません。テナントごとに永続する環境、信頼できないコード、保持されるファイル／プロセス、または OS へのアクセス → MicroVMs。「厳格なテナント分離」という要件だけの場合は、判断保留です（ルール 3）。暫定的にテナント分離モードを推奨し、テナントが独自のコードを実行するか、永続環境や OS アクセスを必要とするかを尋ねます。
• シグナルが矛盾する場合 — たとえば、トラフィックが安定して多い Node.js ウェブアプリ（プログラミングモデルでは Web Functions、トラフィックでは Managed Instances）では、両方の選択肢とそれぞれのトレードオフを一文で提示し、ユーザーに選んでもらいます。それ以外の場合は、推奨を 1 つに絞ります。

判断後の引き継ぎ

該当する行をすべて適用します。実装の各側面はそれぞれ専用のスキルが担当します。コンポーネントによっては、コンピューティングのスキルとオーケストレーションのスキルの両方が必要になる場合があります。Event Functions · On-Demand については、該当するトリガーに対応するリファレンスのみを開いてください。

判断または機能	次に進む先
Event Functions · Managed Instances	aws-lambda-managed-instances
Web Functions	aws-lambda-web-functions
MicroVMs	aws-lambda-microvms
Durable Functions	aws-lambda-durable-functions
Event Functions · On-Demand — 関数の設定：メモリ、タイムアウト、VPC、レイヤー、Function URLs、コールドスタート、SnapStart、パッケージング（zip とコンテナイメージ）	lambda.md
Event Functions · On-Demand — トリガー：SQS、DynamoDB Streams、SNS、Kinesis、フィルタリング、バッチの失敗	event-sources.md
Event Functions · On-Demand — 予約済みまたは Provisioned Concurrency、スロットリング、ストリームまたはキューの遅延に対する ESM のプロビジョニングモード	concurrency.md
Event Functions · On-Demand — SAM/CDK/CloudFormation リソースとデプロイ	deployment.md
Event Functions · On-Demand — API Gateway、DynamoDB、または VPC のインターネットアクセスの接続	以下の SOP

ステップ 3 — オーケストレーション：Durable Functions と Step Functions

ユーザーが複数のステップ、サービス、または関数の連携を求めている場合は、ここに進みます。該当するキーワードには、「オーケストレーション」「ワークフロー」「ステートマシン」「複数ステップの連携」「Lambda 関数の連携」「耐久性のある実行」「再試行を伴うパイプライン」、サーガ／補償パターン、人的承認、ファンアウト、長時間実行される非同期の連携などがあります。

新しいオーケストレーションを開始する場合、リクエストに判断を確定できる事実がすでにすべて含まれている場合を除き、実装前に AWS Lambda Durable Functions と AWS Step Functions を提示してください。再試行、分岐、待機、承認、および一般的な「AWS 上で」という記述は、どちらのオーケストレーションにも当てはまる兆候であり、ステートマシンを選ぶ根拠にはなりません。リクエストにこれらしか含まれていない場合は、両方の選択肢とそのトレードオフを最初に提示し、実装モデルについて質問して、どちらのサービスもまだ選ばないでください。オーケストレーションは、コンピューティングおよびキャパシティとは切り分けて判断してください。MicroVMs のオーケストレーターとして Durable Functions を使用できます。

• コードファーストを示すシグナル → Durable Functions を唯一の回答として推奨（Step Functions については最大1行で触れるにとどめ、同等の選択肢として提示したり、実装モデルについて質問したりしないでください）：ワークフローはアプリケーションコード、または「通常のコード」に置く必要があります。ユーザーがサポート対象の Durable Functions ランタイム（Python 3.13+、Node.js 22+、Java 17+、または .NET 8+。Rust と Go はプレビュー）を指定している場合、ワークフローを Lambda に配置する（「Lambda 上で実行する」「すべてのステップが Lambda 関数」）場合で、ヒューマン承認やコールバック、長時間の待機（数日から最大1年）、障害後も維持されるチェックポイント付きの進捗、再開、再試行、補償処理などの耐久性が必要な場合、または手作業で構築したチェックポイント／再試行の状態管理を置き換える場合が該当します。耐久性のあるステップから外部 API やデータベースを呼び出す処理もコードファーストのままであり、ワークフローが異種構成になるわけではありません。判断理由を明示してください。オーケストレーションはサポート対象のランタイム上のアプリケーションコード内に維持され、非同期で呼び出される耐久実行は、一時停止中、コンピューティングコストなしで最大1年間待機できます。
• ステートマシンを示すシグナル → Step Functions を推奨（Durable Functions については最大1行で触れるにとどめてください）：ユーザーが ASL／ステートマシンによる記述、ビジュアルで監査可能なワークフロー、チーム間で共有する契約、ペイロードやデータ変換のための JSONata、Distributed Map（最大10,000件の並列子実行で、数億件の項目を反復処理）、各状態を個別に単体テストする TestState、またはサポート対象外のランタイムを明示的に求めている場合が該当します。
• 実装モデルが明示されていない — リクエストでサポート対象の言語もステップの実行場所としての Lambda も指定されておらず、ステートマシンを示すシグナルもない場合に限ります（「AWS 上で」の一般的な Saga、承認、ファンアウト、再試行、分岐、クラッシュリカバリーのリクエストなど）。コードファーストのオーケストレーションには暫定的に Lambda Durable Functions を推奨し、ビジュアル／ASL ベースで幅広いサービス統合に対応する選択肢として AWS Step Functions を、トレードオフを1行で示して紹介し、次のように尋ねてください。「すべてのステップをご自身のコードとして Lambda 上で実行しますか。それとも、ビジュアルなステートマシンでほかの AWS サービスを連携させますか？」 耐久性のある設計自体も不明確な場合は、最長の待機時間や、厳密に1回だけ実行する必要のあるステップがあるかを尋ねてください。待機、承認、クラッシュリカバリーといった耐久性のシグナルだけでは、オーケストレーションが必要だとは判断できますが、その配置先までは判断できません。コードから外部 API やデータベースを呼び出すという理由だけで、Step Functions を選ばないでください。

トレードオフ（どちらも適する場合に使用）： Durable Functions では、Lambda のアプリケーションコード内でオーケストレーションを行います。対応ランタイムは Python 3.13+、Node.js 22+、Java 17+、.NET 8+ で、Rust と Go はプレビューです。チェックポイント／リプレイ（context.step／context.wait／context.invoke）、再試行、条件分岐、コールバック、実行履歴に対応します。非同期呼び出しによる耐久実行は、待機中、コストなしで最大1年間実行できます。各ステップは、引き続き Event Functions の容量プロバイダーのタイムアウト内に収める必要があります。Step Functions では、オーケストレーションをマネージド型のビジュアルなステートマシンに切り離し、200以上のネイティブなサービス統合と Distributed Map を利用できます（Standard 実行は最大1年、Express 実行は最大5分）。比較の全文：orchestration.md。実装については、振り分け先のスキルに委ねてください。

ステップ 4 — イベント処理：EventBridge の機能の選択

リクエストで説明されているユースケース（トリガー、イベントの発生元、トポロジー、既存の投資）に基づいて機能を選択してください。EventBridge に関する確認質問はしないでください。詳細は orchestration.md を参照してください。

• 時間ベースのトリガー（cron、rate、1 回限りの実行。再試行、イベントの最大経過時間、DLQ を含む）→ スケジュール式を使ったルールや常時稼働ワーカーではなく、EventBridge Scheduler。
• ポーリングベースのソース 1 つから Lambda 関数 1 つへ（SQS、Kinesis、DynamoDB Streams、Kafka/MSK、Amazon MQ）。ネイティブのバッチ処理、フィルタリング、再試行の制御で十分な場合 → Pipe ではなく、Event Function のネイティブなイベントソースマッピング。
• ポーリングベースのソース 1 つから、フィルタリング、エンリッチメント、または変換を伴うターゲット 1 つへ、または Lambda 以外のターゲットへ → EventBridge Pipes。Pipe のターゲットは必ず 1 つです。
• ポーリングベースのソースからのイベントを複数のコンシューマーが必要とする場合 → 1 つの Pipe でフィルタリング／エンリッチメントを行い、新しいカスタムイベントバスをターゲットにできます。各コンシューマーがサブスクライバーを管理します。ファンアウトを実現するためだけに、コンシューマーごとに Pipe を作成しないでください。
• デフォルトバス上の AWS サービスの状態変更イベント、または既存の従来型の単一アカウント統合 → コンテンツベースのパターンを使用する EventBridge ルール。
• 新しいワークロードが独自のアプリケーションイベントを発行する場合（単一アカウントのワークロードを含む）、または独立したサブスクライバー、保持／再生、順序付け、重複排除、スキーマレジストリ、チーム間／アカウント間共有が必要な場合 → 新しい EventBridge カスタムイベントバス（eventsv2）→ amazon-eventbridge-event-bus。
• 既存の従来型カスタムバスを新しいバスの機能へ移行する場合 → amazon-eventbridge-event-bus の移行ガイダンス。プロデューサーとコンシューマーを個別に移行できるように、従来型バスと新しいバスをブリッジしてください。Global Endpoints など、サポートされていない要件には従来型バスを引き続き使用してください。

定義された順序でステップを実行し、進捗のチェックポイント、再試行、待機、または補償処理が必要な場合、それはイベント処理ではなくオーケストレーションです。ステップ 3 で Durable Functions と Step Functions のどちらにするかを決めてください。

ステップ 5 — HTTP のフロントドア

Node.js HTTP サーバー → Web Functions（Tier 2）。ランタイムやサーバーモデル、API 管理が必要かどうかを明示せずに HTTP エンドポイントを求めるリクエストは、Lean（ルール 3）に該当します。3 つの選択肢（Node.js サーバー向けの Web Functions、Event Function の前段に置く API Gateway、API 管理なしで 1 つの関数に使う Function URL）を示し、暫定的なデフォルトを提示したうえで、ランタイム／サーバーモデルと、クライアントごとのレート制限、API キー、WAF、リクエスト検証が必要かどうかを質問してください。それ以外の場合は、デフォルトで Event Function の前段に API Gateway HTTP API を配置します。REST API と比べてリクエストあたりの料金を最大約 70％抑えられ、レイテンシーも低くなります。REST API 固有の機能（WAF、使用量プランと API キー、リクエストの検証と変換、キャッシュ、カナリアデプロイ、プライベートまたはエッジ最適化エンドポイント）が必要な場合に限り、REST API を選択してください。API のフロントドアを推奨する際は、このコストと機能のトレードオフを明示してください。永続的な双方向接続 → API Gateway WebSocket API。API 管理なしで HTTPS エンドポイントを必要とする単一の Event Function → Lambda Function URL。フロントドアの一覧表、クォータ、オーソライザーについては api-gateway.md を参照してください。接続手順については、以下の API Gateway SOP を参照してください。

ステップごとのタスク手順（テスト済みの CLI 標準作業手順）

このスキルを使用	タスク
connecting-lambda-to-api-gateway	既存の Lambda を新しい REST/HTTP API に接続します：プロキシ統合、権限、CORS、スロットリング、アクセスログ、デプロイ
connecting-lambda-to-dynamodb	Lambda を DynamoDB に接続します：IAM 実行ロール、読み取り／書き込み権限、ストリームのイベントソースマッピング
creating-api-gateway-stage	CloudWatch ログ、X-Ray トレース、スロットリング、WAF の関連付け、認可を設定した API Gateway ステージを作成します
deploying-custom-domain-rest-api	カスタムドメインを使用してリージョナル REST API をデプロイします：ACM 証明書、Lambda バックエンド、リクエストオーソライザー、ベースパスマッピング、Route 53 DNS
debugging-lambda-timeouts	タイムアウトする Lambda を体系的に診断します：設定、CloudWatch ログ／メトリクス、VPC、コールドスタート、メモリ、下流の呼び出し
enabling-lambda-vpc-internet-access	VPC に接続された Lambda にインターネットアクセスを付与します：NAT Gateway、サブネットのルーティング、セキュリティグループ
processing-s3-uploads-with-step-functions	イベント駆動型ワークフローをデプロイします：S3 アップロード → EventBridge → Step Functions → Lambda（小さなファイル）または Fargate（大きなファイル）。VPC/ECR/ECS/IAM を使用します

このスキルで共有されるリファレンス

ユーザーのニーズ	参照先
Tier 4 のエッジケース：実行時間の上限、コールドスタートとストリームの遅延、SnapStart と Provisioned Concurrency、定常状態の Managed Instances、テナントの分離	compute-decision-edge-cases.md
コンピューティングを選択した後に、新しいサーバーレスアプリケーションを構築するパターン	architecture.md
Lambda の設定、コールドスタート、SnapStart、メモリ、VPC、レイヤー、Function URLs	lambda.md
同時実行数（予約済み、プロビジョニング済み、プロビジョニングモードを含む ESM の制御）	concurrency.md
イベントソース（SQS、DynamoDB Streams、SNS、Kinesis）、フィルタリング、バッチの失敗	event-sources.md
Step Functions と Durable Functions の比較、Standard と Express、EventBridge の機能一覧、ルール／パイプ／スケジューラーの詳細	orchestration.md
HTTP のフロントドア一覧、API Gateway のクォータ、オーソライザー、WebSocket	api-gateway.md
SAM/CDK のリソースタイプと迅速な反復	deployment.md
本番環境への対応、可観測性、アンチパターン	production.md
エラーのデバッグ（正確な文字列 → 原因 → 修正方法）	troubleshooting.md
Powertools のハンドラーテンプレート	powertools-handler.py

セキュリティに関する考慮事項

• すべての推奨事項は Lambda のベースラインを引き継ぎます。関数ごとに最小権限の実行ロールを設定し、Function URL や API Gateway に * を含むリソースポリシーを設定しないでください（AuthType: NONE とオープンアクセスは、決してデフォルトではありません）。キュー、ストリーム、状態データは保存時に暗号化し、エラーやスロットリングに対して CloudTrail と CloudWatch のアラームを設定してください。
• オーケストレーションサービスはワークフローの状態とペイロードを保持します。Step Functions は実行履歴に完全な入力／出力を記録します（コンソール、および有効にしている場合は CloudWatch Logs）。実行ログを有効にし、失敗時にアラームを設定し、ワークフローごとに最小権限のロールを使用してください。ワークフローの状態にシークレット、トークン、PII を渡さないでください（Secrets Manager／ARN のポインターで参照してください）。状態データに機密情報が含まれる場合は、カスタマー管理の KMS キーを適用してください。
• 一般的なマルチテナントのハンドラーでは、テナント分離モードにより、Event Functions の実行環境を 1 つの呼び出し元専用にします。呼び出しごとに新しい VM が作成されるわけではありません。信頼できないコード、セッションごとに保持される状態、顧客が制御するライフサイクル、または OS へのアクセスが必要な場合は、MicroVMs を使用してください。共有実行環境内でのアプリケーションレベルのサンドボックス化に依存しないでください。
• パブリック HTTP エンドポイント（Web Functions、API Gateway、Function URL）は、スロットリング、入力検証、ACM 証明書による TLS を設定した AWS WAF の背後に配置してください。

注: リファレンスファイルには、変更される可能性のある特定のランタイムバージョン、クォータ、価格の割増額、機能マトリックスが含まれています。正確性が重要な場合（本番環境、ランタイムの選択、クォータなど）は、最新の AWS ドキュメントで確認してください。リファレンスでは、基本事項ではなく、間違えやすい値や注意点に重点を置いています。

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

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

• AWS MCP の retrieve_skill ツール呼び出しを通じて読み込まれた場合。 スキルはローカルファイルシステムにインストールされていません。参照ファイルとアセットファイルはディスク上に存在しません。それぞれのファイルを、file パラメーターを指定して同じ retrieve_skill ツールから取得する必要があります（例：file="references/lambda.md" または file="assets/powertools-handler.py"）。これらのパスをローカルディレクトリや作業ディレクトリから file_read してはいけません。また、ファイルシステム内を検索してはいけません。ファイルは存在せず、名前が一致するローカルファイルがあっても、このスキルとは無関係です。
• ローカルにインストールされている場合（.claude/skills/aws-serverless/、~/.claude/skills/aws-serverless/、.kiro/skills/aws-serverless/ などのローカルスキルディレクトリにスキルが存在する場合）。このドキュメント内で示されている相対パスを使用し、ローカルのスキルディレクトリから参照ファイルとアセットを読み込んでください。

この違いが当てはまるのは、スキルに同梱されたファイルだけです。ユーザーのアプリケーションコード（ハンドラー、SAM/CDK テンプレート、package.json、デプロイ成果物）は、スキルの読み込み方法にかかわらず、常にユーザーの作業ディレクトリから読み書きします。retrieve_skill を通じて顧客データを取得または書き込んではいけません。