Lambda での再試行動作について

非同期呼び出し － Lambda は、関数エラーを 2 回再試行します。関数にすべての受信リクエストを処理するのに十分な容量がない場合、イベントはキュー内で数時間待機して関数に送信される可能性があります。正常に処理できなかったイベントを把握するために、デッドレターキューを設定できます。詳細については、「Lambda 関数を非同期的に呼び出す」を参照してください。

イベントソースマッピング － ストリームから読み取るイベントソースマッピングは、項目のバッチ全てに対して再試行を実施します。繰り返されるエラーは、そのエラーが解決されるか、項目が期限切れになるまで、影響を受けるシャードの処理を妨げます。停止しているシャードを検出するには、Iterator Age メトリクスをモニタすることができます。

キューから読み取るイベントソースマッピングについては、ソースキューの再試行ポリシーおよび可視性タイムアウトを設定することで、失敗したイベントの送信先と再試行の間の時間の長さを決定します。詳細については、Lambda がストリームおよびキューベースのイベントソースからのレコードを処理する方法 および 他の AWS サービスからのイベントを使用した Lambda の呼び出し のサービス固有のドキュメントを参照してください。

AWS のサービス － AWS のサービスでは、同期的または非同期的に関数を呼び出す場合があります。同期呼び出しの場合、サービスは再試行するかどうかを決定します。例えば、Amazon S3 バッチオペレーションは、Lambda 関数が TemporaryFailure 応答コードを返す場合、オペレーションを再試行します。プロキシがアップストリームユーザーまたはクライアントからリクエストするサービスは、再試行戦略を持っているか、またはリクエスタにエラー応答をリレーする場合があります。例えば、API Gateway は常にエラー応答をリレーしてリクエスタに返します。

非同期呼び出しの場合、再試行ロジックは呼び出しソースに関係なく同じです。デフォルトでは、Lambda は失敗した非同期呼び出しを最大 2 回再試行します。詳細については、「Lambda がエラーを処理し、非同期呼び出しで再試行する方法」を参照してください。

他のアカウントやクライアント － 他のアカウントへのアクセス権限を付与する場合、関数を呼び出すために設定できるサービスやリソースの制限にリソースベースのポリシーを使用することができます。関数を過負荷から守るためには、Amazon API Gateway を使用して、関数の前に API レイヤーを設定することを考慮してください。