JAEN
tech#azure#front-door#cdn#waf#security#architecture#cost

Azure Front Door Standard と Premium の違いを整理する

公開 👁 —
Azure Front Door Standard と Premium の違いを整理する

この記事を書こうと思ったきっかけ

Azure Front Door は名前も役割も知っていたものの、実際に使う機会はあまりなく、最近のアップデートにも追随できていませんでした。

自分のサイトを Azure 上で運用する中で、「Front Door を置くと何が良くなるのか」「Standard と Premium は何が違うのか」「個人サイトにも必要なのか」が気になり、あらためて調べてみることにしました。

最初に結論を書くと、Standard と Premium は配信性能の上下というより、オリジンを非公開にできるか、Microsoft 管理の WAF ルールを使えるかというセキュリティ要件で選ぶのが分かりやすいです。

この記事では、Azure Front Door の役割、両 SKU の機能差、料金、向いているシステムを整理し、最後にこのサイトへ適用するかを考えます。

目次

Azure Front Door とは

Azure Front Door は、Microsoft のグローバルエッジネットワークを利用する、L7 のロードバランサー兼 CDN、アプリケーション配信・保護サービスです。

利用者からの HTTP / HTTPS リクエストを、利用者に近いエッジ拠点で受けます。その後、キャッシュから応答するか、正常性、優先度、重み、遅延などに基づいて適切なオリジンへ転送します。

利用者
  ↓ HTTPS
Azure Front Door のエッジ
  ├─ キャッシュから応答
  ├─ WAF で検査
  └─ 最適なオリジンへ転送
       ├─ 東日本の Web アプリ
       ├─ 西日本の Web アプリ
       └─ 別リージョン、オンプレミス、他クラウド

主な役割は次のとおりです。

Application Gateway も L7 ロードバランサーと WAF を提供しますが、基本的には Azure リージョン内で動作します。Front Door はグローバルエッジで受けるため、世界中の利用者への配信、複数リージョンへのルーティング、エッジでの保護に向いています。

Standard と Premium の共通機能

配信とルーティングの基本機能は、Standard と Premium のどちらでも利用できます。

分野StandardPremium
静的・動的コンテンツ配信○○
エッジキャッシュ、圧縮、キャッシュ削除○○
複数オリジンの負荷分散と正常性プローブ○○
パスベースルーティング○○
Rules Engine、URL 書き換え、リダイレクト○○
WebSockets○○
独自ドメイン、マネージド証明書、BYOC○○
TLS 1.2 / 1.3、HTTP/2、IPv4 / IPv6○○
L3 / L4 DDoS 保護○○
WAF カスタムルール、レート制限、Geo フィルタリング○○
アクセスログ、WAF ログ、正常性プローブログ○○
Azure Policy、Azure Advisor 連携○○

Standard でも、単なる CDN だけではありません。動的サイトの高速化、複数オリジンのフェールオーバー、ルールによる経路制御、独自の WAF ルールまで使えます。

たとえば、特定の国・地域からのアクセスを制限する、特定 IP を拒否する、ログイン API にレート制限を設定するといった制御は Standard でも可能です。

Standard と Premium の機能差

大きな差はセキュリティ機能です。

機能StandardPremium選定への影響
WAF カスタムルール○○自分で条件を定義する防御は両方で可能
Microsoft 管理の WAF ルールセット×○SQL インジェクションや XSS など既知の攻撃を継続的に検知したい場合は Premium
Bot Manager ルールセット×○悪性 Bot、検索エンジン、既知 Bot を分類して制御したい場合は Premium
Private Link によるオリジン接続×○オリジンのパブリック公開をなくしたい場合は Premium
WAF 組み込みレポート×○セキュリティ状況を組み込み画面で確認したい場合は Premium
月額基本料金の公式掲載例$35$330Premium は固定費が大きいため、必要なセキュリティ要件から判断する
リクエスト単価（日本、10,000 件あたり）$0.0108$0.0168リクエスト数が多いシステムでは差が広がる

Premium の差 1: マネージド WAF ルール

Standard の WAF は、IP、地域、ヘッダー、Cookie、パス、リクエスト頻度などを条件に、自分で作るカスタムルールが中心です。

Premium では、それに加えて Microsoft が管理する Default Rule Set を利用できます。SQL インジェクション、クロスサイトスクリプティング、リモートコード実行など、一般的な Web 攻撃パターンに対応するルールの開発と保守を Microsoft が担います。Bot Manager も Premium 限定です。

