AWS DVA 無料サンプル

Lambdaの実行環境（execution environment）はInit・Invoke・Shutdownの3フェーズからなるライフサイクルを持つ。 コールドスタート時にInitフェーズでランタイムの初期化・拡張機能の初期化・ハンドラーファイルのグローバルスコープのコード実行が行われ、 その後に実行環境は一定時間（ウォーム状態）維持され、後続の呼び出しで再利用される。

• DB接続クライアントやAWS SDKクライアントをハンドラー関数の外（グローバルスコープ）で初期化しておくと、 Initフェーズで一度だけ生成され、後続のウォーム実行では再生成せずにそのまま再利用される。
• これによりウォーム実行時のレイテンシが下がり、DBへの新規接続確立回数も抑えられ、接続枯渇のリスクを軽減できる。
• ハンドラー関数内で毎回生成すると、ウォーム実行であっても呼び出しのたびに接続確立コストが発生し、この最適化の恩恵を受けられない。

Lambdaレイヤーは、複数の関数間で共有したいライブラリ・カスタムランタイム・共通コードを 関数本体のデプロイパッケージとは別の.zipアーカイブとしてパッケージ化し、複数の関数にアタッチできる仕組みである。

• 共通のロギングライブラリと社内ユーティリティを1つのレイヤーとして発行し、10個の関数それぞれにそのレイヤーをアタッチする。
• ライブラリを更新する際はレイヤーの新しいバージョンを発行し、各関数の設定でアタッチするレイヤーのバージョンを更新するだけでよく、 関数本体のコードやデプロイパッケージ自体は変更不要（関数コードと依存関係を分離できる）。
• 関数は最大5つのレイヤーをアタッチでき、関数コード＋全レイヤーの展開後の合計サイズは250MB以内に収める必要がある。

Lambdaの環境変数は常にAWS KMSで暗号化されて保存される。追加設定をしなければ、Lambdaサービスが管理する デフォルトのAWS管理キー（aws/lambda）で自動的に暗号化されており、追加コストは発生しない。

• より厳格な監査（CloudTrailでのキー使用履歴）やキーポリシーによるアクセス制御が必要な場合は、カスタマー管理のCMKを指定して暗号化できる。
• ただし、環境変数の値はデフォルトでは lambda:GetFunction 等の権限を持つ者にはコンソール/API上で平文表示され得る。 値そのものを平文表示から保護したい場合は「転送時の暗号化ヘルパー」を有効化し、クライアント側で暗号化した値をコード側で復号する実装が必要になる。
• 環境変数の合計サイズには4KBの上限があり、これを超える設定値はParameter StoreやSecrets Managerを参照する設計にする必要がある。

予約済み同時実行数（reserved concurrency）をPaymentFunctionに設定すると、 その値がアカウント全体の同時実行数プールから切り出され、他の関数からは使われない専用の枠として確保される。

• これによりPaymentFunctionは、他の関数がどれだけ同時実行数を消費していても、設定した数までは常に実行を保証される。
• 同時に、予約済み同時実行数はその関数が同時に実行できる上限（キャップ）としても働く。設定値を超える呼び出しはスロットリングされる。
• 予約済み同時実行数を設定した分、アカウントの「未予約」同時実行プール（他の全関数が共有する枠）は減少するため、 他の関数への影響を考慮して値を決める必要がある。

プロビジョンド同時実行（provisioned concurrency）を設定すると、Lambdaは指定した数の実行環境を 事前に初期化（Initフェーズを事前実行）した状態で待機させる。呼び出しが来た時点ですでにInitフェーズが完了しているため、 コールドスタートに起因するレイテンシが発生しない。

• 特定のバージョン/エイリアスに対して設定し、API GatewayからそのエイリアスのARNを呼び出す構成にする。
• トラフィックが平日日中に偏っているのであれば、Application Auto Scalingのスケジュールベースのスケーリングで、 日中はプロビジョンド同時実行数を増やし、夜間・休日は減らすことでコストを最適化できる。
• プロビジョンド同時実行は設定した容量分、呼び出しの有無に関わらず課金されるため、トラフィックパターンに応じたスケジューリングが重要になる。

