AzureのサーバもAzure外のサーバも一元的に運用管理するEssential Machine Managementを試してみる

本記事について

2026年4月にプレビューが始まったEssential Machine Management (EMM)について試して動作を確認してみました。
EMMはAzure VMとAzure Arc-enabled servers (Azure外のVM)をまとめてAzureサービスでサーバ管理するための機能です。
EMMを利用することでハイブリッドクラウド環境でのサーバ管理を効率的に一元管理できるということで運用を簡便にできる可能性がある注目機能です。
なお、EMM自体はサーバの監視や更新管理等のサーバ管理機能を持つわけではなく、既存のAzureのサーバ管理機能をまとめて有効化し、維持するための仕組みとなっています。

Microsoftのプレビューリリースのアナウンスと公式ドキュメントはこちらです。
MS techcommunity | Announcing Public Preview for Essential Machine Management

MS Learn | 基本的なマシン管理 (プレビュー)

Essential Machine Management (EMM)とは

EMMで有効化されるサーバ管理機能

EMMではAzure VMとArc-enabled serversの両方に対して、以下のサーバ管理サービスを提供します。

機能	Azureサービス
監視	Azure Monitor
更新管理	Azure Update Manager
構成管理	Azure Machine Configuration
変更履歴とインベントリ管理	Azure Change Tracking and Inventory
セキュリティ	Defender for Cloud

どう機能する？

EMMをデプロイすると複数のデプロイが実行されますが、そのメインはAzure Policyです。
サブスクリプションをスコープとしたイニシアティブを割り当てることで、イニシアティブを構成する26のポリシーによりサーバに対してAzure Monitor Agent等の拡張機能のインストールやデータ収集ルールの設定がおこなわれます。
また、Azure Policy以外ではデータ収集ルールのデプロイやメトリックアラートルールのデプロイもおこなわれてAzureでのサーバ管理の土台を整えてくれます。
実際にEMMをデプロイすると、サブスクリプションに対してデプロイが実行されますが、その先ではサーバを含むリソースグループに複数のデプロイが実行されています。

ちなみに、EMMにより割り当てられるイニシアティブは以下の名前で存在しています。
EMMをデプロイすることで「Managedops-Policy-<サブスクリプションID>」という名前でサブスクリプションに割り当てられます。

• [Preview]: Enable Essential Machine Management（[プレビュー]: 重要なマシンの管理を有効にする）

どれだけお得？ (コスト)

さてEMMのコストですがAzure VMに対しては無料で利用できますが、Arc-enabled serversは1台あたり$9/月かかります。
これはEMMで有効化される一部のAzureサービスがArc-enabled servresでは有償なためで、これを割安で利用できるという課金体系になっています。

有効化されるサービスの料金は以下の通りで、すべてを個別に有効化して利用すると$11ですから1台あたり$2割安とサーバ台数が大きくなってくるとお得感がでてきます。

• Azure Monitor: 無償 (ログ保存、アラート設定の費用はAzure VM同様)
• Azure Update Manager: $5
• Azure Machine Configuration / Azure Change Tracking and Inventory: $6
• Defender for Cloud: Defender for Serversを利用する場合はAzure VM同様

一方で、Update Manager、Machine Configuration、Change Tracking and Inventoryをフルに利用しないと割高になってしまいますので、EMMでArc-enabled serversを管理するならばAzureでのサーバ管理を使いこなしている必要がありますね。
なお、Arc-enabled serversがWindowsでSA付きの場合、PAYGライセンスの場合、ESUを適用している場合は、$9なしで利用できるそうです。
また、Defender fro ServersはAzure VM含め別料金です。

2026/4現在のプレビューでは無料で利用できます。

EMMを有効化する

実際にEMMを有効化してAzureサービスがサーバに適用される様子を見てみます。
今回はAzure VM2台 (Windows Server / Ubuntu)とArc-enabled servers1台 (Ubuntu)が起動しているサブスクリプションで試しています。

前提条件・事前準備

前提条件としてユーザー割り当てマネージドIDとLog Analyticsワークスペース、Azure Monitorワークスペースが必要になります。
後者2つはEMMの有効化ウィザードで作成することもできますが、マネージドIDは事前に作成しておく必要があり、マネージドIDにはサブスクリプションスコープの共同作成者が必要です。

