【神アプデ】Amazon MQ for RabbitMQ がついにプライベート接続対応！NLB/NAT Gateway の泥沼運用から解放される日

Amazon MQ for RabbitMQ がプライベートネットワーキングをサポートしました。これにより、VPC 内のリソース（LDAP/OAuth 2.0 プロバイダー、他のブローカー、セルフホストの RabbitMQ など）に対して、パブリックインターネットを経由せずに安全に接続することが可能になります。この仕組みは Amazon VPC Lattice、AWS Resource Access Manager (AWS RAM)、および AWS PrivateLink を組み合わせて実現されており、従来必要だった Network Load Balancer (NLB) や NAT Gateway を使用した複雑な回避策が不要になります。

待望の「脱・回避策」！構成が劇的にシンプルに

これまで Amazon MQ for RabbitMQ を使っているエンジニアにとって、プライベートな認証基盤（LDAP等）に接続したり、ブローカー間で Federation/Shovel を行う際、**「NLB や NAT Gateway を無理やり噛ませて、何とかパブリック経由の通信をプライベートっぽく見せる」**という、かなり力技な構成が必要でしたよね。今回のアップデートで、その泥沼からついに解放されます！

国内エンジニアへの朗報：東京・大阪リージョンで即利用可能

リサーチの結果、東京リージョン (ap-northeast-1) および大阪リージョン (ap-northeast-3) の両方で、前提となる Amazon VPC Lattice が利用可能であることを確認しました。日本の現場でも、セキュリティ要件が厳しいエンタープライズ環境で即座に導入検討ができる状態です。

実装時の「ハマりポイント」と運用アドバイス

導入にあたっては、いくつか注意すべき技術的ポイントがあります。

• AWS RAM の設定に注意: リソース共有設定で allowExternalPrincipals=true を有効にしないと、Amazon MQ と連携できずエラーになります。ここは盲点になりやすいので要注意です。
• ブローカーの再起動が必須: 設定を関連付けた後、UpdateBroker API を実行した後にブローカーの再起動が必要です。クラスター構成ならフェイルオーバーが発生しますし、シングルインスタンスならダウンタイムが発生するので、メンテナンス計画を立ててから実施しましょう。
• コスト面: VPC Lattice や PrivateLink の料金が発生しますが、従来必要だった NLB や NAT Gateway の運用コスト・管理コストを考えると、トータルでは「引き算」になる可能性があります。

まずは何をチェックすべき？

まずは、現在 RabbitMQ の接続に NLB 等を介在させているかどうか、そしてそれらを VPC Lattice ベースの構成に置き換えることでどれだけ構成のシンプルさとセキュリティを高められるか を検証してみてください。特に TLS 検証が必要な RabbitMQ 4 以降の環境では、カスタムドメインの設定もセットで確認しておくのが吉です。

参照元: Amazon MQ Developer Guide: Private networking for Amazon MQ for RabbitMQ