製造業の企業が、オンプレミスで稼働する ActiveMQ ブローカーを AWS に移行しようとしています。既存の製造実行システム（MES）は JMS（Java Message Service）API を使用しており、コードを大幅に変更せずに移行する必要があります。また、ブローカー障害時にも自動フェイルオーバーで継続稼働できる高可用性が必須です。最適なソリューションはどれですか？
Amazon MQ は Apache ActiveMQ と RabbitMQ のマネージドサービスで、JMS・AMQP・STOMP・MQTT・OpenWire などの業界標準プロトコルをネイティブサポートします。既存の JMS コードをほぼそのまま使えるため移行コストが低く、アクティブ/スタンバイ構成ではアクティブブローカーの障害時に自動でスタンバイへフェイルオーバーし、高可用性を確保できます。 選択肢A の Amazon SQS FIFO キューを使い、既存の JMS クライアントコードを SQS SDK を使用するよう書き換える方法は、JMS API と互換性がなく、クライアントコードの全面的な書き換えが必要です。「大幅な変更なし」という要件に反します。 選択肢C の Amazon Kinesis Data Streams を使い、プロデューサーとコンシューマーのコードを Kinesis API に対応させる方法は、高スループットのイベントストリーミング向けサービスで JMS との互換性はなく、既存コードの完全な書き換えが必要です。また MES のメッセージング要件とアーキテクチャ的に一致しません。 選択肢D の Amazon MSK（Managed Streaming for Apache Kafka）を使い、Kafka クライアントライブラリに移行する方法は、大規模ストリーム処理に優れますが JMS と互換性がなく、Kafka クライアントへの移行は大規模なコード変更を伴います。要件の「コード変更を最小化」に反します。