Azure Automation

解決する課題

繰り返し発生する運用作業を人手で行うと、手順のばらつきや夜間対応の負担、操作ミスが避けられません。Azure Automation は、こうした定型運用を Runbook としてコード化し、決められた時刻や条件で無人実行できるようにします。

• VM の夜間停止・朝の起動などスケジュール運用を自動化したい
• 障害検知（アラート）を起点に自動で対処したい
• タグ付け・クリーンアップ・証明書更新など定型タスクを標準化したい
• オンプレや他クラウドも含めて横断的に運用処理を回したい

AWS で言えば Systems Manager（特に Automation ランブックや State Manager、Maintenance Window） に近い位置づけのサービスです。

主要概念と用語

• Automation アカウント: Runbook・資産・スケジュールなどをまとめる管理単位。リージョンに紐づくリソースで、ここにマネージド ID を割り当てて Azure リソースを操作する
• Runbook: 自動化処理の本体。種類として PowerShell / PowerShell Workflow / Python のスクリプト型と、ローコードの グラフィカル Runbook がある
• ジョブ: Runbook を実行した1回分の実行インスタンス。ステータスやログ、出力を確認できる
• 共有リソース（資産）: Runbook から参照する 変数・資格情報・証明書・接続・モジュール。秘密情報は暗号化して保持される
• スケジュール: Runbook を定期または指定時刻に起動する設定。Webhook やアラートのアクションからも起動できる
• ハイブリッド Runbook Worker: Azure 外（オンプレや他クラウド）の OS 上で Runbook を実行する仕組み。Azure 境界の外側の操作に使う
• State Configuration（DSC）: マシンの構成を望ましい状態に保つ機能。新規構成では Azure Machine Configuration（旧称 Guest Configuration）が後継として案内される
• 更新管理 / インベントリ / 変更追跡: 旧来 Automation に含まれた機能群。現在は Azure Update Manager など別サービスへ移行が進んでいる

仕様・制限・クォータ

• Runbook には最大実行時間の上限があり、長時間ジョブはこの制約を意識して分割や非同期化を検討する
• Azure サンドボックスで実行されるジョブには CPU・メモリ・実行時間の上限があり、重い処理はハイブリッド Runbook Worker での実行が適する
• 共有リソースの変数・資格情報・証明書などには数や容量の上限があり、大量データの受け渡しには向かない
• PowerShell / Python とも複数のランタイム バージョンに対応するが、利用できるバージョンは更新されるため、最新の対応状況は公式ドキュメントで確認する
• Automation アカウントはリージョン リソースであり、対象リソースとの配置やネットワーク到達性を設計時に考慮する

変動しやすい具体的な上限値は公式の制限ページで都度確認してください。

内部の仕組み

Runbook は既定では Azure が管理するサンドボックス上で実行されます。Runbook が Azure リソースを操作するときは、Automation アカウントに割り当てたマネージド ID の権限（Azure RBAC）で API を呼び出します。資格情報をスクリプトに直接書く必要がなく、秘密はアカウント内で暗号化して保持されます。

Azure の外にある対象を操作する場合は、その OS 上にハイブリッド Runbook Worker を導入し、Runbook をローカル実行します。これにより、オンプレミスのサーバーや他クラウド、特定ネットワーク内のリソースにも到達できます。

起動経路は複数あり、スケジュールによる定期実行、Webhook による外部からの起動、Azure Monitor アラートのアクションとしての起動などを組み合わせて、無人運用やイベント駆動の自動対処を構成します。

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

• スケジュール運用: 開発環境 VM の夜間停止・朝起動などをスケジュール付き Runbook で自動化し、コストと手間を削減する
• アラート駆動の自動修復: Azure Monitor アラート → アクション グループ → Runbook 起動で、検知から一次対処までを自動化する
• ハイブリッド運用: Azure 境界外の処理はハイブリッド Runbook Worker に寄せ、サンドボックスの制約と到達性の問題を回避する
• 冪等性とログ出力: 再実行しても安全な作りにし、出力・詳細ログを残してジョブ単位で追跡できるようにする
• モジュール化: 共通処理はモジュールとして取り込み、Runbook 側を薄く保つ。バージョンを固定して再現性を確保する

運用・監視

• ジョブの成否・実行ログは Automation アカウントのジョブから確認でき、診断設定で Log Analytics へ送って横断監視・アラート化できる
• 失敗ジョブは**例外メッセージとストリーム（詳細/警告/エラー）**を確認し、権限不足かロジックかを切り分ける
• 動かない原因の典型は、マネージド ID への RBAC 未割り当て、必要モジュール未インストール、サンドボックスの実行時間・リソース超過
• ハイブリッド Worker 経由のジョブは、Worker 側のエージェント稼働とネットワーク到達性も点検する

コスト

課金は主に **Runbook のジョブ実行時間（分）**で発生し、一定の無料枠が用意されています。構成管理（DSC で管理するノード数）など機能ごとに別の課金軸があります。料金は変動するため、見積もりは公式の料金ページで確認してください。

セキュリティ

• Runbook の実行権限は Automation アカウントのマネージド ID + Azure RBAC で制御し、対象スコープに最小権限を付与する
• 秘密情報は Runbook に直書きせず、資格情報・証明書・暗号化変数として保持するか、Key Vault を参照する
• Automation アカウントや Runbook への操作権限は RBAC で限定し、コントロール プレーン操作はアクティビティ ログで監査する
• ネットワークを絞る場合はプライベート エンドポイントで接続経路を限定する

Well-Architected の観点

• 運用上の優秀性（Operational Excellence）: 手順を Runbook としてコード化することで、再現性・標準化・無人実行を実現し、人手とミスを減らす中核サービス
• 信頼性: アラート駆動の自動修復で平均復旧時間（MTTR）を短縮できる。一方で Runbook 自体の失敗監視と冪等性の確保が前提
• セキュリティ: マネージド ID と最小権限、秘密の安全な保持で、認証情報の散在を防ぐ
• コスト最適化: スケジュールによる非稼働時間の停止など、運用自動化そのものがコスト削減手段になる

試験で問われるポイント

関連サービス・比較

Azure Automation は、運用自動化という目的で AWS の Systems Manager と対応づけて理解すると分かりやすいです。

ハンズオン / CLI例

# Automation アカウントを作成（システム割り当てマネージド ID を有効化）
az automation account create \
  --resource-group demo-rg \
  --name demo-aa \
  --location japaneast \
  --assign-identity

# PowerShell Runbook を作成
az automation runbook create \
  --resource-group demo-rg \
  --automation-account-name demo-aa \
  --name Stop-DevVMs \
  --type PowerShell

# ローカルのスクリプトを Runbook の内容として取り込み、発行
az automation runbook replace-content \
  --resource-group demo-rg \
  --automation-account-name demo-aa \
  --name Stop-DevVMs \
  --content @stop-dev-vms.ps1
az automation runbook publish \
  --resource-group demo-rg \
  --automation-account-name demo-aa \
  --name Stop-DevVMs

# Runbook を手動で実行してジョブを開始
az automation runbook start \
  --resource-group demo-rg \
  --automation-account-name demo-aa \
  --name Stop-DevVMs