Amazon MQ 完全ガイド 2026

初心者から実務者向けの包括的解説

Amazon MQ（Message Queue） は、Apache ActiveMQ Classic・ActiveMQ Artemis・RabbitMQ のフルマネージドメッセージブローカーサービスです。既存のオンプレミスメッセージングシステムを最小限のコード変更で AWS に移行（Lift & Shift）することを主目的とし、AMQP・STOMP・MQTT・OpenWire・WebSocket などの業界標準プロトコルをサポートします。2026 年現在、RabbitMQ 4.2 での AMQP 1.0 ネイティブサポート・HTTP ベース認証・クォーラムキュー強化により、エンタープライズグレードのメッセージング基盤を AWS で実現できます。

ドキュメントの目的

本ガイドは以下を対象としています。

• 初心者向け： Amazon MQ とは何か、なぜ必要かを学びたい方
• 開発者向け： ActiveMQ / RabbitMQ アプリケーションを AWS に移行したい方
• SRE / インフラ向け： メッセージブローカー設計・運用・監視を行いたい方
• アーキテクト向け： オンプレ移行戦略・HA 構成・マルチリージョン設計を検討している方
• 意思決定者向け： Amazon MQ vs SQS/SNS vs Kafka の技術選定判断

2025-2026 年の Amazon MQ エコシステム

• RabbitMQ 4.2 サポート（2025 年 11 月）：AMQP 1.0 ネイティブサポート、Khepri メタデータストア、メッセージプライオリティ
• HTTP ベース認証（2026 年 1 月）：RabbitMQ 4.2 ブローカーで HTTP サーバー経由の認証・認可をサポート
• ActiveMQ Artemis への段階的移行：ActiveMQ Classic はレガシーモード、Artemis がモダン標準へ
• リソースリミット設定：RabbitMQ ブローカーの CPU・メモリ・接続数を動的に構成可能
• Enhanced CloudWatch メトリクス：キュー深度・コンシューマー数・スループットの詳細監視
• クロスリージョンレプリケーション（CRDR）：ActiveMQ での非同期レプリケーションと自動フェイルオーバー

目次

1. 概要
2. Amazon MQ が解決する課題
3. 主な特徴
4. アーキテクチャと基本概念
5. エンジン比較：ActiveMQ vs RabbitMQ
6. ブローカーデプロイメントオプション
7. 主要ユースケース（10+）
8. コアコンポーネント
9. ブローカー設定・管理
10. メッセージングパターン
11. CLI・SDK・IaC 実装例
12. セキュリティ（認証・暗号化・ネットワーク）
13. 監視とアラート
14. 類似サービス比較表
15. ベストプラクティス
16. トラブルシューティング
17. 2025-2026 最新動向
18. 学習リソース
19. 実装例・チェックリスト
20. まとめ
21. 参考文献

概要

初心者向けメモ： Amazon MQ は「オンプレミスのメッセージブローカーを AWS でマネージドサービス化するツール」です。企業が ActiveMQ や RabbitMQ を使っている場合、アプリケーションコードをほぼ変更せずに AWS に移行でき、ブローカー管理の負担（HA 構成・パッチ・バックアップ）を AWS に委ねられます。新規開発では SQS/SNS が推奨されますが、プロトコル互換性維持・既存 JMS コード・サードパーティ依存 がある場合は Amazon MQ が最適です。

Amazon MQ は、分散メッセージングシステムの フルマネージド移行プラットフォーム として以下を実現します：

• オンプレ互換性：AMQP・JMS・STOMP・MQTT・OpenWire を業界標準プロトコルでサポート
• マネージドインフラ：HA・バックアップ・パッチ・スケーリングを AWS が自動管理
• 複数エンジン対応：ActiveMQ Classic / Artemis / RabbitMQ を単一コンソールで一元管理
• エンタープライズ機能：クォーラムキュー・ネットワーク・クラスター・CRDR
• コスト透明性：インスタンス時間課金で予測可能な運用コスト

参照：Amazon MQ Developer Guide

Amazon MQ が解決する課題

従来の課題

Amazon MQ が提供する解決策

✅ 最小限のコード変更：プロトコルレベルで互換性保証、アプリケーション変更ほぼ不要
✅ 完全マネージド：AWS がブローカー・ストレージ・ネットワークを管理、ユーザー負荷削減
✅ 高可用性：Active/Standby（ActiveMQ）またはクラスター（RabbitMQ）で 99.99% SLA
✅ 簡単なスケーリング：ブローカークラスを変更するだけで容量拡張
✅ 統合セキュリティ：KMS・VPC・TLS・IAM による多層防御
✅ 詳細監視：CloudWatch メトリクス・ログでリアルタイム可視化
✅ マルチエンジン対応：ActiveMQ / Artemis / RabbitMQ を同一プラットフォームで管理

