Azureでアプリを公開しているが、海外ユーザーからのレスポンスが遅い。Application Gatewayを導入済みなのに、なぜかグローバルで均一なパフォーマンスが出ない——そういった悩みを抱えるインフラエンジニアは少なくない。あるいは「Azure CDNが2027年9月に廃止になる」という情報を聞いて、移行先を探しているケースもあるだろう。
この記事では、Azureのグローバルエッジ配信サービスである Azure Front Door について、オンプレ経験者にもわかりやすく解説する。Application Gatewayや廃止予定のAzure CDN(クラシック)との違い、Standard/Premiumティアの選び方、料金の仕組み、そして現場で役立つ実務Tipsまでカバーする。

なぜAzure Front Doorが必要か——オンプレとの違いから考える
オンプレミス環境でグローバルに展開する場合、拠点ごとにハードウェアロードバランサーやCDNアプライアンスを設置し、DNSのGSLB(Global Server Load Balancing)機能でユーザーを最寄りのデータセンターに誘導していた。しかしこの構成は、ハードウェア調達・保守・多拠点での冗長化に多大な費用と人手がかかる。
Azure Front Doorは、Microsoftが世界中に展開する 190か所以上のPoP(Point of Presence)をエッジとして利用し、ユーザーを自動的に最も近いエッジにルーティングする。具体的には以下の機能を一体化して提供する。
・グローバルロードバランシング: エニーキャスト(Anycast)方式でグローバルに分散配置されたエッジへ誘導
・CDN(コンテンツ配信): 静的・動的コンテンツをエッジでキャッシングし、オリジンサーバーへの負荷を軽減
・WAF(Webアプリケーションファイアウォール): OWASPルールセットやBot管理をエッジで実施
・SSL/TLS終端: エッジでHTTPS処理を完結し、マネージド証明書も無料提供
・オリジンヘルスモニタリング: バックエンドのヘルスプローブで自動フェイルオーバー
オンプレのGSLB+CDNアプライアンス+WAFアプライアンスをそれぞれ個別に構築していたものを、Azureがマネージドサービスとして一本化したイメージだ。
Application Gateway・Azure CDNとの使い分け
Azureにはロードバランシング・CDN系のサービスが複数あり、初見では混乱しやすい。以下の表で整理する。
| サービス | スコープ | 主な用途 | WAF |
|---|---|---|---|
| Azure Load Balancer | リージョン内・L4 | VM・VMSSへのTCP/UDP負荷分散 | なし |
| Azure Application Gateway | リージョン内・L7 | HTTP(S)パスルーティング・SSLオフロード | あり(WAF SKU) |
| Azure Front Door | グローバル・L7 | マルチリージョン配信・CDN・WAF統合 | あり(エッジ) |
| Azure CDN(クラシック) | グローバル | 静的コンテンツのキャッシング配信 | なし |
判断の目安は 「グローバルに分散配信するか」 だ。単一リージョン内でHTTP(S)ルーティングを行いたいだけならApplication Gatewayで十分。しかし複数リージョンのオリジンを束ねてグローバルユーザーに最適配信したい、あるいはエッジでWAFを動作させたいなら、Front Doorを選ぶ。
なお、Azure CDN(クラシック)は2027年9月30日に廃止予定(2026年8月時点)。既存の利用者はFront Door Standardへの移行が推奨されている。CDN専用で使っていた場合でもFront Door Standardで機能的に代替できる。
Azure Load Balancer vs Application GatewayのAzure側負荷分散サービスの詳細な違いについては、Azure Load Balancer vs Application Gateway|オンプレ経験者のためのAzure負荷分散サービスの違いと使い分けガイドも参考にしてほしい。
Standard vs Premiumティアの違いと選び方
Azure Front Doorには現行世代(Classic廃止後)として StandardとPremiumの2ティア がある。Classic(旧世代)は2027年3月31日廃止予定のため、新規構築はStandard/Premiumから選ぶこと。
| 機能 | Standard | Premium |
|---|---|---|
| 基本料金(月額) | $35 | $330 |
| CDN機能 | ○ | ○ |
| グローバルロードバランシング | ○ | ○ |
| WAF(カスタムルール) | ○ | ○ |
| WAF(マネージドルールセット) | △(基本のみ) | ○(Microsoft脅威インテリジェンス含む) |
| Private Link オリジン接続 | × | ○ |
| Security Analytics | × | ○ |
| Bot管理(高度) | × | ○ |
料金はいずれも「基本料金+トラフィック従量課金」 の組み合わせだ(2026年8月時点・東日本リージョン基準。最新料金は必ずAzure公式の料金計算ツールで確認すること)。
【選定の目安】Standardで足りるケース
・CDN移行(Azure CDN クラシックからの置き換え)が主目的
・WAFはカスタムルールで管理できる規模
・バックエンドはパブリックエンドポイントをもつApp ServiceやAzure Storageなど
・金融・医療等の高度なコンプライアンス要件がない
【選定の目安】Premiumが必要なケース
・バックエンドをPrivate Link経由でパブリックIPを持たずに接続したい
・Microsoft脅威インテリジェンスを活用した高度なWAF保護が必要
・Security Analyticsで攻撃トラフィックの詳細分析をしたい
・PCI DSS・HIPAA等の高度なコンプライアンス環境
主要設定の仕組みを理解する
Azure Front Doorの設定は大きく「エンドポイント」「ルートルール」「オリジングループ」「WAFポリシー」の4つで構成される。
1. エンドポイントとカスタムドメイン
Front Doorはデフォルトで `
# カスタムドメインのDNS設定例(CNAMEレコード) # 設定先: DNSプロバイダーの管理画面 www.example.com. CNAME myprofile.z01.azurefd.net. # Azure CLIでカスタムドメインを追加する場合 az afd custom-domain create \ --resource-group myRG \ --profile-name myFrontDoor \ --custom-domain-name myDomain \ --host-name www.example.com \ --certificate-type ManagedCertificate \ --minimum-tls-version TLS12
2. ルートルールとパスルーティング
ルートルール(Route)は、ドメイン・パスパターンと転送先オリジングループの対応を定義する。たとえば `/api/*` はバックエンドAPIサーバー群へ、`/static/*` はAzure Blob Storageへ、という分割もできる。また、HTTPからHTTPSへの強制リダイレクトもルートルールで設定する。
3. オリジングループとウェイトルーティング
オリジングループは複数のバックエンド(オリジン)をまとめる単位だ。各オリジンに 重み(Weight) と 優先度(Priority) を設定できる。
・Weight: 通常時のトラフィック割合(Blue-Green / カナリアリリースに活用)
・Priority: 低優先度はフェイルオーバー先として機能
オンプレのGSLBやハードウェアロードバランサーで実現していたウェイトルーティングをSaaS的に設定できるのが大きな違いだ。
4. キャッシュ設定
ルートルールでキャッシュを有効にすると、エッジPoPでレスポンスをキャッシュできる。キャッシュのTTLはオリジンの `Cache-Control` ヘッダーを優先するが、Front Door側で上書きする設定も可能。動的コンテンツはキャッシュ無効にしてオリジンに直接転送する。
5. WAFポリシーのアタッチ
WAFポリシーは独立したリソースとして作成し、エンドポイントやドメインに紐付ける。検知モード(Detection)と防御モード(Prevention)を選択でき、本番適用前に検知モードで動作確認するのが定石だ。
# Azure CLIでWAFポリシーを作成(Front Door Standard/Premium用) az network front-door waf-policy create \ --resource-group myRG \ --name myWafPolicy \ --sku Standard_AzureFrontDoor \ --mode Detection # マネージドルールセットをアタッチ(Premium: Microsoft_DefaultRuleSet_2.1) az network front-door waf-policy managed-rule-definition list \ --resource-group myRG \ --policy-name myWafPolicy
料金の仕組み(2026年8月時点)
Azure Front Doorの料金は主に3つの要素で構成される。
基本料金(月額固定)
Standard: 約$35/月、Premium: 約$330/月。これはプロファイルごとの固定コスト。
データ転送量(アウトバウンド)
エッジからクライアントへのデータ転送量。ゾーン1(北米・欧州)で最初の10TB/月あたり約$0.087/GBが目安(2026年8月時点)。アジア・オーストラリア(ゾーン2)はやや高め。
HTTPSリクエスト数
100万リクエストあたり$0.01程度。WAFが有効な場合はWAF処理の追加料金がかかる。
オリジンへのデータ転送(Egress)
エッジからオリジン(Azureリージョン)へのデータ転送。同一リージョン内であればほぼ無料だが、クロスリージョンは別途課金される。
コスト試算の落とし穴として、CDNキャッシュヒット率を考慮し忘れることが多い。キャッシュヒット率が低いとオリジンへのアクセスが増え、Application Gatewayとの組み合わせコストが想定以上に膨らむ。事前にCDNキャッシュ率をシミュレーションしてからFront Doorへ移行することを強く勧める。
実務Tips:現場でよく使う設定パターン
カナリアリリース(Weight設定)
新バージョンのApp Serviceスロットをオリジングループに追加し、Weightを10(全体の10%)に設定してトラフィックを絞り込む。問題なければ徐々に100まで上げる。Blue-Greenと異なりフェイルオーバー目的ではなく段階的移行が目的の場合はPriorityを同値(同じ優先度)にしてWeightだけで制御する。
オリジンをPrivate Linkで接続する(Premium限定)
Premiumティアを使うとApp ServiceやStorageのパブリックエンドポイントを閉じた状態でFront Doorから接続できる。インターネットに露出する攻撃面を大幅に削減できるため、セキュリティ要件が厳しい環境では検討を強く勧める。
# オリジングループにPrivate Linkを有効化(Azure CLIイメージ) az afd origin create \ --resource-group myRG \ --profile-name myFrontDoor \ --origin-group-name myOriginGroup \ --origin-name myAppService \ --host-name myapp.azurewebsites.net \ --origin-host-header myapp.azurewebsites.net \ --http-port 80 \ --https-port 443 \ --enable-private-link true \ --private-link-location japaneast \ --private-link-resource /subscriptions/.../sites/myapp \ --private-link-sub-resource-type sites
ヘッダーによるルーティング(X-Forwarded-For)
オリジンサーバー側でクライアントの実IPを取得したい場合は `X-Forwarded-For` ヘッダーを参照する。Front DoorはデフォルトでこのヘッダーにクライアントIPを付与して転送する。App ServiceやAzure VMのアプリケーションログには `X-Forwarded-For` からIPを取得する設定を忘れずに。
Azure Virtual Networkとの連携
オリジンをAzure Virtual Network(VNet)内に配置する場合、Front Door PremiumとPrivate Endpointを組み合わせるパターンが標準的だ。VNet内のApp ServiceへはPrivate Linkを通じてルーティングし、フロントからはパブリックIPなしで接続できる。VNet設計についてはAzure Virtual Network(VNet)入門 サブネット設計からNSG・ピアリングまで現場で使えるネットワーク構築ガイドを参照してほしい。
Azure Firewallとの組み合わせ
Front Doorを通過したHTTP(S)トラフィックに対してさらにレイヤーを重ねたい場合、Azure Firewallと組み合わせることもある。ただし、Front DoorのWAFとAzure Firewallの両方でL7検査を行うとコストが二重にかかるため、役割分担を明確にすることが重要だ。詳細はAzure Firewall入門|オンプレUTM・NGFWと比べてわかるクラウドファイアウォール設計と料金ガイドを参考にしてほしい。
よくあるトラブルと対処法
オリジンに502/503エラーが返り続ける
Front Doorのヘルスプローブがオリジンに到達できていないケースが多い。確認ポイントは2つだ。
・ヘルスプローブのパス設定: デフォルトは `/` だが、オリジンが404や認証エラーを返すパスを指定していると「不健全」と判定される。ヘルスプローブ専用エンドポイント(`/health` 等)を用意して200を返すように調整する
・NSG・ファイアウォール設定: Front DoorのIPレンジからのアクセスを許可していない場合に発生する。AzureはサービスタグとしてAzureFrontDoorを提供しており、NSGにこのサービスタグを許可ルールとして追加する
キャッシュが効かず、毎回オリジンに転送される
オリジンが `Cache-Control: no-store` や `Cache-Control: no-cache` を返していると、Front Doorはキャッシュしない。アプリケーション側のレスポンスヘッダーを確認し、静的アセットには適切なキャッシュヘッダーを設定する。
カスタムドメインのHTTPS証明書が発行されない
Front DoorのマネージドTLS証明書はDV(ドメイン検証)証明書であり、CNAMEによるドメイン所有権の検証が完了しないと発行されない。DNSの伝播に数分~数時間かかる場合があるため、CNAME設定後にしばらく待ってから再確認すること。また、CNAMEの向き先が `
WAFが正常トラフィックをブロックする
WAFを防御モードで突然有効化すると、意図しないトラフィックがブロックされることがある。まず検知モード(Detection)で1週間程度動作させてログを分析し、誤検知ルールを除外設定(Exclusion)に追加してから防御モードへ切り替えるのが現場の定石だ。

本記事のまとめ
| ポイント | 内容 |
|---|---|
| Azure Front Doorとは | グローバルロードバランシング・CDN・WAFを統合したAzureのエッジ配信サービス。190以上のPoPを活用。 |
| Application Gatewayとの違い | Application Gatewayはリージョン内L7ルーティング。Front Doorはグローバルエッジで複数リージョン・CDNを統合。 |
| Azure CDN(クラシック)との関係 | 2027年9月30日廃止予定。移行先はFront Door Standard推奨。 |
| ティア選定 | CDN移行・カスタムWAF程度ならStandard($35/月)。Private Linkや高度WAFが必要ならPremium($330/月)。 |
| コストの落とし穴 | キャッシュヒット率が低いとオリジンEgress料金が膨らむ。事前試算必須。 |
| WAF運用の鉄則 | 最初は検知モードで運用→誤検知除外設定→防御モードへ切り替え。 |
Azure Front Doorを使うと、複数リージョンのオリジンを束ねてグローバルなエッジ配信を実現でき、オンプレ時代に複数ベンダーで構築していたGSLB・CDN・WAFを一元管理できる。Azure CDNクラシックからの移行も含め、Azureでグローバル配信を検討している場合はFront Doorへの移行を早めに計画しておくことを勧める。
PR
AWSクラウド設計完全ガイド(アクセンチュア株式会社/日経BP)
AWS中心の解説だが、クラウドの設計思想・ネットワーク・セキュリティの考え方はAzureにも通じる。オンプレ経験者がクラウド設計の全体像を俯瞰するのに最適な一冊。
