同時実行数（予約済み同時実行）難易度 標準無料
あるAWSアカウントには複数のLambda関数が存在し、アカウント全体の同時実行数の上限を共有している。決済処理を行う重要な関数PaymentFunctionが、他の関数の突発的なトラフィック急増（いわゆるnoisy neighbor）によって同時実行数を奪われスロットリングされる事態を防ぎたい。これを実現する設定として最も適切なものを選べ。（単一選択）
- A
PaymentFunctionに予約済み同時実行数（reserved concurrency）を設定し、アカウントの同時実行数プールから専用の枠を切り出して他の関数に使われないようにする - B
PaymentFunctionのメモリ割り当てを最大の10,240MBに設定し、1回の呼び出しあたりの処理能力を上げる - Cすべての関数にDLQ（デッドレターキュー）を設定し、失敗したイベントを再処理できるようにする
- D
PaymentFunctionのタイムアウト値を1分から15分に延長し、処理が打ち切られないようにする
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
予約済み同時実行数（reserved concurrency）をPaymentFunctionに設定すると、
その値がアカウント全体の同時実行数プールから切り出され、他の関数からは使われない専用の枠として確保される。
- これにより
PaymentFunctionは、他の関数がどれだけ同時実行数を消費していても、設定した数までは常に実行を保証される。 - 同時に、予約済み同時実行数はその関数が同時に実行できる上限（キャップ）としても働く。設定値を超える呼び出しはスロットリングされる。
- 予約済み同時実行数を設定した分、アカウントの「未予約」同時実行プール（他の全関数が共有する枠）は減少するため、 他の関数への影響を考慮して値を決める必要がある。
- Bメモリ設定は1回の実行あたりのCPU/メモリ性能を左右するだけで、アカウント全体の同時実行数の奪い合いという問題は解決しない。
- CDLQはエラー処理の話であり、同時実行数の枠を確保する仕組みではない。noisy neighbor問題への対策にならない。
- Dタイムアウト延長は1回の実行時間の上限を変えるだけで、同時実行数の枠の確保には無関係。むしろ長時間実行は同時実行数を長く占有するリスクもある。
ひっかけ： 予約済み同時実行数は「保証」であると同時に「上限（キャップ）」でもある点に注意。プロビジョンド同時実行（コールドスタート排除のための事前初期化）と混同しないこと。
本問はコールドスタートの話ではなく、他関数からの同時実行数の“横取り”を防ぐ話である。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）