2.1標準
EventBridgeからLambdaへイベントを配信する。
一時障害は再試行し、継続失敗したイベントを失わずに調査したい。
最も適切な設計はどれか。
× 不正解
EventBridgeの再試行ポリシーとDLQで一時障害と恒久失敗を分けて扱う。
詳細解説
誤り失敗イベントを常に破棄する
再処理と原因調査のためのイベントを失う。
再処理と原因調査のためのイベントを失う。
誤りイベントをS3へ保存するだけで自動再試行する
S3保存だけではEventBridgeターゲットへの再試行制御にならない。
S3保存だけではEventBridgeターゲットへの再試行制御にならない。
正しいEventBridgeターゲットの再試行ポリシーとデッドレターキューを設定する
一時障害を再試行し、継続失敗したイベントをDLQへ保管できる。
一時障害を再試行し、継続失敗したイベントをDLQへ保管できる。
誤りRoute 53 TTLを短くしてイベント配信を再実行する
DNS TTLはイベント配信の再試行を制御しない。
DNS TTLはイベント配信の再試行を制御しない。
実際に確かめる
一時的な検証環境で実行できる例です。
Amazon EventBridge retry policyとdead-letter queueの公式説明を確認する。期待される結果
イベント配信の再試行と失敗イベント保管を設計できる。理解のポイント
- EventBridge
- 再試行ポリシー
- デッドレターキュー
確認時の注意
- 確認環境: AWS公式EventBridgeドキュメントの確認
- AWS公式SAA-C03 Domain 2と各サービスの公式ドキュメントを確認する。
基礎のおさらい
判断のポイント
障害ドメイン、データの復旧点、処理の重複、切り替え時間を分けて評価する。
設計の確認
正常系だけでなく、キュー滞留・AZ障害・リージョン障害・依存サービス停止時の動作を確認する。
問題IDAWS-SAA-136
確認環境AWS公式EventBridgeドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告