ただし、現在利用しているルールセットが自動的に常に最新バージョンへ切り替わるとは限りません。Microsoft Learn でも、最新のマネージドルールセットを定期的に確認することが推奨されています。新しいバージョンを検証し、必要な除外設定を引き継いで更新する作業は利用者側の運用として残ります。

公開 Web アプリケーションを守る場合、既知の攻撃パターンをすべて独自ルールで追い続けるのは現実的ではありません。本格的な WAF を Front Door に担わせるなら、Premium が実質的な選択肢になります。

ただし、マネージド WAF を有効にすれば終わりではありません。まず Detection モードで誤検知を確認し、除外設定やルール調整を行ってから Prevention モードへ移す運用が必要です。

Premium は、サポートされている Azure オリジンへ Private Link で接続できます。これにより、利用者からオリジンまでの入口を Front Door に集約し、オリジンをインターネットへ直接公開しない構成を作れます。

インターネット
  ↓
Azure Front Door Premium
  ↓ Private Link
非公開の Azure オリジン

Front Door の前段に WAF を置いても、攻撃者がオリジンのパブリック URL を直接呼べるなら、Front Door を迂回される可能性があります。Standard でパブリックオリジンを使う場合は、AzureFrontDoor.Backend サービスタグによる IP 制限や X-Azure-FDID ヘッダーの検証など、オリジンごとの制限が必要です。

オリジンのパブリックアクセスを無効化することが要件なら、Premium の Private Link が分かりやすい解決策です。ただし、Private Link を構成しただけで、すべてのオリジンが自動的に非公開になるわけではありません。オリジン側でも、Private Link 以外の通信を拒否する設定が必要です。

拒否方法はオリジンによって異なります。たとえば App Service と Azure Functions は Private Endpoint を使用するとパブリックインターネット経由のアクセスが無効になりますが、Azure Storage ではファイアウォールを構成してインターネットからの通信を拒否します。すべてのオリジン種別とリージョンが同じ条件で対応するわけではないため、導入前に公式の対応一覧とオリジンごとの遮断方法を確認する必要があります。

Premium は「速い SKU」ではない

Premium の配信、キャッシュ、ルーティング機能は、基本的に Standard と共通です。Premium に変えれば Web サイトが単純に速くなる、という関係ではありません。

Premium の追加料金は、主に高度な WAF と非公開オリジン接続に対するものです。要件が配信高速化、キャッシュ、グローバル負荷分散だけなら、まず Standard を検討できます。

料金の考え方

Azure Front Door Standard / Premium の料金は、主に次の要素で構成されます。

  1. プロファイルごとの基本料金
  2. クライアントからエッジへのリクエスト数
  3. Front Door エッジからオリジンへのデータ転送量
  4. Front Door エッジからクライアントへのデータ転送量
  5. Edge Actions など追加機能を使う場合の利用量

概念的には、次の式で考えられます。

月額 = 基本料金
     + リクエスト料金
     + エッジ → オリジンの転送料金
     + エッジ → クライアントの転送料金
     + 追加機能の料金

基本料金

Microsoft Learn の比較資料では、月額基本料金の例として次の金額が掲載されています。

SKU月額基本料金の公式掲載例
Standard$35 / プロファイル / 月
Premium$330 / プロファイル / 月

実際には時間単位で課金され、1 時間未満も課金対象です。トラフィックがなくても、プロファイルを削除するまで基本料金は発生します。

1 プロファイルには複数のエンドポイントを含められ、エンドポイントごとの追加基本料金はありません。環境やマイクロサービスごとにプロファイルを細かく分割すると、特に Premium では基本料金が積み上がります。セキュリティ境界と運用境界を保ちながら、プロファイルを集約できるかもコスト設計のポイントです。

上記は公式ドキュメントに掲載された米ドル建ての比較用価格です。契約、通貨、税、価格改定によって実請求額は変わります。最新の単価は Azure Front Door の料金ページ と Azure Pricing Calculator で確認してください。

従量料金

リクエスト料金とデータ転送料金は、リクエストを処理したエッジの料金ゾーンによって異なります。Premium は Standard よりリクエスト単価が高く、エッジからクライアントへの転送単価は両 SKU で同じです。