両者はどちらも「同時実行数」に関わる設定だが、目的とコスト特性が全く異なる。

• 予約済み同時実行数：アカウントの同時実行数プールから専用枠を確保/上限を設けるだけであり、 実行環境の事前初期化は行わない。設定自体に追加課金は無い（通常の実行時間課金のみ）。
• プロビジョンド同時実行：指定数の実行環境を事前に初期化して待機させる。 呼び出しの有無に関わらず、設定した容量分の時間課金が発生する（未使用でも課金対象）。
• プロビジョンド同時実行はApplication Auto Scalingと統合でき、スケジュールベース（時間帯指定）や ターゲット追跡（利用率メトリクスに基づく自動調整）でスケーリングできる。
• プロビジョンド同時実行を設定してもアカウント全体の同時実行数上限そのものが引き上がるわけではない。あくまで既存の上限の中で確保される容量である。

非同期呼び出し（S3、SNS、EventBridge等がトリガーとなるケース）でハンドラーがエラーを返す（または関数が異常終了する）と、 Lambdaは自動的に最大2回まで再試行する（初回呼び出し＋既定で2回のリトライ＝合計最大3回の試行）。

• 再試行の間には遅延（バックオフ）が設けられる。再試行回数はMaximumRetryAttempts（0〜2）で減らすことができ、 MaximumEventAgeInSecondsでイベントが再試行対象となる最大経過時間を制御できる。
• すべての試行が失敗し、かつDLQやon-failure destinationが未設定の場合、そのイベントは（設定によっては）破棄され、 自動的な失敗イベントの保存は行われない。運用上はDLQまたはDestinationsの設定が強く推奨される。
• これに対し、API Gateway経由などの同期呼び出しではLambda自身は自動リトライを行わない点と対比して押さえておく。

従来のデッドレターキュー（DLQ、SQS/SNSのみ対応）は、失敗したイベントの元のペイロードのみを保存する仕組みであり、 成功時の情報連携や、呼び出し結果・エラー詳細などの実行コンテキストの付加情報は持たない。

• これに対しLambda Destinationsは、非同期呼び出しの「成功時（on-success）」「失敗時（on-failure）」の両方について、 SQS・SNS・EventBridge・別のLambda関数のいずれかへ結果を送信できる。
• Destinationsが送る情報には、元のイベント・呼び出しのレスポンスペイロード・タイムスタンプ・呼び出し回数などの実行コンテキストが含まれ、 DLQより豊富な情報を後続の処理（監査ログ、通知、リカバリ処理等）で活用できる。
• DLQとDestinationsは併用も可能だが、新規実装ではDestinationsの利用が推奨されている。

同期呼び出し（API Gateway、ALB、SDKのInvoke（InvocationType=RequestResponse）等）では、 Lambda自体は失敗した呼び出しを自動的に再試行しない。エラーは即座に呼び出し元へ返される。

• 再試行が必要な場合は、呼び出し元（クライアントアプリケーション、SDKのリトライ設定、API Gateway側の設計）が責任を持って実装する必要がある。
• これは非同期呼び出し（既定で最大2回の自動再試行）やストリームベースのポーリング呼び出し（Kinesis/DynamoDB Streams、 エラー時にバッチ全体を再試行し続ける）とは明確に異なる挙動である。
• 設計上は、下流の一時的なエラーに備えて呼び出し元側で指数バックオフ付きの再試行やサーキットブレーカーを実装するのが定石。

Lambdaの呼び出しモデルの多くは「少なくとも1回（at-least-once）」の実行を保証するものであり、 「厳密に1回（exactly-once）」を保証するものではない。これが冪等設計が必要とされる根本理由である。

