1.はじめに

株式会社NTTデータ九州公共システム事業部公共ビジネス統括部の田中です。
私は主にMicrosoft Azureクラウド基盤を用いたシステムの導入、維持保守を担当しております。

本記事では、Azure FirewallとExpressRouteを利用して、Microsoft Azure上のWebシステムとお客様閉域網を接続した際の設計・検証内容を紹介します。
特に、Azure Firewallによる通信制御を実現するためのRoute Table設計と、ExpressRoute利用時に考慮すべき通信経路のポイントについて解説します。

縁あって、「とあるWebシステム」とお客様閉域網を接続するお仕事を担当することになりました。
「とあるWebシステム」はMicrosoft社のMicrosoft Azureクラウド基盤上で動作しており、（1）プライベート領域の閉域網とクラウドのパブリック網をどのように接続するか、（2）所在のわかっている閉域網とはいえ不特定多数の人が接続するため一定のセキュリティ確保が必要、（3）既存のWebシステムの構成にできるだけ影響を与えないようにすることが要件としてありました。

2.構成概要

（1）に対しては、閉域網をオンプレ領域とみなして、ExpressRouteの導入を行うことで通信品質とセキュリティを確保しました。
（2）に対しては、主に閉域網の前面にAzure Firewallを配置する、NSG、後述するプロキシサーバのACLでアクセス制御することとしました。
（3）に対しては、既存システムとの間に別に仮想ネットワークを準備し、通信の中継としてプロキシサーバを配置することで既存システムの構成変更を最小限に抑える方針としました。
ざっくりとした構成図としては以下の通りです。
本記事のIPアドレスおよびネットワーク構成例は説明用に簡略化しています。

3.検討時に苦労した点

Azureは世界3大クラウドの1つであり、情報も豊富であるため、比較的容易に情報を収集できると考えていました。
ところが実際に調べてみると思ったより情報が少なく、外側からの通信をAzure Firewallを用いて制御する方法や構築例の情報はインターネット上にはあまりありませんでした。
このような構成であれば、参考情報が多く公開されていると考えていましたが、なかなか見つかりませんでした。
きっと私が見つけきれなかっただけです。とは言え、設計期間が限られていたため、早期に検証を進める必要がありました。
まずは検証を進めようと考え、試行的に構築を開始しました。リソース自体のセットアップにはあまり苦戦することはありませんでしたが、例えば外からの通信を模擬したクライアントVMからプロキシサーバを模擬したInternet Information Services（IIS）サーバにアクセスする、その際、クライアントVMからIISサーバへのアクセスにおいてはAzure Firewallでフィルタリングする、という単純構成を試してみました。これがうまくいきませんでした。

4.解決策とその他の問題点

ポイントとしては、以下の通りです。
Azure Firewallは通信経路上に自動的に配置されるものではなく、フィルタリングしたい通信をAzure Firewall側に向けてあげる必要があります。オンプレミスの場合だと通信の出入り口にあるもの（意図的にそうするもの）、なので意識することはありませんが、クラウドの場合は異なり、ここはクラウド初心者だと場合によっては苦労するところかと思います。
これをどう解決するかというと、Route Tableというリソースが重要になります。本リソースはサブネットに紐づけるものですが、宛先に対してネクストホップを指定することができます。平たく表現すると、サーバのIPアドレスレンジに通信したい場合は、Azure Firewallを経由するよう定義できるということです。
実際には、以下のような設定になります。

ルート定義情報	値	説明
仮想ネットワーク	Virtual Network1	Route Tableを設定する対象のサブネットが所属する仮想ネットワークを選択します。
サブネット	GatewaySubnet	Route Tableを設定する対象のサブネットを選択します。今回のポイントです。
宛先IPアドレス	192.168.1.0/27	192.168.1.0/27はServerSubnetになります。プロキシサーバにアクセスする場合を定義しています。
ネクストホップの種類	仮想アプライアンス	Azure Firewallを経由したい場合は、仮想アプライアンスを選択します。
ネクストホップアドレス	192.168.1.132	Azure FirewallのプライベートIPを指定します。

このように、Azure Firewallを構成する場合は、Route Tableが必要になるケースがあることにご注意ください。