2026 年 7 月 25 日時点で Azure 公式料金ページに掲載されている、最初の 2.5 億リクエストまでの単価は次のとおりです。単位は 10,000 リクエストあたりの米ドル価格です。

料金ゾーン主な地域StandardPremium
Zone 1北米$0.0090$0.0150
Zone 2アジア太平洋（日本を含む）$0.0108$0.0168
Zone 3南米$0.0199$0.0259
Zone 4オーストラリア$0.0113$0.0173
Zone 5インド$0.0108$0.0168
Zone 6ヨーロッパ$0.0090$0.0150
Zone 7中東・アフリカ$0.0108$0.0168
Zone 8韓国$0.0181$0.0241
Zone 9US Government$0.0113$0.0188

日本の利用者から 1 か月に 100 万リクエストを受けた場合、リクエスト料金だけを単純計算すると、Standard は 100 × $0.0108 = $1.08、Premium は 100 × $0.0168 = $1.68 です。これとは別に、プロファイルの基本料金とデータ転送料金などが発生します。

この表は 2026 年 7 月 25 日時点の Azure 公式料金ページに掲載された参考価格です。2.5 億件を超えるリクエストは公式ページで問い合わせ扱いです。実際の請求額は、契約、通貨、税、購入日、為替レート、リクエストを処理したエッジのゾーンによって変わります。最新価格は Azure Front Door の料金ページ と Azure Pricing Calculator で確認してください。

料金を考えるときは、次の点に注意が必要です。

見積もりに必要な数字

導入前に、少なくとも次の情報を集めます。

リクエスト数が非常に多い API は、データ量が小さくてもリクエスト料金が効きます。動画、画像、ファイル配信は、リクエスト数より転送量とキャッシュヒット率が大きく効きます。固定費だけで SKU を比較せず、実トラフィックを Pricing Calculator に入れることが大切です。

Standard が向いているシステム

Standard は、配信・可用性・独自のアクセス制御が主目的で、オリジンを Private Link にする要件やマネージド WAF が不要なシステムに向いています。

1. 複数リージョンの公開 Web サイト、API

複数リージョンへ同じアプリケーションを配置し、利用者に近い正常なオリジンへルーティングしたいケースです。正常性プローブと優先度を使えば、通常は近いリージョンへ送り、障害時には別リージョンへ切り替えられます。

2. 静的コンテンツやダウンロード配信

画像、JavaScript、CSS、ドキュメント、ソフトウェア配布物などをキャッシュし、オリジン負荷と遅延を減らしたいケースです。Rules Engine でキャッシュ期間、圧縮、ヘッダー、URL 書き換えも制御できます。

3. アクセス条件が明確な公開サービス

国・地域制限、IP 許可・拒否、特定パスのレート制限など、必要な防御をカスタムルールで明確に定義できるケースです。

4. SaaS の共通入口

複数ドメインや複数サービスを 1 つの Front Door プロファイルに集約し、TLS、ルーティング、ログ、基本的な WAF ポリシーを共通化したいケースです。

Standard は「Premium の廉価版」というより、高度なセキュリティ機能を別の層で満たせるシステムの本命 SKUと考える方が自然です。

Premium が向いているシステム

Premium は、インターネット公開サービスに対して、エッジからオリジンまで一貫したセキュリティ境界を作りたい場合に向いています。

1. オリジンをインターネットへ公開できないシステム

金融、医療、会員情報、企業の重要データなどを扱い、オリジンのパブリックアクセスを禁止したいケースです。Private Link を構成し、オリジン側で Private Link 以外の経路を拒否することで、Front Door を唯一の公開入口にできます。

2. OWASP 系の攻撃へ継続的に対応したい公開 Web アプリ

EC サイト、会員ポータル、予約サイト、公開 API など、SQL インジェクション、XSS、プロトコル攻撃への標準的な防御が必要なケースです。Microsoft 管理の WAF ルールを利用することで、ルールの開発と保守を Microsoft に任せられます。利用者側では、最新バージョンの確認、アップグレード検証、誤検知の調整を継続します。

3. Bot の影響が大きいサービス

スクレイピング、在庫買い占め、クレデンシャルスタッフィング、不正ログインなど、Bot の分類と制御が必要なケースです。Bot Manager とカスタムのレート制限を組み合わせます。

4. 複数リージョンのミッションクリティカルなサービス

