Azure Arc Gatewayは、Azure Arcを使うために必要な送信先エンドポイントを減らし、企業プロキシやファイアウォール配下のサーバーをAzure Arcへ接続しやすくする仕組みです。特にAzure Arc-enabled serversでは、従来のように多数のFQDNを個別に許可するのではなく、主要な通信をAzure Arc Gateway経由にまとめられる点が大きな変更です。Microsoftの公式ドキュメントでは、企業プロキシで送信トラフィックを管理している環境でも、Azure Arc Gatewayを使うことで7つのFQDNを許可する形でオンボードできると説明されています。(Microsoft Learn)
ただし、「Azure Arc Gatewayを入れれば、すべてのAzure Arc関連通信が自動的に解決する」と考えるのは危険です。Azure Monitor Agent、Key Vault証明書同期、Microsoft Defender、Windows Update関連など、利用する拡張機能やサービスによっては追加の許可設定が必要です。管理者は、エンドポイントの削減効果だけでなく、既存プロキシ、TLS検査、Connected Machine agentのバージョン、移行手順、検証コマンドまで確認してから展開する必要があります。(Microsoft Learn)
Azure Arc Gatewayで何が変わるのか
Azure Arc Gatewayの目的は、Azure Arcに接続するためのネットワーク構成を簡素化することです。オンプレミスサーバー、他社クラウド上の仮想マシン、分離されたネットワークセグメントなどをAzure Arcで管理する場合、通常はAzure側の複数エンドポイントへの送信通信を許可する必要があります。
Azure Arc Gatewayを使うと、Azure Connected Machine agentの通信が次のような経路になります。
Azure Arc agents → Azure Arc proxy → Enterprise proxy → Azure Arc Gateway → Target service
Azure Arc GatewayはAzure上の共通フロントエンドとして機能し、Azure Arc proxyはAzure Arcエージェント側に追加されるプロキシコンポーネントです。Azure Arc proxyはサービスとして動作し、Azure Arcエージェントや拡張機能が利用します。利用者側でAzure Arc proxyを個別に細かく構成する必要はありません。(Microsoft Learn)
| 観点 | 従来の構成 | Azure Arc Gateway利用時 |
|---|---|---|
| ファイアウォール設定 | Azure Arc関連の複数FQDNを個別に許可 | Azure Arc Gatewayを中心に許可先を整理 |
| プロキシ運用 | サービスごとの通信先を追跡しやすいが、許可リストが増えやすい | 通信経路を集約しやすい |
| 監査 | プロキシやファイアウォール側で個別に確認 | Azure Arc Gateway経由の通信をAzure Arc proxyログで確認しやすい |
| 注意点 | エンドポイント管理が煩雑 | 拡張機能によっては追加エンドポイントが必要 |
実務上のメリットは、単に「FQDNが減る」ことではありません。ネットワークチーム、Azure管理者、セキュリティ担当者が同じ通信経路を前提に設計・監査・トラブルシュートできるようになる点が重要です。
対象になる環境と優先度
Azure Arc Gatewayの影響を受けやすいのは、次のような環境です。
| 対象 | 確認すべき理由 |
|---|---|
| 企業プロキシで送信通信を制御している環境 | 許可するFQDNを整理できる可能性がある |
| ファイアウォールの変更申請が厳格な環境 | ネットワーク変更の範囲を小さくできる |
| Azure Arc-enabled serversを大量に管理している環境 | リージョンごとのGatewayリソース数や負荷設計が必要 |
| Azure Arc拡張機能を使っている環境 | 追加エンドポイントが必要になる場合がある |
| TLS検査を行っている環境 | Azure Arc GatewayエンドポイントのTLS検査除外が必要になる可能性がある |
| Connected Machine agentを古いまま運用している環境 | Gateway連携や検証手順がバージョンにより異なる |
逆に、すでにAzure Arc用のネットワーク要件を満たしており、プロキシやファイアウォールの運用負荷が小さい環境では、すぐに導入する必要性は低い場合があります。導入判断では、「通信先を減らせるか」だけでなく、「運用上の変更が増えないか」「既存の監査要件に合うか」を見るべきです。
Azure Arc Gatewayで許可が必要になる主なFQDN
Azure Arc Gatewayリソース作成後は、GatewayのURLと、Azure Arc接続に必要なFQDNをネットワーク側で許可します。Microsoft Learnでは、必要URLの一覧が最近更新されたため、以前に設定済みの環境でも再確認するよう案内されています。(Microsoft Learn)
| 許可する項目 | 用途 |
|---|---|
<Your URL prefix>.gw.arc.azure.com | 作成したAzure Arc GatewayのURL |
management.azure.com | Azure Resource Managerの制御チャネル |
login.microsoftonline.com | Microsoft Entra IDのトークン取得 |
<region>.login.microsoft.com | リージョン別のMicrosoft Entra ID関連エンドポイント |
gbl.his.arc.azure.com | Azure Arcエージェントとクラウドサービスの通信 |
<region>.his.arc.azure.com | Azure Arcのコア制御チャネル |
packages.microsoft.com | LinuxサーバーをAzure Arcへ接続する際に必要 |
download.microsoft.com | Windows用インストールパッケージのダウンロード |
ここで注意したいのは、「7つのFQDN」という説明と、実際の許可項目の表現が必ずしも1行1FQDNではないことです。たとえばMicrosoft Entra ID関連ではグローバルとリージョン別のエンドポイントが並びます。実際のファイアウォール申請では、公式ドキュメントの最新表を基準に、環境ごとのリージョン値を埋めて確認してください。
追加エンドポイントが必要になるケース
Azure Arc GatewayはAzure Arc-enabled serversの接続要件を大きく簡素化しますが、すべての拡張機能や関連サービスの通信を完全に置き換えるものではありません。Microsoftは、利用するシナリオによっては追加エンドポイントの許可が必要になると説明しています。(Microsoft Learn)
| シナリオ | 追加許可の考え方 |
|---|---|
| SSH Arc | 追加エンドポイント不要とされるシナリオ |
| Extended Security Updates | 追加エンドポイント不要とされるシナリオ |
| Azure Extension for SQL Server | 追加エンドポイント不要とされるシナリオ |
| Azure Arc-enabled data services | *.ods.opinsights.azure.com、*.oms.opinsights.azure.com、*.monitoring.azure.comなどが必要 |
| Azure Monitor Agent | Log AnalyticsワークスペースIDに紐づくエンドポイントが必要 |
| Azure Key Vault certificate sync | 対象Key Vaultのエンドポイントが必要 |
| Azure Automation Hybrid Runbook Worker extension | *.azure-automation.netが必要 |
| Windows OS Update Extension / Azure Update Manager | Windows Update側の前提条件を満たす必要がある |
| Microsoft Defender | Microsoft Defender側の前提条件を満たす必要がある |
よくある失敗は、「Azure Arc Gatewayを設定したので、Azure Monitor AgentやDefender関連の許可は不要」と判断してしまうことです。Azure Arcの基本接続、監視、セキュリティ、更新管理は、それぞれ必要な通信先が異なります。導入前に、実際に使っている拡張機能を棚卸ししてください。
Azure Arc Gatewayの制限事項
Azure Arc Gatewayには、設計時に必ず確認すべき制限があります。
| 制限・注意点 | 実務での確認ポイント |
|---|---|
| サブスクリプションごとにAzure Arc Gatewayリソースは5個まで | 大規模環境ではリージョン別・用途別に設計が必要 |
| Azure public cloudでの接続に使われる | Government、21Vianetなどの利用では公式要件を別途確認 |
| TLS終端・TLS検査が必要な環境には推奨されない | GatewayエンドポイントをTLS検査から除外できるか確認 |
| 拡張機能によっては追加エンドポイントが必要 | Azure Monitor、Defender、Automationなどの利用有無を確認 |
| Gateway解除後は通常のAzure Arcネットワーク要件が必要 | 切り戻し時の通信要件を事前に準備 |
特にTLS検査は重要です。Azure Arc GatewayではAzure Arc proxyとAzure Arc Gatewayの間にTLSセッションが確立され、その内部で宛先サービスへの接続が転送されます。標準的なTLS終端プロキシでは内側の暗号化通信を通常どおり検査できないため、MicrosoftはAzure Arc Gatewayエンドポイントに対してTLS検査をスキップすることを推奨しています。(Microsoft Learn)
2026年5月時点で注目すべきConnected Machine agent 1.64の変更
Azure Arc Gatewayを使う環境では、Azure Connected Machine agentのバージョン確認も重要です。2026年5月版のConnected Machine agent 1.64では、Arc Gateway bypass list supportが追加されています。これは、構成したFQDNをAzure Arc Gateway経由ではなく、顧客側のエンタープライズプロキシまたは直接接続へ迂回させるための機能として説明されています。(Microsoft Learn)
この変更は、ネットワーク設計上かなり重要です。たとえば、次のようなケースで検討対象になります。
| ケース | bypass listを検討する理由 |
|---|---|
| 一部のFQDNは社内プロキシで監査したい | Gatewayに集約しすぎると既存ログ設計と合わない場合がある |
| 特定のエンドポイントだけ直接通信させたい | 遅延、経路、検査ポリシーの都合で分けたい場合がある |
| 拡張機能ごとに通信経路を分けたい | 監視、セキュリティ、更新管理で要件が異なる場合がある |
| 既存のプロキシ例外設定を活かしたい | 全面移行ではなく段階移行しやすくなる |
一方で、Azure Arc Gatewayの公式ページには、Azure Arc Gateway利用時のproxy bypassに関する制限も記載されています。ドキュメントの更新タイミングやエージェントのバージョンによって扱いが変わる可能性があるため、実際にbypass listを使う場合は、対象サーバーのagentバージョン、azcmagent config infoで確認できる設定項目、azcmagent checkの結果を必ず確認してください。(Microsoft Learn)
Azure Arc Gatewayリソースの設計ポイント
Azure Arc Gatewayを本番展開する前に、Gatewayリソースの数、配置、権限を決める必要があります。
リージョン選択は「通信の近さ」ではなく管理プレーンの配置
Azure Arc Gatewayはグローバルサービスとして動作し、実行時の接続はAzure Front Doorのグローバルエッジネットワーク経由でルーティングされます。Gateway作成時に選ぶリージョンは、Gatewayリソースと管理メタデータが存在する管理プレーンの場所を決めるものであり、実行時の接続先やパフォーマンスを直接制限するものではありません。(Microsoft Learn)
そのため、リージョン選択では次を基準にすると判断しやすくなります。
| 判断基準 | 具体例 |
|---|---|
| 運用チームの管理単位 | Japan Eastで管理するAzureリソースが多い |
| RBAC・ポリシーの適用範囲 | 特定リージョンのリソースグループに集約したい |
| データ所在地・社内標準 | 管理メタデータの配置を社内ルールに合わせたい |
| 障害時の運用 | 誰がどのGatewayを管理するか明確にしたい |
「日本のサーバーだからJapan EastのGatewayにしないと遅くなる」と短絡的に判断する必要はありません。むしろ、管理責任と運用ルールに合わせて決めるのが現実的です。
Gatewayリソース数は規模で決める
Azure Arc-enabled serversのみを対象にする場合、Microsoftは1つのAzure Arc Gatewayリソースでリージョンあたり2,000リソースを扱えるという一般的な目安を示しています。複数種類のArc対応リソースを組み合わせる場合は、サーバー、Kubernetesクラスター、Azure Localインスタンスを含めた計算式で必要数を見積もります。(Microsoft Learn)
公式ドキュメントの考え方は次の式です。
Score = (Servers ÷ 20) + (Kubernetes clusters ÷ 10) + (Azure Local instances ÷ 10)| スコア | 判断 |
|---|---|
| 100未満 | そのリージョンでは1つのAzure Arc Gatewayリソースで足りる目安 |
| 100以上 | 複数のAzure Arc Gatewayリソースが必要になる目安 |
大規模環境では、「とりあえず1つ作る」のではなく、リージョンごとのArc対象リソース数を先に集計してください。サブスクリプションあたり5個の制限もあるため、将来の拡張を見越した設計が必要です。
新規オンボード時の設定手順
新しくサーバーをAzure Arcへ接続する場合は、Azure Arc Gatewayリソースを作成してからオンボードスクリプトを生成します。
Azure Arc Gatewayリソースを作成する
Azure Arc Gatewayリソースは、Azureポータル、Azure CLI、Azure PowerShellで作成できます。CLIで作成する場合は、まず拡張機能を追加します。(Microsoft Learn)
az extension add -n arcgatewayその後、Gatewayリソースを作成します。
az arcgateway create \
--gateway-name <gateway-name> \
--resource-group <resource-group> \
--location <location>作成後は、Gateway URLを確認し、ネットワークチームへ許可申請します。
az arcgateway listここで取得した<Your URL prefix>.gw.arc.azure.comが、ファイアウォールやプロキシ許可の対象になります。
オンボードスクリプトでGatewayを選択する
Azure Arc-enabled serversのオンボードスクリプトを生成するときは、Connectivity methodでPublic Endpointを選び、Gateway Resourceのドロップダウンで作成済みのAzure Arc Gatewayリソースを選択します。生成されたスクリプトには、Azure Arc GatewayリソースのAzure Resource Manager IDが--gateway-idとして含まれます。(Microsoft Learn)
ここで間違いやすいのは、Private Endpointや既存の接続方式と混同することです。Azure Arc Gatewayを使う場合でも、オンボードスクリプトの生成画面では指定箇所を正しく選ぶ必要があります。既存の手順書を使い回している場合は、スクリーンショットやCLIテンプレートを更新してください。
既存のAzure Arc-enabled serversを移行する手順
すでにAzure Arcへ接続済みのサーバーも、Azure Arc Gatewayに関連付けられます。AzureポータルからGatewayリソースのAssociated resourcesに対象サーバーを追加する方法のほか、Azure CLIやAzure PowerShellでも設定できます。(Microsoft Learn)
Azure CLIの例は次のとおりです。
az arcgateway settings update \
--resource-group <resource-group> \
--subscription <subscription-name> \
--base-provider Microsoft.HybridCompute \
--base-resource-type machines \
--base-resource-name <server-name> \
--gateway-resource-id <gateway-resource-id>Connected Machine agentのバージョンにも注意が必要です。agent 1.50以前では、Gatewayを使うために次のコマンドも実行する必要があります。agent 1.51以降では、この操作は自動的に行われると説明されています。(Microsoft Learn)
azcmagent config set connection.type gateway実務では、移行前に対象サーバーのagentバージョンを一覧化し、1.50以前のサーバーを別グループに分けるのが安全です。古いサーバーを混ぜたまま一括移行すると、一部だけGateway経由にならず、原因調査に時間がかかります。
設定後の検証方法
Azure Arc Gatewayは、作成して関連付けただけでは完了ではありません。サーバー側で通信経路と到達性を確認します。
azcmagent showで状態を確認する
オンボード済みサーバーで次を実行します。
azcmagent show期待する状態は次のとおりです。
| 項目 | 確認内容 |
|---|---|
| Agent Status | Connectedになっている |
| Using HTTPS Proxy | http://localhost:40343が表示される |
| Upstream Proxy | 企業プロキシを設定している場合、その情報が表示される |
| Gateway URL | Azure Arc GatewayリソースのURLが反映されている |
Microsoftのドキュメントでは、Azure Arc Gateway設定後の検証としてazcmagent showとazcmagent checkの利用が案内されています。(Microsoft Learn)
azcmagent checkで到達性を確認する
次に、ネットワーク到達性を確認します。
azcmagent check確認すべきポイントは、connection.typeがgatewayになっていることと、必要URLのReachable列がtrueになっていることです。ここで失敗する場合、よくある原因は次のとおりです。
| 症状 | ありがちな原因 |
|---|---|
| Gateway URLに到達できない | ファイアウォールで*.gw.arc.azure.comが許可されていない |
| Entra ID関連で失敗する | login.microsoftonline.comまたは<region>.login.microsoft.comの許可漏れ |
| Linuxだけ失敗する | packages.microsoft.comが許可されていない |
| Windowsのインストールや更新で失敗する | download.microsoft.comが許可されていない |
| 一部拡張機能だけ失敗する | 追加エンドポイントの許可漏れ |
| プロキシ環境で不安定 | TLS検査、認証プロキシ、bypass設定の不整合 |
検証は、Azureポータル上の接続状態だけで終わらせないでください。サーバー上でazcmagent checkを実行し、実際の通信経路で成功しているかを確認することが重要です。
Azure Arc Gatewayのログ確認
通信の監査やトラブルシュートでは、Azure Arc proxyのログを確認します。Windowsではazcmagent logsをPowerShellで実行し、生成されるzipファイル内のProgramData\AzureConnectedMachineAgent\Logフォルダーにあるarcproxy.logを確認します。Linuxではsudo azcmagent logsを実行し、/var/opt/azcmagent/log/配下のarcproxy.logを確認します。(Microsoft Learn)
azcmagent logssudo azcmagent logsログ確認で見るべき点は、単にエラーの有無だけではありません。
| 見るポイント | 理由 |
|---|---|
| Gateway URLへ通信しているか | 想定どおりAzure Arc Gateway経由になっているか確認 |
| enterprise proxyの経路 | 社内プロキシを経由しているか確認 |
| 接続失敗の宛先 | 追加エンドポイントの許可漏れを特定 |
| TLS関連エラー | TLS検査や証明書チェーンの問題を切り分け |
| agent更新前後の差分 | バージョン変更による挙動差を確認 |
本番展開時は、パイロットサーバーで正常時のログを保存しておくと、障害時の比較がしやすくなります。
セキュリティ・ネットワーク管理者が確認すべき設定
Azure Arc Gatewayの導入では、Azure管理者だけで判断しない方が安全です。特にプロキシ、ファイアウォール、TLS検査、ログ監査を担当するチームとのすり合わせが必要です。
| 確認項目 | 判断基準 |
|---|---|
| Gateway URLの許可 | <Your URL prefix>.gw.arc.azure.comを許可しているか |
| Entra ID関連の許可 | login.microsoftonline.comとリージョン別ログインエンドポイントを許可しているか |
| Azure Resource Managerの許可 | management.azure.comを制御チャネルとして許可しているか |
| TLS検査 | Gatewayエンドポイントを検査対象から除外できるか |
| 追加サービスの利用 | Azure Monitor、Defender、Update Managerなどの要件を確認したか |
| 監査ログ | 企業プロキシ側とAzure Arc proxy側のどちらで何を見るか決めているか |
| 直接接続への切り戻し | Gateway解除時に通常のAzure Arcネットワーク要件を満たせるか |
Azure Arc-enabled serversの通常のネットワーク要件では、Connected Machine agentはTCP 443でAzure Arcと安全に通信します。また、ファイアウォールやプロキシで送信通信を制限している場合は、必要なURLやサービス タグをブロックしないようにする必要があります。(Microsoft Learn)
特に2026年4月以降、Azure Arc-enabled serversのネットワーク要件ではAzureFrontDoor.Frontendサービス タグが必要とされています。Azure Arc Gatewayを使う場合でも、切り戻しや混在構成では通常のAzure Arcネットワーク要件を再確認しておくべきです。(Microsoft Learn)
開発者・DevOps担当者が見直すべきポイント
Azure Arc Gatewayはインフラ管理者向けの変更に見えますが、DevOpsや自動化スクリプトにも影響します。特に、オンボードスクリプト、構成管理、CI/CD、監視エージェントの展開を自動化している場合は注意が必要です。
| 対象 | 見直す内容 |
|---|---|
| オンボードスクリプト | --gateway-idを含めるか、Gateway Resource選択手順を更新する |
| IaCテンプレート | Gatewayリソース、RBAC、タグ、リソースグループ設計を反映する |
| 構成管理 | agent 1.50以前と1.51以降で手順を分ける |
| 監視設定 | Azure Monitor Agent利用時の追加エンドポイントを確認する |
| セキュリティ自動化 | DefenderやUpdate Managerの通信要件を別途確認する |
| ログ収集 | arcproxy.logをトラブルシュート手順に加える |
| バージョン管理 | Connected Machine agent 1.64以降のGateway bypass list supportを検証する |
避けたいのは、古いオンボードスクリプトをそのまま使い続けることです。Azureポータルで生成したスクリプトを一度取得し、既存の自動化テンプレートとの差分を確認してください。
移行・展開で失敗しやすいポイント
「7つのFQDNだけで全機能が使える」と誤解する
Azure Arc Gatewayは接続要件を簡素化しますが、Azure Monitor Agent、Microsoft Defender、Windows Update関連などは追加要件が発生する場合があります。導入前に、Azure Arcで管理している拡張機能と関連サービスを一覧化してください。
TLS検査をそのまま残す
Gatewayエンドポイントに対してTLS終端やTLS検査を行うと、Azure Arc Gatewayの通信方式と合わない可能性があります。TLS検査が必須の組織では、Gatewayエンドポイントだけ除外できるか、セキュリティチームと事前に調整してください。
Gatewayのリージョンを性能目的で選ぶ
Gateway作成時のリージョンは主に管理プレーンの配置です。実行時接続のルーティングや性能を単純にリージョンだけで判断しないでください。運用管理、RBAC、社内標準を基準に決める方が実務的です。
古いagentを混在させたまま移行する
Connected Machine agent 1.50以前では、Gateway利用に追加コマンドが必要です。agent 1.51以降では自動化されるため、混在環境では手順が分かれます。移行前にagentバージョンを確認し、古いものは先に更新するか、別手順で管理してください。
Gateway解除後の通信要件を準備していない
Azure Arc Gatewayの関連付けを解除してdirectへ戻す場合、通常のAzure Arcネットワーク要件を満たす必要があります。切り戻し手順に、ファイアウォール許可とazcmagent checkの確認を含めてください。
大規模環境でGatewayリソース数を見積もらない
サブスクリプションあたり5個の制限や、リージョンごとのリソース数の目安を考えずに展開すると、後から構成変更が必要になります。サーバー数、Kubernetesクラスター数、Azure Localインスタンス数をもとに事前計算してください。
導入前チェックリスト
Azure Arc Gatewayを導入する前に、次のチェックリストを使うと抜け漏れを減らせます。
| チェック | 内容 |
|---|---|
| 対象リソースの棚卸し | Azure Arc-enabled servers、Kubernetes、Azure Localの数を把握したか |
| 利用サービスの確認 | Monitor、Defender、Update Manager、Automation、Key Vault連携の有無を確認したか |
| agentバージョン確認 | 1.50以前のサーバーを特定したか |
| Gatewayリソース設計 | リージョン、リソースグループ、タグ、RBACを決めたか |
| 許可FQDNの確認 | Gateway URLと公式の必要URLをネットワークチームへ共有したか |
| TLS検査の確認 | GatewayエンドポイントをTLS検査から除外できるか確認したか |
| パイロット対象選定 | Windows、Linux、プロキシ配下、拡張機能利用中の代表サーバーを選んだか |
| 検証コマンド | azcmagent show、azcmagent check、azcmagent logsを手順に入れたか |
| 切り戻し手順 | connection.type directへ戻す手順と通常ネットワーク要件を確認したか |
推奨する展開手順
Azure Arc Gatewayは、いきなり全サーバーへ適用するより、段階的に展開する方が安全です。
| フェーズ | 実施内容 | 合格条件 |
|---|---|---|
| 事前調査 | agentバージョン、拡張機能、ネットワーク要件を棚卸し | 対象と追加要件が明確になっている |
| Gateway作成 | Azure Arc Gatewayリソースを作成 | Gateway URLを取得できる |
| ネットワーク許可 | 必要FQDNをプロキシ・ファイアウォールへ登録 | azcmagent checkで到達性を確認できる |
| パイロット移行 | 少数のWindows/Linuxサーバーを関連付け | Agent StatusがConnected、Reachableがtrue |
| 拡張機能検証 | Monitor、Defender、Update Managerなどを確認 | 既存機能が正常に動作する |
| 本番展開 | リージョン・用途ごとに段階展開 | 監視とログで異常がない |
| 運用化 | 手順書、ログ確認、障害対応を更新 | 新規オンボード時にもGatewayを選べる |
展開後は、Azureポータルの状態だけでなく、サーバー側のazcmagent checkとarcproxy.logを確認してください。ネットワーク変更は「設定したか」ではなく、「実際にその経路で疎通しているか」で判断するのが基本です。
まとめ：まず確認すべきこと
Azure Arc Gatewayは、Azure Arcのネットワーク構成をシンプルにし、企業プロキシやファイアウォール配下のハイブリッド環境を管理しやすくする機能です。特にAzure Arc-enabled serversでは、主要な接続要件をAzure Arc Gateway経由にまとめられるため、許可リスト管理の負荷を下げられます。
一方で、Azure Monitor Agent、Microsoft Defender、Update Manager、Key Vault連携などを使っている場合は、追加エンドポイントの確認が必要です。TLS検査を行う環境では、Gatewayエンドポイントを検査対象から除外できるかも重要な判断材料になります。
最初に取るべき行動は、次の3つです。
- Azure Arc対象サーバーのagentバージョンと利用中の拡張機能を棚卸しする
- Azure Arc Gatewayで許可するFQDNと、追加サービスに必要なエンドポイントをネットワークチームと確認する
- 少数のWindows/Linuxサーバーで
azcmagent show、azcmagent check、azcmagent logsを使って検証する
Azure Arc Gatewayは、単なるネットワーク設定の省略機能ではありません。Azure Arcを大規模に運用するための通信経路を整理し、監査しやすくするための設計要素です。導入効果を最大化するには、Gatewayリソースの設計、agentバージョン、TLS検査、追加エンドポイント、切り戻し手順まで含めて計画することが重要です。
コメント