Azure Event Grid入門｜AWS EventBridgeとの違い・トピック設計・料金をオンプレ経験者向けに解説する実践ガイド

Azureリソースの変化をリアルタイムで別のサービスへ通知したい——そんなニーズをフルマネージドで解決するのがAzure Event Gridです。オンプレではcronで5分ごとにログを確認するスクリプトを書いていた、という経験のある方も多いはずです。Event Gridを使えば、Blob ストレージへのファイルアップロードやAzure VMの状態変化を即座に検知し、Azure FunctionsやLogic Apps、Service Busへルーティングできます。
この記事では、Event Gridの基本概念（トピック・サブスクリプション・イベントスキーマ）から設定手順・料金・AWS EventBridgeとの違いまで、オンプレ経験者にもわかりやすく解説します。

オンプレ「ポーリング監視」との決別——イベント駆動が必要な理由

オンプレの運用では、変化を検知するために「定期ポーリング」に頼るケースが多くあります。たとえば5分おきにファイルサーバーをチェックしてディレクトリに新規ファイルが入ったら処理を走らせる、というスクリプトが社内のcrontabに眠っていないでしょうか。
このポーリング型には3つの構造的な問題があります。
・検知遅延: 最悪でポーリング間隔（例: 5分）の遅延が生じる
・無駄なリソース消費: 変化がなくてもサーバーやネットワークに負荷がかかる
・スケール困難: 監視対象が増えるほどポーリング本数が線形に増える
クラウドのイベント駆動モデルはこれを根本から逆転させます。「変化があったときだけ」通知が来るプッシュ型なので、平常時のリソース消費はほぼゼロです。Azure Event Gridはその仕組みをサーバーレスで提供するマネージドサービスです。

Azure Event Gridとは？基本概念を整理する

Event Gridは、Azureの各サービスやカスタムアプリが発生させる「イベント」を受け取り、登録された宛先へルーティングするフルマネージドのイベントブローカーです。
構造を理解するには5つの構成要素を押さえてください。

1. System TopicとCustom Topicの違い

System Topicは、Azure Blob Storage・Azure Resource Manager・Azure Container Registry等、Azureのサービスが自動的に発行するイベントの受信窓口です。Azureポータル上でストレージアカウントの「イベント」メニューを開くと、裏側でSystem Topicが自動作成されます。ユーザー側での管理は不要です。
Custom Topicは、自社アプリやサードパーティシステムが発行するイベントのために自分で作成するトピックです。エンドポイントURLとキーを取得し、アプリからHTTP POSTでイベントを送信します。

2. イベントスキーマ: Event GridスキーマとCloudEvents

Event Gridはイベントのフォーマットとして、独自のEvent GridスキーマとCNCFが策定した標準規格CloudEvents 1.0の両方をサポートしています。新規構築では、将来的なベンダー非依存を見据えてCloudEventsを採用するケースが増えています。どちらを選ぶかはサブスクリプション作成時に固定されるため、プロジェクト初期に方針を決めておくことが重要です。

AWS EventBridgeとの違い——どちらを使うべきか

AWS EventBridgeを知っているエンジニアは「Event Gridと何が違うのか」が気になるはずです。両者は概念的に似ていますが、設計哲学と対応ユースケースが異なります。

AzureをメインクラウドとしてFunctionsやLogic Appsと組み合わせるならEvent Gridが自然な選択です。一方、SaaSとの豊富な連携やスケジューラー機能が必要なAWS環境ではEventBridgeが優位です。詳細はAWS EventBridge入門も参照ください。

基本的な使い方——Azure CLIによる設定手順

1. カスタムトピックを作成する

まずリソースグループとカスタムトピックを作成します。

# リソースグループを作成（東日本リージョン: japaneast）
az group create --name rg-eventgrid-demo --location japaneast

# カスタムトピックを作成（CloudEventsスキーマを指定）
az eventgrid topic create \
  --name myapp-events \
  --resource-group rg-eventgrid-demo \
  --location japaneast \
  --input-schema cloudeventschemav1_0

# エンドポイントURLとアクセスキーを取得
TOPIC_ENDPOINT=$(az eventgrid topic show \
  --name myapp-events \
  --resource-group rg-eventgrid-demo \
  --query "endpoint" -o tsv)

TOPIC_KEY=$(az eventgrid topic key list \
  --name myapp-events \
  --resource-group rg-eventgrid-demo \
  --query "key1" -o tsv)

2. イベントサブスクリプションを設定する

イベントの送信先としてWebhookエンドポイントを登録します。ここではAzure Functionsのエンドポイントを想定しています。

# イベントサブスクリプションを作成（Azure Functions Webhookを宛先に指定）
TOPIC_ID=$(az eventgrid topic show \
  --name myapp-events \
  --resource-group rg-eventgrid-demo \
  --query id -o tsv)

az eventgrid event-subscription create \
  --name myapp-subscription \
  --source-resource-id "${TOPIC_ID}" \
  --endpoint https://myfunctions.azurewebsites.net/api/HandleEvent \
  --included-event-types "MyApp.OrderCreated" "MyApp.OrderShipped"

3. カスタムイベントを発行してテストする

アプリケーションからEvent GridへHTTP POSTでイベントを送信します。CloudEventsスキーマの場合のサンプルです。

# CloudEventsスキーマでイベントをバッチ発行
curl -X POST "${TOPIC_ENDPOINT}" \
  -H "Content-Type: application/cloudevents-batch+json" \
  -H "aeg-sas-key: ${TOPIC_KEY}" \
  -d '[
    {
      "specversion": "1.0",
      "type": "MyApp.OrderCreated",
      "source": "/myapp/orders",
      "id": "order-12345",
      "time": "2026-09-02T10:00:00Z",
      "data": {
        "orderId": "12345",
        "amount": 9800
      }
    }
  ]'

