Azure Arcは、オンプレミスや他社クラウドにあるサーバー・Kubernetesクラスター・SQL ServerをAzure Resource Manager(ARM)のリソースとして登録し、Azureのポリシー・監視・更新管理・セキュリティをAzureの外へ広げる仕組みです。登録そのものは無料で、料金がかかるのはその上で使うサービスです。この記事では、Microsoft Learnの公式ドキュメントとAzureの価格API(2026年10月1日時点・米ドル定価)をもとに、無料で使える範囲、有料機能ごとの単価と月額の試算、対応OS、azcmagent による接続手順、拡張セキュリティ更新(ESU)の扱い、そしてArcを入れないほうがよい場面までを整理します。
まとめ:Azure Arcの料金と導入の要点
- Arcはサーバー・Kubernetes・SQL ServerをARMに「投影」する管理の土台で、サーバーを動かす場所は変わらない
- リソースの登録、タグ、管理グループ、Resource Graphでの検索、RBACは追加料金なし
- サーバーで課金されるのは上に載せる機能で、Machine Configurationは1台月6ドル、Azure Update Managerは1台月5ドル、Essential Machine Management(プレビュー)は1台月9.01ドル
- Software Assurance付きのWindows Serverは、宣言(attestation)すればUpdate ManagerやMachine Configurationなどが無料になる
- KubernetesのGitOps(Flux)はサブスクリプションあたり最初の6 vCPUが無料、超えた分が1 vCPU月2ドル
- Connected Machine agentの基本通信はTCP 443のアウトバウンド。ESUの証明書更新にはTCP 80も必要で、利用機能ごとの通信許可を確認する。データサービスの間接接続モードは2025年9月に廃止された
- Windows Server 2016のESUは2026年8月3日からArc経由で設定でき、課金は2027年1月13日から始まる
Azure Arcの仕組み:Azure外のリソースのARM登録と管理
Azure Arcに接続したサーバーは、Azureポータル上で Microsoft.HybridCompute/machines というリソースとして現れます。実体はオンプレミスやAWS・Google Cloud上で動いたままで、AzureのVMに移行するわけではありません。Azure側にリソースができることで、Azure VMと同じ方法でタグを付け、Azure Policyを割り当て、RBACで権限を委任し、拡張機能(VM extensions)として監視エージェントなどを配れるようになります。
Arcで管理できる4種類のリソース
Microsoft Learnの概要ページ(2026年8月1日更新)は、Azureの外にあるものとして次の4種類を挙げています。
| 種類 | 対象 | 接続に使うもの |
|---|---|---|
| サーバーとVM | 物理・仮想のWindows/Linux | Connected Machine agent |
| VM基盤 | VMware vCenter・SCVMM・Azure Local | Arcリソースブリッジ |
| Kubernetesクラスター | AWS・Google Cloud・オンプレミスのK8s | Arcエージェント(Helm) |
| SQL Server | Azure外のSQL Serverインスタンス | サーバーのArc接続+拡張機能 |
VMware vCenterやSCVMM配下のVMは、サーバーとして1台ずつ接続することも、リソースブリッジを置いてVMの作成・停止・削除までAzureから操作することもできます。Azure Stack HCIは2024年11月19日にAzure Localへ改称された、Arcを前提に動くオンプレミス基盤です。
エージェントとリソースブリッジの役割
サーバーに入れるのはAzure Connected Machine agent(コマンド名 azcmagent)で、2026年9月時点の最新は1.68です。エージェントはAzure側の身元となるマネージドIDを持ち、拡張機能のインストールや設定の同期をこのエージェント経由で行います。Microsoftがサポートするのはリリースから1年以内のバージョンだけなので、自動アップグレードを有効にするか、パッケージ管理で定期的に更新する運用が要ります。
リソースブリッジは、vCenterやSCVMMの管理面とAzureをつなぐ仮想アプライアンスです。各VMにエージェントを入れなくても在庫(VM・テンプレート・データストアなど)をAzureから見られる点が、サーバー単位の接続との違いです。
Azure Arcの料金:無料の範囲と有料になる機能
「Azure Arcの利用料はいくら?」への答えは、Arc自体はほぼ無料で、上に何を載せるかで決まるです。以下の単価はAzure Retail Prices API(米ドル定価)の値で、月額はMicrosoftの料金ページと同じ730時間で換算しています。円での請求額は契約通貨と為替で変わるため、見積もりは料金計算ツールで確定させてください。
追加料金なしで使えるコントロールプレーン機能
Arc対応サーバーで無料と明記されているのは、管理グループとタグによる整理、Azure Resource Graphでの検索・インデックス、Azure RBACによるアクセス制御、テンプレートと拡張機能による環境構成と自動化です。VMware vSphereとSCVMMでは、これに加えて在庫の一覧表示とVMの作成・サイズ変更・削除・起動停止も無料です。
つまり「全拠点のサーバーを1つの画面で数え、タグで持ち主を付け、誰が触れるかをEntra IDで決める」までなら課金は発生しません。料金が出てくるのは、Microsoft Defender for CloudやAzure Monitorのように、そのサービス自体に料金表があるものを有効にしたときです。
サーバーに付ける有料機能の単価
| 機能 | 課金単位 | 単価(USD) | 月額換算 |
|---|---|---|---|
| Machine Configuration | サーバー・月 | 6.00 | 6.00 |
| Azure Update Manager | サーバー・月 | 5.00 | 5.00 |
| Essential Machine Management | サーバー・時間 | 0.01233 | 約9.00(730時間換算。公式月額目安は9.01) |
| Defender for Servers Plan 1 | サーバー・時間 | 0.00672 | 約4.91 |
| Defender for Servers Plan 2 | サーバー・時間 | 0.02 | 約14.60 |
| Windows Server従量課金 | コア・時間 | 0.046 | 約33.58 |
| SQL Server Standard従量課金 | コア・時間 | 0.10 | 約73.00 |
| SQL Server Enterprise従量課金 | コア・時間 | 0.375 | 約273.75 |
各単価はAzure Retail Prices API(2026年10月1日取得)で製品名・メーター名を照合した値で、Defender for Serversは東日本リージョンの価格です。最新の金額はAzure Arcの料金ページで確認してください。Azure Monitorのログは取り込んだデータ量で別に課金され、上の表には含みません。
Essential Machine Management(EMM)は2026年9月時点でパブリックプレビューの新しい入口で、サブスクリプション単位で有効にすると、配下のAzure VMとArcサーバーにUpdate Manager、変更追跡とインベントリ、Machine Configuration、監視の推奨アラート、Azureセキュリティベースラインがまとめて構成されます。Update ManagerとMachine Configurationを個別に付けると月11ドルなので、両方使うならEMMの月9.01ドルのほうが安くなります。Defender for Servers Plan 2を付けたサーバーでは、EMMの機能が追加料金なしになります。
Windows Serverの従量課金はWindows Server 2025のStandard/Datacenterが対象で、エディションによらず同じ単価、通常のクライアントアクセスライセンス(CAL)は不要です(リモートデスクトップのCALは別途必要)。SQL Serverの従量課金はArc対応サーバー上のSQL Serverを時間単位でライセンスする方式で、手持ちのライセンスを使うなら課金されません。
Software Assuranceで無料になるWindows Server Management
Software Assurance付き、またはサブスクリプションライセンスのWindows Serverは、「Windows Server Management enabled by Azure Arc」の特典を受けられます。対象はUpdate Manager、変更追跡とインベントリ、Machine Configuration、Windows Admin Center in Azure、Best Practices Assessment、Azure Site Recoveryの構成、Azure File Syncの割引などです。ただし、Azure Site Recoveryは構成機能が特典の対象で、サービス利用料やコンピューティング・ストレージ・ネットワーク費用は別途発生します。Azure File Syncも無料ではなく、対象エージェントでサーバー単価の割引が適用されます。ログ取り込みにも別途費用がかかります。
注意点は、Arcに接続しただけでは無料にならないことです。サーバーごとにSoftware Assuranceを持っていると宣言(attestation)するか、Windows Serverの従量課金に登録して初めて課金対象から外れます。宣言を忘れたままUpdate Managerを使うと、1台月5ドルが請求されます。
Kubernetes(GitOps)の課金:6 vCPUの無料枠
Arc対応Kubernetesは、クラスターを登録するだけなら無料です。課金されるのはFlux v2によるGitOps構成(microsoft.flux 拡張機能)で、サブスクリプション内の最初の6 vCPUまでは無料、超えた分がクラスターのvCPU数に応じて1 vCPU月2ドルかかります。接続中は5分ごとにvCPU数が更新され、切断中は最後に登録されたvCPU数で課金されます。AKS、AKS Edge Essentials、Azure Local上のAKSではFluxの料金はかかりません。
リポジトリをいくつつないでもクラスター単位の課金は1つです。Defender for ContainersやAzure Monitorのコンテナー分析を有効にすれば、それぞれの料金が別に加わります。
月額の試算:Linux 20台とK8s 3クラスターの場合
仮に、Software Assurance付きのWindows Server 30台、ライセンス特典のないLinuxサーバー20台、16 vCPUのKubernetesクラスター3つをArcにつなぎ、更新管理と構成監査とGitOpsを使うとします。
| 対象 | 使う機能 | 計算 | 月額(USD) |
|---|---|---|---|
| Windows Server 30台 | SA特典(宣言済み) | 0×30 | 0 |
| Linux 20台 | Update Manager+Machine Configuration | (5+6)×20 | 220 |
| Linux 20台(代替案) | EMM | 9.01×20 | 180.20 |
| K8s 3クラスター | GitOps | (48−6)×2 | 84 |
この構成ではLinux分をEMMに寄せると月約40ドル下がり、合計は約264ドルです。ログの取り込み量は台数よりも収集するイベントの種類で大きく変わるため、Log Analyticsへ送るデータを先に絞ってから見積もるのが安全です。Azure Monitor側の課金の考え方はAzure Monitorとは?監視の仕組みと料金モデルで詳しく扱っています。
Azure Arcの対応OSとサポート終了が近いバージョン
Connected Machine agentが動くのは64ビットのx86-64で、Arm64は一部の機能のみ、32ビットは非対応です。Arm64ではMachine Configurationがまだ使えません。Microsoft Learnの前提条件ページには、OSごとに「Arcのサポート終了予定」が載っており、2026年11月で終わるものが多く含まれています。
| OS | 継続して使える版 | 2026年11月にArcサポート終了予定 |
|---|---|---|
| Windows Server | 2016・2019・2022・2025 | 2012・2012 R2 |
| Ubuntu | 22.04・24.04・26.04 | 18.04・20.04 |
| RHEL | 8・9・10 | 7 |
| SLES | 15 SP7 | 12 SP5・15 SP3〜SP6 |
| Debian | 13 | 11・12 |
| Amazon Linux | 2023 | 2 |
| Oracle Linux | 8・9・10 | 7 |
| AlmaLinux/Rocky Linux | 8・9 | なし |
Windows 10/11とWindows IoT Enterpriseも対象に入っていますが、クライアントOS向けの別ガイダンスに従う扱いです。一覧の原典はMicrosoft LearnのConnected Machine agentの前提条件です。Debian 12やSLES 15 SP6のように、まだOS自体のサポートが続いている版も2026年11月でArcのサポート終了予定に入っている点は見落としやすく、これからArcに載せるなら新しい版へ上げてから接続するほうが手戻りがありません。
Azure Arcの導入手順:サーバーとKubernetesの接続
事前準備:リソースプロバイダーとロール
サーバーを接続するサブスクリプションで、次のリソースプロバイダーを登録します。SQL Serverも載せるなら Microsoft.AzureArcData、Update Managerを使うなら Microsoft.Compute も必要です。
az login
az account set --subscription "サブスクリプション名"
az provider register --namespace 'Microsoft.HybridCompute'
az provider register --namespace 'Microsoft.GuestConfiguration'
az provider register --namespace 'Microsoft.HybridConnectivity'
az provider register --namespace 'Microsoft.AzureArcData'
接続作業をする人(または自動化用のサービスプリンシパル)には、対象リソースグループで「Azure Connected Machine Onboarding」か「共同作成者」のロールが要ります。接続後に設定変更や削除をするには「Azure Connected Machine Resource Administrator」を割り当てます。台数が多いなら、オンボード専用のロールだけを持つサービスプリンシパルを作り、スクリプトで一括接続するのが定石です。
サーバーの接続:azcmagent connect
以下のLinux用コマンドは、対象サーバーのrootシェルで実行します。Azure側には登録先のリソースグループ HybridServers を事前に作成しておきます。インストールスクリプトでエージェントを入れ、azcmagent connect でAzureに登録します。Windowsは AzureConnectedMachineAgent.msi を msiexec で入れたあと、同じ azcmagent connect を実行します。
# Linux:エージェントのインストール
wget https://aka.ms/azcmagent -O ~/Install_linux_azcmagent.sh
bash ~/Install_linux_azcmagent.sh
# 接続前にネットワーク到達性を確認
azcmagent check --location "japaneast"
# デバイスコードでサインインして接続
azcmagent connect --subscription-id "サブスクリプションID" \
--resource-group "HybridServers" --location "japaneast" --use-device-code
# 接続状態の確認
azcmagent show
無人で大量に接続する場合は、--use-device-code の代わりに --service-principal-id・--service-principal-secret(または証明書)・--tenant-id を渡します。プロキシ環境ではインストールスクリプトに --proxy "proxy.example.com:8080" を付けます。オンプレミスのRunbook実行基盤をArc対応サーバーへ寄せる場合は、拡張機能版のHybrid Runbook Workerへの移行も合わせて検討します。
Kubernetesクラスターの接続:az connectedk8s connect
クラスター側には、Arcエージェント用に850MB以上の空きメモリと、1 CPUの約7%の処理能力が必要です。作業端末には最新のAzure CLIと connectedk8s 拡張、対象クラスターを指すkubeconfigを用意します。
az extension add --name connectedk8s
az provider register --namespace Microsoft.Kubernetes --wait
az provider register --namespace Microsoft.KubernetesConfiguration --wait
az provider register --namespace Microsoft.ExtendedLocation --wait
az group create --name AzureArcTest --location japaneast
az connectedk8s connect --name onprem-k8s-01 --resource-group AzureArcTest
az connectedk8s connect はHelm 3を作業端末の .azure フォルダに入れてArcエージェントをデプロイします。既存のHelmは置き換えません。GitOpsで使われるFlux自体の仕組みやArgo CDとの違いはFlux CDとは?GitOps Toolkitの仕組みとArgo CDとの違いを参照してください。
ネットワーク要件:443のアウトバウンドとArc gateway
エージェントはTCP 443のアウトバウンド通信だけでAzureとやり取りし、インバウンドの穴あけは要りません。常時許可が必要な宛先には *.his.arc.azure.com(メタデータとハイブリッドID)、login.microsoftonline.com と各リージョンの <region>.login.microsoft.com、guestnotificationservice.azure.com などがあり、management.azure.com は接続・切断のときだけ使われます。
許可するFQDNを減らしたい場合はAzure Arc gatewayを使います。ゲートウェイリソースを作ると、エージェントの通信が「Arcプロキシ→社内プロキシ→Arc gateway」の経路にまとまり、Arcへのオンボードに必要な公開側の宛先を7つのFQDNに集約できます。ただし、Azure Monitor AgentやHybrid Runbook Workerなど、利用する拡張機能によって追加の宛先許可が必要です。ただしゲートウェイ使用中はプロキシのバイパス設定が効かず、1サブスクリプションあたり5個までという上限があり、TLSを復号・検査するプロキシの下では推奨されていません。閉域で通したい場合はPrivate Link Scopeを使いますが、Entra IDなど一部の宛先はプライベートエンドポイント化できず、インターネット側の許可が残ります。
ESU(拡張セキュリティ更新)をArc経由で買う場合
Arcの導入目的の一つに、サポートが終わったWindows ServerやSQL ServerのESUを月額で購入することがあります。ボリュームライセンスで年額一括払いするのと違い、Arc経由ならAzureの請求に乗り、台数やコア数を月単位で増減できます。
- Windows Server 2012/2012 R2:2023年10月10日にサポート終了し、Arc経由のESUは2023年10月から課金。ただしこの2つのOSは2026年11月でArcのサポート終了予定に入っている
- Windows Server 2016:2027年1月12日にサポート終了。ESUはポータルで2026年8月3日から設定でき、課金は2027年1月13日から。最長3年、2030年まで重要・緊急のセキュリティ更新を受けられる
- SQL Server 2014/2016:Arc対応SQL Serverの価格表にStandard/EnterpriseそれぞれのESU単価が載っている
Windows Server 2016のESUを使うには、Connected Machine agent 1.62以上が必要です(出典:Extended Security Updatesの準備)。また証明書更新のため www.microsoft.com/pkiops/certs へのHTTP(80)とHTTPS(443)の通信を許可しておく必要があります。2016のサーバーを抱えていて2027年1月までに移行が終わらない場合、まずESUの購入資格を確認してください。Windows Server 2016では、対象のボリュームライセンス契約によるSoftware Assurance、または同等のサーバーサブスクリプションが必要です。そのうえでArcへの接続、ESUへの登録、更新プログラムの適用経路を準備します。
Azure Arcを採用しないほうがよい場面
Arcは「Azureの管理機能を外へ広げる」製品です。有料サービスを使わなくても在庫の一覧・タグ・管理グループ・RBACによる権限委任までは無料で使えますが、既存の管理基盤で同じことができているなら、増えるのはエージェントの更新と通信許可の保守です。次の条件に当てはまる場合は、Arcを前提にした設計を見直したほうがよいと判断します。
- インターネットに出られない閉域・オフライン環境:Arcは常時接続が前提で、データサービスの間接接続モードも2025年9月に廃止された。切断が続くと拡張機能の更新もポリシー評価も止まる
- AWSやGoogle Cloudのワークロードしかなく、Azureの契約が他に無い:AWS Systems ManagerやGKE Enterpriseのように、そのクラウドの管理ツールで足りることが多い。マルチクラウドKubernetes管理の別解はAnthos(GKE Enterprise)の解説で比較できる
- Argo CDなど既存のGitOps基盤が動いているKubernetes:ArcのGitOpsにはFlux拡張機能(サブスクリプションあたり6 vCPUを超える分が課金対象)のほか、Argo CD拡張機能も用意されている。ただ既存のArgo CDを拡張機能版へ載せ替える必然性は薄く、Arcはインベントリとポリシーに使い、デプロイは既存の仕組みに残すほうが二重管理を避けられる
- TLS検査プロキシを外せないネットワーク:Arc gatewayの宛先を検査対象から除外できないなら、宛先を個別に許可する構成になり、FQDNの保守負担が残る
逆に、Windows Server 2016の延命、SA付きサーバーの更新管理の無償化、オンプレミスとAzure VMで同じAzure Policyを効かせたい、のいずれかに当てはまるなら、接続自体は無料なので、まず数台に絞って接続し、エージェントの自動更新と通信許可の運用が回るかを確かめてから台数を広げるのが現実的です。オンプレミスとクラウドの接続方式やアプリ配置の判断から考えたい場合は、ハイブリッドクラウド移行の接続方式とネットワーク設計も参考になります。
Azure Arcに関するよくある質問
Azure Arcは無料で使えますか?
サーバーやKubernetesクラスターをArcに登録し、タグ・管理グループ・Resource Graph・RBACで管理する範囲は無料です。Machine Configuration(1台月6ドル)、Update Manager(1台月5ドル)、Defender for Cloud、Azure Monitor、GitOps(6 vCPU超)などを使うと、それぞれの料金がかかります。
Azure Arcはどのクラウドのサーバーに対応していますか?
エージェントが対応OSで動き、TCP 443で外に出られれば、AWSのEC2、Google CloudのCompute Engine、オンプレミスの物理サーバーや他社ハイパーバイザー上のVMのいずれでも接続できます。Kubernetesも、AWSやGoogle Cloud上のクラスター、オンプレミスのVMware vSphereやAzure Local上のクラスターを接続でき、OpenShift、Rancher(RKE2/K3s)、VMware Tanzuなどのディストリビューションは接続の検証済み一覧に載っています。
Azure ArcとAKSの違いは何ですか?
AKSはAzure上でKubernetesクラスターを提供するマネージドサービスで、Arc対応Kubernetesは既にどこかで動いているクラスターをAzureから管理するための接続です。Azure上で新しくクラスターを作るならAKS(Azure Kubernetes Service)、AWS上やオンプレミスで既に動いているクラスターを統制したいならArcという分担になります。
Azure Stack HCIとAzure Arcの関係は?
Azure Stack HCIは現在Azure Localという名前になっており、Arcを使って管理されるオンプレミスのハイパーコンバージド基盤です。Azure Local上のVMはArcのリソースブリッジ経由でAzureポータルから作成・操作できます。
Azure Arcのエージェントをアンインストールするには?
まず導入済みのVM拡張機能をすべてアンインストールします。続いて、Azure Local上のArc対応VMでは azcmagent disconnect --force-local-only、それ以外では azcmagent disconnect を管理者権限で実行してAzure側のリソースを削除し、その後でエージェントをアンインストールします。Linuxは sudo apt purge azcmagent、sudo yum remove azcmagent、sudo zypper remove azcmagent のいずれか、Windowsは製品コードを指定した msiexec.exe /x かコントロールパネルから削除します。Azure Local上のVMで --force-local-only を付けずに切断すると、VMがAzure側とオンプレミス側の両方から削除されるおそれがあります。