ある大手ECプラットフォームは、1日あたり10万件の注文を処理するマイクロサービスアーキテクチャを運用しています。現在は注文サービス→在庫サービス→支払いサービス→配送サービスへの同期REST API呼び出しチェーンで構成されています。ブラックフライデーなどのピーク時に支払いサービスのタイムアウトが発生すると、在庫が引き落とされたままの注文がロストするデータ不整合が生じています。新アーキテクチャへの要件は以下のとおりです。 ①正確に1回の注文処理（冪等性の保証） ②長時間実行ワークフローの完全な状態遷移履歴と監査証跡の保持 ③支払い失敗時の補償トランザクション（在庫の自動ロールバック） ④メンテナンス時の処理一時停止と再開（注文ロストなし） ⑤各ステップのタイムアウトとリトライの設定可能な制御 要件を充足する実装として正しいものを2つ選んでください。
AWS Step Functions スタンダードワークフローは要件②③ ⑤を直接実現する。実行履歴はコンソールとAPIで最大90日間参照でき完全な状態遷移ログを提供し（要件②、長期保持にはCloudWatch Logs連携を推奨）、ステートマシン定義にRetryとCatchを宣言的に記述することでエラー種別ごとの補償トランザクション（在庫ロールバックステートへのフォールバック）とリトライ制御が可能（要件③⑤）。WaitForTaskTokenで支払いサービスのような外部非同期処理を無制限に待機できる。 Amazon SQS FIFOキューはMessageDeduplicationIdによる5分間の重複排除ウィンドウで要件①を実現し、LambdaイベントソースマッピングのEnable/Disableによりメンテナンス中の注文をキューに保持したまま一時停止・再開が可能（要件④）。DLQで最終失敗注文を安全に隔離できる。 選択肢CのKinesis Data Streamsはリアルタイムストリーミングに優れるが、補償トランザクションのネイティブサポートがなく状態遷移履歴も提供しない。 選択肢DのEventBridgeはイベントルーティングに有効だが、ワークフロー状態管理・補償トランザクション・ステップ単位のタイムアウト/リトライを内蔵せず要件②③ ⑤を単体で満たせない。 選択肢EのStep Functions Expressワークフローは最大実行時間が5分に制限され長時間注文フローには不適切。実行履歴はCloudWatch Logsのみに記録されコンソールから個別実行の状態遷移を参照できない（要件②不充足）。