主な特徴

1. オンプレ互換プロトコル

ActiveMQ・RabbitMQ の標準プロトコルをネイティブサポート：
├── AMQP 0-9-1 / 1.0（メッセージング標準）
├── STOMP（シンプルテキストプロトコル、WebSocket対応）
├── MQTT（IoT 向け軽量プロトコル）
├── OpenWire（ActiveMQ ネイティブプロトコル）
├── JMS（Java Message Service）
└── WebSocket（ブラウザベースクライアント）

2. エンジンオプション

• ActiveMQ Classic（従来）→ ActiveMQ Artemis（モダン標準へ段階移行）
• RabbitMQ（AMQP・クォーラムキュー・Federation対応）
• → 既存環境に応じて最適エンジン選択可能

3. デプロイメント形態

Single-Instance Broker:
    - 開発・テスト環境
    - 1 AZ、メンテ時停止あり

Active/Standby Broker（ActiveMQ）:
    - 本番環境推奨
    - NFS/EFS 共有ストレージでフェイルオーバー（数十秒）

Cluster Deployment（RabbitMQ）:
    - マルチ AZ、フルレプリケーション
    - 1 ノード停止でも継続動作

4. 統合管理

• 統一コンソール：ActiveMQ / RabbitMQ / Artemis を単一ダッシュボードで操作
• API：AWS SDK で全操作を自動化
• CloudFormation：IaC でブローカー構成をコード化

アーキテクチャと基本概念

ブローカーアーキテクチャ

┌─────────────────────────────────────┐
│      Amazon MQ Broker               │
├──────────────────────────────────────┤
│ Engine                               │
│ ├── ActiveMQ Classic / Artemis      │
│ └── RabbitMQ 4.2+                   │
├──────────────────────────────────────┤
│ Features                             │
│ ├── Destination Management          │
│ │  ├── Queues（キュー）             │
│ │  └── Topics（トピック）           │
│ ├── Authentication & Authorization  │
│ │  ├── ユーザー/パスワード          │
│ │  └── HTTP External Auth（v4.2+）  │
│ ├── Persistence                     │
│ │  ├── EBS（ブロックストレージ）    │
│ │  └── EFS（共有ストレージ）        │
│ └── Monitoring                      │
│    └── CloudWatch メトリクス         │
└──────────────────────────────────────┘

Connection Protocols:
├── OpenWire（ActiveMQ Native）
├── AMQP（Standard）
├── STOMP / WebSocket
└── MQTT（IoT）

メッセージングトポロジー

Producer ─→ Broker ─→ Queue / Topic ─→ Consumer
            └─ Storage（Persistent）

オンプレ / VPN ←→ Amazon MQ ←→ EC2 / Lambda
                          ├── HA（Active/Standby）
                          └── Monitoring（CloudWatch）

エンジン比較：ActiveMQ vs RabbitMQ

ブローカーデプロイメントオプション

ActiveMQ Classic / Artemis

Single-Instance（開発）:
  構成: 1 ブローカー / 1 AZ / ローカルストレージ
  SLA: なし（メンテ時停止あり）
  用途: 開発・テスト・PoC

Active/Standby（本番推奨）:
  構成: 
    - Active ブローカー（処理中） / Standby ブローカー（別 AZ）
    - 共有ストレージ: EFS / NFS
  フェイルオーバー: 自動（数十秒）
  SLA: 99.99%
  用途: 本番環境・ミッションクリティカル

Cluster（ActiveMQ Artemis）:
  構成: 2～3+ ノード全て Active
  レプリケーション: レプリケートされたキュー
  SLA: 99.99%
  用途: 高スループット・マルチテナント

RabbitMQ

Single-Instance（開発）:
  構成: 1 ブローカー / 1 AZ
  SLA: なし
  用途: 開発・テスト

Cluster（本番推奨）:
  構成: 3+ ブローカー / 3 AZ（各 AZ に 1 つ）
  キュータイプ: クォーラムキュー（3+ レプリカ）
  フェイルオーバー: 自動（新リーダー選出）
  SLA: 99.99%
  用途: 本番・エンタープライズ

Federation：
  複数クラスター間でのリモートキューアクセス
  用途: 地理的分散・マルチリージョン

主要ユースケース（10+）

1. オンプレ ActiveMQ から AWS への Lift & Shift 移行

