MENU

Azure Front Door edge actions入門｜JavaScriptでカナリア配信・ヘッダー操作・WAF連携を安全に検証

Azure

Azure Front Door edge actionsを使うと、オリジンへ到達する前のクライアントリクエスト段階で軽量なJavaScriptを実行し、ヘッダー操作、URL書き換え、カナリアルーティング、JWT検証、リクエスト拒否などを実装できます。

ただし、2026年7月時点ではパブリックプレビューです。WAFはEdge Actionより先に実行され、JavaScriptの実行時間が10ミリ秒を超えると、Edge Actionの処理を適用せずにリクエストが先へ進みます。そのため、カナリア配信には「安定版を既定にする」、認証には「オリジンでも再検証する」という設計が欠かせません。(Microsoft Azure)

この記事では、Azure Front Door edge actionsの適用範囲、WAF・Rules・Cache・Routingとの評価順、カナリアルーティングの実装例、安全なフォールバック、ログを使った確認方法まで具体的に解説します。

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

Azure Front Door edge actionsとは

Azure Front Door edge actionsは、Microsoftのグローバルエッジ上で独自のJavaScriptを実行する機能です。Azure Update ID 567402として案内され、現在はパブリックプレビューとして提供されています。

従来のAzure Front Door Rule setでも、条件付きルーティング、リダイレクト、URL書き換え、ヘッダー操作などは設定できました。ただし、Rule setは宣言的な設定であり、複数の入力を組み合わせた判断や、オリジンの状態に応じた細かな分岐には限界があります。

Edge Actionでは、リクエストヘッダー、国・地域、デバイス種別、現在時刻、正常なオリジンの一覧などをJavaScriptから参照し、処理結果をリクエストやルーティングへ反映できます。(TECHCOMMUNITY.MICROSOFT.COM)

実装場所適している処理適していない処理
Azure Front Door Rule set固定条件によるリダイレクト、ヘッダー追加、キャッシュ制御、単純なルーティング多数の条件を組み合わせる複雑な分岐
Edge Actionカナリア判定、動的なオリジン選択、軽量な認証前処理、ヘッダー正規化10ミリ秒を超える処理、状態管理、重いライブラリ
API Managementやオリジン厳密な認証・認可、外部API連携、データベース参照、業務処理すべてのリクエストで行う単純なエッジ判定

固定条件だけで済むなら、まずRule setを使う方が管理しやすくなります。Edge Actionを選ぶべきなのは、「複数のリクエスト情報をJavaScriptで評価しなければ判断できない場合」です。

Hyperlight microVMでJavaScriptを分離実行する

ユーザーが記述したJavaScriptは、Hyperlightを基盤とする軽量なmicroVM内で実行されます。

Hyperlight microVMには汎用的なゲストOSがなく、それぞれのEdge Actionコードをハードウェアベースの境界で分離します。通常の仮想マシンより小さな実行環境にすることで、起動や実行に伴う負荷を抑えながら、ホストや他のテナントとの分離を確保する設計です。(TECHCOMMUNITY.MICROSOFT.COM)

ただし、microVMによる分離は、JavaScriptの業務ロジックが正しいことを保証するものではありません。次の問題は利用者側で防ぐ必要があります。

  • 意図しないオリジンへの振り分け
  • クライアントが偽装できるヘッダーの信用
  • JWT検証の不足
  • 認証情報や個人情報のログ出力
  • タイムアウト時の認証迂回
  • キャッシュによるカナリアコンテンツの混在

パブリックプレビューで利用できる機能と制約

現在のEdge Actionは、クライアントからリクエストを受け取った段階で実行する「client request invocation」のみに対応しています。

対応シナリオと主要な制約は次のとおりです。(Microsoft Learn)