グローバル負荷分散、エッジ WAF、非公開オリジンを 1 つのサービスで統合したいケースです。可用性だけでなく、Front Door を迂回できない構成にすることが重要です。

Premium の判断基準は「予算に余裕があるか」より、Private Link またはマネージド WAF がアーキテクチャ要件かです。どちらも不要なら、Premium の固定費を正当化しにくくなります。

Front Door を置かない方がよいケース

Standard と Premium の比較を始める前に、Front Door 自体が必要かも確認します。

次のようなケースでは、導入しない判断も十分に合理的です。

Front Door を追加すると、DNS、証明書、キャッシュ、正常性プローブ、WAF、オリジン制限、監視、障害切り分けの対象が増えます。課題が曖昧なまま「将来のため」に置くと、固定費と運用負荷だけが先に発生します。

導入事例ハイライト：コンテンツワークスの PaaS 化

Microsoft Customer Stories のコンテンツワークス事例は、フォトブック作成サービス「Photoback」を支えてきたオンプレミス環境を、単純なリフト＆シフトではなく Azure の PaaS を中心とした構成へ移行した事例です。

同社のシステムは約 20 年にわたってオンプレミスで稼働しており、増加するユーザーデータやアクセスへの対応が課題になっていました。支援したゼンアーキテクツの紹介によると、2〜3 日間のハッカソン形式で解決策を具体化し、難易度の高い領域を含む PaaS 化を約 1 年で実現しています。

Front Door は PaaS 全体の「玄関」

この事例の構成図で Azure Front Door は、利用者からの通信を最初に受ける位置にあります。その先には、Storage Blob の静的 Web サイト、Azure Static Web Apps、Azure Web Apps が並びます。さらにバックエンドでは、Azure Cache for Redis、Azure SQL Managed Instance、Event Hubs、Azure Functions、Azure Cosmos DB、Key Vault、Microsoft Entra ID などが役割ごとに組み合わされています。

Front Door の注目点
個々の PaaS を直接公開するのではなく、異なる配信先を 1 つのエッジ入口へまとめています。Front Door は「CDN を後付けする部品」ではなく、静的コンテンツと動的アプリケーションを同じ公開面で受け止める、PaaS アーキテクチャの境界として配置されています。

この配置から読み取れる Front Door の価値は、次の 3 点です。

  1. 入口の統一：静的サイト、Static Web Apps、Web Apps の違いを利用者から隠し、単一の公開入口からパスやルールに応じて振り分けられる。
  2. 配信と保護の集約：TLS、キャッシュ、ルーティング、WAF などのエッジ機能を、各 PaaS に個別実装せず入口へ集約できる。
  3. 段階的なモダナイズとの相性：オンプレミスの機能を一度に同じ PaaSへ移すのではなく、静的配信、Web、イベント処理、データストアを適材適所で分離しても、外部公開面を安定させやすい。

ただし、構成図だけでは Front Door の SKU、WAF ポリシー、キャッシュ TTL、オリジン制限の詳細までは確認できません。したがって、この事例は「Premium の採用事例」としてではなく、PaaS 化で分散した複数のサービスを Front Door で束ねる実例として捉えるのが適切です。

この事例で特に印象的なのは、移行の目的がサーバーの置き場所を変えることではなく、サービスごとにマネージド機能を選び直し、開発と事業のスピードを上げることに置かれている点です。Front Door は、その変化を利用者側から一貫したサービスとして見せるための重要なレイヤーになっています。

Microsoft 公式の適用シナリオ

Microsoft Learn には、Azure Front Door をどのような構成で使うかを示す公式シナリオと参照アーキテクチャがあります。顧客名を伴う導入事例ではありませんが、課題、構成、Front Door の役割が明示されており、SKU を選ぶ際の具体例として参考になります。

1. 公開 Web アプリケーションの高速化と保護

公開 Web アプリケーションを高速化して保護するシナリオでは、Front Door をインターネット公開アプリの共通入口として配置します。

配信性能と複数オリジンへのルーティングが中心なら Standard が候補です。マネージド WAF、Bot Manager、Private Link まで同じ入口へ統合するなら Premium が適します。

2. Azure Storage Blob の静的コンテンツ配信

Azure Storage Blob と Azure Front Door を組み合わせるシナリオでは、Web サイトの画像、CSS、JavaScript、PDF、JSON、非ストリーミング動画などを Front Door 経由で配信します。