Point: 共同作成者ロールのユーザー割り当てマネージドIDの準備が必要！

有効化

まずEMMを有効化するサブスクリプションを選択し、用意しておいたマネージドIDを選択します。

次にAzure MonitorワークスペースとLog Analyticsワークスペースを選択 or 作成します。

最後にDefender for Cloudのプランを選択します。
デフォルトは無料のFoundation CSPMが選択されていますが、Defender CSPMとDefender for Servers P2を選択して有効化することができます。
今回はデフォルトのままで進めています。

サブスクリプションスコープでdefaultという名前でデプロイが走りまして、しばらくするとデプロイが完了してEMMの画面で当該サブスクリプションが有効になったことが確認できます。
ただし、拡張機能のインストール等は裏でAzure Policyの修復動作を経由して適用されていきますので、この時点でサーバ管理機能が使える状態ではありません。気長に待ちましょう。

有効化後の挙動

さて有効化してしばらくするとAzure Policyの割り当てに"Managedops-Policy-<サブスクリプションID>"が作成されて、ポリシーが評価されていることが確認できます。

評価が終わるとこのように修復状態が完了 or 失敗になりました。

今回失敗しているのはArc-enabled serversにAzure Monitor Agentをインストールするポリシーでした。
ポリシーではAMAの1.29.6というバージョンをインストールする設定になっていましたが、用意していたUbuntu 24.04はAMAの1.29.6ではサポートされていなかったためです。
ただし、AMAが自動アップグレード有効で設定されており、しばらくすると自動でAMAが最新バージョンにアップデートされてUbuntu 24.04で動作するバージョンになって正常に動作していました。

また、リソースグループを確認すると以下のリソースが作成されていました。

• データ収集ルール 2件 (Azure Monitor用 / Change Tracking用)
• Log Analyticsワークスペースのソリューション (Change Tracking用)
• メトリックアラートルール (サーバのリソース監視用)
  

サーバには各サービス用の拡張機能がインストールされています。

設定される内容

設定された内容をサービスごとに見てみます。

監視 (Azure Monitor)

サーバ監視はメトリックアラートが設定されています。
メトリックはAzure MonitorワークスペースにOpenTelemetryメトリックとして保存されており、Log Analyticsワークスペースにはメトリックが保存されていません。

収集されているメトリックの詳細をDCRのJSONビューで確認するとこのようになっていました。

そして、作成されているアラートルールと監視内容は以下のとおりです。
ManagedOpsを接頭辞に8つのメトリックアラートルールが作成されました。
すべて1分間隔でチェックされています。
しきい値が静的に設定されていますので、環境に応じてカスタマイズした方がよいかもしれません。

監視内容	メトリックアラートルール名
死活監視 (直近5分間のメトリックなしで発火)	ManagedOps-VM-Availability-<サブスクリプションID>
CPU使用率 (直近5分間のCPU使用率の平均が80%以上で発火)	ManagedOps-High-CPU-Usage-<サブスクリプションID>
メモリ使用率 (直近5分間で利用可能なメモリが1GiBを下回ると発火)	ManagedOps-Low-Available-Memory-<サブスクリプションID>
ディスクIO (直近5分間の最大IOPSが5,000以上で発火)	ManagedOps-High-Disk-IOPS-<サブスクリプションID>
ディスクのレイテンシ (直近5分間の平均レイテンシが100ms以上で発火)	ManagedOps-Slow-Disk-Operations-<サブスクリプションID>
インバウンド通信量 (1日あたりのインバウンド通信量が100GiB以上で発火)	ManagedOps-High-Network-Inbound-Traffic-<サブスクリプションID>
アウトバウンド通信量 (1日あたりのアウトバウンド通信量が50GiB以上で発火)	ManagedOps-High-Network-Outbound-Traffic-<サブスクリプションID>
ネットワークのエラー (直近5分間のエラーが10件以上で発火)	ManagedOps-High-Network-Errors-<サブスクリプションID>

メトリックアラートルールのPromQLも参考に貼っておきます。

