みなさん、こんにちは。ネットワールドでSA（ソリューションアーキテクト）として活動している後藤です。
MicrosoftのAzure Local は「Azureのサービス」として提供されています。この話は「いい加減聞き飽きた」と言われるかもしれませんが、オンプレミスに置かれる「Azureのサービス」なので、オンプレミス製品とは異なる視点で気を付けなければならない部分があります。
それが「Azureとの通信」です。
Azure Localはそのサービス仕様上Azureと接続している必要があり、とくにAzure Local 23H2以降のAzure Arc VM管理でAzureポータルからAzure Local上の仮想マシンをコントロールする場合には、Azureポータルからの操作内容がAzure Local上のリソースブリッジを介してオンプレミスのAzure Localに転送されるので、高頻度でAzureとリソースブリッジ間で通信が発生します。
以前から以下URLの通り「Azureとの同期通信のために30日に1回はかならずAzureに接続する必要がある」とは言われていて、現在も最低30日に1回はAzureと通信しないと機能制限モードに移行するのは変わりませんが、最近はAzure ArcによるAzure側に管理機能を寄せていった結果、常時接続が必要といっても差し支えない状態ですね。
こうなると大変なのが、通信帯域の管理もそうですが、今回の主題であるインターネット通信の疎通要件の管理（通信先のURL管理）ではないでしょうか。
Azure Localで必要なインターネット通信要件は以下のMicrosoftのドキュメントにまとまってますので、ご一読ください。
Azure Local単体でみると、リソースを作成するリージョンごとに通信許可をしなければならないURLが微妙に異なっていて、例えば東日本リージョンの場合は以下のドキュメントになります。
URLとしては執筆時点（2025年7月中旬）で全部で103個になってます。
これ以外にもOEMメーカーによっては追加で必要な通信要件がありますし、さらにAzure MonitorやAzure Site RecoveryといったAzureサービスを併用する場合は、それらのサービスごとの通信要件が追加になります。
OEMメーカー用の通信要件や併用するAzureサービスの通信要件はさておき、Azure Localを運用するためにで103もの通信先を管理しなければならない、しかもGithubのリストの履歴を見ていると微妙に更新がかかっている、というのは管理コスト的に考えても厳しいと言わざるを得ないですね。
この103もの通信先をある程度絞り込んでくれるサービスが、今回ご紹介する「Azure Arcゲートウェイ」になります。
- 1：最初に注意事項と免責事項
- 2：Azure Arcゲートウェイとは
- 3：Azure Arcゲートウェイの作成
- 4：Azure Arcのセットアップ
- 5：Azure Localのデプロイ
- 6：Azure Localのデプロイ（追加検証）
- 7：プロキシログの解析
- 8：最後に
1：最初に注意事項と免責事項
本記事で取り扱っている「Azure Arcゲートウェイ」は、執筆時点（2025/07中旬）でパブリックプレビューの機能になります。
執筆時点の情報になりますので、もしかしたら明日には仕様が変更されているかもしれません。最新の情報はMicrosoftの公式ドキュメントをご参照ください。
また、本記事に従って作業を行って発生した問題について、弊社は責任を負いかねますので、自己責任でお願いします。
2：Azure Arcゲートウェイとは
Azure Arcゲートウェイとは、前述の通りAzure Localのデプロイと管理で必要な通信要件（通信先エンドポイント）を大幅に削減してくれるサービスになります。
どのくらい削減してくれるかというと、Azure Arcゲートウェイを設定した後に要求されるURLは次のリンクの通り執筆時点（2025年7月中旬）で28個です。
そのうち4つはAzure Local 2504の新しいデプロイ（つまり24H2のAzure Localを新規デプロイする場合）には不要、とのことなので、103のURLを実質24個のURLまで削減してくれます。76％削減です、すごいですね。
どうやって実装してるの？ ですが、Azure Arcゲートウェイは2つのサービスとコンポーネントから構成されます。
- Arc ゲートウェイ リソース
サービスとしてAzure上に作成され、<Azure ArcゲートウェイのID>.gw.arc.azure.comのURLになります。 - Azure Arc プロキシ
サービスとしてAzure Localノードで実行されます。
Azure Arc エージェントと拡張機能の転送プロキシとして機能します。
Azure ArcエージェントにAzure Arcゲートウェイが設定されると、AzureArcエージェント並びに機能拡張のAzure通信は、まずAzure Arcプロキシに通信を行うよう変更されます。
転送プロキシとして機能しているAzure Arcプロキシが通信先を識別し、Azure Arcゲートウェイ経由でアクセス可能なAzureリソースにはAzure Arcゲートウェイに、それ以外には直接アクセスするよう、振り分けを行います。
なお、Azure Arcプロキシに対して企業内プロキシを設定することも可能で、Azure Arcプロキシのトラフィックを直接インターネットへ流すこともできれば、すべてのトラフィックを企業内プロキシへ転送することも可能です。
プロキシを使用する場合、本来であれば、Azure Arcの通信だけではなく、Azure Localの管理インターフェースからでる通信、前述の24個のURLのHTTP/HTTPS通信もプロキシを経由させるべきでは？ というのがごもっともな疑問です。
この辺りも確認していますので、以下の項でご確認ください。
3：Azure Arcゲートウェイの作成
Azure Arcゲートウェイの有効化には2つのステップがあります。
- Azureポータルで「Azure Arcゲートウェイ」を作成
- Azure LocalノードのAzure Arcセットアップ。その際、Azure ArcゲートウェイのリソースIDを指定して実行
まずは、Azure Arcゲートウェイの作成を実施したいと思います。
Azure ArcゲートウェイはAzureポータルのAzure Arcのページから作成します（図1）。
「Azure Arcゲートウェイの作成」をクリックし、設定画面にて作成先のサブスクリプションとリソースグループ、Azure Arcゲートウェイの名前と作成先リージョンを指定するだけで作成完了です（図2）。
デプロイは5分程度で完了します。
出来上がったAzure Arcゲートウェイがこちらです（図3）。
「ゲートウェイのURL」に欄に記載されているURLが、疎通許可を行うURLになります。nslookupで調べてみると、トラフィックマネージャーで負荷分散されているようですね。最終的なホストはmsedge.netのドメイン名を持つホストで、IPアドレスはMicrosoft所有IPアドレスです（図4）。Azureのサービスなので当然ですね。
これで、Azure Arcの通信をAzure Arcゲートウェイ経由にする準備が整ったので、実際にAzure Arcをセットアップしてみましょう。
4：Azure Arcのセットアップ
前々項でも解説した通り、Azure Arcプロキシは企業内プロキシを指定することができます。使わないことも可能です。
普通にセットアップしても面白くないので、今回は以下のような構成でセットアップしてみます（図5）。
Azure IaaSに仮想マシンでプロキシをたてて、Azure Arcセットアップ時にそのプロキシを指定します。
図4で確認した通り、Azure ArcゲートウェイはAzureのIPを持っていますので、Azure上からのアクセスであればインターネットを通ることなく、Azureのネットワーク内で完結します。これにより、Azure外のネットワークにAzure Localのトラフィックを送信する機会を減らすことができます。
「プライベートリンクを使えばプロキシもいらないのでは？」と思われる方もいらっしゃるかもしれませんが、執筆時点（2025年7月中旬）で以下のドキュメントに「Azure ローカルに必要なパブリック エンドポイントにアクセスできないため、Azure Express Route と Azure Private Link は、Azure Local またはそのコンポーネントではサポートされていません。」と記述されており、Azure LocalはプライベートリンクやExpressRouteをサポートしていません。そのため、インターネット経由での接続が必須になっています。
余談ですが、完全なる閉域網で運用したい場合には、Azure Localのセットアップ方法の一つである「ディスコネクテッド オペレーション」を選択する必要があります。
これを利用することで、オフライン環境でAzure Localを運用することができますが、ディスコネクテッド オペレーションは執筆時点でプレビュー機能であり、またプレビュー参加にも高いハードルが設定されています。
筆者も検証できていませんので参考情報です。
話を戻すと、今回のプロキシサーバーはAzure IaaSでUbuntuの仮想マシンを構築し、squidを導入してプロキシサーバーとしました。お手軽な感じのものにしたので、細かい設定はしていません。待ち受けポート番号は8080/TCPとしました。
では、Azure Arcのセットアップを行います。
Azure Localのセットアッププロセスの中では、Azure Arcのセットアップは最初期に実施します。まずはAzure LocalのホストをAzure Arcに接続して、AzureポータルからAzure Localのデプロイを実施する、というステップなので、Azure Stack HCI OS導入後に実施する作業、つまりは「Invoke-AzStackHciInitialization」コマンドレットを実行するステップですね。
当該コマンドレットに対して、「-ArcGatewayID」オプションでAzure ArcゲートウェイのリソースIDを、「-Proxy」オプションでプロキシサーバーのURLを、「-ProxyBypass」オプションでプロキシサーバーをバイパスするURLのリストを指定して実行する、という流れになります。
ここで重要なのが、実は「-ProxyBypass」オプション指定するプロキシを通過させない通信先の指定、になります。
プロキシのバイパスリストを指定しなくても「Invoke-AzStackHciInitialization」コマンドレットはエラーを出力することなく完了します。が、Azure Localノード間やクラスター通信などはプロキシを通すべきではありません。したがって、最低限「Azure Localのノード」「クラスターIP」「ローカルホスト」「ローカルドメイン名のホスト」は除外すべきでしょう。
この辺りは、Microsoftドキュメントにもバイパスリストの例として挙がっていますので、参照してみてください。
上記のドキュメントのスクリプトに従ってAzure Arcのセットアップを実施します（図6）。
「Invoke-AzStackHciInitialization」コマンドレット実行時に、Azure Arcゲートウェイ用のオプションを付けて実行していることが確認できます。また、それぞれのオプションで設定している内容についても、図6の変数にて確認できると思います。
こちらでAzure Arcの設定はすんなり完了すると思います。
実際の設定内容については、Microsoftのドキュメントの通り「arcagent show」コマンドや「arcagent check」コマンドで確認できると思います。詳細は割愛しますが、「arcagent show」コマンドでAzure Arc Proxyサービスが実行中であることが確認できます。
ここまではドキュメントに書いてある通りなのですが、ちょっと突っ込んで設定を見てみたいと思います。
Azure Arcのセットアップが終わった環境でAzure上のプロキシサーバーのログを見ていると、Azure Arcゲートウェイ宛の通信以外もプロキシを通過していることがわかります（図8）。
ということは、どこかでプロキシの設定がされているということですね。実際に環境を確認してみると、WinHTTPと環境変数にプロキシの設定が入っていることが確認できました（図9）。
これであれば、確かにほとんどの通信がプロキシ経由になるのも理解できます。
5：Azure Localのデプロイ
この状態でAzure Localのデプロイを実行してみると、通常通りデプロイが成功しました。当たり前といえば当たり前ですね。
では、デプロイ中にどのような通信が発生していたかを確認してみます。
インターネット接続ファイアウォールは、Azure Localのノードを送信元とするインターネット接続について、あえてdenyにはせず、permitの状態ですべての通信ログを出力するように設定しました。
その結果、ほとんどの通信はプロキシ経由であることが確認できたのですが、以下の通信においてはAzure Localノード、もしくはリソースブリッジから直接インターネットへ疎通していたことが確認できました。
| アクセス元 | アクセス先ホストアドレス | プロトコル |
|
Azure Localノード |
azurestackreleases.download.prss.microsoft.com |
https |
|
Azure Localノード |
msk8s.sb.tlu.dl.delivery.mp.microsoft.com |
https |
| Azure Localノード |
time.windows.com |
NTP |
| リソースブリッジ |
usage.projectcalico.org |
https |
| 表1：Azure Localデプロイ中に発生した直接通信 | ||
「azurestackreleases.download.prss.microsoft.com」は、デプロイ処理の中にここからファイルをダウンロードしてました。重要なアクセス先ですね。
なお、当該通信は図10のようにBITS（バックグラウンド インテリジェント転送サービス）プロセスが送信元プロセスであるため、Azure Arcゲートウェイのhttpsプロキシ設定が適用できないのかを追加確認する必要があります。
「usage.projectcalico.org」については、Azure Localのアクセス先一覧の中に含まれていないホスト名でした。
このホスト名はログを取得していたファイアウォール上での名前解決の結果であり、CNAMEが設定されている可能性もあるので、追加検証が必要です。
time.windows.comへのアクセスについては、確かにアクセス先一覧に含まれているものの、NTPサーバーを設定していればアクセスは発生しないかな、とも思ったのですが、ホスト再起動等のタイミングでアクセスが発生していました。こちらも閉塞して問題ないかを確認する必要がありますね。
上表には入れませんでしたが、他にMicrosoft Defenderのサイト（wdcp.microsoft.com）へのアクセスなどもありました。
6：Azure Localのデプロイ（追加検証）
インターネット接続ファイアウォールで、Azure Localの関連IPアドレスを送信元としたインターネット通信をすべて遮断し、IPSecトンネルしか通過できないようにポリシーを変更して、再度デプロイしてみました。
最初期から遮断すると、当然のことながら「Invoke-AzStackHciInitialization」コマンドレットを実行する前の「Connect-AzAccount」コマンドレットもアクセス制限で正常終了しません（プロンプトに戻らず、Ctrl+Cで強制終了する必要あり）。
したがって、PowerShellコマンドレット実行時にプロキシ設定が必要なので、以下のドキュメントに従ってプロキシを設定します。
このドキュメントに従ってWininetに対してプロキシ設定を行うことで、PowerShellの通信がプロキシ経由になりますが、この設定を行うコマンドレットである「Set-WinInetProxy」コマンドレットのインストール時に、ちょっとひねりを加える必要があります。
具体的には以下の手順が必要になります。
- Register-PSRepositoryコマンドレットでPSGalleryを登録
- Install-ModuleコマンドレットでWinInetProxyモジュールをダウンロード
両コマンドレットともにインターネット上のサイトからファイルをダウンロードしてくる挙動のため、それらのコマンドレットに対してプロキシ設定を与えてあげる必要があり、両コマンドレット実行時のオプションで「-Proxy」オプションが存在するので、そちらを付与して実行します。
具体的なコマンドレット例としては、本環境では以下のようなものになります。
Register-PSRepository -Default -InstallationPolicy Trusted -Proxy http://10.1.254.4:8080
Install-Module -Name WinInetProxy -Proxy http://10.1.254.4:8080
Set-WinInetProxy -ProxySettingsPerUser 0 -ProxyServer http://10.1.254.4:8080 -ProxyBypass "localhost;127.0.0.1;*.<ドメイン名>;AzHost21;AzHost22;192.168.*.*;AzStackHCI20"こちらを実行した結果が図11になります。
これでWinInetへのプロキシ設定が完了しましたので、AzureへのサインインとArc Arcのセットアップがプロキシ経由になりました。
以降は「4：Azure Arcのセットアップ」と同じ手順でAzure Arcのセットアップ、およびAzure Localのデプロイを実施します。
Azure Arcのセットアップ、並びにAzure Localのデプロイは問題なく完了するため、Azure Localから直接インターネットへ疎通許可を行うことなく、Azure Arcゲートウェイの設定だけでも問題ないことが確認できました。
インターネット接続ファイアウォールのログをみると、「azurestackreleases.download.prss.microsoft.com」への直接アクセスを試みているもののアクセスできず、その後プロキシ経由でのダウンロードトラフィックが発生しているので、「直接アクセスして、不可であればプロキシ経由」というような順番でファイルダウンロードを試みているように見えます。であれば、直接アクセスの試行はできれば止めてほしいと思います。
また、time.windows.comへのNTPアクセスも記録されていますが、時刻同期は内部ネットワーク内のNTPサーバーと同期しているので、アクセスできなくても問題ないと思われます。
この辺りは今後のAzure Arcゲートウェイのアップデートに期待ですね。
他、プロキシ経由でアクセスしているURLについても次項にて触れていますので、そちらでご確認ください。
7：プロキシログの解析
Azure Localのデプロイが完了した際のプロキシのアクセスログ（21470件）を精査すると、ほぼAzure Arcゲートウェイへの通信が占めており（16948件なので78.9%）、またドキュメントに記載のあった「Azure Arcゲートウェイにリダイレクトできない」通信としてあげられていたURLへのアクセスが確認できました（23URL合計で3006件なので14％）。
今回展開したAzure Localは2506なのですが、なぜか「2504 の新しいデプロイ以降は必要ありません。」と記述されているURLに対してもアクセスが発生しており（3URL合計で76件なので0.35%）、これが仕様なのか、アクセスできなくても問題ないのかは、要切り分けですね。
それ以外にも、数は少ないもののAzure Localのファイアウォール疎通要件にあげられていたURLに対しても若干数アクセスが発生していました（21URL合計で455件なので2.1％。ほとんどが1桁から2桁の前半なのですが、2URLでそれぞれ146件発生）。
それらについてはアップデートによって改善されるのか、それともアクセスできなくても問題ないのかについては、今後確認する予定です。
それ以外はいわゆる「ネットワーク接続インジケーター」へのアクセスや、インターネット疎通確認のためでしょうか、「www.bing.com」へのアクセスが確認されましたが、このあたりについても閉塞して問題ないかは今後確認する予定です。
8：最後に
Azure Arcゲートウェイによって、接続先として管理すべきURLが格段に減っているのは確認できました。
プレビュー機能だからでしょうか、想定されていたアクセス先よりも多い数のURLへアクセスしていたのが気になります。
この辺りは、GAまでに改善されることを期待します。
このAzure Arcゲートウェイは、Azure Localだけではなく、Azure Arc で有効になっている Azure Kubernetes Service （AKS）などでも使用できるので、一度評価してみてはいかがでしょうか？
書いた人：後藤 諭史（Satoshi GOTO）
ソリューションアーキテクト部所属。
専門はWindows Server Hyper-VやAzure LocalといったMicrosoft仮想化技術。Microsoft SDN（Hyper-V Network Virtualization）などのWindows Server ネットワーク技術も。
Microsoft オンプレ技術以外にも、エンタープライズネットワークとかMicrosoft Azureとか、運用とか。
ネットワークやハードウェアといった物理層に近いところが大好きな、昔ながらのインフラ屋さん。得意技はケーブル整線。
Microsoft MVP for Cloud and Datacenter Management（2012-2026）
Microsoft MVP for Microsoft Azure（2024-2026）
