便利で安心安全な CDN である Azure Front Door の パスベースルーティング機能 を試してみたいと思います。詳細な技術仕様は以下のドキュメントの通り。
参考ドキュメント => ルーティング規則に対する要求の照合方法

今回作成するイメージとしては、東日本と中央アメリカの WebApp をバックエンドで起動させ、/japan というパスがリクエストされたら東日本のリソースへアクセス、/us というパスがリクエストされたら中央アメリカのリソースにアクセスするというものです。

ではさっそく作成していきましょう。

バックエンドの App Services の準備

東日本、中央アメリカのそれぞれに App Services をデプロイします。プランは最小のもので問題ありません。今回は B1 プランで二つの App Services をデプロイしました。

このままではどちらにアクセスしたか分からないので、それぞれの App Services にアクセスした際のホーム画面で表示されるページに、東日本の WebApp、US の webApp と HTML ベースで追加します。Web App の標準機能である App Services Editor(プレビュー) を使用すると便利です。

少し雑ですが、まぁ分かればよいので、hoststarting.html の中に以下のようにテキストを追加します。US の方も同じように編集します。

そうすると WebApp にアクセスした際にどちらの WebApps にアクセスしているのかが表示でわかるようになります。東日本の WebApps にアクセスした場合はこんな感じです。

これで App Services の準備は完了です！

Azure Front Door でルールを追加する

それでは Azure Front Door でルールを追加していきましょう。Front Door を作成する際には、Front、BackEnd、ルール、の3つを指定して作成することができます。最初の Front は適当な名前、BackEnd には作成した二つのバックエンドプールをまず追加します。ルールは以下のように設定します。
/japan の Path の場合は東日本リージョンの App Services が含まれているプールにルーティングします。

/us の Path の場合は US のリージョンの App Services が含まれているプールにルーティングします。

これでルールの設定は完了です。ではさっそく作成した Front Door のフロントエンドアドレス/path にアクセスしてみましょう！

エラーが発生するので Web.config を作成する

ここまでやるとうまくいくのでは？と思うかもしれませんが、こんな感じのエラーが発生します。

エラーメッセージはこんな感じです。

The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

このエラーメッセージは App Services から返されているもので、調べるとこんな感じの回避策が見つかりました。

参考URL => Error : The resource you are looking for has been removed, had its name changed, or is temporarily unavailable

先ほどの App Services Editor で web.config をディレクトリに追加し、以下のようなコードを追加します。

<configuration>
<system.webServer>
    <rewrite>
      <rules>
        <rule name="Main Rule" stopProcessing="true">
                <match url=".*" />
                <conditions logicalGrouping="MatchAll">
                    <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                    <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
                </conditions>
                <action type="Rewrite" url="/" />
            </rule>
        </rules>
    </rewrite>
</system.webServer>
</configuration>

これでもう一度アクセスしてみると、リクエストをした方の正しいリージョンにルーティングされるようになります。

正しくルーティングされました。通常の IIS などで作成したすでに Web.config が構成されているアプリケーションにアクセスする際にはこのような手順はいらないですが、ありものの App Services のページを使おうとする場合はこのような工夫が必要です。

使ってみた感想

GUI ベースでサクサクルールが作成できるし、変更したときの反映スピードも早いので汎用的に使いやすいと思いました。
Region 内のロードバランシングツールである Application Gateway だと編集画面で分かりやすい絵がでてきますが、Front Door だとないため、複雑なルールを設定する場合は少し使いにくいかなと思います。これは Application Gateway の画面。
同じサブスクに含まれる App Services ならばプルダウン式に選択できるのは便利。ルーティングルールをさくっと作成できる
パスごとにどれくらいのアクセスがあったかは Log Analytics にメトリックを投げてそこでクエリをかける必要がありそう。過去の膨大なログを見るとなるとそれなりに保管するデータの課金がかかりそう。単純な Health 系のログはデフォルトで抽出可能

全体的に使いやすいですし、WAF機能やキャッシュ機能も付いているので、グローバルに負荷分散させたいアプリケーションを作成する際のフロントエンドには是非たててみたいサービスかと思いました！