• 非同期呼び出しでは、下流エラーや関数の異常終了時に既定で最大2回の自動再試行が行われる。 1回目の試行でDynamoDBへの書き込みが成功した後に決済API呼び出しでエラーが発生すると、再試行によりDynamoDBへの書き込みや決済APIの呼び出しが重複実行され得る。
• SQS標準キューをイベントソースとするイベントソースマッピングはat-least-once配信を前提としており、 まれに同一メッセージが複数回Lambdaへ配信されることがある。関数側が冪等でなければ、同じ注文が二重処理される可能性がある。
• 冪等性を担保する実装パターンとしては、リクエストごとの一意な冪等キーを条件付き書き込み（ConditionExpression）でチェックする、 AWS Lambda Powertoolsの冪等性ユーティリティを使う、などが挙げられる。

Lambdaで関数コードと設定を更新すると、常に$LATESTという可変（mutable）なバージョンが更新される。 $LATESTは常に最新の変更を反映するため、単体では「固定されたスナップショット」にはならない。

• バージョンを発行（publish）すると、その時点の$LATESTのコード・設定（メモリ・環境変数・レイヤー参照等）を 不変（immutable）なスナップショットとして、一意な番号（1, 2, 3...）付きのARNで固定できる。
• 発行済みバージョンのコード・設定はその後変更されることがないため、そのバージョンのARNを参照している限り、 誰かが$LATESTを更新しても影響を受けない。
• 過去の任意のバージョンへ切り戻す（ロールバック）際は、そのバージョン番号（またはそれを指すエイリアス）を参照先として設定し直すだけでよい。

エイリアス（alias）は、特定のバージョン（または複数バージョンへの加重）を指す名前付きの安定したポインタであり、 それ自体が固有のARNを持つ。

• クライアントはエイリアスのARN（例：...function:MyFunction:prod）を呼び出すように設定しておく。
• 新しいバージョンをリリースする際は、エイリアスが指すバージョン番号を更新するだけでよく、クライアント側の設定・呼び出し先ARNは一切変更不要。
• これにより、バージョンのリリース／切り戻しをエイリアスの参照先変更だけで完結させられ、クライアントとバージョン管理を疎結合にできる。

エイリアスの加重ルーティング（weighted alias）を使うと、1つのエイリアスに対して 2つのバージョンとその重み（パーセンテージ）を設定でき、呼び出しトラフィックをその比率で振り分けられる。

• prodエイリアスの追加バージョン設定でバージョン6に10%の重みを割り当てると、 呼び出しの約10%がバージョン6へ、残り90%がバージョン5（プライマリバージョン）へルーティングされる。
• CloudWatchメトリクス（エラー率・レイテンシ等）を監視しながら、問題なければ重みを段階的に引き上げ、最終的に100%を新バージョンへ切り替える。
• この手動での重み調整に加え、AWS CodeDeployと連携すると、Canary（一定割合を流し一定時間後に残りを一括切替）・ Linear（一定間隔で均等に切替）といった設定済みパターンで自動化し、CloudWatchアラームと連動した自動ロールバックも組める。

CodeDeployはLambdaのデプロイにおいて、エイリアスが指す新旧バージョン間のトラフィック移行を自動化する。

• あらかじめ用意されたデプロイ設定として、Canary（一定割合を流した後、一定時間経過で残り全部を切替）、 Linear（一定間隔で均等な割合ずつ段階的に切替）、AllAtOnce（即時に全トラフィックを切替）がある。
• デプロイ前後のフック（BeforeAllowTraffic/AfterAllowTraffic）として検証用Lambda関数を設定でき、 さらにCloudWatchアラームを関連付けておくと、アラームが発報した場合にCodeDeployが自動的にエイリアスを旧バージョンへロールバックする。
• トラフィックシフトの対象は発行済みバージョンを指すエイリアスであり、常に可変な$LATESTを直接のシフト対象にすることはできない。