安心したのも束の間で、Route Tableを構成する場合は、通信元がどこになるかに特に注意する必要があります。特に外側から通信がくる場合、その通信元はどこになるのかという点です。
これについては、ExpressRouteを用いた場合の通信経路を少し理解しておく必要があります。
クライアントVMからIISサーバへのアクセスのようなMicrosoft Azure内で完結している単純構成であれば、クライアントVMが所属するサブネットにRoute Tableを紐づければよいだけです。しかし、今回のようにMicrosoft Azure外から通信がくる場合はどうなるのでしょうか。一見すると疑問に思われるかもしれませんが、外からの通信はExpressRouteを通ってきます。仮想ネットワークとの接点としては、仮想ネットワークゲートウェイが担います。
今回の構成では、ExpressRouteから到着した通信は仮想ネットワークゲートウェイを経由して仮想ネットワークへ入ってきます。そのため、通信をAzure Firewallへ誘導するためには、入口となる経路を意識したRoute Table設計が必要でした。私は当初、サーバ側サブネットだけを意識していましたが、ExpressRoute接続では仮想ネットワークゲートウェイ側から見た通信経路も考慮する必要がありました。
言葉で表現すると簡単ですが、設計時に机上で辿り着くのは少し苦労しました。

その他、Azure Firewallを構成する仮想ネットワークのサブネット設計は特に机上で入念にやっておくことをお勧めします。構成要素が多めで手戻りになる可能性があるためです。
私の場合だと、サーバ所属サブネットに/27、GatewaySubnetに/27、AzureBastionSubnetに/26、Azure Firewall Subnetに/26としました。
GatewaySubnetについては、Microsoft公式ドキュメントでも/27以上のアドレス空間が推奨されています。本検証では試験的に/28で構成したところ、仮想ネットワークゲートウェイのデプロイ時にサブネットサイズ不足により失敗しました。そのため、本構成では/27を採用しました。
VPN Gateway FAQ

Azure Firewall Management Subnetサブネットのように使う機能（強制トンネリング等）によってサブネット構成が変わる場合があることに注意してください。
→私の場合だと、Azure Firewall Management Subnetは使用しませんでした。ただし、Azure Firewall SubnetとAzure Firewall Management Subnetは分離することが推奨されていますので、分離するか、分離する場合においては各サブネットのアドレス範囲が仮想ネットワークのCIDR範囲内に収まるかを設計しておく必要があります。この点について、やや話がそれますが、Azure FirewallのSKUで何を選択するかで、Azure Firewall Management Subnetが必要か否かも変わります。
Basicを選択すると必須になる場合もあり、SKUの選択基準はこちらをご参照ください。
Azure Firewall SKU の選択基準
私の場合は、通信要件からStandardを選択しております。

SKUに何を選択するかは細かい話のようで、Azure Firewallにおいては実はサブネット構成のような設計の根幹部分に関わるため、早めに決める必要があります。

5.おわりに、学んだこと

今回の構築で特に重要だと感じたのは以下の3点です。

Azure Firewallは配置しただけでは通信を制御できない
Route Tableによる経路制御が重要
ExpressRoute利用時は、通信がどこから仮想ネットワークへ入ってくるかを意識する
オンプレミス環境ではファイアウォールが通信経路上に配置されることが多いため意識しませんでしたが、Azureでは通信経路を明示的に設計する必要があります。
特にAzure FirewallとRoute Tableはセットで考えるべきだと感じました。

ということで、ExpressRoute等あまり頻出するサービスリソースではないことや、Azure FirewallやRoute Tableなどを組み合わせて通信環境を構築しないといけない方向けに参考となる情報となりましたら、筆者としては大変うれしく感じます。私が悩んだ時期にこんな情報があれば少しでも助かっただろうなという想いで執筆しました。
ExpressRouteやAzure Firewallは非常に安定し高品質のリソースであり、サービス開始後もトラブルは起きていません。おすすめですので、機会がありましたら是非設計に組み込むことをご検討ください。

【執筆日・免責事項・前提条件】

【執筆日】2026年9月1日

【免責事項】本記事は執筆時点の情報に基づいています。サービス仕様や推奨構成は変更される場合がありますので、最新情報はMicrosoft公式ドキュメントをご確認ください。

【前提条件】検証環境・Microsoft Azure ・Azure Firewall Standard ・ExpressRoute利用