同時実行数（バースト制限とスロットリング）難易度 標準無料
ECサイトのフラッシュセール開始直後、API Gateway経由で同期呼び出しされるLambda関数への同時リクエスト数が急増し、一部のリクエストが429 TooManyRequestsExceptionエラーとなった。この現象の説明として最も適切なものを選べ。（単一選択）
- Aトラフィック急増により利用可能な同時実行数（アカウント上限や予約枠）を使い切り、それ以上の同期呼び出しがスロットリングされ
429が返された。対策として同時実行数上限の引き上げやプロビジョンド同時実行の確保が有効 - BLambdaは同時実行数について事実上無制限に瞬時スケールするため、アカウントやリージョンの上限に達してスロットリングされることは起こり得ない
- C
429エラーはLambda関数のコード内で発生した未処理例外が原因であり、インフラの同時実行数の制約とは無関係である - D
429はAPI Gateway側のスロットリング設定のみに起因し、Lambda側の同時実行数制約が原因になることはない
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
Lambdaは急激なトラフィック増加に対して、関数ごとに10秒あたり1,000実行環境（＝10秒あたり10,000リクエスト/秒）のペースでスケールできる。 このスケーリングレートは関数単位の制限であり、各関数は他の関数と独立して、アカウント（リージョン）の同時実行数クォータに達するまでスケールする。
- アカウントの同時実行数の上限（またはそのタイミングで利用可能な未予約の同時実行数）に達すると、それ以上の同期呼び出しは
429 TooManyRequestsExceptionでスロットリングされる。 - これに対し非同期呼び出しがスロットルされた場合は、Lambda側で自動的に再試行される。 ポーリングベース（Kinesis/SQS等）のイベントソースは、スロットル時にポーリング頻度を落として自動調整する。
- 対策としては、プロビジョンド同時実行の事前確保やアカウントの同時実行数上限の引き上げ申請、 重要な関数への予約済み同時実行数の割り当てなどが挙げられる。
- B事実に反する。アカウント/リージョン単位の同時実行数上限とバーストの増加ペースが存在し、それを超えると同期呼び出しは
429でスロットリングされる。 - C
429 TooManyRequestsExceptionはLambdaサービス側のスロットリングを示すエラーであり、関数コード内の未処理例外（通常は500系や関数固有のエラー形式で返る）とは異なる。 - DAPI Gateway自体にもスロットリング設定はあるが、本問のようにLambda側の同時実行数上限に達したことも
429系エラーの発生要因になり得る。両者は独立した制約であり混同しないこと。
ひっかけ： 「Lambdaは無制限に瞬時スケールできるので同時実行数の上限に達することはない（B）」は誤り。アカウント/リージョン単位の同時実行数上限とバースト制限が存在し、
それを超えると同期呼び出しはスロットリング（429）される。この上限の存在を前提に容量計画（Well-Architectedの信頼性の柱）を行う必要がある。
公式ドキュメント・関連AWS Lambda Developer Guide ― Lambda function scaling↗AWS Lambda Developer Guide ― Lambda quotas↗
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）