物流会社がオンプレミスで稼働するMySQL 5.7ベースの基幹システム（荷物追跡DB、1日1億件のINSERT/UPDATE、トランザクションログのサイズが1日200GB）をAmazon Aurora MySQL Compatible Editionへ移行しようとしています。現在のシステムは24時間365日停止不可（SLA: 99.95%）であり、移行中もリアルタイム荷物追跡サービスを停止できません。 追加の技術的制約： ・バイナリログ（binlog）は現在有効になっていない（有効化には数時間のメンテナンスウィンドウが必要） ・データベースサーバーはオンプレミスファイアウォール背後にあり外部への直接接続が制限されている ・セキュリティポリシーによりサードパーティツールのインストールが禁止されている（AWSエージェント以外） ・ソースデータベースへのスーパーユーザー権限はある このシナリオでダウンタイムを最小化してAurora MySQLへ移行するための最適なアーキテクチャはどれですか？
選択肢AはAWS DMS Full Load + CDCを採用する最適なアプローチです。CDCにはbinlogが必要ですが、低トラフィック時間帯のメンテナンスウィンドウでbinlogを有効化することで最小限のダウンタイムに抑えられます。DMSはソースDBへアウトバウンドで接続するためファイアウォールルールの調整は最小限で済み、AWSエージェント以外禁止のセキュリティポリシーにも適合します。 選択肢Bはmysqldumpで論理バックアップを取得しSnowball EdgeでAurora MySQLへインポートするアプローチですが、1日200GBのトランザクションログを手動でCDCとして差分適用することは非現実的であり、カットオーバー時に数時間のダウンタイムが発生しSLA要件を満たせません。 選択肢CはネイティブMySQLレプリケーション経由でRDS for MySQLを中間ステップとして使用しますが、binlogが必要な点は選択肢Aと同じです。さらにオンプレミス→RDS for MySQL→Auroraという二段階移行となり、中間インスタンスのコストと運用複雑性が増大します。DMS経由でAuroraへ直接移行できる選択肢Aと比較して冗長であり最適ではありません。 選択肢DはKinesis Data Streams + LambdaによるCDC代替アーキテクチャですが、1日1億件の高スループット環境での独自開発・テスト・運用コストが過大であり、DMSという標準ツールが利用可能な状況でこの構成を採用する合理的な理由がありません。