項目パブリックプレビュー時点の仕様
対応言語JavaScript
実行タイミングクライアントリクエスト段階
コードサイズ1バージョンあたり16KB
最大実行時間10ミリ秒
バージョン数Edge Actionごとに最大3
リソース数サブスクリプションあたり最大100
呼び出し方法Azure Front DoorのルートにRule set経由で関連付ける
主な用途A/Bテスト、カナリア配信、ヘッダー操作、リクエスト拒否、動的オリジン選択、URL書き換え・リダイレクト、JWT検証

レスポンスヘッダーの設定や401・403による拒否は可能ですが、現時点ではオリジンからレスポンスを受け取った後に、別のレスポンス用フックでJavaScriptを実行する機能は提供されていません。Microsoftは、レスポンス段階の呼び出しを将来の拡張候補として示しています。(TECHCOMMUNITY.MICROSOFT.COM)

最重要の制約は10ミリ秒超過時の挙動

JavaScriptの実行が10ミリ秒を超えると、Azure Front Doorはコードの実行を終了し、Edge Actionの処理を適用しない状態でリクエストを先へ送ります。(Microsoft Learn)

この動作は、用途によって影響が異なります。

用途タイムアウト時の影響必要な対策
カナリアルーティングオリジン選択が適用されないAzure Front Door標準の選択先を安定版にする
ヘッダー付与オリジンへ必要なヘッダーが届かないオリジン側で未設定時の既定動作を安全にする
URL書き換え元のURLのまま処理される可能性がある元URLでも権限や入力を再検証する
JWT認証Edge Actionによる拒否を通過する可能性があるオリジンでも必ずJWTを検証する
不正リクエスト拒否Edge Actionで拒否できない可能性があるWAFとオリジン側の検証を併用する

この仕様から、Edge Actionを唯一の認証境界として使う設計は避けるべきです。カナリア配信ではフェイルセーフな安定版へ進めますが、認証では「処理しなかった場合に拒否する」仕組みをオリジン側にも持たせる必要があります。

WAF、Rule set、Edge Action、Cache、Routingの評価順

Azure Front Doorの公開ドキュメントを組み合わせると、処理の流れは概ね次のように整理できます。

順序処理主な役割
1Front Doorプロファイルの特定Hostヘッダーから対象プロファイルを決定
2WAF評価不正な入力、Bot、IP、レートなどを検査
3ルートの照合パスやプロトコルから対象ルートを決定
4Rule setの評価条件、ヘッダー操作、書き換え、Edge Action呼び出しなどを実行
5Edge Actionの実行JavaScriptでリクエスト、レスポンス、オリジン選択を変更
6キャッシュ確認有効なキャッシュがあればオリジンへ送らず返却
7オリジン選択Edge Actionの指定、または標準の優先度・重み・遅延判定を使用
8オリジンへ転送最終的なリクエストをバックエンドへ送信

WAFはRule setより先に処理され、Rule setはルートに設定した順序で評価されます。Edge Actionは、Rule set内の「Invoke Edge Action」アクションによって呼び出されます。キャッシュヒット時はオリジンへ到達しません。(Microsoft Learn)

WAFはEdge Actionによる変更前のリクエストを評価する

WAFが先に実行されるため、Edge Actionで後から追加したヘッダーや書き換えたURLを、同じリクエスト内でWAFが再評価する前提にはできません。

例えば、Edge Actionで次の処理をしても、その結果を同じWAF評価へ戻すことは想定しない方が安全です。

  • /public/reportを/admin/reportへ書き換える
  • x-app-role: adminを追加する
  • クエリ文字列から値を取り出して認証ヘッダーを作る
  • クライアントヘッダーを正規化してからWAFカスタムルールへ渡す

公開されている処理順には、Edge Action実行後にWAFへ戻る手順は示されていません。したがって、書き換え後のパスや追加ヘッダーに対するアクセス制御は、Edge Action自身またはオリジンで実施します。

WAFは、入力された元のリクエストに対する脆弱性対策、IP制限、レート制限、Bot対策などに使います。Edge Actionは、その後の業務的な振り分けや軽量な前処理に使うと役割を分離できます。(TECHCOMMUNITY.MICROSOFT.COM)