オンプレ ActiveMQ クラスター
    ↓ (スキーマ・トポロジーそのまま)
Amazon MQ Active/Standby
    ↓ (アプリコード変更最小)
既存 Spring JMS / Apache Camel コンポーネント継続動作

メリット：アプリケーション変更ほぼ不要、移行リスク最小化

2. RabbitMQ on-premises のマネージド化

セルフマネージド RabbitMQ クラスター（管理負荷高）
    ↓
Amazon MQ RabbitMQ クラスター
    ↓
AWS が HA・バックアップ・パッチを管理

メリット：運用負荷 90% 削減、24/7 AWS サポート

3. Java EE / Spring マイクロサービス間通信

Spring Boot マイクロサービス
    ↓ (JMS)
Amazon MQ Queue
    ↓
非同期ワーカー処理（Spring JMS Listener）

メリット：同期依存排除、スケーラビリティ向上

4. Apache Camel ベースの統合プラットフォーム

複数の SaaS / On-Prem データソース
    ↓ (Camel Routes)
Amazon MQ（Camel Endpoints）
    ↓ (Router / Transformer)
AWS Lambda / RDS / S3

メリット：EIP（Enterprise Integration Pattern）をコード化

5. 金融システムの高信頼性メッセージング

取引プロデューサー
    ↓
Amazon MQ Active/Standby（99.99% SLA）
    ↓ (永続化ログ / 監査)
リスク管理システム

メリット：メッセージロスゼロ、正確に一回配信保証

6. IoT デバイスからの リアルタイムデータ取得

Edge デバイス（MQTT クライアント）
    ↓
Amazon MQ（MQTT ブローカー）
    ↓
AWS IoT Core / Lambda

メリット：数百万デバイス接続、低レイテンシ

7. 非同期ログ集約・監査ログ

複数 EC2 インスタンス
    ↓ (ログをメッセージ化)
Amazon MQ Topic（Pub/Sub）
    ↓
CloudWatch Logs / S3 Archival

メリット：リアルタイムログ処理、コンプライアンス対応

8. バッチ処理ワーカープール

スケジューラー
    ↓ (ジョブをキューに投入)
Amazon MQ Queue
    ↓
ECS / EC2 ワーカー（Auto Scaling対応）

メリット：動的スケーリング、負荷分散

9. マルチリージョンメッセージレプリケーション

• Primary Region: Amazon MQ (Active)
• ↓ (CRDR非同期レプリケーション)
• Replica Region: Amazon MQ (Replica)
• ↓ (フェイルオーバー時に昇格)

メリット：DR / ビジネス継続性

10. サードパーティ製品との統合（SAP・Oracle）

SAP / Oracle SOA Suite（JMS接続）
    ↓
Amazon MQ（プロトコル互換）
    ↓
AWS ネイティブサービス

メリット：既存エンタープライズ製品の活用

11. イベントドリブンアーキテクチャ

オンプレイベントソース（ActiveMQ）
    ↓
Amazon MQ（EventBridge Piped Connector）
    ↓
AWS Lambda / Step Functions

メリット：イベント駆動への段階的移行

12. マルチテナント SaaS のメッセージング

SaaS テナント管理プレーン
    ↓ (仮想キュー)
Amazon MQ（テナント分離）
    ↓
テナント固有のワーカー

メリット：テナント隔離、スケーラブル SaaS

コアコンポーネント

1. ブローカー（Broker）

定義: メッセージキュー・トピック・認証を管理するコンポーネント
設定項目:
  - Engine（ActiveMQ / RabbitMQ）
  - Instance Class（mq.t3.micro ~ mq.r5.4xlarge）
  - Deployment Mode（Single / Active-Standby / Cluster）
  - EBS Storage（30 GB ~ 200 GB）
  - Maintenance Window（日次ウィンドウ）

2. Queue（キュー）

特徴: ポイント to ポイント（1対1）メッセージング
セマンティクス:
  - メッセージ は先入先出（FIFO）
  - 1 つのコンシューマーのみ消費（競争モデル）
  - Dead Letter Queue（DLQ）でリトライ失敗メッセージ処理

3. Topic（トピック）

特徴: Pub/Sub（発行購読）メッセージング
セマンティクス:
  - 複数のサブスクライバーが同一メッセージ受信
  - メッセージは一時的（永続化なし、またはDurable Subscriber）
  - Wildcard subscriptions（topic.#）で柔軟なルーティング

4. Configuration（設定）

ブローカー固有設定:
  - ユーザー/パスワード（Secrets Manager 統合）
  - セキュリティグループ（ネットワークアクセス制御）
  - KMS キー（保存時暗号化）
  - ログレベル（CloudWatch Logs）
  - オートスケーリングポリシー（RabbitMQ）