Kinesis/DynamoDB Streamsのイベントソースマッピングは、既定ではバッチ処理が失敗すると同じバッチ全体を再試行し、 成功するか設定した保持期間・再試行回数の上限に達するまでそのシャードの後続レコードの処理をブロックする。

• 「バッチをバイセクト（bisect batch on function error）」を有効にすると、エラー発生時にバッチを半分に分割して再試行し、 それでも失敗すればさらに半分に分割……と繰り返すことで、問題のあるレコードを迅速に特定・分離できる。
• あわせて最大再試行回数（maximum retry attempts）や最大レコード経過時間（maximum record age）を設定しておくと、 特定・分離された問題レコードを一定回数/時間で見切ってスキップし、残りの正常なレコードの処理を先に進められる。
• 問題レコードはon-failure destination（設定していれば）へ送信し、後で個別に調査・再処理することも可能。
• なおReportBatchItemFailures（部分的バッチ失敗報告）は2020年12月にKinesis Data Streams・DynamoDB Streams向けに提供が始まっており（SQS向けの提供は2021年11月）、バイセクトと併用可能な別軸の機能である。ただしこれは関数コード側が失敗したレコードのシーケンス番号を自ら識別してitemIdentifierとして返すことが前提の仕組みであり、本問のように関数が個々のレコードを識別できずバッチ全体に対して例外をスローするだけの状況では、有効化しても問題レコードの自動切り分けにはつながらない。

SQSのイベントソースマッピングで関数レスポンスタイプReportBatchItemFailuresを有効化すると、 Lambda関数は処理結果として失敗したメッセージのIDだけを含むレスポンス（batchItemFailures）を返せるようになる。

• これにより、Lambdaのイベントソースマッピングはレスポンスで報告された失敗メッセージのみを可視性タイムアウト後に再度キューへ戻し、 成功した残りのメッセージはキューから正常に削除される（重複再処理を防ぐ）。
• この機能を有効化しない場合、既定の挙動としてバッチ内の1件でもエラーになるとバッチ全体が失敗扱いとなり、 成功したメッセージも含めて全件が再度可視化されてしまう（重複処理・非効率の原因）。
• 実装としては、関数がハンドラーの戻り値で{"batchItemFailures": [{"itemIdentifier": "<失敗メッセージID>"}]}形式のレスポンスを返すようにする。

Lambdaは急激なトラフィック増加に対して、関数ごとに10秒あたり1,000実行環境（＝10秒あたり10,000リクエスト/秒）のペースでスケールできる。 このスケーリングレートは関数単位の制限であり、各関数は他の関数と独立して、アカウント（リージョン）の同時実行数クォータに達するまでスケールする。

• アカウントの同時実行数の上限（またはそのタイミングで利用可能な未予約の同時実行数）に達すると、それ以上の同期呼び出しは 429 TooManyRequestsExceptionでスロットリングされる。
• これに対し非同期呼び出しがスロットルされた場合は、Lambda側で自動的に再試行される。 ポーリングベース（Kinesis/SQS等）のイベントソースは、スロットル時にポーリング頻度を落として自動調整する。
• 対策としては、プロビジョンド同時実行の事前確保やアカウントの同時実行数上限の引き上げ申請、 重要な関数への予約済み同時実行数の割り当てなどが挙げられる。

Lambda拡張機能（Lambda extensions）は、関数の実行環境内でランタイムとは別プロセスとして動作し、 Lambda Extensions APIを通じてInit・Invoke・Shutdownの各ライフサイクルイベントを購読できる仕組みである。

• 外部拡張機能（external extension）として、サードパーティのオブザーバビリティエージェントをレイヤーとしてパッケージ・配布し、 関数にアタッチするだけでログ・メトリクス転送機能を追加できる。ハンドラーのビジネスロジックのコード変更は不要。
• 拡張機能はShutdownイベントを購読できるため、実行環境が破棄される直前の通知を受け取り、 バッファ中のデータを確実にフラッシュしてから終了する処理を実装できる。
• 関数コード側で毎回同期的にログ転送APIを呼ぶ実装（B）は、ハンドラーの実行時間・レイテンシに転送処理の待ち時間が上乗せされ、 かつビジネスロジックとの結合度が高くなる。