Rule setの順序と停止設定にも注意する

複数のRule setやルールを関連付けた場合、設定された順序で処理されます。「Stop evaluating remaining rules」を有効にしたルールが先に一致すると、後続のEdge Action呼び出しまで到達しない可能性があります。(Microsoft Learn)

評価順が重要な場合は、次のように分けると確認しやすくなります。

  1. 対象ホスト・パスを限定するRule set
  2. 必要な静的ヘッダー操作を行うRule set
  3. Edge Actionを呼び出すRule set
  4. キャッシュ設定やオリジングループ上書きを行うRule set

ただし、Edge Actionで変更した値を後続ルールの条件に利用できると決めつけてはいけません。プレビュー環境では、ルール間の変更伝播も含めて実リクエストで検証し、順序に強く依存する処理は可能な範囲で一つのEdge Actionへまとめる方が安全です。

カナリアルーティングは2種類を区別する

Edge Actionでカナリア配信を行うときは、何をカナリア化するのかを分けて考える必要があります。

対象使用する機能目的
Edge ActionのJavaScriptコードバージョンとExecution filter新しいJavaScript自体を限定ユーザーで検証する
WebアプリケーションJavaScriptによる動的オリジン選択安定版とカナリア版のオリジンを振り分ける

Execution filterでは、特定のHTTPヘッダーがある場合だけ新しいEdge Actionバージョンを実行できます。通常リクエストは既定バージョン、検証担当者だけ新バージョンという段階的な展開が可能です。(Microsoft Learn)

一方、アプリケーションのカナリア配信では、実行されたJavaScriptがorigin_dataから対象オリジンを探し、event.origin.idへ設定します。

デバッグを単純にするため、次のようにヘッダーを分けるのがおすすめです。

  • x-edge-code-version：Edge Actionコードのバージョン選択
  • x-app-release-ring：アプリケーションの安定版・カナリア版選択

同じヘッダーで両方を切り替えると、「JavaScriptが変わったため結果が変化したのか」「オリジンが変わったため結果が変化したのか」を判断しにくくなります。

単純な割合配信なら標準の重み付けも検討する

「全体の5％を新オリジンへ送る」といった単純な割合配信だけなら、Azure Front Doorのオリジン重み付けで実現できます。

Edge Actionが特に有効なのは、次のようなコホート単位の振り分けです。

  • 社内テスターだけをカナリア版へ送る
  • 特定テナントだけを新バージョンへ送る
  • サーバーが発行したCookieに基づいて振り分ける
  • 国・地域やデバイス種別によって振り分ける
  • 特定のAPIパスだけ新オリジンへ送る

固定割合だけなら標準ルーティング、リクエストの内容に基づく判断が必要ならEdge Action、という基準で選ぶと過剰実装を避けられます。(Microsoft Learn)

安全なカナリアルーティングのJavaScript例

Edge Actionの公式インターフェースでは、handler(event)がイベントを受け取り、変更後のイベントを返します。

リクエストヘッダー名は小文字で扱います。origin_dataには現在利用可能なオリジンが入り、オリジンIDはリクエストごとに変わる可能性があります。そのため、IDをコードへ固定せず、名前から検索して現在のIDを設定します。

次のコードは、検証用ヘッダーを受け取ったときだけカナリアオリジンを選択する例です。

// @ts-check

