Azure Front Door vs. Application Gateway: 2026年版アーキテクチャ比較

2026年において、Azure Front Door (AFD) とApplication Gatewayのアーキテクチャに関する議論は、「グローバル VS リージョン」という二者択一ではなく、TLSハンドシェイクをどこで終端させたいのか、そしてPrivate Linkバックホールによるメリットに対してどの程度のコストを許容するかという点に集約されています。もし依然としてマルチリージョンマイクロサービスのエッジイングレスとしてApplication Gatewayを主要にデプロイしているのであれば、おそらくコンピューティングコストを過剰にかけ、Microsoftが提供するAnycastエッジの膨大なキャパシティを十分に活用できていないでしょう。

構造的相違点：エッジでのLayer 7処理 vs. VNet内での処理

Azure Front Doorは、Microsoftの190以上のPoP（Points of Presence）で稼働する、分散型マルチテナントサービスです。Anycastを使用して、トラフィックを最寄りのエッジロケーションにルーティングします。対照的に、Application Gateway (AppGW) は、Virtual Network (VNet) に直接注入されるマネージドリージョンリソースです。この違いは極めて重要です。AFDはエッジでTCP/TLSを終端し（初期ハンドシェイクのRTTを短縮）、AppGWは特定のAzureリージョン内でそれを終端させます。

2026年の高性能ワークロードにおいては、Front Doorの「Split-TCP」アーキテクチャがレイテンシー面で明確な勝者となります。ユーザーに近い場所でハンドシェイクを終端させることで、パケットはPoPからオリジンまでMicrosoftのプライベートファイバーバックボーンを経由し、パブリックインターネットの「コールドポテト」ルーティングとは異なります。ユーザーがグローバルに分散している場合、パブリックIPの背後にAppGWを配置する設計パターンは時代遅れであり、ジッターと不必要なレイテンシーを招きます。

AFD Premium：パブリックに公開されたApplication Gatewayの終焉か？

Azure Front Door Premiumの導入と、Private Linkとの深い統合は、意思決定マトリックスを根本から変革しました。これまで、AFDの「パブリックIP」要件は、App ServiceまたはInternal Load Balancer (ILB) がAFDのIP範囲（サービス・タグ）をホワイトリストに登録する必要があることを意味し、これはしばしばコンプライアンス上の課題となっていました。

AFD Premiumを使用すると、Private Linkを介してバックエンドに接続できるようになりました。これにより、バックエンド（AKSクラスターのILB、ストレージアカウント、仮想マシンなど）は、パブリックエンドポイントを必要としなくなります。これは、ほとんどのマルチリージョンシナリオにおいて、パブリックに公開されたApplication Gatewayを実質的に不要なものにします。AppGWスケールセットの複雑さ（およびその苛立たしい15分のデプロイ時間）を管理する代わりに、Private Linkによるプライベートトンネルを用いてAFDのグローバルスケールを活用できるのに、なぜAppGWを選ぶのでしょうか？

# 例：CLIによるAFDオリジンのPrivate Linkステータス確認
az afd origin show \
  --origin-name my-aks-origin \
  --profile-name my-afd-profile \
  --resource-group rg-prod-network \
  --query "privateLinkAlias"

Application Gateway v2：VNet最後の砦

では、2026年においてApplication Gateway v2が実際に意味をなすのはどのような場合でしょうか？以下の3つの特定のシナリオでは、AppGWが依然として唯一最良の選択肢であり続けます。

• 内部専用ロードバランシング： トラフィックが厳密に「East-West」またはオンプレミスExpressRoute/VPNからの「North-South」である場合、AFDでは処理できません。VNet内部のL7ルーティングにはAppGWが必要です。
• 高検査制限を伴うカスタムWAF規則： AFD WAFは強力ですが、AppGW WAF v2は、リクエストボディ検査（標準で最大128KB、一部設定でカスタマイズ可能）や特定のリージョン固有のコンプライアンス要件に対してよりきめ細かな制御を可能にします。
• 厳格な相互TLS (mTLS) 要件： AFDもmTLSをサポートしていますが、複雑なエンタープライズグレードのmTLSの構成や証明書管理は、ゲートウェイレベルで信頼されたルートCAを管理するAppGWインスタンスの方が、より「ネイティブ」で制御しやすいと感じられることがよくあります。

また、AppGW v2の「Basic」SKU（もしその機能削減バージョンをそう呼べるのであれば）は、スケールイベント時のパフォーマンスにおいて依然として悪夢であることに注意が必要です。Standard_v2またはWAF_v2を使用し、コールドスタートペナルティを回避するために常に最低2ユニットのキャパシティを維持してください。

イングレスの計算：RPSあたりのコスト

