Azure Monitor Agent Requirements を確認する管理者が最初に押さえるべき結論は、Azure Monitor Agent（AMA）は「VM に拡張機能を入れれば終わり」ではないという点です。インストール前に、対応 OS、VM 拡張機能の種類、権限、マネージド ID、ディスク容量、ネットワーク疎通、データ収集ルール（DCR）まで確認しておかないと、エージェントは入っているのにログが収集されない、移行後にデータが重複する、Linux 環境で通信できない、といった問題が起きます。AMA は Azure VM、仮想マシン スケールセット、Azure Arc 対応サーバーに対するゲスト OS 監視の中核となるエージェントで、収集設定は DCR で管理します。(Microsoft Learn)
なお、提示された Microsoft Learn の「Azure Monitor Agent requirements」ページ自体は、確認時点で最終更新日が 2026 年 1 月 7 日と表示されています。本稿ではこの要件ページを軸に、2026 年 6 月末時点で管理者があわせて確認すべき公式情報、特に拡張機能バージョン、対応 OS、WAD/LAD からの移行、Log Analytics agent からの移行も含めて整理します。(Microsoft Learn)
まず押さえる結論：Azure Monitor Agent Requirements は導入前チェックリストとして読む
Azure Monitor Agent Requirements は、新機能紹介というより「AMA を安全に導入・移行するための前提条件リスト」として読むべきドキュメントです。特に重要なのは、AMA が Azure VM 拡張機能として実装されること、データ収集には DCR の関連付けが必要なこと、Azure VM ではマネージド ID が必要なこと、Arc 対応サーバーではシステム割り当てマネージド ID のみがサポートされることです。(Microsoft Learn)
| 確認ポイント | 管理者が見るべき内容 | 実務での判断基準 |
|---|---|---|
| インストール方式 | VM 拡張機能、DCR 作成、VM insights、Azure Policy、Windows MSI など | 数台ならポータル、全社展開なら Azure Policy または IaC を優先 |
| データ収集 | AMA 単体ではなく DCR で収集対象・宛先を定義 | 「エージェント導入」と「DCR 関連付け」を別タスクとして管理 |
| 認証 | Azure VM ではマネージド ID が必要 | 大規模展開はユーザー割り当て ID、Arc はシステム割り当て ID |
| ディスク容量 | キャッシュ、ログ、イベント用の空き容量が必要 | アップグレード時は一時的に必要容量が増える前提で監視 |
| ネットワーク | AzureMonitor / AzureResourceManager タグ、443/TCP、DCE、Private Link など | プロキシ、Firewall、HTTPS インスペクションを事前に確認 |
| 移行 | WAD/LAD、Log Analytics agent から AMA + DCR へ移行 | 収集データの同等性を確認してから旧エージェントを削除 |
影響範囲：Azure VM だけでなく Arc 対応サーバーも対象になる
Azure Monitor Agent は、Azure 上の VM だけでなく、Azure Arc を通じてオンプレミスや他クラウド上のサーバーにも導入できます。ゲスト OS のログやパフォーマンス データを収集し、Azure Monitor、Microsoft Sentinel、Microsoft Defender for Cloud などで利用するデータ基盤になります。(Microsoft Learn)
影響を受けるのは、次のような環境です。
| 対象環境 | 影響 |
|---|---|
| Azure VM | AMA 拡張機能、DCR、マネージド ID、ネットワーク要件の確認が必要 |
| Azure Virtual Machine Scale Sets | 拡張機能の更新ポリシー、ローリング更新、Azure Policy 展開の設計が必要 |
| Azure Arc 対応サーバー | Azure Arc Connected Machine agent が前提。Arc 側の ID と拡張機能管理を確認 |
| オンプレミス / 他クラウド | Arc 経由で Azure 管理対象にしたうえで AMA を展開 |
| Microsoft Sentinel 利用環境 | Syslog、CEF、Windows イベント、カスタムログの DCR 設計が重要 |
| WAD/LAD 利用環境 | 2026 年 3 月 31 日に非推奨・サポート終了済みのため、移行後の重複収集を防ぐ必要がある |
特に WAD/LAD を使っていた環境では、単純なエージェント差し替えではなく、収集対象、保存先、転送先、アラート、コストを見直す機会として扱うべきです。Microsoft は WAD/LAD が 2026 年 3 月 31 日に非推奨となり、サポートされなくなったことを明記しており、AMA 構成後は重複データを避けるために WAD/LAD を削除するよう案内しています。(Microsoft Learn)
Azure Monitor Agent の基本：DCR なしでは収集が始まらない
AMA の設計で初心者がつまずきやすいのは、「エージェント」と「収集設定」が分離されている点です。従来の Log Analytics agent や WAD/LAD では、ワークスペースや拡張機能の設定に収集内容が強く結びついていました。一方、AMA では DCR が「何を収集し、どのように処理し、どこへ送るか」を定義します。(Microsoft Learn)
| 項目 | 従来型エージェントで起きがちな考え方 | AMA での考え方 |
|---|---|---|
| 設定単位 | エージェントやワークスペース側で設定 | DCR で一元管理 |
| 収集対象 | VM 単位で個別設定が増えやすい | DCR を複数 VM に関連付け |
| コスト最適化 | 収集後に調整しがち | DCR の変換やフィルターで入口から調整 |
| 展開方法 | 手動設定が残りやすい | Azure Policy や IaC で標準化 |
| 移行時の注意 | 旧設定が残り重複収集しやすい | データ同等性確認後に旧エージェントを削除 |
実務では、AMA をインストールする作業と、DCR を作成・関連付ける作業を別々に管理してください。VM 拡張機能だけで AMA を入れた場合、DCR は自動作成されないため、少なくとも 1 つの DCR を作成して対象マシンに関連付ける必要があります。(Microsoft Learn)
VM 拡張機能としての要件：Publisher と Type を間違えない
Azure Monitor Agent は、Azure VM 拡張機能として実装されています。PowerShell、Azure CLI、ARM テンプレート、Azure Policy、ポータルなどで展開できますが、OS によって拡張機能の Type が異なります。(Microsoft Learn)
| OS | Publisher | Type |
|---|---|---|
| Windows | Microsoft.Azure.Monitor | AzureMonitorWindowsAgent |
| Linux | Microsoft.Azure.Monitor | AzureMonitorLinuxAgent |
この値を間違えると、テンプレートやポリシーは正しく見えても展開に失敗します。IaC で標準テンプレートを作る場合は、OS 判定と Type の出し分けを必ず入れてください。
また、TypeHandlerVersion は固定値を長期間放置しないほうが安全です。Microsoft は AMA のバージョンについて、直近 1 年以内にリリースされたバージョンをサポート対象とし、バグ修正は最新バージョンに提供すると説明しています。通常運用では自動拡張機能更新を有効にして、サポート対象バージョンから外れないようにするのが現実的です。(Microsoft Learn)
2026 年 6 月時点のバージョン更新で見るべきポイント
2026 年 6 月の AMA 拡張機能バージョンでは、Linux 1.42 が示されており、エージェント側のフィルター・変換処理の性能改善、SUSE 16 互換性、Metrics Extension 更新、Azure OpenTelemetry Collector コンポーネント更新、関連する CVE 対応、プロキシ設定の挙動修正、メモリリーク修正などが含まれています。Windows 側では 2026 年 5 月の 1.43 でインストーラークラッシュ修正や OpenSSL 更新が示されています。(Microsoft Learn)
管理者が見るべきポイントは、単に「新しいバージョンが出たか」ではありません。次の 3 点を確認してください。
| 確認項目 | なぜ重要か | 確認方法の例 |
|---|---|---|
| 自動更新が有効か | セキュリティ修正や信頼性改善を取り込めないリスクを下げるため | 拡張機能設定、Azure Policy、IaC テンプレートを確認 |
| Linux のプロキシ設定 | https_proxy や proxy.mode=none の扱いが監視データ送信に影響するため | Firewall / Proxy 経由環境で検証 VM を用意 |
| SUSE / OpenTelemetry / Metrics 利用有無 | OS やメトリック収集の更新影響を受ける可能性があるため | 対象 OS、DCR、メトリック送信先を棚卸し |
リリースは Azure Safe Deployment Practices に沿って段階的に展開されるため、全リージョン・全 VM に同時に同じバージョンが入るとは限りません。Azure VM とスケールセットでは自動更新の完了に通常 4〜6 週間程度かかり、Arc 対応サーバーでは追加検証によりさらに時間がかかる場合があります。(Microsoft Learn)
対応 OS と環境：x86 は対象外、カスタム OS イメージにも注意
Azure Monitor Agent の対応 OS は、Windows Server、Windows クライアント、主要 Linux ディストリビューション、Azure Local、Windows 365 Cloud PC などに広がっています。ただし、公式ドキュメントでは、一覧にある OS は x64 前提であり、x86 はサポートされないと説明されています。(Microsoft Learn)
Windows では Windows Server 2025、2022、2019、2016、Windows 11、Windows 10 1803 以降などが対象です。Linux では RHEL 系、Debian 系、SUSE、Amazon Linux、Azure Linux などが対象に含まれます。Azure Linux / CBL-Mariner では既定のディスクサイズが小さい場合があり、AMA のインストールと正常稼働には少なくとも 4 GB のディスクサイズが必要とされています。(Microsoft Learn)
注意したいのは、OS 名が対応一覧にあっても、過度にカスタマイズされたアプライアンス型 OS や、ユーザーが必要パッケージを追加できないホステッド環境ではサポートされない可能性がある点です。最小構成イメージ、CIS 強化イメージ、社内標準のハードニング済みイメージを使っている場合は、本番展開前に AMA のインストール、DCR 適用、データ送信までを検証してください。(Microsoft Learn)
権限要件：ポータル以外の展開ではロール不足に注意
Azure portal 以外の方法で AMA をインストールする場合、対象に応じたロール割り当てが必要です。Azure VM やスケールセットには仮想マシン共同作成者、Azure Arc 対応サーバーには Azure Connected Machine Resource Administrator が必要になります。また、ARM テンプレートや Azure Policy 経由で拡張機能を展開する場合は、Microsoft.Resources/deployments/* を含むロールも関係します。(Microsoft Learn)
| 作業 | 必要になりやすい権限 | 失敗しやすいポイント |
|---|---|---|
| Azure VM に AMA を導入 | Virtual Machine Contributor | VM は見えるが拡張機能を追加できない |
| Azure Arc 対応サーバーに AMA を導入 | Azure Connected Machine Resource Administrator | Arc リソース側の権限が不足する |
| ARM テンプレートで展開 | Microsoft.Resources/deployments/* を含むロール | デプロイ自体の権限が不足する |
| Azure Policy で大規模展開 | ポリシー割り当て、修復タスク、マネージド ID の権限 | ポリシーは割り当て済みだが修復されない |
| DCR を関連付け | DCR と対象リソースへの適切な権限 | エージェント導入済みでもデータが来ない |
実務では「監視担当者」「基盤担当者」「セキュリティ担当者」の権限境界で止まりやすい作業です。移行計画では、拡張機能展開、DCR 作成、DCR 関連付け、Log Analytics ワークスペース確認、旧エージェント削除の権限を分けて棚卸ししてください。
マネージド ID：大規模展開ではユーザー割り当て ID を優先する
Azure VM では、AMA 利用にマネージド ID が必要です。システム割り当てマネージド ID とユーザー割り当てマネージド ID の両方がサポートされますが、大規模展開ではユーザー割り当てマネージド ID が推奨されます。理由は、1 つの ID を複数 VM で共有でき、VM の増減に伴う Microsoft Entra ID 上の ID 作成・削除の増加を抑えやすいためです。(Microsoft Learn)
| 種類 | 向いている用途 | 注意点 |
|---|---|---|
| ユーザー割り当てマネージド ID | 大規模展開、Azure Policy 展開、標準化された運用 | 拡張機能設定に ID 情報を渡す必要がある |
| システム割り当てマネージド ID | 初期検証、小規模環境 | 大量 VM では ID の作成・削除が増えやすい |
| Arc 対応サーバーのシステム割り当て ID | Azure Arc 対応サーバー | Arc 対応サーバーではこの方式のみサポート |
Arc 対応サーバーでは、Azure Arc agent のインストール時にシステム割り当てマネージド ID が自動的に有効になります。オンプレミスや他クラウドのサーバーへ AMA を入れる場合は、先に Azure Arc Connected Machine agent の導入状態を確認してください。(Microsoft Learn)
ディスク容量：アップグレード時は一時的に余裕を持たせる
Azure Monitor Agent は、ローカル ファイルシステムにキャッシュやログを保持します。特に注意すべきなのは、AMA のアップグレード中に新旧 2 バージョンが一時的に共存するため、必要なディスク容量が実質的に増える点です。ディスクに余裕がない VM では、アップグレード失敗やデータ送信遅延の原因になります。(Microsoft Learn)
| 用途 | 環境 | 主なパス | 推奨容量 |
|---|---|---|---|
| パッケージのダウンロード・インストール | Linux | /var/lib/waagent/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent-{Version}/ | 700 MB |
| パッケージのダウンロード・インストール | Windows | C:\Packages\Plugins\Microsoft.Azure.Monitor.AzureMonitorWindowsAgent | 500 MB |
| 拡張機能ログ | Linux Azure VM | /var/log/azure/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent/ | 100 MB |
| 拡張機能ログ | Linux Azure Arc | /var/lib/GuestConfig/extension_logs/Microsoft.Azure.Monitor.AzureMonitorLinuxAgent-{version}/ | 100 MB |
| 拡張機能ログ | Windows Azure VM | C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.Monitor.AzureMonitorWindowsAgent | 100 MB |
| 拡張機能ログ | Windows Azure Arc | C:\ProgramData\GuestConfig\extension_logs\Microsoft.Azure.Monitor.AzureMonitorWindowsAgent | 100 MB |
| エージェント キャッシュ | Linux | /etc/opt/microsoft/azuremonitoragent, /opt/microsoft/azuremonitoragent | 500 MB |
| エージェント キャッシュ | Windows Azure VM | C:\WindowsAzure\Resources\AMADataStore.{DataStoreName} | 10.5 GB |
| エージェント キャッシュ | Windows Azure Arc | C:\Resources\Directory\AMADataStore.{DataStoreName} | 10.5 GB |
| イベント キャッシュ | Linux | /var/opt/microsoft/azuremonitoragent/events | 10 GB |
| イベント キャッシュ | Linux | /var/lib/rsyslog | 1 GB |
本番環境では、表の容量を「最低限の目安」として見るだけでなく、OS ディスクの空き容量アラートを設定しておくと安全です。特に Windows のキャッシュ領域、Linux のイベントキャッシュ、rsyslog の増加は、ログ量が多い環境で問題化しやすいポイントです。
ネットワーク要件：443/TCP を開けるだけでは足りない場合がある
AMA の通信は、直接接続、プロキシ、Log Analytics gateway、Private Link などに対応しています。ネットワーク制御では AzureMonitor と AzureResourceManager のサービス タグが必要になり、Firewall では各種エンドポイントへの 443/TCP のアウトバウンド通信を許可します。さらに、すべてのエンドポイントで HTTPS インスペクションを無効にする必要があります。(Microsoft Learn)
| ネットワーク構成 | 確認ポイント |
|---|---|
| 通常の Azure VM | AzureMonitor と AzureResourceManager サービスタグを許可 |
| Firewall 経由 | control、metrics、ODS、DCE ingest などへの 443/TCP を許可 |
| Private Link 利用 | DCR で DCE を使い、Azure Monitor Private Link Scope 側に DCE を追加 |
| プロキシ利用 | Windows / Linux の拡張機能設定で proxy mode、address、認証を設定 |
| カスタムログ / IIS ログ | DCE のパブリック IP 許可が必要になる場合がある |
| HTTPS インスペクション | 無効化が必要 |
よくある失敗は、Log Analytics ワークスペースへの送信先だけを許可し、DCR の取得先や DCE の取り込み先を許可していないケースです。エージェント導入は成功しても、DCR を取得できない、ログを送れない、Metrics 宛先だけ失敗する、といった症状になります。
Linux の暗号化ポリシー：FUTURE モードは使えない
Linux 環境では、システム全体の暗号化ポリシーを FUTURE モードにしていると AMA が動作しません。FUTURE モードでは一部の暗号アルゴリズムが無効化され、Azure Monitor バックエンドとの通信を妨げる可能性があるためです。現在の設定は sudo update-crypto-policies --show で確認できます。(Microsoft Learn)
セキュリティ強化済み Linux を使う組織では、次の流れで確認してください。
sudo update-crypto-policies --show結果が FUTURE の場合は、AMA の導入検証を止めて、セキュリティ基準と Microsoft のサポート要件を照合します。CIS、STIG、FIPS などのハードニング自体は AMA が広くサポートしていますが、公式 CIS ベンチマークと異なる独自カスタマイズが入っている場合はサポート外になる可能性があります。(Microsoft Learn)
移行期限：WAD/LAD と Log Analytics agent の残存確認が急務
2026 年時点で最も重要な運用タスクは、古いエージェントが残っていないかを確認することです。WAD/LAD は 2026 年 3 月 31 日に非推奨となりサポートされなくなっています。Log Analytics agent も 2024 年 8 月 31 日に廃止済みで、2026 年 3 月 2 日以降はデータアップロードが予告なく停止する可能性があると案内されています。(Microsoft Learn)
| 旧エージェント | 状態 | 管理者の対応 |
|---|---|---|
| Azure Diagnostics extension（WAD/LAD） | 2026 年 3 月 31 日に非推奨・サポート終了済み | AMA + DCR へ移行し、データ同等性確認後に削除 |
| Log Analytics agent（MMA/OMS） | 2024 年 8 月 31 日に廃止済み | AMA + DCR へ移行し、必要に応じて Migration Helper workbook を活用 |
| WAD/LAD と AMA の併用 | 移行期間中のみ許容 | 重複収集・重複課金を避けるため早期に旧エージェントを削除 |
| SCOM 専用の Log Analytics agent | 一部例外あり | SCOM 連携用途か Azure Monitor 収集用途かを切り分ける |
WAD/LAD の棚卸しには、Azure portal の各 VM で「拡張機能とアプリケーション」を確認する方法に加え、Azure Resource Graph で Microsoft.Azure.Diagnostics publisher を検索する方法があります。公式ドキュメントでも、サブスクリプション全体の確認用クエリが示されています。(Microsoft Learn)
resources
| where type contains "extension"
| extend parsedProperties = parse_json(properties)
| extend publisher = tostring(parsedProperties.publisher)
| project-away parsedProperties
| where publisher == "Microsoft.Azure.Diagnostics"
| distinct idLog Analytics agent からの移行では、Microsoft が Migration Helper workbook と DCR Config Generator を案内しています。大規模環境では、まず既存エージェント、ワークスペース、依存サービスを棚卸しし、小規模なパイロットで DCR を検証してから Azure Policy で展開する流れが現実的です。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
Azure Monitor Agent Requirements を読んだ後に、管理者が実際に取るべき行動は次のとおりです。
| 優先度 | 確認項目 | 具体的な確認内容 |
|---|---|---|
| 高 | 旧エージェントの残存 | WAD/LAD、MMA/OMS が残っていないか |
| 高 | DCR の関連付け | AMA 導入済み VM に DCR が関連付いているか |
| 高 | 収集データの同等性 | Windows イベント、Syslog、パフォーマンス、カスタムログが移行前後で揃っているか |
| 高 | 重複収集 | 旧エージェントと AMA が同じログを送っていないか |
| 高 | マネージド ID | Azure VM では ID 有効化、Arc ではシステム割り当て ID を確認 |
| 中 | ディスク空き容量 | AMA キャッシュ、ログ、イベントキャッシュ、アップグレード時の余裕を確認 |
| 中 | ネットワーク疎通 | サービスタグ、DCE、Private Link、プロキシ、HTTPS インスペクションを確認 |
| 中 | バージョン | 直近 1 年以内のサポート対象バージョンか、自動更新が有効か |
| 中 | Linux 暗号化ポリシー | FUTURE モードになっていないか |
| 中 | OS 対応 | x64、対応ディストリビューション、カスタムイメージの制約を確認 |
特に本番 VM では、エージェントのインストール成功だけで完了判定にしないでください。公式の移行手順でも、AMA 展開後は Heartbeat、パフォーマンス カウンター、Windows イベント、Syslog、カスタムログなどのデータ収集を検証してから展開を広げる流れが示されています。(Microsoft Learn)
失敗しやすいポイントと対処法
エージェントは入っているのにログが来ない
最も多い原因は DCR の未作成、DCR の未関連付け、DCR の対象リソース誤りです。VM 拡張機能で AMA を入れるだけでは DCR は作成されません。ポータルから DCR を作成する方法では、対象マシンに AMA が必要に応じてインストールされ、DCR 関連付けも作成されます。(Microsoft Learn)
対処法は、VM の拡張機能状態を見るだけでなく、対象 VM に DCR association があるか、DCR のデータソースが期待どおりか、送信先ワークスペースが正しいかを確認することです。
Arc 対応サーバーで認証エラーになる
Arc 対応サーバーでは、システム割り当てマネージド ID のみがサポートされます。Azure VM 向けに作ったユーザー割り当て ID 前提の展開テンプレートをそのまま Arc に流用すると、認証設計が合わないことがあります。(Microsoft Learn)
対処法は、Azure VM 用と Arc 対応サーバー用でポリシーや IaC テンプレートを分けることです。特にハイブリッド環境では、Arc agent の状態、マネージド ID、拡張機能の Provisioning 状態をセットで確認してください。
移行後にログ量とコストが増える
旧エージェントを残したまま AMA を動かすと、同じ Windows イベント、Syslog、パフォーマンス データが二重に取り込まれることがあります。Microsoft は、AMA のデータ収集を確認した後に旧エージェントを削除して重複収集を避けるよう案内しています。(Microsoft Learn)
対処法は、移行期間中だけ併用し、KQL で移行前後のデータ件数を比較したうえで旧エージェントを削除することです。DCR の変換やフィルターを使えば、不要データを入口で減らし、コスト最適化にもつなげられます。(Microsoft Learn)
Linux でインストールや通信が不安定になる
Linux では、対応ディストリビューション、Python、必要パッケージ、rsyslog、暗号化ポリシー、プロキシ設定が影響します。特に FUTURE モードの暗号化ポリシーは AMA と互換性がありません。(Microsoft Learn)
対処法は、本番投入前に OS 標準イメージと社内カスタムイメージの両方で検証することです。CIS や STIG の準拠を維持しながら AMA を使う場合も、公式にサポートされる範囲のハードニングかどうかを確認してください。
実務での推奨手順：小さく検証してから Azure Policy で展開する
グローバル環境や複数サブスクリプションを持つ組織では、いきなり全 VM に AMA を展開するのではなく、次の順序で進めるのが安全です。
| フェーズ | 作業 | 完了条件 |
|---|---|---|
| 棚卸し | WAD/LAD、MMA/OMS、既存ワークスペース、収集データを確認 | 旧エージェントと収集対象の一覧がある |
| 設計 | Windows / Linux / Arc / Sentinel / カスタムログごとに DCR を設計 | DCR、DCE、送信先、変換方針が決まっている |
| パイロット | 少数 VM に AMA と DCR を適用 | Heartbeat、ログ、メトリックが期待どおり届く |
| 比較 | 旧エージェントと AMA のデータ件数・項目を比較 | 欠落や重複の有無を確認できている |
| 展開 | Azure Policy または IaC で標準展開 | 新規 VM にも自動適用される |
| 削除 | 旧エージェントを削除 | 重複収集がなく、監視・アラートが継続している |
| 運用 | 自動更新、ディスク、ネットワーク、DCR 変更管理を継続 | バージョンと収集品質を定期確認できる |
Azure Policy を使うと、AMA 拡張機能の自動展開と DCR association の適用を大規模に管理できます。Microsoft も、Log Analytics agent からの移行では、パイロット検証後に Azure Policy で大規模展開する流れを案内しています。(Microsoft Learn)
グローバル向け運用で注意したいリージョンとクラウドの違い
Azure Monitor Agent は、一般提供機能についてグローバル Azure リージョン、Azure Government、21Vianet が運用する Azure で利用できます。ただし、VM 拡張機能はエアギャップ クラウドではサポートされず、Windows MSI クライアント インストーラーはエアギャップ クラウドをサポートする、と説明されています。(Microsoft Learn)
また、ネットワーク エンドポイントのサフィックスはクラウドによって異なります。Commercial Azure は .com、Azure Government は .us、21Vianet 版 Azure は .cn です。グローバル展開では、Firewall ルールやプロキシ許可リストを単一リージョン前提で作らないようにしてください。(Microsoft Learn)
多国籍企業では、同じ DCR 設計でも、リージョン、データ所在地、Private Link、Sentinel ワークスペース、政府クラウド利用有無によって実装が変わります。標準テンプレートを作る場合は、クラウド種別、リージョン、DCE、ワークスペース ID、マネージド ID をパラメーター化しておくと運用が安定します。
まとめ：Azure Monitor Agent Requirements は移行と標準化の起点になる
Azure Monitor Agent Requirements で確認すべき本質は、AMA の導入条件を満たすことだけではありません。DCR を中心に、収集対象、認証、ネットワーク、ディスク、バージョン、旧エージェントの削除までを一つの運用設計としてまとめることが重要です。
まず実施すべき行動は、WAD/LAD と Log Analytics agent の残存確認です。次に、対象 VM と Arc 対応サーバーの OS、マネージド ID、ネットワーク、ディスク容量を確認し、小規模なパイロットで AMA + DCR のデータ収集を検証します。その後、Azure Policy や IaC で標準展開し、旧エージェントを削除して重複収集と余計なコストを防ぎます。
AMA は単なるエージェント更新ではなく、Azure Monitor のデータ収集を DCR ベースに再設計するタイミングです。移行作業を「期限対応」で終わらせず、不要ログの削減、DCR の標準化、セキュアなマネージド ID 認証、グローバル展開に耐えるネットワーク設計まで見直すことで、監視基盤の信頼性と運用効率を大きく改善できます。
コメント