function handler(event) {
  const request = event.request;
  const response = event.response;
  const origins = event.origin_data || [];

  const requestedRing =
    request.headers["x-preview-ring"] === "canary";

  const canaryOrigin = origins.find(
    (origin) => origin.name === "app-canary"
  );

  const stableOrigin = origins.find(
    (origin) => origin.name === "app-stable"
  );

  // クライアントから送られた制御・信頼ヘッダーをそのまま転送しない
  delete request.headers["x-preview-ring"];
  delete request.headers["x-release-ring"];

  let selectedRing = "platform-default";

  if (requestedRing && canaryOrigin) {
    event.origin.id = canaryOrigin.id;
    selectedRing = "canary";
  } else if (stableOrigin) {
    event.origin.id = stableOrigin.id;
    selectedRing = "stable";
  } else {
    // -1はAzure Front Door標準のオリジン選択へ戻す
    event.origin.id = -1;
  }

  // オリジン向けにEdge Actionが確定した値を付与する
  request.headers["x-release-ring"] = selectedRing;

  // 検証期間だけクライアントにも結果を返す
  response.response_code = 200;
  response.headers["x-edge-ring"] = selectedRing;

  console.log(`selected-ring=${selectedRing}`);

  return event;
}

公式サンプルで定義されているイベントでは、event.origin.id = -1はオリジン選択を上書きせず、Azure Front Door標準の選択ロジックを使うことを意味します。また、現在のorigin_dataには正常と判断されたオリジンだけが含まれるため、カナリアオリジンが異常になれば検索結果から外れます。(GitHub)

フォールバックで守るべきポイント

安全なカナリア配信では、次の順序でフォールバックさせます。

  1. 条件に一致し、カナリアオリジンが利用可能ならカナリアへ送る
  2. カナリアを選べない場合は、名前を指定した安定版へ送る
  3. 安定版も見つからない場合は-1で標準選択へ戻す
  4. Azure Front Door側の優先度・正常性プローブでも安定版へ到達できるようにする

origin_data[0]のように配列の先頭を安定版として扱う設計は避けます。配列順序ではなく、管理されたオリジン名で選択してください。

また、クライアントが自由に送信できるx-preview-ring: canaryだけで本番ユーザーを振り分けるのは危険です。検証後は、署名付きCookie、信頼できる上流で付与したヘッダー、テスター用ネットワークなど、クライアントが簡単に偽装できない条件へ置き換えます。

ヘッダー操作では「削除してから上書き」が基本

Edge Actionでは、リクエストヘッダーとレスポンスヘッダーの追加・変更・削除ができます。ただし、一部の制限されたヘッダーは変更できません。また、イベント内のリクエストヘッダー名は小文字です。(GitHub)

特に注意したいのが、オリジンで信用するヘッダーです。

次のようなヘッダーを、受信した値のままオリジンへ転送してはいけません。

  • x-authenticated-user
  • x-user-role
  • x-tenant-id
  • x-release-ring
  • x-internal-request

クライアントが同名のヘッダーを付ければ、オリジンで内部ヘッダーと誤認する可能性があります。

安全な処理は次のとおりです。

delete event.request.headers["x-authenticated-user"];
delete event.request.headers["x-user-role"];

event.request.headers["x-authenticated-user"] = verifiedUser;
event.request.headers["x-user-role"] = verifiedRole;

つまり、クライアントから届いた値を一度削除し、Edge Actionが検証・決定した値だけを上書きする設計にします。

さらに、オリジンへの直接アクセスを制限し、Azure Front Doorを経由しないリクエストが内部ヘッダーを偽装できない構成にする必要があります。Azure Front Door以外からオリジンへ直接到達できる状態では、Edge Actionでヘッダーを安全に付与しても信頼境界が成立しません。(Microsoft Learn)

デバッグ用ヘッダーは本番で削除する

検証中は、次のようなレスポンスヘッダーを付けると挙動を確認しやすくなります。

x-edge-ring: canary
x-edge-code-version: v2

ただし、本番でオリジン名、バージョン、内部テナント情報などを公開すると、攻撃者へ構成情報を与える可能性があります。検証完了後は削除するか、管理者だけが利用できる条件で付与してください。

JWT認証はEdge Actionだけで完結させない

パブリックプレビューでは、JWTトークン検証が対応シナリオとして案内されています。無効なリクエストに対して、401または403を返してオリジンへの到達を止めることもできます。(Microsoft Learn)

