はじめに
こんにちは、パナソニックコネクト株式会社の山本です。
先日、Azure でアウトバウンド通信の制御方式を検討していたとき、Azure Firewall の SKU 選びで一度手が止まりました。
（この要件なら Basic で足りるのか、それとも Standard が要るのか、、、を判断するのに、機能表を何度も往復する羽目になりました
）
同じところで迷う人もいそうなので、そのとき調べた内容と判断の勘所を、実務目線で残しておきます。
この記事は「機能を上から順に解説する」のではなく、やりたいこと（要件）から必要な SKU を逆引きする構成にしています。カタログを眺めても決めきれなかった、という方に読んでもらえるとうれしいです。
なお、そもそも「なぜアウトバウンド（外向き）通信を制御する必要があるのか」——データ漏洩やマルウェアの外部通信を防ぐという観点は、なぜアウトバウンド通信の制御は重要なのか？ で分かりやすく整理されています。本記事はその必要性を前提に、Azure Firewall で「どの SKU を選ぶか」に焦点を当てます。
そもそも Azure Firewall の SKU は何が違うのか
Azure Firewall には Basic・Standard・Premium の 3 つの SKU があり、選んだ SKU で「出せる速度」「使える制御」「かかる料金」が段階的に変わります。ざっくり言えば、
- Basic: 速度もほどほど、制御もシンプル、そのぶん安い
- Standard: 速度と機能のバランス型。多くの本番はここ
- Premium: 通信の中身まで検査する高機能・高価格帯
という位置づけです。数字（下の表）を眺める前に、この 3 段階のイメージだけ持っておくと読みやすくなります。
なお、この記事で出てくる用語をいくつか先に補足しておきます。
-
FQDN（Fully Qualified Domain Name）:
www.example.comのような完全修飾ドメイン名。IP の代わりにドメイン名でルールを書ける - IDPS（Intrusion Detection and Prevention System）: 侵入検知・防止。既知の攻撃パターンを検出してブロックする仕組み
- TLS インスペクション: 暗号化された通信を一度復号して中身を検査し、再暗号化して転送する機能
機能の全体像を一枚の表で
まず 3 SKU の主要な違いを一覧にします。個別解説の前に、この表で「自分の要件がどの行に触れるか」をあたりを付けてください。
| 比較軸 | Basic | Standard | Premium |
|---|---|---|---|
| 最大スループット | 250 Mbps | 30 Gbps（オートスケール） | 100 Gbps（オートスケール） |
| L3-L7 フィルタリング | ステートフル＋FQDN（SNI） | ＋ネットワークレベル FQDN | ＋URL フィルタリング（フルパス） |
| 脅威インテリジェンス | アラートのみ | ブロック可 | ブロック可 |
| TLS インスペクション | × | × | ○（送信方向のフォワードプロキシ） |
| IDPS | × | × | ○（シグネチャベース） |
| DNS プロキシ / カスタム DNS | × | ○ | ○ |
| Web カテゴリフィルタリング | × | ○ | ○ |
| Fat Flow サポート | N/A | 1 Gbps | 10 Gbps |
| 可用性ゾーン | ○ | ○ | ○ |
| コスト感（相対） | 低 | 中 | 高 |
表の上から下に向かうほど「通信の中身に踏み込んだ制御」になっていきます。逆に言えば、要件が上のほうの行（速度と基本的なフィルタ）で収まるなら Basic で足りる、下のほうの行（検査・脅威対策）に触れるなら Standard 以上、という読み方ができます。
【本題】要件から逆引き：この制御にはどの SKU が要る？
ここがこの記事のいちばん伝えたいところです。SKU 選定でつまずくのは、たいてい「自分がやりたい通信制御に、どの SKU が必要か」がカタログから読み取りにくいからです。実際に検討でぶつかったパターンを、逆引きの早見表にしました。
アウトバウンド（内部 → 外部）の制御
| やりたい制御 | 使うルール | 必要 SKU |
|---|---|---|
| 固定 IP + ポートへの通信を許可（例: 特定 IP の 443 のみ） | ネットワークルール | Basic |
HTTPS / SQL をドメイン名で絞る（例: *.microsoft.com のみ許可） |
アプリケーションルール（SNI） | Basic |
| それ以外のプロトコル（FTP 等）をドメイン名で絞る | ネットワークレベル FQDN | Standard |
URL のパス単位で絞る（例: example.com/admin だけ拒否） |
URL フィルタリング | Premium |
| 業務外サイトをカテゴリでまとめてブロック | Web カテゴリ | Standard |
| 通信の中身を検査してマルウェアを弾く | TLS インスペクション + IDPS | Premium |
ポイントは 「ドメイン名で絞りたい対象が HTTPS（や SQL）かどうか」 が Basic と Standard の分岐点になることです。
- HTTPS のドメイン制御は、TLS 接続時に平文で流れる接続先ドメイン名（SNI）を見て判定できるため、Basic でも可能（アプリケーションルールは平文 HTTP や SQL も扱えます）
- FTP など SNI で判定できないプロトコルをドメインで絞るには、FQDN を DNS 解決して IP で判定する「ネットワークレベル FQDN」が必要で、これは Standard 以上
同じ「ドメインで絞る」でも仕組みが 2 通りあり、対応 SKU が違う、というのが盲点でした。公式も精度の高いアプリケーションルール（SNI 方式）の優先利用を推奨しています。
インバウンド（外部 → 内部）の制御
受け付ける側の通信は考え方が変わります。DNAT で受け口を作り、送信元を絞る形になります。
| やりたい制御 | 必要 SKU |
|---|---|
| 外部からの受付を DNAT で公開し、送信元 IP で絞る | Basic |
| 受け付けた通信を検査して攻撃を弾く（IDPS 等） | Premium |
| 送信元を「ドメイン名」で絞る | SKU 問わず不可（IP / サービスタグで指定する） |
注意したいのは、アウトバウンドで使える FQDN フィルタは「宛先」を絞るもので、インバウンドの「送信元」には使えない点です。送信元不特定のインターネットからの受付は、送信元 IP かサービスタグ（Azure サービス群を表す識別子）で絞るのが基本になります。
料金の考え方
SKU を決めるうえで料金は外せません。Azure Firewall の課金は、SKU を問わず 2 本立てです。
- 固定費（デプロイ課金）: ファイアウォール 1 台につき時間単位。停止中でもかかる
- 従量費（データ処理課金）: 通過したトラフィック量（GB）に応じて
東日本リージョンの公開単価（USD 建て）をもとにした概算が次です。為替や契約で変わるので、SKU 間の相対感をつかむ目安として見てください。
| SKU | 固定費（/時） | 従量費（/GB） | ざっくり月額（固定費のみ・730h） |
|---|---|---|---|
| Basic | 約 $0.395 | 約 $0.008 | 約 $290 |
| Standard | 約 $1.25 | 約 $0.016 | 約 $910 |
| Premium | 約 $1.75 | 約 $0.016 | 約 $1,280 |
正確な数値は Azure Firewall の価格ページ（リージョンで「東日本」を選択）で確認してください。固定費だけでも SKU 間で 3〜4 倍の差があるので、「機能が余っている SKU を選ばない」ことがコスト最適化の第一歩になります。
各 SKU の性格と、ハマりやすいポイント
早見表で目星を付けたら、候補 SKU の性格と落とし穴を確認しておきましょう。
Basic：安く小さく始めるための SKU
基本的なフィルタリングと NAT が揃っていて、コストは最小限。開発・テスト専用というわけではなく、250 Mbps 未満のシンプルな要件なら小〜中規模の本番でも使えます。
内部的には 処理 VM が常に 2 台に固定され、負荷が増えても台数が増えません（オートスケールしない）。これが 250 Mbps という上限と直結しています。ただし 2 台構成なので可用性は確保されており、可用性ゾーンにも対応します。可用性が Standard/Premium に劣るわけではなく、妥協するのはあくまで速度と機能という理解が正確です。
気をつけたい点:
- 250 Mbps を超えるバースト（バックアップ転送や大量同期）で頭打ちになる
- 脅威インテリジェンスがアラート止まりで、悪意ある通信を自動遮断できない
- DNS プロキシ・Web カテゴリは非対応
- 後述の通り、Standard への"アップグレード"ができない（作り直しになる）
Standard：多くの本番はここに落ち着く
速度と機能のバランス型で、本番ワークロードの標準解です。最大 30 Gbps までオートスケールし、脅威インテリジェンスによる自動ブロック、DNS プロキシ、Web カテゴリ、ネットワークレベル FQDN が使えます。
気をつけたい点:
- TLS インスペクションがないので、暗号化通信の中身は見えない
- IDPS がないので、シグネチャベースの侵入検知はできない
- トラフィックが少ない環境だと、固定費のぶん Basic より割高になりやすい
Premium：通信の中身まで守りたいとき
TLS インスペクションと IDPS を備えたハイエンド。暗号化通信を復号して検査し、URL のパス単位まで制御できます。決済・金融・医療のように、検査やコンプライアンスが要件になる領域向けです。
気をつけたい点:
- 3 SKU で最も高い
- TLS インスペクションは CA 証明書の管理が必要で運用負荷が増える
- 復号処理でレイテンシが増えうる（事前のパフォーマンステスト推奨）
選定フロー
ここまでを一枚のフローにまとめます。
Basic で始める前に知っておきたい「移行の壁」
「まず Basic で安く始めて、必要になったら Standard に上げればいい」——検討中に自分もそう考えたのですが、ここに落とし穴がありました。
公式ドキュメントによると、Basic から Standard への直接アップグレードはサポートされていません。Standard ⇄ Premium はダウンタイムなしのワンクリックで相互変更できるのに、Basic だけは既存リソースの SKU 変更ができないのです。つまり Basic → Standard は、新しいファイアウォールを立てて切り替える実質的な作り直しになります。
作り直しに伴う主な作業と影響:
- ルール（ポリシー）の再適用: Basic のルールを新 Standard へ移す
- UDR の張り替え: ルートのネクストホップを新ファイアウォールに向け直す
- ダウンタイム: 切り替えの瞬間に通信断が起こりうる
- コストの二重発生: 新旧を並行稼働する期間は両方に固定費がかかる
一方で、相手から見える送信元 IP は維持できます。Azure Firewall はアウトバウンド時に SNAT を行うため、接続先から見える送信元 IP はファイアウォールのパブリック IP です。このパブリック IP は別リソースなので、静的（Static）かつ Standard SKU の IPであれば旧ファイアウォールから切り離して新ファイアウォールに付け替えられます。接続先の IP 許可リストを変更せずに移行できるわけです。
紛らわしいポイント: 「ファイアウォールの SKU（Basic/Standard/Premium）」と「パブリック IP の SKU（Basic/Standard）」は別リソースの別設定です。Standard/Premium ファイアウォールは Standard SKU の IP を要求します。なお Basic SKU のパブリック IP は 2025 年 9 月末で廃止済みなので、いま新規に作る IP は基本的に Standard SKU です。
将来 Standard に上げる可能性が高いなら、最初から Standard を選ぶほうが作り直しの手間を丸ごと回避できます。当面 Basic で十分なら、移行に備えて パブリック IP は静的・Standard SKU で確保しておく／ルールはポリシー（できれば IaC）で管理しておく と、いざというとき楽になります。
まとめ
要件から逆引きする、という視点で整理すると次のようになります。
- IP/ポートベースの制御、HTTPS のドメイン制御までで、速度が 250 Mbps 以内 → Basic
- HTTPS 以外もドメインで絞りたい / 脅威を自動ブロックしたい / 速度が足りない → Standard
- 通信の中身を検査したい（TLS インスペクション・IDPS）/ コンプライアンス要件 → Premium
そして選定と同じくらい大事なのが、**Basic から Standard へは"上げられない"（作り直しになる）**という制約でした。安さだけで Basic を選ぶと後で移行コストを払うことになるので、将来像が見えているなら最初から Standard を選ぶ判断も十分ありです。カタログの機能比較だけでなく、「自分のやりたい制御」と「将来の伸びしろ」の両面から選んでもらえればと思います。
注意事項
本ブログに掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。