5. Maintenance Window（メンテナンスウィンドウ）

自動メンテナンス対象:
  - パッチ・セキュリティアップデート
  - エンジンバージョンアップグレード
  - インフラストラクチャメンテナンス

スケジュール: 週次（日曜日推奨時間帯指定）
ダウンタイム: Active/Standby / Cluster = ほぼ 0（自動フェイルオーバー）

ブローカー設定・管理

ブローカー作成（CLI）

# ActiveMQ Active/Standby ブローカー作成
aws mq create-broker \
  --broker-name my-activemq-broker \
  --engine-type ACTIVEMQ \
  --engine-version 5.18.3 \
  --deployment-mode ACTIVE_STANDBY_MULTI_AZ \
  --broker-node-group-info "InstanceType=mq.m5.large" \
  --storage-type EBS \
  --security-groups sg-xxxxxxxx \
  --subnet-ids subnet-xxxxx subnet-yyyyy \
  --publicly-accessible false \
  --logs '{"Cloudwatch": {"Enabled": true, "LogGroup": "mq-logs"}}' \
  --users '[
    {
      "Username": "admin",
      "Password": "YourSecurePassword123!",
      "ConsoleAccess": true,
      "Groups": ["admins"]
    }
  ]'

# RabbitMQ クラスターブローカー作成
aws mq create-broker \
  --broker-name my-rabbitmq-cluster \
  --engine-type RABBITMQ \
  --engine-version 4.2.5 \
  --deployment-mode CLUSTER_MULTI_AZ \
  --broker-node-group-info "InstanceType=mq.r5.large,AZ=[ap-northeast-1a,ap-northeast-1c,ap-northeast-1d]" \
  --users '[
    {
      "Username": "admin",
      "Password": "SecurePassword456!",
      "ConsoleAccess": true
    }
  ]' \
  --publicly-accessible false

ブローカーの更新

# インスタンスクラス変更（ダウンタイムあり / Active-Standby で自動フェイルオーバー）
aws mq update-broker \
  --broker-id your-broker-id \
  --broker-node-group-info "InstanceType=mq.m5.xlarge"

# ユーザー追加
aws mq create-user \
  --broker-id your-broker-id \
  --username new-user \
  --password NewSecurePass789! \
  --console-access true

# ブローカー削除
aws mq delete-broker --broker-id your-broker-id

ActiveMQ キューの操作（OpenWire Protocol）

// Java Client（Spring Boot）
import org.springframework.jms.core.JmsTemplate;
import org.springframework.beans.factory.annotation.Autowired;

@Service
public class MessageProducer {
  @Autowired
  private JmsTemplate jmsTemplate;

  // メッセージ送信
  public void sendMessage(String queueName, String message) {
    jmsTemplate.convertAndSend(queueName, message);
  }

  // トランザクション付き送信
  @Transactional
  public void sendTransactional(String topic, String message) {
    jmsTemplate.convertAndSend(topic, message);
  }
}

// Consumer
@Component
public class MessageConsumer {
  @JmsListener(destination = "order.queue")
  public void receiveMessage(String message) {
    System.out.println("Received: " + message);
  }
}

RabbitMQ キューの操作（AMQP Protocol）

# Python Client（pika - RabbitMQ AMQP ライブラリ）
import pika
import ssl

# SSL 接続設定
context = ssl.create_default_context()
context.check_hostname = False
context.verify_mode = ssl.CERT_NONE

credentials = pika.PlainCredentials(username='admin', password='password')
parameters = pika.ConnectionParameters(
    host='b-xxx.mq.ap-northeast-1.amazonaws.com',
    port=5671,  # AMQP over TLS
    credentials=credentials,
    ssl_options=pika.SSLOptions(context)
)

connection = pika.BlockingConnection(parameters)
channel = connection.channel()

# キュー宣言
channel.queue_declare(queue='my.queue', durable=True)

# メッセージ送信
channel.basic_publish(
    exchange='',
    routing_key='my.queue',
    body='Hello RabbitMQ',
    properties=pika.BasicProperties(delivery_mode=2)  # Persistent
)

# メッセージ受信
def callback(ch, method, properties, body):
    print(f"Received: {body}")
    ch.basic_ack(delivery_tag=method.delivery_tag)

channel.basic_consume(queue='my.queue', on_message_callback=callback)
channel.start_consuming()

メッセージングパターン

Queue（Point-to-Point）