Webhookエンドポイントを使う場合、Event GridはサブスクリプションURL作成時にエンドポイント検証リクエストを送信します。ハンドラー側がこの検証に応答しないとサブスクリプションが有効化されないため、注意が必要です。Azure FunctionsのEvent Gridトリガーバインディングを使うと検証処理が自動化されます。

料金の仕組み（2026年9月時点）

Event Gridの料金はシンプルです。「オペレーション数」に対して課金されます。
・無料枠: 月間100万オペレーションまで無料
・超過分: 100万オペレーションあたり約$0.60（USD・2026年9月時点）

「オペレーション」として数えられる操作は以下のとおりです。
・イベント発行: トピックへのPOSTリクエスト（64KB単位でカウント。64KB超は複数オペレーション）
・配信試行: ハンドラーへの送信1回ごとにカウント（自動再試行も含む）
・高度なフィルタリング: サブスクリプションごとに月5件まで無料。超過は$0.09/件

デッドレターへの転送や再試行もオペレーションとしてカウントされます。ハンドラーが頻繁にタイムアウトすると再試行コストが膨らむため、ハンドラー側の応答時間を適切に管理することが実務上のポイントです。月100万オペレーションという無料枠は中規模のシステムであれば十分に収まることが多く、コスト面での導入ハードルは低いといえます。

実務Tips——フィルタリング・デッドレター・再試行設計

【重要】サブジェクトフィルタリングでノイズを排除する

Blob Storageのイベントを受け取る場合、コンテナ全体ではなく特定パス配下のBlobのみに絞り込めます。無駄なイベントをハンドラーに流さないことがコスト最適化と処理効率の両方に効きます。

# imagesフォルダ配下のJPGファイル作成イベントだけに絞り込む
az eventgrid event-subscription update \
  --name mystorage-subscription \
  --source-resource-id /subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account} \
  --subject-begins-with /blobServices/default/containers/mycontainer/blobs/images/ \
  --subject-ends-with .jpg

イベントタイプフィルタ（`–included-event-types`）と組み合わせることで、「特定コンテナへの書き込みかつBlobCreatedのみ」のような細かい絞り込みが可能です。

デッドレター——配信失敗時のイベント退避

ハンドラーが一定回数（デフォルト30回・最大1440分のTTL内）配信に失敗すると、イベントはデッドレターへ転送されます。デッドレター先としてAzure Blob Storageのコンテナを指定できます。
・デッドレターを設定しない場合: 配信失敗したイベントはそのまま消失します
・本番環境での推奨: 必ずデッドレターストレージを設定してください

デッドレターに滞留したイベントは手動または自動プロセスで再処理できます。Azure Monitorの「DeadLetteredCount」メトリクスをアラート化しておくと、運用上の見落としを防げます。

再試行ポリシーの設計

Event Gridは失敗した配信を指数バックオフで自動再試行します。デフォルト設定は以下です。
・最大配信試行回数: 30回
・イベントTTL: 1440分（24時間）

再試行回数とTTLはサブスクリプション単位でカスタマイズ可能です。処理時間が長いバッチ処理ハンドラーには大きめのTTLを設定し、即時性が求められるリアルタイム処理には短めのTTLを設定するなど、ユースケースに合わせて調整してください。

クレームチェックパターン——1MB超のペイロードへの対処

Event Gridが受け付けるイベントサイズの上限は1MB（バッチ全体）です。大きなデータを扱う場合は「クレームチェックパターン」が有効です。実際のデータはBlobストレージやAzure Service Busに置き、Event GridのイベントにはそのURLや参照IDだけを載せます。ハンドラーはイベントを受け取った後、参照先から本体データを取得して処理します。

よくあるトラブルと対処法

Q. Webhookサブスクリプションを作成しようとするとエラーになる
A. Event GridはWebhook登録時にエンドポイント検証として HTTP POSTの「検証リクエスト」を送信します。エンドポイントがこのリクエストに含まれる`validationCode`を200で返さないとサブスクリプションが有効化されません。Azure FunctionsのEvent Gridトリガーバインディングを使えばこの検証応答が自動化されます。

Q. イベントを発行しているのにハンドラーに届かない
A. サブスクリプションのイベントタイプフィルタを確認してください。`–included-event-types`に発行しているイベントタイプが含まれていないケースがよくあります。Azure Monitorの「DeliveryFailedCount」メトリクスと「DeliverySuccessCount」メトリクスを比較し、配信試行自体が行われているか確認しましょう。

Q. 発行したイベントが400エラーで拒否される
A. Event Gridの1リクエストあたりのサイズ上限（1MB）を超えている可能性があります。また、CloudEventsスキーマで作成したトピックにEvent Gridスキーマ形式のリクエストを送るなど、スキーマの不一致も原因になります。`Content-Type`ヘッダーがスキーマに対応したMIMEタイプになっているか確認してください。

Q. デッドレターが設定してあるのにイベントが見当たらない
A. デッドレター用ストレージアカウントへのアクセス権（Storage Blob Data Contributorロール）がEvent Gridのシステムマネージドアイデンティティに付与されているか確認してください。権限がないと書き込みが失敗し、イベントが消失します。

本記事のまとめ

Azure Event Gridのポイントをまとめます。

Event Gridはオンプレのポーリング型監視スクリプトを置き換えるだけでなく、Azureサービス同士を疎結合に連携させるアーキテクチャの根幹を担います。まずはストレージアカウントのSystem Topicから試してみると、イベント駆動の手応えをすぐに体感できます。