あるグローバルな保険会社が、レガシーなモノリシックアプリケーション（Java EE、オンプレミスのWebLogicサーバーで稼働）をAWSでマイクロサービスアーキテクチャへリアーキテクチャする計画を持っています。現在の構成と要件は以下の通りです： 【現在のシステム】 ・保険金請求処理システム：年間処理件数500万件、平均処理時間2分/件 ・相互依存するモジュール：顧客管理、ポリシー管理、請求評価、支払処理、不正検知の5モジュール ・データベース：Oracle Database（単一インスタンス、500GB） ・外部システム連携：銀行API（同期、REST）、規制当局レポーティングシステム（バッチ、SFTP）、再保険会社（非同期、EDI形式） ・EDI（Electronic Data Interchange：電子データ交換、企業間の標準的なデータフォーマット）を使用した再保険会社との連携は変更不可 【移行後の要件】 ・各マイクロサービスの独立したデプロイ・スケーリング ・請求評価モジュールは機械学習モデルによる自動評価を導入（現在は手動） ・支払処理は最終的一貫性（結果整合性）で許容されるが、重複支払いは絶対に防止 ・不正検知はリアルタイム（請求提出から1秒以内） ・規制当局へのレポーティングは毎日深夜にバッチ処理 ・再保険会社とのEDI連携は継続（フォーマット変換はAWS側で対応） ・すべてのサービス間通信は暗号化・認証済みであること ・各マイクロサービスのSLA：99.99%可用性 この移行を最もよく実現するアーキテクチャはどれですか？
Amazon ECSとAWS Fargateを組み合わせてサービスごとのコンテナを運用し、サービスディスカバリにはAmazon CloudMapを使用する。サービス間の非同期通信はAmazon EventBridge（イベント駆動）とAmazon SQS（ポイントツーポイント）を組み合わせ、用途に応じて使い分ける。データベースはDomain-Driven Design（DDD：ドメイン駆動設計）の原則に基づきサービスごとに分離し、支払処理サービスにはAmazon RDS for PostgreSQL（Multi-AZ）と分散サーガパターン（各サービスのローカルトランザクションをイベントで連携し、補償トランザクションで整合性を維持する設計パターン）を実装して重複支払いを防止する。不正検知サービスはEventBridgeのカスタムイベントバスで請求提出イベントを受信し、SageMakerリアルタイム推論エンドポイントを呼び出す（ターゲットレイテンシ：p99 800ms）。ML自動評価はSageMaker PipelinesとSageMaker Model Registryで継続的なモデル更新パイプラインを構築する。EDI連携はAWS Transfer Family（AS2）＋AWS Step Functionsで変換し、Amazon MQ（ActiveMQ）で再保険会社のレガシーシステムとの非同期連携を実現する。バッチレポートはAWS BatchとAmazon SFTPプロトコルのAWS Transfer Familyで規制当局に送信する。すべてのサービス間通信はAWS Certificate ManagerのPrivate CAでmTLSを実装し、AWS IAM Roles for Service Accounts（IRSA相当）をECSタスクロールで実現する。 解説： ECS Fargateはマネージドでインフラ管理が不要、かつWebLogicからのJavaアプリ移行に適しています。分散サーガパターンで最終的一貫性を維持しながら重複支払いを防止し、EventBridgeとSQSの使い分けはイベント駆動マイクロサービスのベストプラクティスです。AS2対応のTransfer FamilyはEDI連携の標準実装です。 選択肢AはEKSが過剰に複雑でDynamoDBを請求評価に使う根拠が薄く、重複防止の実装が不完全です。 選択肢BはLambdaの15分制限が保険処理フローと相性が悪く、Aurora共有スキーマはマイクロサービスの原則に反します。 選択肢DのセルフマネージドIstioは運用負担が高く、MSK（Kafka）の採用は専門知識が必要で過剰な複雑性を生じます。