以下は2019/06/11現在の情報に基づきます。そのため、将来の機能改廃に伴って記述内容との乖離が発生する可能性があります。

Azureで提供しているQueue/Topic機能を有するサービス

以下のものがある。

• Queue Storage
• Azure Event Grid
• Azure Service Bus
• Azure Event Hubs

選定のポイント

Queue StorageとService Busの比較は以下を参照。

Storage キューと Service Bus キューの比較 / Storage queues and Service Bus queues – compared and contrasted
https://docs.microsoft.com/azure/service-bus-messaging/service-bus-azure-and-service-bus-queues-compared-contrasted

Queue/TopicとEvent Hubの違い

	Queue/Topic	Event Hub
Unit of Work (作業単位)	メッセージ	Stream
インフラ	軽量	重量

選択の指針

Queue Storage	特定の追加要件のないシンプルなキューが必要な場合 キューを通ったすべてのメッセージの監査証跡が必要な場合 キューのサイズが 80 GB を超えると予想される場合 キュー内のメッセージ処理の進行状況の追跡が必要な場合
Azure Service Bus (Queue)	At-Most-Once 配信保証が必要な場合 FIFO保証が必要 メッセージをトランザクションにグループ化する必要がある場合 キューをポーリングせずにメッセージ受信できる必要がある場合 キューにロール ベースのアクセス モデルを設定する必要がある場合 64 KB を超えるが 256 KB 未満のメッセージを処理すればよい場合 キューのサイズが 80 GB を超えない場合 バッチ メッセージの発行および利用が必須の場合
Azure Service Bus (Topic)	各メッセージを処理する複数の受信側が必要な場合
Azure Event Grid	ソースをサブスクライバーに簡単に接続したい場合 トピックから受け取るイベントに対し、フィルタリングで細かく制限したい場合 同じイベントやトピックにエンドポイントを無制限にサブスクライブさせたい場合 イベントの配信を、各サブスクリプションに対して最大で 24 時間再試行させる必要がある場合 送信するイベント数のみに対する従量課金を選択したい場合
Azure Event Hubs	多数の発行元の認証をサポートする必要がある場合 Data Lake または BLOB ストレージにイベントのストリームを保存する必要がある場合（Streaming） イベント ストリームの集計または分析が必要な場合（Streaming Analytics） 信頼できるメッセージングまたは回復性が必要な場合

Service Busについて

注意点

いわゆるSOAミドルウェアの場合、Service Busが送信側からメッセージを受け取ると受信側に転送する振る舞いだが、Azure Service Busの場合、送受信ともService Busに接続し、受信側はCallbackを登録（Long Polling）して着信を待つ（SOAミドルウェアの場合転送メッセージを内部で保持しないことが多い）点と、蓄積交換型のミドルウェアのような振る舞いをする点に特徴がある。もしSOAミドルウェアと同様の振る舞いをさせるには、WCF Relay（旧Service Bus Relay、WCF：Windows Communication Foundationベース）を使う。

注意：Azure Relayの場合、WebSocketを使う。Relayの種類と機能の違いは以下を参照。

機能 / Features
https://docs.microsoft.com/azure/service-bus-relay/relay-what-is-it#features

接続できるプロトコル

Service BusではHTTPベースの通信だけでなく、AMQP、JMSでのメッセージ送受信も可能（AMQP 1.0、JMS 1.1もしくは2.0）。