具体的な数字を見てみましょう。2026年には、データエグレスと「リクエスト処理ユニット」(RPUs) または「キャパシティユニット」のコストを誤って選択すると、予算を圧迫することになります。毎秒5,000リクエスト(RPS)を処理する高トラフィックサイトの場合：

Azure Front Door (Standard/Premium)

• 基本料金： 月額約35ドル（Standard）から330ドル（Premium）。
• リクエスト料金： 100万リクエストあたり約0.75ドル。
• データ転送： エッジからユーザーへのアウトバウンドデータに対して課金されます。Azureオリジンからエッジへのデータ転送は$0です（これは大きな隠れた節約になります）。

Application Gateway v2

• 固定コスト： 月額約180ドル（WAF_v2）。
• キャパシティユニット (CU) コスト： CU時間あたり0.008ドル。5,000 RPS（平均サイズ10KB、ヘッダー2KBと仮定）は、通常およそ10〜15 CUに相当します。
• データ転送： 標準のVNetエグレス料金が適用され、これはAFDの割引料金よりも大幅に高くなる可能性があります。

結論： 大量のグローバルなトラフィックについては、Front Doorがほぼ常に安価です。なぜなら、「オリジンからインターネット」へのエグレス料金を排除できるからです。クラウド支出の最適化についてさらに詳しく知るには、ExpressRouteとエグレスのコスト最適化に関するガイドを参照してください。

高度なWAF戦略：レート制限とボット防御

Front Door PremiumのWAFは、リージョンAppGW WAFよりもはるかに進んでいます。2026年には、自動化されたボット攻撃やDDoSの「Slow and Low」攻撃が一般的です。AFD Premiumには、Microsoft脅威インテリジェンスに基づいたボットマネージャーのルールセットが含まれており、既知の「優良ボット」（Google、Bing）を識別し、「悪意のあるボット」がAzureリージョンに到達する前にブロックまたはチャレンジします。

AFDのレート制限もより堅牢です。クライアントIP、地理的位置、さらには特定のリクエストヘッダーに基づいてレート制限を定義できます。AppGW中心の設計からAFD中心の設計に移行すると、エッジでトラフィックをドロップする機能が得られ、正当なユーザーのためにバックエンドのコンピュートサイクル（およびオートスケールコスト）を節約できます。

# AFDレート制限ルールの部分的なARMテンプレート
{
  "name": "RateLimitRule",
  "priority": 100,
  "ruleType": "RateLimitRule",
  "action": "Block",
  "matchConditions": [
    {
      "matchVariable": "RemoteAddr",
      "operator": "IPMatch",
      "negateCondition": false,
      "matchValue": ["0.0.0.0/0"]
    }
  ],
  "rateLimitThreshold": 1000,
  "rateLimitDurationInMinutes": 1
}

マルチリージョン高可用性 (DR)

真の「高可用性」（99.99%以上）を構築する場合、Application Gatewayはシングルリージョンの障害点です。各リージョンにAppGWをデプロイし、その前にAzure Traffic Manager（DNSベース）を配置することは可能ですが、これは「貧者の」グローバルロードバランシングです。DNSベースのフェイルオーバーはTTL（Time to Live）キャッシングの影響を受けやすく、障害発生後数分間、ユーザーが停止中のリージョンにアクセスし続ける可能性があります。

Azure Front Doorは、HTTPレベルのヘルスプローブとAnycastを使用します。もし西日本2リージョンがダウンした場合、エッジPoPは直ちに（数秒以内に）東日本または北欧にトラフィックを再ルーティングします。DNS伝播遅延は発生しません。これがAFDがMicrosoft自身のサービス（Office 365、Xbox Liveなど）のバックボーンである理由です。

これらのアーキテクチャパターンについては、マルチリージョンAKSネットワーキングに関する詳細ガイドで議論しており、VNetへの特定の注入要件がある場合にのみ、AppGWをAFDの背後に配置すべき理由を説明しています。

結論：TechLeagueの推奨

2026年における選択の階層は明確です。アプリケーションがパブリックに公開されている場合、Azure Front Door Premiumを使用してください。Anycastによるレイテンシー削減、Edge WAF、Private Linkオリジンサポートの組み合わせにより、セキュリティとパフォーマンスの両面で優れた選択肢となります。Application Gateway v2は、内部トラフィックの「バックエンドコンシューマー」として、またはAFDエンジンがまだサポートしていない特定のWAFリライトに関するレガシー要件がある場合にのみ使用してください。

クラウドを物理的なデータセンターのように扱うのはやめましょう。WAFはインターネットの正面玄関に設置されるべきであり、ユーザーから40ミリ秒離れたサブネットに隠されているべきではありません。これらのスタックに関するアーキテクチャレビューや専門トレーニングについては、techleague.ioの集中ワークショップをご覧ください。

よくある質問