Azure Update Manager

解決する課題

サーバーの OS パッチ適用は、放置すると脆弱性が積み上がり、かといって手作業で進めるとサーバーごとに状態がばらつき、再起動のタイミング管理も煩雑になります。Azure Update Manager は、Windows と Linux のサーバーへの更新を一元的に評価・配布・スケジュールし、適用状況（コンプライアンス）を可視化することで、こうした取りこぼしや属人化を減らします。

• 多数のサーバーのパッチ未適用状況をまとめて把握したい
• メンテナンス時間枠に合わせて無人でパッチを配布したい
• Azure VM だけでなくオンプレや他クラウドのサーバーも同じ仕組みで更新したい
• どのマシンが基準を満たしているか、コンプライアンスを継続的に確認したい

AWS で言えば Systems Manager Patch Manager に近い位置づけのサービスです。

主要概念と用語

• 評価（アセスメント）: マシンに不足している更新プログラムを調べる処理。定期評価を有効にすると、一定間隔で自動的に最新状態を取得する
• 更新の展開（デプロイ）: 実際にパッチを適用する処理。今すぐ実行するオンデマンド適用と、時間枠を決めて行うスケジュール適用がある
• メンテナンス構成（Maintenance Configuration）: スケジュール適用の定義。実行時刻・繰り返し・対象更新の分類・再起動の方針などを持ち、対象マシンを割り当てて使う
• 動的スコープ: メンテナンス構成の対象を、サブスクリプションやリソース グループ、タグなどの条件で動的に決める仕組み。新規マシンも条件に合えば自動で対象になる
• 更新の分類: セキュリティ更新・重要な更新など、適用対象を種類で絞り込む区分。特定の KB やパッケージを含める/除外する指定もできる
• コンプライアンス: マシンが必要な更新を適用済みかどうかの状態。準拠/非準拠を一覧やダッシュボードで確認できる
• Azure Arc 対応サーバー: Azure 外のマシンを Arc で接続したもの。Update Manager は Arc 経由でオンプレや他クラウドのサーバーも同じ操作対象にできる
• 定期的なアセスメント / ホットパッチ: 自動評価の有効化設定や、再起動を伴わずに一部の更新を当てる方式など、運用負荷を下げるための関連機能

仕様・制限・クォータ

• 対応 OS は Windows / Linux の主要ディストリビューションで、対象は Azure VM と Azure Arc 対応サーバー。サポート対象の OS バージョンは更新されるため公式ドキュメントで確認する
• 旧来の Automation の更新管理（Update Management）からの移行先であり、Log Analytics ワークスペースを前提とせず、ネイティブな仕組みで動作する
• スケジュール適用はメンテナンス構成で定義し、1回のメンテナンス時間枠には**最大実行時間（タイムアウト）**の上限がある。時間内に終わらない更新は次回に持ち越される
• 適用できるのは OS の更新プログラムであり、アプリケーション固有の更新や、サポート対象外プラットフォームの更新は範囲外
• 1つのメンテナンス構成や動的スコープに割り当てられる対象数などに上限があり、変動しやすい具体値は公式の制限ページで都度確認する

内部の仕組み

Azure Update Manager は SaaS（サービスとして提供される） 形式で動作し、評価や配布の管理に専用のエージェントを追加導入する必要がありません。Azure VM では既存の VM エージェント、Azure Arc 対応サーバーでは Arc の接続エージェントを通じて、各マシンの更新状態の評価と更新プログラムの適用が行われます。

評価では、マシンが OS のソース（Windows Update / WSUS、または Linux のパッケージ リポジトリなど）に問い合わせ、不足している更新の一覧を取得します。適用フェーズでは、その更新をダウンロードしてインストールし、設定に応じて再起動を制御します。これらの状態は Azure 側に集約され、コンプライアンス情報として一覧化されます。

スケジュール適用はメンテナンス構成を起点に動きます。指定した時間枠が来ると、対象マシン（静的な割り当て、または動的スコープの条件に合致するマシン）に対して評価と適用が実行されます。