Producer → Queue → Consumer1（メッセージ消費）
              └──→ Consumer2（メッセージ消費）

競争モデル: Consumer1, 2 が同じキューから取得時、1つのメッセージは 1 つの Consumer のみ処理

Topic（Pub/Sub）

Publisher → Topic → Subscriber1（コピー受信）
                 ├→ Subscriber2（コピー受信）
                 └→ Subscriber3（コピー受信）

ブロードキャスト: 複数 Subscriber に同一メッセージ配信

Request/Reply（RPC 型）

• Requester → Request Queue → Worker
• ↓ (処理)
• Reply Queue ← Requester（correlationId で追跡）

Dead Letter Queue（DLQ）

• Queue → Consumer（処理失敗、再試行超過）
• ↓
• DLQ（最大リトライ後）
• ↓ (管理者が手動対応)

CLI・SDK・IaC 実装例

Terraform で ActiveMQ ブローカー作成

resource "aws_mq_broker" "activemq_broker" {
  broker_name             = "my-activemq"
  engine_type             = "ACTIVEMQ"
  engine_version          = "5.18.3"
  deployment_mode         = "ACTIVE_STANDBY_MULTI_AZ"
  instance_type           = "mq.m5.large"
  publicly_accessible     = false

  security_groups = [aws_security_group.mq_sg.id]

  subnet_ids = [
    aws_subnet.private_az1.id,
    aws_subnet.private_az2.id,
  ]

  logs {
    cloudwatch_logs {
      enabled = true
      log_group = aws_cloudwatch_log_group.mq_logs.name
    }
  }

  user {
    username       = "admin"
    password       = random_password.admin.result
    console_access = true
  }

  tags = {
    Name = "my-activemq"
  }
}

resource "aws_security_group" "mq_sg" {
  name = "mq-broker-sg"
  vpc_id = aws_vpc.main.id

  ingress {
    from_port   = 61617  # OpenWire
    to_port     = 61617
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }

  ingress {
    from_port   = 8162  # Web Console
    to_port     = 8162
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/8"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

CloudFormation で RabbitMQ クラスター

AWSTemplateFormatVersion: '2010-09-09'
Description: 'RabbitMQ Cluster on Amazon MQ'

Resources:
  RabbitMQCluster:
    Type: AWS::MQ::Broker
    Properties:
      BrokerName: my-rabbitmq-cluster
      EngineType: RABBITMQ
      EngineVersion: '4.2'
      DeploymentMode: CLUSTER_MULTI_AZ
      HostInstanceType: mq.r5.large
      PubliclyAccessible: false
      SecurityGroups:
        - !Ref RabbitMQSecurityGroup
      SubnetIds:
        - !Ref PrivateSubnetAZ1
        - !Ref PrivateSubnetAZ2
        - !Ref PrivateSubnetAZ3
      Tags:
        - Key: Name
          Value: MyRabbitMQCluster
      Users:
        - Username: admin
          Password: !Sub '{{resolve:secretsmanager:rabbitmq-admin-password:SecretString:password}}'
          ConsoleAccess: true

  RabbitMQSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: 'RabbitMQ Security Group'
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 5671
          ToPort: 5671
          CidrIp: 10.0.0.0/8
          Description: 'AMQP over TLS'
        - IpProtocol: tcp
          FromPort: 15672
          ToPort: 15672
          CidrIp: 10.0.0.0/8
          Description: 'Management UI'

Outputs:
  BrokerArn:
    Value: !GetAtt RabbitMQCluster.Arn
  BrokerEndpoint:
    Value: !Sub 'amqps://b-${RabbitMQCluster.BrokerId}.mq.${AWS::Region}.amazonaws.com:5671'

AWS CDK（Python）で ブローカー構築

from aws_cdk import (
    core,
    aws_mq as mq,
    aws_ec2 as ec2,
    aws_secretsmanager as secrets,
)

class MQBrokerStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs):
        super().__init__(scope, id, **kwargs)

        vpc = ec2.Vpc.from_lookup(self, "VPC", vpc_name="my-vpc")
        
        # RabbitMQ パスワード管理
        admin_password = secrets.Secret(self, "RabbitMQPassword",
            generate_secret_string=secrets.SecretStringValueEventDetails(
                secret_string_template='{"username": "admin"}',
                generate_string_key="password",
                exclude_punctuation=True
            )
        )

        # RabbitMQ クラスターブローカー
        broker = mq.CfnBroker(self, "RabbitMQCluster",
            broker_name="my-rabbitmq",
            engine_type="RABBITMQ",
            engine_version="4.2",
            deployment_mode="CLUSTER_MULTI_AZ",
            host_instance_type="mq.r5.large",
            publicly_accessible=False,
            security_groups=[vpc.select_subnets(
                subnet_type=ec2.SubnetType.PRIVATE
            ).subnets],
            users=[mq.CfnBroker.UserProperty(
                username="admin",
                password=admin_password.secret_value.to_string(),
                console_access=True
            )]
        )

        core.CfnOutput(self, "BrokerEndpoint",
            value=f"amqps://b-{broker.broker_id}.mq.{self.region}.amazonaws.com:5671"
        )

セキュリティ（認証・暗号化・ネットワーク）

ブローカー認証

ユーザー/パスワード（ローカル）

aws mq create-user \
  --broker-id my-broker \
  --username app-user \
  --password "SecurePassword123!" \
  --console-access false

HTTP ベース認証（RabbitMQ 4.2+、2026年新機能）

# HTTP サーバーで認証・認可を外部化
# RabbitMQ 側で HTTPS リクエストで認証
# 利点: LDAP / Active Directory / Okta との統合が可能

aws mq update-broker \
  --broker-id my-rabbitmq \
  --configuration '{"AuthenticationUri": "https://auth-server.example.com/auth"}'

転送中の暗号化

全プロトコルで TLS 1.2 以上を強制:
├── OpenWire: SSL://host:61617
├── AMQP: AMQPS://host:5671
├── MQTT: MQTTS://host:8883
└── WebSocket: WSS://host:61619

保存時の暗号化

# KMS CMK（Customer Master Key）で EBS・EFS 暗号化
aws mq create-broker \
  --broker-name secure-broker \
  --kms-key-id arn:aws:kms:region:account:key/xxxxx \
  # 自動的に EBS、メッセージストレージを暗号化

ネットワーク分離（VPC）

# ブローカーをプライベートサブネットに配置
aws mq create-broker \
  --publicly-accessible false \
  --subnet-ids subnet-private-1a subnet-private-1b \
  --security-groups sg-private-mq \
  # インターネット露出ゼロ
  # オンプレから VPN / Direct Connect 経由でアクセス

IAM ポリシー例

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "MQBrokerAccess",
      "Effect": "Allow",
      "Action": [
        "mq:DescribeBroker",
        "mq:ListBrokers",
        "mq:GetBrokerAttributes"
      ],
      "Resource": "arn:aws:mq:region:account:broker/my-broker:*"
    },
    {
      "Sid": "SecretsManagerAccess",
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:region:account:secret:mq-*"
    }
  ]
}