ただし、認証をEdge Actionだけに任せるべきではありません。理由は、10ミリ秒を超えるとEdge Action処理なしでリクエストが先へ進むためです。

安全な役割分担は次のとおりです。

層実施する処理
WAF攻撃パターン、Bot、IP、レートなどの入口防御
Edge Action明らかに無効なJWTの早期拒否、軽量な属性判定
オリジンまたはAPI基盤最終的な署名、発行者、対象者、有効期限、権限の検証

JWT検証を実装するときは、最低限次の項目を確認します。

  • 署名が正しいこと
  • 許可した署名アルゴリズムだけを受け入れること
  • issが想定した発行者であること
  • audが対象アプリケーションであること
  • expを過ぎていないこと
  • 必要に応じてnbfを確認すること
  • 権限やロールを文字列の存在だけで判断しないこと
  • トークン本体をconsole.logへ出力しないこと

鍵の配置、公開鍵の更新、ローテーション方法は、プレビュー時点の対応APIを確認したうえで実機検証します。外部サービスへの問い合わせや重い暗号処理を毎回行う設計は、10ミリ秒という制約と相性がよくありません。

Cacheとカナリアルーティングを組み合わせる際の注意点

Edge Actionでオリジンを選択しても、有効なキャッシュが見つかればリクエストはオリジンへ到達しません。

そのため、同じURLをヘッダーだけで安定版とカナリア版へ振り分けると、先にキャッシュされたレスポンスが返り、期待したオリジンへ到達しない可能性があります。

Azure Front Doorでは、動的コンテンツや認証済みAPIのキャッシュを避け、静的コンテンツと動的コンテンツでルートを分けることが推奨されています。(Microsoft Learn)

検証中は対象ルートのキャッシュを無効にする

最初の検証では、カナリア対象ルートのキャッシュを無効にします。

これにより、次の問題を切り分けやすくなります。

  • Edge Actionが実行されたか
  • 期待したオリジンが選択されたか
  • 安定版へのフォールバックが動いたか
  • オリジンでヘッダーを受信できたか
  • JavaScriptの変更が反映されたか

キャッシュを有効にしたまま検証すると、JavaScriptやルーティングが正しくても、以前のレスポンスが返って「変更が反映されない」ように見えることがあります。

本番でキャッシュするならバリエーションをURLへ反映する

安定版とカナリア版でコンテンツが異なる場合は、次のいずれかを選びます。

  • カナリア対象ルートのキャッシュを無効にする
  • /stable/と/canary/のようにパスを分ける
  • キャッシュキーへ含める専用クエリパラメーターを使う
  • 両オリジンが同一コンテンツを返す静的アセットだけキャッシュする

Azure Front Doorでは、クエリ文字列をキャッシュキーへ含めるか、指定したパラメーターだけを含めるかを設定できます。ヘッダーだけに依存したカナリア判定ではなく、キャッシュキーとして明確に区別できるURL設計にすると事故を減らせます。(Microsoft Learn)

X-Cacheでキャッシュ状況を確認する

レスポンスのX-Cacheを見ると、キャッシュが影響しているか判断できます。

X-Cacheの例意味
TCP_HITエッジキャッシュから返却
TCP_REMOTE_HIT別のエッジキャッシュから返却
TCP_MISSキャッシュミスでオリジンから取得
CONFIG_NOCACHEFront Door設定でキャッシュ無効
PRIVATE_NOSTORECache-Controlによりキャッシュ不可

また、キャッシュ可能なオリジンレスポンスではSet-Cookieが削除されるため、Cookieを使ったコホート固定を行う場合も注意が必要です。(Microsoft Learn)

Azure Front Door edge actionsの管理者設定手順

パブリックプレビューでは、通常のAzure portalを直接開くとEdge Actions関連の項目が表示されない場合があります。Microsoft Learnから案内されている専用のプレビューポータルセッションを利用してください。(Microsoft Learn)