設計パターン / ベストプラクティス

• 環境ごとのリング配布: 開発 → 検証 → 本番の順にメンテナンス構成を分け、まず影響の小さい環境へ適用してから本番に広げる
• 動的スコープでの自動編入: タグやリソース グループで対象を定義し、新規サーバーも条件に合えば自動でパッチ対象に含める。設定漏れを防げる
• メンテナンス時間枠の整合: 業務の閑散時間帯に時間枠を設定し、再起動方針（必要時のみ再起動など）を明示する
• 除外リストの管理: 互換性問題が分かっている特定の更新は除外指定し、検証後に解除する運用にする
• 適用前後の検証: 適用後のコンプライアンスとアプリの正常性を確認し、問題時に切り戻せるよう構成のバックアップやスナップショットを併用する

運用・監視

• 各マシンの**コンプライアンス（準拠/非準拠）**と適用履歴を Update Manager のダッシュボードで確認し、非準拠マシンを優先的に対処する
• スケジュール適用の結果はメンテナンス実行の履歴として残り、成功・失敗・タイムアウトを切り分けられる
• 適用が進まない典型要因は、マシン側エージェントの停止、更新ソース（WSUS / リポジトリ）への到達性不足、時間枠内に終わらないタイムアウト
• 大規模環境では Azure Policy と組み合わせ、定期評価の有効化やスケジュール適用を組織全体に強制・展開できる
• 重要イベントは Azure Monitor へ連携してアラート化し、非準拠の増加や適用失敗を検知する

コスト

Azure VM に対する更新管理の基本機能は追加料金なしで利用できます。一方、Azure Arc 対応サーバー（オンプレや他クラウドのマシン）に対する更新管理は、マシン単位の課金が発生します。料金は変動するため、見積もりは公式の料金ページで確認してください。

セキュリティ

• パッチ適用は脆弱性の蓄積を防ぐ基本的なセキュリティ対策であり、定期評価とスケジュール適用で適用遅延を最小化する
• Update Manager の操作権限は Azure RBAC で制御し、メンテナンス構成の作成・適用の実行権限を必要な担当者に限定する
• セキュリティ更新の分類を優先して配布し、重要度の高い更新を後回しにしない運用にする
• Arc 対応サーバーでは、Arc エージェントの接続と認証が経路となるため、エージェントの正常性と権限を継続的に点検する

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: パッチ適用をスケジュール化・動的スコープ化して標準化し、手作業と属人化を減らす中核機能
• セキュリティ: OS の脆弱性を放置せず、セキュリティ更新を継続的に適用してリスクを抑える
• 信頼性: メンテナンス時間枠と再起動方針を制御し、計画的な適用でサービス影響を最小化する
• コスト最適化: Azure VM では追加料金なしで運用でき、Arc 対象を必要範囲に絞ることで管理コストを抑える

試験で問われるポイント

関連サービス・比較

Azure Update Manager は、サーバーのパッチ適用という目的で AWS の Systems Manager Patch Manager と対応づけて理解すると分かりやすいです。

ハンズオン / CLI例

# 1台の VM に対して、不足更新の評価を今すぐ実行
az vm assess-patches \
  --resource-group demo-rg \
  --name demo-vm

# オンデマンドでパッチを適用（再起動は必要時のみ、対象はセキュリティと重要な更新）
az vm install-patches \
  --resource-group demo-rg \
  --name demo-vm \
  --maximum-duration PT2H \
  --reboot-setting IfRequired \
  --classifications-to-include-win Critical Security

# スケジュール適用用のメンテナンス構成を作成（毎週の時間枠を定義）
az maintenance configuration create \
  --resource-group demo-rg \
  --name weekly-patch \
  --location japaneast \
  --maintenance-scope InGuestPatch \
  --recur-every "1Week" \
  --duration "02:00" \
  --reboot-setting IfRequired