公式の Premium 構成例では、Front Door が WAF でリクエストを検査し、キャッシュがあればエッジから応答します。キャッシュミス時だけ Microsoft のバックボーンと Private Link を通って Storage へ接続し、Storage ファイアウォールはインターネットからの直接アクセスを拒否します。

この構成には、次の狙いがあります。

Private Link で Storage を非公開にする公式例は Premium です。直接アクセスの遮断が不要なら、Standard と公開オリジンを使う選択肢も公式に示されています。

3. ミッションクリティカルなグローバル配信

ミッションクリティカルなグローバル Web アプリケーションでは、Azure Front Door を通常時の主経路として使い、複数リージョンへの active-active または active-passive ルーティング、エッジキャッシュ、WAF を提供します。

さらに Front Door 自体を単一障害点として扱えないほど厳しい可用性目標では、Azure Traffic Manager の配下に Front Door と別のルーターまたは CDN を置き、Front Door 障害時に代替経路へ切り替える構成が紹介されています。グローバルコンテンツ配信のシナリオでは、通常時は Front Door を使い、障害時は別 CDN へ切り替えます。

ただし Microsoft は、この構成が多くのシステムには不要であり、コスト、DNS、証明書、WAF の同等性、キャッシュ再充填、監視、複数コントロールプレーンの運用が複雑になると注意しています。可用性を上げるための追加経路が、設計と運用を誤ると全体の信頼性を下げる可能性もあります。

この事例から分かるのは、Front Door を置けば可用性設計が完了するのではなく、目標とする SLO に応じて、オリジンの冗長化、入口の冗長化、継続的なフェールオーバーテストまで設計する必要があるという点です。

選定時のチェックリスト

Front Door を導入するか

Standard で足りるか

Premium が必要か

この順番で考えると、最初から SKU の機能表だけを眺めるより判断しやすくなります。

最近の状況として押さえておきたいこと

Classic ではなく Standard / Premium を選ぶ

Azure Front Door (classic) は 2027 年 3 月 31 日に廃止予定です。新規プロファイルや新規ドメインのオンボーディングもすでに停止されています。これから新しく構成する場合は Standard または Premium が前提です。

Classic から Standard / Premium には移行機能があります。また、Standard から Premium にはアップグレード機能があります。一方、Premium から Standard へ戻すシームレスなダウングレード機能はなく、プロファイルの再作成が必要です。

「まず Premium で試して後から簡単に Standard へ戻す」という進め方は避け、必要なセキュリティ機能を先に整理した方が安全です。

TLS 1.3 と最近のセキュリティ機能

Standard / Premium は TLS 1.2 と TLS 1.3 に対応しています。Microsoft Learn の比較表では、Front Door からオリジンへの認証に使うマネージド ID も Preview として掲載されています。

Preview 機能は、提供リージョン、制限、SLA、将来の変更可能性を確認したうえで採用する必要があります。特に本番のオリジン保護では、Preview だけに依存せず、Private Link やオリジン側のアクセス制限も含めて設計します。

まとめ

Azure Front Door Standard と Premium は、どちらもグローバル配信、キャッシュ、動的サイト高速化、負荷分散、Rules Engine、独自ドメイン、カスタム WAF ルールを提供します。

違いを短くまとめると、次のとおりです。

選択判断の目安
導入しない既存サービスの配信で足りており、グローバル負荷分散やエッジ保護の課題がない
StandardCDN、動的配信、複数オリジン、ルーティング、カスタム WAF が必要
PremiumStandard の機能に加え、Private Link、マネージド WAF、Bot Manager が必要

料金は、Standard が月額 $35、Premium が月額 $330 という公式掲載例の基本料金に、リクエスト数とデータ転送量などが加わります。Premium は配信性能の上位版というより、高度なセキュリティを統合した SKU です。

自分のサイトについて考えた結果、今は Front Door を追加しないことにしました。Static Web Apps の配信で現状の要件を満たしており、追加の固定費と運用負荷を正当化する課題がまだないためです。

一方で、公開 API の重要度が上がる、複数リージョン化する、オリジンのパブリックアクセスを閉じる、マネージド WAF が必要になる、といった変化があれば Premium を含めて再評価します。サービス名や機能の多さから選ぶのではなく、どの課題をエッジで解決したいかを明確にすることが、Front Door と SKU 選定の出発点だと分かりました。

公式情報源