検証用ルートを準備する

最初から既存の本番ルート全体へ適用せず、次のような専用ルートを作ります。

https://edge-preview.example.com/

または、既存ドメイン内で検証パスを分けます。

https://www.example.com/edge-preview/*

検証ルートでは、次の状態を明確にします。

  • 安定版オリジンの名前
  • カナリア版オリジンの名前
  • 安定版を優先するオリジン設定
  • 正常性プローブ
  • キャッシュ無効
  • WAFポリシー
  • 診断ログの出力先

Edge Actionリソースとバージョンを作成する

専用プレビューポータルから、次の順で作成します。

  1. 「Edge Actions」を検索する
  2. Edge Actionリソースを作成する
  3. VersionsからJavaScriptファイルをアップロードする
  4. 最初のバージョンを既定バージョンに設定する
  5. プロビジョニング状態が成功になるまで確認する

プレビュー期間中は、コードのアップロード処理に最大10分かかる場合があります。Edge Actionごとに最大3バージョンを保持できるため、常に直前の正常版を残しておくとロールバックしやすくなります。(Microsoft Learn)

例えば、次のように管理します。

バージョン用途状態
v1-stable現在の正常版既定
v2-canary次回リリース候補Execution filterで限定実行
v0-rollback緊急切り戻し用非既定

Rule setからEdge Actionを呼び出す

高度な条件を設定する場合は、Azure Front DoorプロファイルでRule setを作成します。

  1. Azure Front Doorプロファイルを開く
  2. 「Rule sets」を開く
  3. 新しいRule setを作成する
  4. 検証用ホスト、パス、ヘッダーなどの条件を設定する
  5. アクションで「Invoke Edge Action」を選択する
  6. 対象のEdge Actionを指定する
  7. Rule setを対象ルートへ関連付ける
  8. ルートの「Manage Edge Actions」で関連付けを確認する

条件を設定せず、ルート全体で呼び出すこともできます。ただし、初回検証ではホスト、パス、テストヘッダーのいずれかで適用範囲を限定してください。(Microsoft Learn)

管理権限は分離する

Edge Actionの運用では、少なくとも次の変更権限が関係します。

  • Edge Actionリソースの作成・変更
  • JavaScriptバージョンのアップロード
  • 既定バージョンの切り替え
  • Execution filterの設定
  • Front Door Rule setの変更
  • ルートへの関連付け
  • 診断設定の変更

JavaScriptを開発する担当者にFront Door全体の変更権限を与えるのではなく、コード作成、レビュー、デプロイ、ルート関連付けを可能な範囲で分離します。

最低限、次の情報を変更記録へ残します。

  • コードのコミットID
  • Edge Actionのバージョン名
  • 対象ルート
  • 適用条件
  • 既定のフォールバック先
  • 検証結果
  • 切り戻し手順

Execution filterでJavaScript自体をカナリア展開する

新しいJavaScriptを全リクエストへ即時適用するのではなく、Execution filterを使って限定的に実行できます。

例えば、通常はv1-stableを実行し、次のヘッダーがある場合だけv2-canaryを実行します。

x-edge-code-version: v2

検証が完了したら、次の順で切り替えます。

  1. v2-canaryを限定ヘッダーで実行する
  2. 動作、実行時間、エラー、オリジン到達先を確認する
  3. v2-canaryを既定バージョンへ変更する
  4. Execution filterを削除する
  5. 問題があればv1-stableへ戻す

Execution filterから参照されているバージョンは使用中として扱われます。削除や更新の前に、関連するExecution filterを確認してください。(Microsoft Learn)

curlとログで動作を確認する

通常リクエストとカナリアリクエストを比較する

通常リクエストを送信します。

curl -sS -D - -o /dev/null \
  https://edge-preview.example.com/app

カナリア条件を付けたリクエストを送信します。

