オンプレでUTM（統合脅威管理）やNGFW（次世代ファイアウォール）をちゃんと運用してきたエンジニアが、Azure環境に移行したとき最初に戸惑うのが「NSGだけじゃダメなの？」という疑問です。NSG（Network Security Group）がすでにあるのに、なぜ別途Azure Firewallを立てる必要があるのか、コストに見合う価値があるのか、判断しにくいと感じる方も多いでしょう。
この記事では、Azure Firewallの基本的な仕組みを、オンプレのUTM・NGFWと比べながら解説します。デプロイ手順・ルール設定・料金の考え方・NSGとの役割分担まで、現場で即使える知識を体系的にお届けします。
なぜAzure Firewallが必要なのか？（NSGだけでは不十分な理由）
「NSGでポート制御できるなら、それでいいんじゃないか」という考えは、オンプレ経験者には自然な発想です。NSGはAzureにおけるネットワークACLのようなもので、送信元・宛先IPアドレスとポート番号による制御が可能です。しかし、NSGにはいくつかの限界があります。
| 機能 | NSG | Azure Firewall |
|---|---|---|
| 制御レイヤー | L3/L4（IP・ポート） | L3/L4/L7（FQDN・URL・TLS） |
| FQDNフィルタリング | 不可 | 可能（Application Rules） |
| 脅威インテリジェンス | なし | Microsoftのフィードで自動ブロック |
| ログ・可視化 | NSGフローログ（基本的） | Azure Monitor・Log Analytics連携 |
| 集中管理 | サブネット・NIC単位 | Hub VNetで一元管理 |
| SNAT/DNAT | なし | あり |
| TLS検査 | 不可 | 可能（Premiumのみ） |
| IDPS（侵入検知・防止） | 不可 | 可能（Premiumのみ） |
オンプレで「Fortigate」「Palo Alto」「Cisco ASA」などを使っていたエンジニアなら、NSGは「静的なACLリスト」に相当し、Azure Firewallが「ちゃんとしたFW/UTM」に相当すると理解するとわかりやすいです。
例えば、Azure環境からインターネットへの送信トラフィックを制御したい場合、NSGだけでは「どのIPへ行くか」しか制御できません。しかしAzure Firewallなら「*.microsoft.comへのHTTPS通信は許可するが、それ以外は拒否」といったFQDNベースのアプリケーション制御が可能です。悪意ある既知のC2サーバーへの通信を、Microsoftの脅威インテリジェンスで自動ブロックすることもできます。
Azure Firewallの基本アーキテクチャ
Azure FirewallはHub-and-Spoke（ハブアンドスポーク）構成で使われることが多いです。これはオンプレの「中央ファイアウォール→各セグメント」という設計とほぼ同じ発想です。
1. Hub VNetにAzure Firewallを配置する
Azure Firewallは「AzureFirewallSubnet」という専用サブネット（最小/26）に配置します。このHub VNetと、各ワークロードが乗るSpoke VNetをVNet Peeringで接続します。
# Hub-and-Spike構成のイメージ [オンプレ] ←VPN/ExpressRoute→ [Hub VNet] ↓ [Azure Firewall] / | \ [Spoke1 VNet] [Spoke2 VNet] [Spoke3 VNet] (Web層) (App層) (管理系)
2. ルートテーブル（UDR）でトラフィックをFirewall経由にする
Azure Firewallを配置しただけでは、トラフィックは勝手にFirewallを通りません。Spoke VNetの各サブネットに対して、「インターネット向け（0.0.0.0/0）の次ホップをAzure FirewallのプライベートIPにする」というUDR（ユーザー定義ルート）を設定する必要があります。これがオンプレの「デフォルトゲートウェイをFWのIPに向ける」作業に相当します。
3. Azure Firewall PolicyでルールをIaC管理する
Azure Firewallのルール管理には「Firewall Policy」という独立したリソースを使うことを強く推奨します。Policyを使うと複数のFirewallで設定を共有できるほか、ARM templateやTerraformによるIaC管理が容易になります。
Azure Firewallのデプロイ手順（ポータル操作）
1. 前提リソースの準備
Azure Firewallをデプロイする前に、以下のリソースを準備します。
・Hub VNet: AzureFirewallSubnetを/26以上のアドレスレンジで作成
・パブリックIPアドレス: Azure FirewallのSNAT用（Standard SKU）
・Azure Firewall Policy: 先にPolicyリソースを作成しておくとスムーズ
# Azure CLIでAzureFirewallSubnetを持つHub VNetを作成する例 az network vnet create \ --resource-group rg-hub \ --name vnet-hub \ --address-prefix 10.0.0.0/16 \ --subnet-name AzureFirewallSubnet \ --subnet-prefix 10.0.1.0/26 # パブリックIPアドレスの作成（Standard SKU必須） az network public-ip create \ --resource-group rg-hub \ --name pip-azfw \ --sku Standard \ --allocation-method Static
2. Azure Firewallのデプロイ
Azure PortalでAzure Firewallを検索し、「作成」を選択します。主要な設定項目は以下の通りです。
・サブスクリプション・リソースグループ: Hub VNetと同じ場所に配置
・名前: 命名規則に従って設定（例: azfw-hub-eastjp-001）
・リージョン: Hub VNetと同じリージョン
・ファイアウォール階層: Standard（通常用途）またはPremium（TLS検査・IDPS必要時）
・仮想ネットワーク: Hub VNetを選択
・パブリックIPアドレス: 先ほど作成したpip-azfwを選択
・ファイアウォール ポリシー: 既存のPolicyを紐付け（または新規作成）
デプロイには10分程度かかります。NSGやセキュリティグループが数秒で適用されるのと違い、仮想アプライアンスとして起動するため時間がかかります。この点はオンプレのFW新規立ち上げと感覚が近いです。
3. ルートテーブル（UDR）の設定
Spoke VNetのサブネットにUDRを関連付けます。
# Azure CLIでルートテーブルを作成し、デフォルトルートをFirewall経由に設定 # AZFW_PRIVATE_IPはAzure FirewallのプライベートIPアドレス（例: 10.0.1.4） az network route-table create \ --resource-group rg-spoke1 \ --name rt-spoke1 az network route-table route create \ --resource-group rg-spoke1 \ --route-table-name rt-spoke1 \ --name DefaultToFirewall \ --address-prefix 0.0.0.0/0 \ --next-hop-type VirtualAppliance \ --next-hop-ip-address 10.0.1.4 # Spoke1のサブネットにルートテーブルを関連付け az network vnet subnet update \ --resource-group rg-spoke1 \ --vnet-name vnet-spoke1 \ --name snet-app \ --route-table rt-spoke1
ルール設定の基本（Network・Application・NATの3種類）
Azure Firewallのルールは3種類あります。優先度が低い数値ほど先に評価されます（例: 100→200→300の順）。
1. Networkルール（L3/L4制御）
送信元IP・宛先IP・プロトコル・ポートによる制御です。オンプレのACLルールと同等です。以下はSMTPサーバーからメールリレーを許可する例です。
# Azure CLIでNetworkルールコレクションを追加 az network firewall policy rule-collection-group collection add-filter-collection \ --policy-name afwpol-hub \ --resource-group rg-hub \ --rule-collection-group-name DefaultNetworkRuleCollectionGroup \ --name AllowSMTP \ --collection-priority 200 \ --action Allow \ --rule-name AllowOutboundSMTP \ --rule-type NetworkRule \ --source-addresses "10.1.0.0/24" \ --destination-addresses "*" \ --ip-protocols TCP \ --destination-ports 587
2. Applicationルール（FQDN制御）
これがNSGとの最大の差別化ポイントです。FQDNやURLパターンで送信トラフィックを制御できます。例えば「*.windows.net」「*.microsoft.com」へのHTTPS通信のみ許可し、その他のインターネット通信を拒否するといった設定が可能です。
# FQDNベースのApplicationルール追加例 az network firewall policy rule-collection-group collection add-filter-collection \ --policy-name afwpol-hub \ --resource-group rg-hub \ --rule-collection-group-name DefaultApplicationRuleCollectionGroup \ --name AllowAzureServices \ --collection-priority 300 \ --action Allow \ --rule-name AllowMicrosoftFQDNs \ --rule-type ApplicationRule \ --source-addresses "10.0.0.0/8" \ --protocols "https=443" \ --fqdn-tags WindowsUpdate MicrosoftActiveProtectionService
3. NATルール（DNAT：外部からの受信制御）
Azure FirewallのパブリックIPに届いたトラフィックを、内部のVMに転送するDNATルールです。オンプレのポートフォワーディング設定に相当します。
| ルールタイプ | 用途 | オンプレ相当 |
|---|---|---|
| Networkルール | IP/ポートによるL3/L4フィルタリング | ACL・パケットフィルタ |
| Applicationルール | FQDN・URLによるL7フィルタリング | プロキシサーバー・UTMのURLフィルタ |
| NATルール（DNAT） | 外部からの受信トラフィック転送 | ポートフォワーディング・静的NAT |
料金の仕組み（コスト感覚を掴む）
Azure Firewallの料金は「デプロイ時間課金＋データ処理課金」の二本立てです。2026年3月時点の東日本リージョン（Japan East）での参考料金は以下の通りです（USD）。
・Standard階層: 約$1.25/時間（デプロイ）+ $0.016/GB（データ処理）
・Premium階層: 約$1.878/時間（デプロイ）+ $0.016/GB（データ処理）
・Basic階層: 約$0.31/時間（デプロイ）+ $0.016/GB（小規模・非本番向け）
月額に換算すると（Standard 1台、データ転送1TB/月の場合）：
# 月額コスト試算（概算） デプロイ課金: $1.25 × 24時間 × 30日 ≒ $900/月 データ処理: $0.016 × 1,024GB ≒ $16/月 合計: ≒ $916/月（約13万円/月）
これがAzure Firewallの「重い」と言われる理由です。オンプレのFirewallは初期投資が大きく月額は安いですが、Azure Firewallは常に固定費が発生します。開発・検証環境では「使わない時間は削除する」か「Basic階層にする」ことでコストを抑えることができます。
また、Azure Firewallは高可用性（HA）を内蔵しており、オンプレでActiveStandby構成を組む際のライセンス×2やハードウェア×2のコストが不要という観点で考えると、意外とコストパフォーマンスが見合う場合も多いです。
応用・実務Tips
【Tips 1】NSGとAzure Firewallの役割分担
「NSGもAzure Firewallも両方設定する必要があるのか」という疑問は現場でよく出ます。答えは「両方使うのが正解」です。
・NSG（マイクロセグメンテーション）: サブネット・NIC単位の細かいL3/L4制御。Spoke内のVM間通信制御に使う。
・Azure Firewall（境界制御）: Hub-and-Spokeの出口でインターネットや他セグメントへの集中制御。FQDNやアプリ制御はここで行う。
オンプレで言うと「NSG=内部セグメント間のACL」「Azure Firewall=インターネット境界のUTM/NGFW」というイメージが近いです。
【Tips 2】強制トンネリング（オンプレへのバックホール）
オンプレと接続しているハイブリッド構成で「すべてのインターネット通信をオンプレのプロキシ経由にしたい」場合、Azure Firewallの「強制トンネリング」機能を使うことで実現できます。ただし、この設定はFirewall作成時にしか有効にできないため、後から追加はできません。
【Tips 3】Firewall PolicyによるIaC管理
ルールをAzure Portalで手動管理すると、どの設定が何のためにあるのか後から追いづらくなります。Terraform（azurerm_firewall_policy_rule_collection_groupリソース）またはARM templateでPolicy全体をコードで管理することを強く推奨します。変更履歴がGitで管理でき、チームでのレビューも可能になります。
【Tips 4】診断ログの有効化は必須
Azure Firewallは、デプロイしただけでは通信ログが記録されません。Log Analytics WorkspaceへのDiagnostic Settings（診断設定）を必ず有効にしてください。特に「AzureFirewallApplicationRule」「AzureFirewallNetworkRule」ログを有効にすることで、どのトラフィックが許可・拒否されたかを追跡できます。
よくあるトラブルと対処法
トラブル1: デプロイしても通信がFirewallを通らない
最も多いのがUDRの設定漏れです。Azure Firewallを配置しただけではトラフィックは通りません。Spoke VNetの各サブネットに「0.0.0.0/0 → Azure FirewallのプライベートIP」のルートテーブルを確実に紐付けてください。Azure Network Watcher（Next Hop機能）でトラフィックの経路を確認できます。
トラブル2: FQDNルールが機能しない
ApplicationルールのFQDNフィルタリングはTLS（HTTPS）通信をSNI（Server Name Indication）で判断します。クライアントのDNSがAzure Firewallを経由していない場合、FQDNが解決できず意図した動作になりません。Hub VNetのDNS設定を確認し、仮想マシンのDNSがAzure FirewallのプライベートIPを向いているか確認してください。
トラブル3: SNAT後のIPが予測できない
デフォルトでAzure Firewallは送信元トラフィックをSNATします。複数のパブリックIPを割り当てた場合、どのIPが使われるか事前に特定できません。外部サービスでIPホワイトリスト登録が必要な場合は、Firewall Policyの「SNAT設定」で特定のプライベートIPレンジからのトラフィックはSNATしないよう設定するか、固定のパブリックIPを明示的に紐付けるよう設計してください。
トラブル4: コストが予想より高い
開発環境でAzure Firewallを24時間365日動かし続けると月額10万円超になります。開発・検証では営業時間外にAzure Firewallを削除し（パブリックIPとVNetは残す）、翌朝再デプロイするスクリプトを組むか、Basic階層にダウングレードするとコストを大幅に抑えられます。ただし、再デプロイ時にプライベートIPが変わる可能性があるため、UDRの更新も自動化する必要があります。
本記事のまとめ
Azure Firewallは、単なるポートフィルタリングを超えた、オンプレUTM/NGFWに相当するクラウドネイティブなファイアウォールサービスです。
・NSGとの違い: FQDNフィルタ・脅威インテリジェンス・集中ログ管理の3点が大きな差
・アーキテクチャ: Hub VNetのAzureFirewallSubnetに配置し、UDRでトラフィックを経由させる
・ルール種別: NetworkルールはL4制御、ApplicationルールはFQDN制御、NATルールはDNAT
・料金: Standard約$1.25/時間の固定費が発生。本番は常時起動、開発は停止/削除で最適化
・推奨: Firewall PolicyでIaC管理、診断ログは必ず有効化
Linuxサーバーの構築・運用の基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。クラウド上のLinux環境を安全に運用するための知識と合わせて参照してください。
Azure Firewallの設計、どこから手をつければいい？
Hub-and-Spoke構成やUDR設定など、Azure Firewallは設計の前提知識が多く、独学では抜け漏れが出やすいポイントです。
オンプレの経験を活かしながら、現場で使えるクラウドスキルを体系的に身につけたい方へ、メルマガで実践的なクラウド活用ノウハウをお届けしています。