2019年以前は、VPC内Lambdaはセキュリティグループ/サブネットの組み合わせごとに呼び出し時にENIを都度作成する設計であり、 これが大きなコールドスタート要因になっていた。しかし現行のVPC Lambdaのネットワーキングモデル（Hyperplane ENIによる共有ENIプール）では、 同一のVPC設定（サブネット・セキュリティグループの組み合わせ）を持つ実行環境間でENIが共有・再利用されるようになっている。

• 同じVPC設定の関数・実行環境がスケールしても、呼び出しのたびに新規ENIを作成するわけではなく、共有ENIプールから割り当てるため、 ENI作成に起因するコールドスタート遅延は大幅に削減されている。
• ただし、そのVPC設定（サブネット/セキュリティグループの組み合わせ）に対する初回のENI準備や、 関数自体の初期化（ランタイム初期化・ハンドラーのグローバルスコープ処理）に起因するコールドスタートは依然として発生し得る。
• また、ENIはプライベートIPのみを持つため、VPC内Lambdaがインターネット上のリソースへアクセスするには NATゲートウェイ等を経由するルーティング設計が別途必要である点は変わらない。

コールドスタート対策は「Initフェーズの所要時間を短くする」設計・実装上の工夫と、 「Initフェーズを事前に済ませておく」インフラ側の仕組みの2軸で考えると整理しやすい。

• プロビジョンド同時実行は、指定数の実行環境のInitフェーズを呼び出し前に完了させて待機させる、後者の代表的な対策。
• デプロイパッケージのサイズを小さくする（不要な依存関係を減らす）ことと、SDKクライアント等の再利用可能なリソースの初期化をハンドラー外（グローバルスコープ）で行うことは、 前者（Initフェーズ自体の所要時間短縮とウォーム実行での再利用の最大化）に効く実装上のベストプラクティス。
• 一方、タイムアウト値の延長は1回の実行が許される最大時間を延ばすだけで、Initフェーズの所要時間そのものには影響しない。
• メモリ割り当ての増加はCPU割当も比例して増えるため実行時間の短縮に寄与し得るが、 「コールドスタートを確実にゼロにする」保証を与えるものではなく、対策として過信すべきではない。

API GatewayにはREST API・HTTP API・WebSocket APIの3種類があり、 要件次第で最適なタイプが変わる。

• HTTP API：Lambdaプロキシ統合やHTTPバックエンドへのシンプルなプロキシに最適化されており、 REST APIよりも低レイテンシ・低コスト（最大で約70%安価）である。 JWTオーソライザーをネイティブでサポートし、Cognito/Auth0等のOIDC/OAuth 2.0トークンを追加のLambdaコードなしで検証できる。
• REST API：マッピングテンプレート（VTL）による詳細なリクエスト/レスポンス変換、APIキー・使用量プラン、 リクエスト単位のキャッシュ、AWS WAF直接統合など高度な機能が必要な場合に選ぶ。その分コスト・レイテンシは高め。
• WebSocket API：双方向のリアルタイム通信（チャット等）向けで、本設問の要件（シンプルなプロキシ＋JWT認可）には過剰。

本設問はマッピングテンプレートもAPIキーも不要でコスト最小化・JWT認可が要件のため、HTTP APIが最適解となる。

Lambdaプロキシ統合（AWS_PROXY）を使うと、API Gatewayはリクエストの変換を行わず、 HTTPメソッド・パス・ヘッダー・クエリ文字列・ボディなどリクエスト全体をそのままイベントオブジェクトとしてLambdaに渡す。