curl -sS -D - -o /dev/null \
  -H "x-preview-ring: canary" \
  https://edge-preview.example.com/app

検証用コードでx-edge-ringを付けている場合、次のように差を確認できます。

x-edge-ring: stable
x-edge-ring: canary

同時に、次のヘッダーも記録します。

  • X-Azure-Ref
  • X-Cache
  • HTTPステータス
  • 検証用のx-edge-ring

EdgeActionConsoleLogを確認する

Edge ActionリソースのDiagnostic settingsで、allLogsをLog Analyticsワークスペースへ送信します。

JavaScript内のconsole.logは、EdgeActionConsoleLogテーブルへ記録されます。(Microsoft Learn)

EdgeActionConsoleLog
| where TimeGenerated > ago(30m)
| project
    TimeGenerated,
    TrackingReference,
    EdgeActionVersion,
    LogMessage,
    ResourceId
| order by TimeGenerated desc

TrackingReferenceは、クライアントやオリジンへ送られるX-Azure-Refと対応します。この値を使うと、Edge Actionログ、Azure Front Doorアクセスログ、WAFログを同じリクエスト単位で追跡できます。

Azure Front DoorアクセスログのedgeActionsStatusCodeでは、次の状態を確認できます。

値意味
200Edge Actionの実行成功
503Edge Action実行中のエラー

ここでのedgeActionsStatusCodeは、Edge Actionの実行状態を示すログ項目です。クライアントへ返されたHTTPステータスコードと同じとは限りません。(Microsoft Learn)

必ず実施したいテストケース

テスト条件期待する結果
通常アクセス制御ヘッダーなし安定版オリジン
カナリアアクセス正しい検証ヘッダーありカナリアオリジン
不正な制御値想定外のヘッダー値安定版オリジン
カナリア異常カナリアを無効化または異常状態にする安定版または標準選択へフォールバック
Edge Actionタイムアウト検証環境で10ミリ秒超過を再現Edge Action未適用時も安全な結果になる
JavaScript例外検証用バージョンで例外を発生ログで実行エラーを確認
WAFブロック検証用WAFルールに一致Edge Actionより前に拒否
キャッシュヒット同一GETを繰り返すX-Cacheとオリジン到達有無を確認
JWTなしAuthorizationなしEdge Actionまたはオリジンで拒否
JWT不正期限切れ・対象者不一致などオリジンでも拒否
直接オリジンアクセスFront Doorを経由しない接続拒否または認証拒否

特に重要なのは、正常系よりも「Edge Actionが実行されなかった場合」の結果です。JavaScriptが動かない状態でも安定版へ進み、認証が必要なリクエストはオリジンで拒否できることを確認してください。

設定変更が反映されないときの確認ポイント

Azure Front Doorはグローバルサービスであり、Rule setやルート設定の変更には伝播時間があります。通常、多くのRule set変更は15分以内に反映されますが、変更を連続して行うと全体で約30分かかる場合があります。(Microsoft Learn)

変更直後に期待した結果が出ない場合は、次の順で確認します。

  1. Edge Actionコードのアップロード状態が成功しているか
  2. 正しいバージョンが既定になっているか
  3. Execution filterが別バージョンを選んでいないか
  4. Rule setの条件がリクエストに一致しているか
  5. 「Invoke Edge Action」が設定されているか
  6. Rule setが対象ルートへ関連付けられているか
  7. 先行ルールで評価停止していないか
  8. 対象ルートでキャッシュが有効になっていないか
  9. X-Azure-Refでログを追跡できるか
  10. 設定のグローバル伝播を待ったか

設定を何度も連続変更すると、どの変更の結果を見ているのか分からなくなります。1回の変更ごとにバージョン名を変え、伝播とログを確認してから次へ進めます。

よくある失敗と修正方法

通常のAzure portalでEdge Actionsが表示されない

パブリックプレビュー用のポータルセッションを経由していない可能性があります。Microsoft Learnで案内されている専用プレビューポータルから開き直します。(Microsoft Learn)

