エラーハンドリング（冪等性設計）難易度 高無料
あるLambda関数はイベントを受け取り、注文レコードをDynamoDBに書き込んだ後に決済APIを呼び出す処理を行う。開発者は「関数コードを冪等（idempotent）に設計する必要はない」と主張している。この主張が誤りである根拠として正しいものを2つ選べ。
- A非同期呼び出しでは既定で最大2回の自動再試行が行われるため、1回目の試行の一部処理（DB書き込み等）が成功した後にエラーが起きると、再試行により処理が重複実行され得る
- BSQS標準キューのイベントソースマッピングはat-least-once配信を前提としており、まれに同一メッセージが複数回Lambdaに配信され重複処理が起こり得る
- CLambdaはすべての呼び出しタイプ（同期・非同期・ポーリングベース）についてexactly-once（厳密に1回）の実行を保証しているため、重複処理は原理的に起こり得ない
- DDynamoDB Streamsをイベントソースとするイベントソースマッピングは常にexactly-onceで処理されるため、DynamoDBが関わる場合に限り冪等設計は不要である
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：A・BAI作成・AIで再検証済
解説
Lambdaの呼び出しモデルの多くは「少なくとも1回（at-least-once）」の実行を保証するものであり、 「厳密に1回（exactly-once）」を保証するものではない。これが冪等設計が必要とされる根本理由である。
- 非同期呼び出しでは、下流エラーや関数の異常終了時に既定で最大2回の自動再試行が行われる。 1回目の試行でDynamoDBへの書き込みが成功した後に決済API呼び出しでエラーが発生すると、再試行によりDynamoDBへの書き込みや決済APIの呼び出しが重複実行され得る。
- SQS標準キューをイベントソースとするイベントソースマッピングはat-least-once配信を前提としており、 まれに同一メッセージが複数回Lambdaへ配信されることがある。関数側が冪等でなければ、同じ注文が二重処理される可能性がある。
- 冪等性を担保する実装パターンとしては、リクエストごとの一意な冪等キーを条件付き書き込み（
ConditionExpression）でチェックする、 AWS Lambda Powertoolsの冪等性ユーティリティを使う、などが挙げられる。
- C事実に反する。Lambdaの多くの呼び出しモデルはat-least-onceであり、exactly-onceを保証しない。重複実行を前提に冪等設計をすべきである。
- D誤り。ストリームベースの呼び出しもエラー時にバッチ単位で再試行が行われるため、同一レコードが複数回処理される可能性があり、冪等設計は必要。
ひっかけ： 「Lambdaは全呼び出しタイプでexactly-onceを保証する（C）」「DynamoDB Streamsのイベントソースマッピングはexactly-onceだから冪等設計は不要（D）」は
いずれも典型的な誤解。ストリームベースの呼び出しもエラー時のバッチ再試行によって同一レコードが複数回処理され得るため、冪等性は呼び出しタイプを問わず設計すべき前提である。
公式ドキュメント・関連AWS Lambda Developer Guide ― Error handling and automatic retries in AWS Lambda↗Amazon SQS Developer Guide ― At-least-once delivery↗
AIが作成し、別の手順のAIで誤りを点検した解説です（有資格者による監修は経ていません）