# 死活監視
(count (count_over_time({"system.uptime"}[1d])) by ("microsoft.resourceid")) unless (count (count_over_time({"system.uptime"}[5m])) by ("microsoft.resourceid"))

# CPU使用率
avg_over_time(((sum by ("microsoft.resourceid") (irate({"system.cpu.time","state" !~ "idle|iowait|steal"}[2m]))) / (sum by ("microsoft.resourceid")(irate({"system.cpu.time"}[2m]))))[5m:]) * 100 > 80

# メモリ使用率
min_over_time((sum by ("microsoft.resourceid") ({"system.memory.usage", state=~"free|cached|buffered|slab_reclaimable"}))[5m:]) < (1 * 1024 * 1024 * 1024)

# ディスクIO
max_over_time((sum by ("microsoft.resourceid") (irate({"system.disk.operations"}[2m])))[5m:]) > 5000

# ディスクレイテンシ
avg_over_time(((sum by ("microsoft.resourceid") (irate({"system.disk.operation_time"}[2m]))) / (sum by ("microsoft.resourceid")(irate({"system.disk.operations"}[2m]))))[5m:]) * 1000 > 100

# インバウンド通信量
sum_over_time((sum by ("microsoft.resourceid") (irate({"system.network.io", direction="receive"}[2m])))[1d:]) > (100 * 1024 * 1024 * 1024)

# アウトバウンド通信量
sum_over_time((sum by ("microsoft.resourceid") (irate({"system.network.io", direction="transmit"}[2m])))[1d:]) > (50 * 1024 * 1024 * 1024)

# ネットワークのエラー
sum_over_time((sum by ("microsoft.resourceid") (irate({"system.network.errors"}[2m])))[5m:]) > 10

更新管理 (Azure Update Manager)

Update Managerで定期評価が有効化されており、適用可能な更新プログラムがあることが確認できます。
更新適用のメンテナンススケジュールの設定は作成されていませんので、自動更新を設定したい場合は自分で設定する必要があります。

構成管理 (Azure Machine Configuration)

構成管理機能が有効化されてマシン構成が割り当てられていることが確認できます。

変更履歴とインベントリ管理 (Azure Change Tracking and Inventory)

変更履歴とインベントリも有効化されていることが確認できます。

サーバごとの変更履歴、インベントリもしっかり取得されています。

セキュリティ (Defender for Cloud)

今回Defender for Serversは有効化していないためこちらは特に変化はありません。
有効化した場合はおそらくサブスクリプションレベルでDefender for Servers P2が有効になると思われます。(検証環境にDfSを有効化したくないものがあり、今回はスキップ・・・)

Cost Managementの表示

EMMの費用は検証時点ではプレビューで発生しないのですが、Cost ManagementではこのようにAzure Arcのサービスの中にEMMの費目が表示されていました。
内部的にどうEMMの課金対象がカウントされているのか気になりますが、おそらくサブスクリプション内のArc-enabled serversの数が計上されるのでしょうか。

まとめ

EMMを有効化してその挙動を確認してみました。
1つ1つの機能は普段から使われている方も多いAzure MonitorのアラートやUpdate Managerの更新管理ですが、環境全体にAzure Policyを使って一括で適用してくれるのは便利ですね。

一方で、現状は一部のサーバへの適用除外ができない制限があり、本番環境や開発環境が混在しているサブスクリプションなどで費用の問題等からすべてに適用したくない場合は要注意です。
仮に本番・開発環境すべてに適用するにしても、Log AnalyticsワークスペースやAzure Monitorワークスペースを分けることができないのも少し不便かなと感じます。
リソースグループスコープで適用できるようになるとより柔軟に利用できると思いますが、一元的に管理するというコンセプトは取りこぼしが出ないようにする労力も不要にしたいという考えがあると思うのでEMMの思想に合わないのかもしれません。

Azure VMのみの環境であれば費用もかかりませんのでベースとして適用しつつ、必要に応じてカスタマイズしていくというオンボードで有効に思います。
Arc-enabled serversを管理するハイブリッドクラウドシナリオではコストをどう考えるかですね。$9払うのであればがっつりとAzureサービスを使ってハイブリッドなサーバ管理環境を整えたいところです。