監視とアラート

CloudWatch メトリクス

主要メトリクス:

ActiveMQ:
├── CpuUtilization（CPU 使用率）
├── MemoryUsed（メモリ消費）
├── NetworkIn / NetworkOut（ネットワークトラフィック）
├── TotalMessageCount（キュー内メッセージ数）
├── TotalConsumerCount（アクティブコンシューマー数）
└── OpenConnectionsCount（接続数）

RabbitMQ:
├── QueueDepth（キューのメッセージ数）
├── ConsumerCount（コンシューマー数）
├── MessageRate（メッセージスループット）
├── AckRate（確認応答レート）
└── ClusterNodesUp（クラスターノード数）

CloudWatch アラーム

# キュー深度が閾値超過時アラート
aws cloudwatch put-metric-alarm \
  --alarm-name MQ-QueueDepth-High \
  --alarm-description "Alert if queue depth exceeds 1000" \
  --metric-name QueueDepth \
  --namespace AWS/MQ \
  --statistic Average \
  --period 300 \
  --threshold 1000 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:region:account:alert-topic

# ブローカーダウンアラート
aws cloudwatch put-metric-alarm \
  --alarm-name MQ-Broker-Down \
  --metric-name BrokerHealthStatus \
  --namespace AWS/MQ \
  --statistic Maximum \
  --period 60 \
  --threshold 0 \
  --comparison-operator LessThanOrEqualToThreshold

CloudWatch Logs

# ブローカーログを CloudWatch Logs に送信
aws mq update-broker \
  --broker-id my-broker \
  --logs '{"Cloudwatch": {"Enabled": true, "LogGroup": "mq-logs"}}'

# ログレベル設定
# ブローカー管理コンソール（http://broker:8162/admin）から
# Log Level: DEBUG / INFO / WARN / ERROR を選択

カスタムメトリクス送信

import boto3
import time

cloudwatch = boto3.client('cloudwatch')

