プロビジョンド同時実行難易度 標準無料
API Gatewayの背後で動くLambda関数がJVMベースのランタイムを使用しており、コールドスタート時の初期化に数秒かかるため、レイテンシに敏感なユーザー向けAPIでp99レイテンシが悪化している。トラフィックパターンは平日日中に集中している。コールドスタートの影響を排除するために最も適切な対応を選べ。（単一選択）
- A対象バージョン/エイリアスにプロビジョンド同時実行を設定し、平日日中はApplication Auto Scalingのスケジュールで数を増やし夜間・休日は減らす
- B関数に予約済み同時実行数を設定すれば、実行環境が事前初期化されコールドスタートは発生しなくなる
- CLambda関数をLambda@Edgeとして再デプロイし、CloudFrontのエッジロケーションで実行することでコールドスタートを解消する
- D関数のタイムアウトを最大値の15分に設定し、初期化にかかる時間分の余裕を持たせる
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
プロビジョンド同時実行（provisioned concurrency）を設定すると、Lambdaは指定した数の実行環境を 事前に初期化（Initフェーズを事前実行）した状態で待機させる。呼び出しが来た時点ですでにInitフェーズが完了しているため、 コールドスタートに起因するレイテンシが発生しない。
- 特定のバージョン/エイリアスに対して設定し、API GatewayからそのエイリアスのARNを呼び出す構成にする。
- トラフィックが平日日中に偏っているのであれば、Application Auto Scalingのスケジュールベースのスケーリングで、 日中はプロビジョンド同時実行数を増やし、夜間・休日は減らすことでコストを最適化できる。
- プロビジョンド同時実行は設定した容量分、呼び出しの有無に関わらず課金されるため、トラフィックパターンに応じたスケジューリングが重要になる。
- B予約済み同時実行数は同時実行の保証/上限を定めるだけで、実行環境を事前初期化する機能ではない。コールドスタート対策にはプロビジョンド同時実行が必要。
- CLambda@Edgeへの移行はユースケース（エッジでの軽量処理）が異なり、JVMベースの重い初期化を伴う関数の一般的なコールドスタート対策として適切ではない。
- Dタイムアウトの延長は初期化にかかる時間そのものを短縮せず、レイテンシ悪化という問題を解決しない。
ひっかけ： 「予約済み同時実行数を設定すればコールドスタートが無くなる（B）」という混同が典型的な誤り。予約済み同時実行数は同時実行数の保証/上限であり、実行環境の事前初期化は行わない。
コールドスタート自体を無くしたいならプロビジョンド同時実行が正しい選択。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）