Edge Actionを作成しただけで実行されると思っている

Edge ActionリソースとJavaScriptバージョンを作成しただけでは実行されません。Rule setの「Invoke Edge Action」を経由して、Azure Front Doorのルートへ関連付ける必要があります。

オリジンIDをJavaScriptへ固定している

オリジンIDはリクエストごとに変化する可能性があります。origin_dataからオリジン名を検索し、そのリクエストで提供されたIDを設定します。(GitHub)

クライアントが送った内部ヘッダーを信用している

内部用ヘッダーは最初に削除し、Edge Actionが検証・決定した値で上書きします。オリジンへの直接アクセス制限も必要です。

カナリア指定をしても安定版の内容が返る

キャッシュヒットの可能性があります。X-Cacheを確認し、検証ルートのキャッシュを無効にします。

WAFでEdge Action追加後のヘッダーを検査しようとしている

WAFはEdge Actionより先に実行されます。Edge Actionが付与した内部ヘッダーの検査は、同じリクエスト内のWAFではなくオリジンで行います。

Edge Actionだけで認証を完結している

10ミリ秒超過時にはEdge Action処理なしでリクエストが先へ進みます。オリジンでもJWTやセッションを再検証します。

console.logへトークンや個人情報を出力している

console.logの内容はLog Analyticsへ送られます。JWT、Cookie、Authorizationヘッダー、メールアドレスなどは記録せず、リクエストID、選択したリング、コードバージョン、処理結果だけを残します。

Edge Actionを採用するか判断する基準

要件推奨する実装
固定条件でヘッダーを追加するRule set
HTTPをHTTPSへリダイレクトするRule set
パスを固定ルールで書き換えるRule set
オリジンへ一定割合で配信する標準の重み付けルーティング
テナントやCookieでオリジンを変えるEdge Action
国・デバイス・時刻を組み合わせて判断するEdge Action
明らかに不正なリクエストを早期拒否するWAFとEdge Action
JWTを最終的に認証するオリジンまたはAPI基盤
データベースや外部APIを参照するオリジンまたはAPI基盤
オリジンレスポンス本文を複雑に変換するオリジン側
長時間の計算や大きなライブラリが必要オリジン側

Edge Actionは「オリジンの代わり」ではなく、「Azure Front Doorの宣言的ルールとオリジン処理の間を埋める、極めて軽量な判断層」と考えると適用範囲を誤りにくくなります。

安全に導入するための最終チェック

Azure Front Door edge actionsでカナリアルーティング、ヘッダー操作、認証前処理を安全に実装するには、次の状態を作ることが重要です。

  • 本番ルートではなく、限定したプレビュー用ルートから始める
  • キャッシュを無効にしてEdge Actionの挙動を検証する
  • Azure Front Door標準のルーティング先を安定版にする
  • オリジンを名前で検索し、IDを固定しない
  • カナリアオリジンがない場合のフォールバックを実装する
  • クライアント由来の内部ヘッダーを削除してから上書きする
  • WAFがEdge Actionより先に動くことを前提にする
  • JWT認証はオリジンでも再実行する
  • Edge ActionとAzure Front Doorの診断ログを有効にする
  • X-Azure-RefでWAF、Edge Action、アクセスログを関連付ける
  • タイムアウト、JavaScript例外、オリジン異常を必ず試験する
  • Execution filterで新しいコードを限定展開する
  • 直前の正常バージョンを残してロールバックできるようにする

まずは、キャッシュを無効にした検証ルートへ安定版・カナリア版の2オリジンを登録し、ヘッダーによる明示的なカナリア選択から始めます。そのうえで、WAFブロック、10ミリ秒超過、カナリア異常、Edge Action未実行の各ケースでも安全な結果になることを確認してから、適用範囲を段階的に広げるのが現実的です。

Azure
JavaScript WAF Azure Front Door edge actions カナリアリリース

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次