# アプリケーション側でカスタムメトリクス送信
cloudwatch.put_metric_data(
    Namespace='CustomMQ',
    MetricData=[
        {
            'MetricName': 'MessageProcessingTime',
            'Value': 234,  # ミリ秒
            'Unit': 'Milliseconds',
            'Timestamp': int(time.time())
        },
        {
            'MetricName': 'ProcessingErrorRate',
            'Value': 0.5,  # %
            'Unit': 'Percent'
        }
    ]
)

類似サービス比較表

ベストプラクティス

設計・構成

✅ 本番環境は Active/Standby または Cluster を使用

• Single-Instance は開発・テスト限定
• ダウンタイムゼロ・99.99% SLA を確保

✅ 共有ストレージ（EFS）で永続性確保

• Active/Standby 時は EFS でメッセージロス防止
• RabbitMQ Cluster は全ノードにレプリケート

✅ VPC 内プライベートサブネットに配置

• インターネット露出ゼロ
• セキュリティグループで接続元制限

✅ マルチ AZ 構成で可用性確保

• Active/Standby：異なる AZ に配置
• RabbitMQ Cluster：3 AZ に分散配置

✅ CloudWatch ログを有効化

• CloudWatch Logs で全ログ集約
• 監査・トラブルシューティング対応

運用・監視

✅ CloudWatch メトリクス・アラーム設定

• キュー深度・メモリ・CPU 閾値設定
• SNS で管理者に通知

✅ メンテナンスウィンドウを適切に設定

• 週次、オフピーク時間帯を選択
• Active/Standby なら自動フェイルオーバー

✅ 定期的なバックアップ・復旧テスト

• EBS スナップショット、あるいはメッセージ手動バックアップ
• 年 1 回は復旧手順を検証

✅ ブローカーパフォーマンスチューニング

# キャッシュサイズ設定（ActiveMQ）
KahaDBStore cache size: 65536

# コンシューマープリフェッチ（オーバーロード防止）
activemq.prefetchSize: 1（低レイテンシ）or 100（スループット重視）

セキュリティ

✅ KMS CMK で保存時暗号化

--kms-key-id arn:aws:kms:...

✅ Secrets Manager でパスワード管理

# パスワードハードコード禁止
aws secretsmanager get-secret-value --secret-id mq-admin-password

✅ IAM ポリシー最小権限の原則

• DescribeBroker / ListBrokers のみ許可
• DeleteBroker は管理者のみ

✅ 定期的なセキュリティアップデート

• メンテナンスウィンドウで自動適用
• パッチ後の HA フェイルオーバーを監視

トラブルシューティング

2025-2026 最新動向

1. RabbitMQ 4.2 ネイティブサポート（2025年11月）

• AMQP 1.0 正式対応：プロトコル標準化、相互運用性向上
• Khepri メタデータストア：より高速・安定したメタデータ管理
• メッセージプライオリティ：quorum queue でメッセージ優先度制御
• 参照: Amazon MQ now supports RabbitMQ version 4.2

2. HTTP ベース認証（RabbitMQ 4.2+、2026年1月）

• 外部認証システム統合：LDAP / Active Directory / Okta と連携
• 動的権限管理：HTTP リクエストで実行時認可判定
• 参照: Amazon MQ now supports HTTP based authentication for RabbitMQ brokers

3. ActiveMQ から Artemis への段階的移行

• ActiveMQ Classic はレガシーモード
• Artemis がモダン標準、AMQP 1.0 フル対応
• 既存ユーザーへの段階的移行パス提供

4. リソースリミット動的設定

• RabbitMQ 4.2 で CPU・メモリ・接続数を動的に構成可能
• ブローカー再起動なしでの調整

5. AWS DMS Serverless（関連）との統合

• DB マイグレーション + メッセージング統合シナリオの拡大
• リアルタイムデータパイプラインの強化

学習リソース

公式ドキュメント・ガイド

1. Amazon MQ Developer Guide
2. Amazon MQ API Reference
3. Getting Started: Creating and Connecting to an ActiveMQ Broker
4. Getting Started: Creating and Connecting to a RabbitMQ Broker
5. Best Practices for Amazon MQ
6. Amazon MQ Pricing
7. Amazon MQ FAQ
8. AWS Security Best Practices for Amazon MQ

オープンソース・コミュニティ

1. Apache ActiveMQ Documentation
2. Apache ActiveMQ Artemis Guide
3. RabbitMQ Documentation
4. RabbitMQ GitHub Repository
5. Apache Camel Documentation

AWS ブログ・チュートリアル

1. AWS News: Amazon MQ Latest Updates
2. AWS Samples: MQ Examples
3. AWS Well-Architected Messaging Patterns

実装例・チェックリスト

