Amazon MQ
Apache ActiveMQ および RabbitMQ をフルマネージドで提供し、既存のメッセージングアプリケーションを最小限のコード変更でクラウドに移行できるメッセージブローカーサービス
概要
Amazon MQ は、Apache ActiveMQ と RabbitMQ の 2 つのオープンソースメッセージブローカーエンジンをフルマネージドで提供するサービスです。JMS、AMQP、STOMP、MQTT、OpenWire などの業界標準プロトコルに対応しており、オンプレミスで稼働している既存のメッセージングアプリケーションを、コードの大幅な書き換えなしにクラウドへ移行できます。ブローカーのプロビジョニング、パッチ適用、障害検知、フェイルオーバーが自動化されており、運用負荷を減らせます。マルチ AZ 配置によるアクティブ/スタンバイ構成で高可用性を確保し、ActiveMQ のメッセージは既定で複数の AZ に複製される Amazon EFS に永続化されます。
ブローカーエンジンの選択とデプロイ構成
Amazon MQ では ActiveMQ (概要の頁と FAQ の表記は Apache ActiveMQ Classic) と RabbitMQ の 2 つのエンジンから選択します。ActiveMQ は JMS (Java Message Service) API を使用する既存の Java アプリケーションとの互換性が高く、エンタープライズ統合パターン (EIP) に基づく複雑なルーティングやメッセージ変換をブローカー側で処理できます。RabbitMQ は AMQP 0-9-1 プロトコルを中心に、柔軟な Exchange タイプ (Direct、Topic、Fanout、Headers) によるメッセージルーティングが強みです。デプロイ構成には、単一インスタンス、アクティブ/スタンバイ (マルチ AZ)、RabbitMQ のクラスターデプロイがあります。本番環境ではアクティブ/スタンバイ構成が推奨され、プライマリブローカーの障害時に自動的にスタンバイへフェイルオーバーします。クライアントは Failover Transport (failover://) を使い、冗長な組のどちらのエンドポイントにも接続する設定にします。インスタンスタイプは ActiveMQ では評価向けの mq.t3.micro や本番向けの mq.m5 系などから選び、メッセージスループットと同時接続数に応じてサイジングします。
ActiveMQ のネットワークオブブローカーと永続化
ActiveMQ エンジンでは、ネットワークオブブローカー (Network of Brokers) 構成により、複数のブローカーインスタンスを論理的に接続してメッセージを転送できます。この構成は、地理的に分散したシステム間でメッセージを中継する場合や、ブローカーの負荷を分散する場合に有効です。各ブローカーはローカルのキューとトピックを持ちつつ、ネットワークコネクタを通じて他のブローカーのコンシューマーにメッセージを転送します。ActiveMQ のブローカーのストレージは既定で Amazon EFS で、Amazon EBS もありますが、アクティブ/スタンバイ構成は EFS を使い、EBS は mq.m5 系の単一インスタンスのブローカーに限られると開発者ガイドに記載されています。永続メッセージは、ブローカーの再起動やフェイルオーバーの後も保持されます。ブローカーあたりのストレージ容量の上限はインスタンスタイプによって異なり、クォータの頁に記載されています。デッドレターキュー (DLQ) を設定すると、処理に失敗したメッセージが DLQ に退避され、メインキューの滞留を防ぐ助けになります。DLQ に溜まったメッセージを CloudWatch メトリクスで監視し、閾値超過時にアラートを発報する運用パターンがあります。
認証 / 暗号化とメンテナンスウィンドウ
Amazon MQ のセキュリティは、ネットワーク層、認証層、暗号化層の 3 層で構成されます。ブローカーは VPC 内のプライベートサブネットにデプロイされ、セキュリティグループでアクセス元を制限します。パブリックアクセスを有効にすることも可能ですが、本番環境では VPC 内配置が推奨されます。認証は ActiveMQ の場合 SimpleAuthenticationPlugin によるユーザー名/パスワード認証、RabbitMQ の場合はネイティブのユーザー管理機能が基本で、既存のディレクトリサービスと連携する LDAP 統合はどちらのエンジンでも利用できます (2026 年 10 月時点)。通信の暗号化は TLS で保護され、保管時のデータは常に暗号化されます。キーは AWS が所有するキー (既定)、AWS マネージドキー、AWS KMS のカスタマーマネージドキーから選ぶと開発者ガイドに記載されています。メンテナンスウィンドウは週 1 回の開始日時を指定し、この間にエンジンのパッチ適用やマイナーバージョンアップが実行されます。メンテナンスの所要は予定された操作によって最大 2 時間と開発者ガイドに記載されています。アクティブ/スタンバイ構成ではメンテナンスが 1 台ずつ行われて少なくとも 1 台が稼働した状態に保たれ、アクティブのインスタンスに接続したクライアントについては短いフェイルオーバーの注記があります。AWS は開発者ガイドで、サポート終了日の 30 日前からはそのバージョンでの新しいブローカーの作成を受け付けず、サポート終了を迎えたバージョンのブローカーはメンテナンスウィンドウの間に次のサポート対象のバージョンへ自動で更新されると案内しています (2026 年 10 月時点)。CloudWatch メトリクスで CpuUtilization、HeapUsage、StorePercentUsage を監視し、容量逼迫を早期に検知します。
参考資料 (AWS 公式)
本ページの一次情報は AWS 公式サイトと公式ドキュメントです。最新の仕様と料金は次の公式ページで確認できます。
本ページと公式ドキュメントの記述が食い違う場合は、公式ドキュメントを正としてください。