• Lambda側は event.body・event.headers・event.queryStringParameters 等を自分でパースする必要がある。
• レスポンスも、Lambda関数が {"statusCode": 200, "headers": {...}, "body": "..."} という決まった形式のJSONを返さなければならない。API Gatewayはこれをそのままクライアントへ返す（変換しない）。
• 対してカスタム統合（AWS）では、統合リクエスト/統合レスポンスのマッピングテンプレート（VTL）で API Gateway側がリクエスト/レスポンスを変換でき、Lambda側は素のペイロードだけを扱えばよい。

プロキシ統合は設定がシンプルな反面、リクエスト解析・レスポンス整形の責務がLambda関数のコード側に寄る点が最大の違いである。

API Gatewayのカスタム統合では、統合リクエスト側にマッピングテンプレートを設定でき、 Velocity Template Language（VTL）を使ってクライアントからのリクエストボディを バックエンドが期待する形式へ変換できる。

#set($inputRoot = $input.path('$'))
{
  "userName": "$inputRoot.user_name"
}

このように Content-Typeごとにマッピングテンプレートを定義し、 $input.path()・$input.json()等のVTL変数でリクエストボディを参照・変換して、 Lambda関数が期待するJSON構造を組み立てる。レスポンス側にも同様に統合レスポンスのマッピングテンプレートを設定できる。

なお、この仕組みはプロキシ統合（AWS_PROXY）では使えない（プロキシ統合はリクエスト/レスポンスをそのまま素通しするため）。 Lambda関数のコードを変更せずに済ませたい場合は、カスタム統合＋マッピングテンプレートの組み合わせが適切である。

REST APIでは主に3種類の認可方式が使える。

• Lambdaオーソライザー（TOKEN/REQUEST型）：任意のトークン形式・独自ロジックで認可判定でき、 IAMポリシードキュメントを返すことでリクエストの許可/拒否を制御する柔軟な方式。判定結果は既定でキャッシュ可能（TTL設定）。
• Cognitoオーソライザー：Cognitoユーザープールが発行したJWT（IDトークン）を検証する組み込み方式で、 独自のLambdaコードを書かずにユーザープールのグループ/スコープに基づく認可が行える。
• IAM認可（AWS_IAM）：SigV4署名されたリクエストのIAM権限を検証する。呼び出し元がAWS内部のサービス/IAMプリンシパルである場合に向く。

Lambdaオーソライザーの判定結果はデフォルトで最大3600秒（1時間）までキャッシュ可能で、同一の認可トークンに対する繰り返し呼び出しのレイテンシとコストを削減できる。

Lambdaオーソライザーには2つのタイプがある。

• TOKEN型：単一のトークン値（例：Authorizationヘッダー）だけをLambdaオーソライザーに渡す。単純なBearerトークン検証に向く。
• REQUEST型：ヘッダー・クエリ文字列パラメータ・パスパラメータ・ステージ変数・リクエストコンテキストなど、 複数の入力値を組み合わせてLambdaオーソライザーに渡せる。identitySourceで参照する値を指定する。

本設問のように複数の情報源を組み合わせた認可判定が必要な場合はREQUEST型を選ぶ。 なお、いずれのタイプでもLambdaオーソライザーはIAMポリシードキュメント（およびオプションでコンテキスト）を返す点は共通である。

パートナーごとに異なるレート制限・クォータを課しつつ識別可能にする標準的な仕組みは、APIキー＋使用量プラン（usage plan）である。

• パートナーごとにAPIキーを発行し、リクエストヘッダー（x-api-key）で送らせることでクライアントを識別する。
• 使用量プランで、レート（steady-state のリクエスト/秒）・バースト（トークンバケットの容量）・クォータ（日/週/月あたりの総リクエスト数）を設定し、 各APIキーを該当のプランに関連付ける。
• 使用量プランはステージ単位で紐付けるため、パートナーA用プラン・パートナーB用プランのようにパートナーごとに異なる上限を個別設定できる。

なお、使用量プランのスロットリング/クォータはAPI全体の既定のアカウントレベル・ステージレベルのスロットリングとは別レイヤーで、APIキー単位にきめ細かく制御する点が特長である。