実装例：Spring Boot + Amazon MQ（ActiveMQ）

// application.yml
spring:
  activemq:
    broker-url: failover:(ssl://b-xxx.mq.ap-northeast-1.amazonaws.com:61617)
    user: admin
    password: ${ACTIVEMQ_PASSWORD}
  jms:
    pub-sub-domain: false

// OrderProducer.java
@Service
public class OrderProducer {
  @Autowired private JmsTemplate jmsTemplate;

  public void publishOrder(Order order) {
    jmsTemplate.convertAndSend("order.queue", order);
  }
}

// OrderConsumer.java
@Service
public class OrderConsumer {
  @JmsListener(destination = "order.queue")
  public void processOrder(Order order) {
    // ビジネスロジック
  }
}

導入チェックリスト

• [ ] 計画段階

  • [ ] 既存オンプレ ActiveMQ / RabbitMQ 構成をドキュメント化
  • [ ] 必要なプロトコル（OpenWire / AMQP / STOMP）確認
  • [ ] メッセージボリューム・スループット見積もり
  • [ ] HA 要件（Active/Standby or Cluster）定義

• [ ] 設計段階

  • [ ] VPC・サブネット・セキュリティグループ設計
  • [ ] ブローカークラス・ストレージサイズ決定
  • [ ] メンテナンスウィンドウスケジュール（週次推奨）
  • [ ] 監視・ロギング戦略（CloudWatch 統合）

• [ ] 実装段階

  • [ ] Terraform / CloudFormation で IaC コード化
  • [ ] 開発環境（Single-Instance）構築・テスト
  • [ ] 本番環境（Active/Standby or Cluster）構築
  • [ ] セキュリティグループ・IAM ポリシー適用
  • [ ] KMS キー・Secrets Manager パスワード設定

• [ ] 検証段階

  • [ ] ブローカー接続テスト（複数クライアント）
  • [ ] メッセージ送受信テスト
  • [ ] フェイルオーバーテスト（1 ノード停止時）
  • [ ] CloudWatch メトリクス確認
  • [ ] ログ集約確認

• [ ] 運用段階

  • [ ] CloudWatch アラーム設定（キュー深度・メモリ等）
  • [ ] 定期バックアップ計画
  • [ ] 年 1 回以上の復旧テスト
  • [ ] セキュリティ監査（アクセス制御・暗号化）
  • [ ] パフォーマンスチューニング（必要に応じ）

まとめ

Amazon MQ は「オンプレミス Active MQ / RabbitMQ を AWS でマネージド化する最適なソリューション」 です。

主要なポイント：

1. オンプレ互換性：AMQP・JMS・STOMP・MQTT のネイティブサポートで、アプリケーション変更最小化
2. 完全マネージド：AWS が HA・バックアップ・パッチを自動管理、運用負荷 90% 削減
3. 柔軟なデプロイ：Single-Instance（開発）/ Active/Standby（本番）/ Cluster で要件に応じた選択
4. エンタープライズ機能：99.99% SLA・KMS 暗号化・CloudWatch 統合で大規模組織対応
5. 2025-2026 強化：RabbitMQ 4.2 AMQP 1.0・HTTP 認証で、プロトコル標準化・動的認可が可能

採用判断：

✅ Amazon MQ を選ぶべき：

• オンプレミス ActiveMQ / RabbitMQ を AWS に移行したい
• 既存 JMS / AMQP コードを保護したい
• エンタープライズグレードの HA が必須
• サードパーティ製品との互換性が重要

❌ Amazon MQ ではなく SQS/SNS を選ぶべき：

• 新規 AWS アーキテクチャ設計
• 無制限スケーリング必要
• 低コスト重視
• シンプルなキュー・Pub/Sub で十分

Amazon MQ は、エンタープライズ移行・プロトコル互換性・運用負荷削減 の 3 つが重要な組織に最適なマネージドメッセージブローカーサービスです。

参考文献

公式ドキュメント

• Amazon MQ Developer Guide
• Amazon MQ API Reference
• Amazon MQ Release Notes

オープンソース

• Apache ActiveMQ Official Documentation
• Apache ActiveMQ Artemis Guide
• RabbitMQ Official Documentation
• RabbitMQ GitHub Repository

AWS 最新情報

• Amazon MQ now supports RabbitMQ version 4.2 - AWS
• Amazon MQ now supports HTTP based authentication for RabbitMQ brokers - AWS

関連サービス

• AWS SQS
• AWS SNS
• AWS EventBridge
• Apache Camel
• Spring Framework JMS

最終更新：2026-04-26
バージョン：v2.0