API Gatewayのスロットリングはトークンバケットアルゴリズムで実装されている。

• バースト（burst）＝バケットの容量（トークンの最大保持数）。本設問では2,000トークンまで即座に消費可能。
• レート（rate）＝バケットへトークンが補充される速度（1秒あたり1,000トークン）。
• 2,500リクエストが一瞬で来た場合、最初の2,000リクエストはバースト容量の範囲内で処理される。 残りの500リクエストはバケットにトークンが無いため 429 Too Many Requests（ThrottlingException）でスロットリングされる。
• その後はレート（1,000/秒）でトークンが補充されるペースに応じて、後続のリクエストが順次処理される。

レートとバーストは別々のパラメータであり、瞬間的な超過に対する許容量（バースト）と、継続的な処理能力（レート）を分けて理解することが重要である。

API Gatewayのステージキャッシュは、バックエンド（Lambda等）への呼び出し回数を減らし、レイテンシとコストを削減する機能である。

• キャッシュはステージ単位で有効化し、TTL（0〜3600秒、既定300秒）を設定できる。TTLを0にするとキャッシュを一時的に無効化（保存はするが即時失効）できる。
• キャッシュキーには、メソッド／統合リクエストのパラメータ（URLパス・クエリ文字列・カスタムヘッダー）のうち、明示的に指定したものだけが含まれる。 クエリ文字列やヘッダーは既定ではキャッシュキーに入らない（リソースにキャッシュを設定する際はキャッシュキーが必須で、最低1つを指定する）。 指定しなかったパラメータは区別されないため、条件の違うリクエストへ同じレスポンスが返る点に注意。
• クライアントは Cache-Control: max-age=0 ヘッダーを送ることでキャッシュをバイパスして最新データを取得できる（ただし呼び出し元にキャッシュ無効化権限＝IAMポリシーの許可が必要な場合がある）。
• コンソール/APIから明示的にキャッシュ全体をフラッシュ（invalidate）することも可能。
• キャッシュはリージョンエンドポイントの場合API Gateway自体が管理し、キャッシュサイズ（0.5GB〜237GB）に応じて追加コストが発生する。

API Gatewayのカナリアリリース（canary release deployment）機能を使うことで、 同一ステージ内で新しいデプロイ（カナリア）と既存の本番デプロイ（ベースライン）にトラフィックを指定した比率で振り分けることができる。

• prodステージでカナリア設定を有効化し、カナリアトラフィックパーセンテージを5%に設定して新しいデプロイをカナリアへ適用する。
• 残り95%のトラフィックは既存のベースラインデプロイのまま処理される。カナリア用のCloudWatchメトリクス（Latency・5XXError等）は ベースラインと分離して監視できるため、新ロジックの影響を切り分けて評価できる。
• 問題がなければカナリアパーセンテージを段階的に引き上げ、最終的にベースラインへ昇格（promote）させて全トラフィックを新バージョンにする。 問題があればカナリア設定を削除するだけで即座にロールバックできる。

ステージ変数と組み合わせれば、カナリア側だけ異なるLambdaエイリアス/バージョンを参照させることも可能である。

ステージ変数（stage variables）は、API Gatewayのステージごとに設定できるキー・バリューのペアで、 統合のARNやHTTPエンドポイントなど、ステージによって変えたい値をテンプレート化できる。

• Lambda統合のARNに ${stageVariables.lambdaAlias} のようにステージ変数を埋め込むことで、 同じAPI定義のまま、ステージごとに異なるLambdaエイリアス（例：devステージはdevエイリアス、prodステージはprodエイリアス）を呼び分けられる。
• ステージ変数はマッピングテンプレート内や、一部のログ設定・VPCリンク先の指定でも参照できる。
• これによりAPI定義そのものを複製せず、ステージのデプロイ設定だけを切り替えることで環境差分を吸収できる。