Management & Monitoring

カテゴリ概要

Azure の管理・監視サービスは、Azure Monitor を中心とした統合的な可観測性基盤と、Bicep / ARM Templates による IaC、Azure Policy によるコンプライアンス強制、Azure Arc によるハイブリッド・マルチクラウド管理を提供している。AWS では CloudWatch・CloudTrail・CloudFormation・Config・Systems Manager 等が個別サービスとして存在するが、Azure ではこれらの機能がより統合されたサービス群として提供される傾向がある。特に Azure Arc は AWS に直接の対応がない独自の機能であり、オンプレミスや他クラウドのリソースを Azure のコントロールプレーンで一元管理できる点が大きな差別化要素である。

サービスマッピング一覧

主要サービス詳細

Azure Monitor（AWS: CloudWatch）

Azure リソースとアプリケーションの統合モニタリングプラットフォームで、メトリクス・ログ・アラート・Application Insights を単一のサービスとして提供する。

AWS エンジニアが知っておくべき違い:

• CloudWatch + CloudWatch Logs + X-Ray を統合したサービス — AWS では監視（CloudWatch）、ログ管理（CloudWatch Logs）、分散トレーシング（X-Ray）が事実上別々のサービスとして機能するが、Azure Monitor はこれらすべてを 1 つのプラットフォームに統合している。メトリクス、ログ、トレースを同一のインターフェースで横断的に分析できる
• ログ分析に KQL（Kusto Query Language）を使用 — CloudWatch Logs Insights の独自クエリ構文に対し、Azure Monitor は KQL を使用する。KQL は SQL に似た構文で学習コストが低く、結合・集計・時系列分析などの高度なクエリが容易に書ける
• Log Analytics ワークスペースにログを集約 — CloudWatch Logs のロググループに相当するが、複数のリソースやサブスクリプションからのログを単一のワークスペースに集約して横断分析できる設計が標準
• アラートルールの構造が異なる — CloudWatch Alarms がメトリクスごとに個別に設定するのに対し、Azure Monitor のアラートルールはメトリクス・ログ・アクティビティログを統一的なフレームワークで管理し、アクショングループ（通知先の定義）を共有できる
• Workbooks でカスタムダッシュボードを構築 — CloudWatch Dashboards に相当するが、KQL クエリ結果の可視化やパラメータ化されたインタラクティブなレポートを作成できる

Application Insights（AWS: X-Ray）

Azure Monitor のサブ機能として提供される APM（Application Performance Management）サービスで、アプリケーションのパフォーマンス監視・分散トレーシング・障害検知を行う。

AWS エンジニアが知っておくべき違い:

• Azure Monitor の一部として統合されている — X-Ray が独立したサービスであるのに対し、Application Insights は Azure Monitor のサブ機能という位置づけ。メトリクスやログと同じプラットフォーム上でトレースデータを分析できるため、可観測性の統合度が高い
• 自動インストルメンテーションの対応範囲が広い — .NET、Java、Node.js、Python 等の主要言語で、コード変更なし（またはごく少量の変更）でテレメトリを収集できる。X-Ray SDK の明示的な組み込みと比較して導入コストが低い
• スマート検出機能 — 異常なレスポンスタイム、失敗率の急増、メモリリーク等を機械学習ベースで自動検出し、アラートを生成する。X-Ray にはこの機能はない
• アプリケーションマップで依存関係を可視化 — サービス間の呼び出し関係、レスポンスタイム、エラー率をトポロジマップとして自動生成する。X-Ray の Service Map に相当するが、Azure Monitor のメトリクスと統合されている

ARM Templates / Bicep（AWS: CloudFormation）

Azure リソースを宣言的に定義・デプロイする IaC ツール。ARM Templates は JSON ベースのテンプレート、Bicep はその DSL（ドメイン固有言語）で、より簡潔な構文で同等の定義が可能。

AWS エンジニアが知っておくべき違い:

• Bicep は ARM JSON テンプレートの簡略版 DSL — CloudFormation の YAML / JSON テンプレートに相当するが、Bicep は型安全・自動補完・モジュール化に優れた独自構文を持つ。ARM JSON テンプレートに直接コンパイルされるため、ARM の全機能を利用可能。CloudFormation に CDK があるように、ARM Templates に Bicep がある、という対応関係に近い
• What-if 操作で変更プレビュー — CloudFormation の Change Set に相当する機能として、az deployment group what-if コマンドでデプロイ前に変更内容をプレビューできる
• デプロイスコープが柔軟 — CloudFormation がスタック（リージョン単位）でデプロイするのに対し、Bicep / ARM Templates はリソースグループ・サブスクリプション・管理グループ・テナントの 4 つのスコープでデプロイできる
• モジュールによる再利用 — Bicep のモジュール機能で、テンプレートを分割・再利用できる。CloudFormation のネストされたスタックに相当するが、より直感的な構文で参照できる
• ステート管理が不要 — CloudFormation と同様に、Azure 側でリソースの状態を管理する。Terraform のようなローカルステートファイルの管理は不要

Azure Policy（AWS: AWS Config + SCP）

Azure リソースのコンプライアンスを評価・強制するサービスで、組織のルールやベストプラクティスへの準拠をリソースのライフサイクル全体にわたって保証する。

AWS エンジニアが知っておくべき違い:

• リソース作成時にルールを強制（Deny 効果）できる — AWS Config Rules が主に事後検出・修復のモデルであるのに対し、Azure Policy は Deny 効果を使ってポリシー非準拠のリソース作成自体を拒否できる。SCP の制御に近いが、より細かいリソースプロパティレベルでの制御が可能
• 組み込みポリシーが豊富 — Azure が提供する数百の組み込みポリシー定義を利用でき、カスタムポリシーを一から作成する必要が少ない。Config Rules のマネージドルールに相当するが、Deny や自動修復まで含めた定義が標準
• イニシアティブ（ポリシーセット）でグルーピング — 複数のポリシーをイニシアティブとしてまとめて割り当てできる。コンプライアンス標準（CIS、ISO 27001 等）に対応したイニシアティブが事前定義されている
• スコープの階層的な割り当て — 管理グループ・サブスクリプション・リソースグループの任意のレベルにポリシーを割り当てでき、子スコープに自動継承される

Azure Resource Graph（AWS: AWS Config Advanced Query）

Azure のすべてのサブスクリプションにまたがるリソースを KQL で高速に検索・集計するサービス。

AWS エンジニアが知っておくべき違い:

• リアルタイムに近いリソース検索が可能 — AWS Config の Advanced Query がリソース構成のスナップショットに対してクエリを実行するのに対し、Resource Graph は Azure Resource Manager のデータに直接クエリを発行するため、ほぼリアルタイムの結果を返す
• KQL でクエリを記述 — SQL に似た KQL 構文で、結合・集計・プロジェクション等の高度なクエリが可能。数千のリソースに対しても高速にレスポンスを返す
• Azure Portal の検索バーと統合 — Portal 上部の検索バーからリソースを検索する際、内部的に Resource Graph が使用されている

Azure Automation（AWS: Systems Manager）

PowerShell や Python の Runbook によるクラウドリソースの運用自動化サービス。

AWS エンジニアが知っておくべき違い:

• Runbook ベースの自動化 — Systems Manager の Run Command や Automation ドキュメントに相当するが、Azure Automation は PowerShell / Python スクリプトを Runbook として管理し、スケジュール実行やイベントトリガーで自動化する
• Update Management 機能 — Systems Manager Patch Manager に相当する OS パッチ管理機能を統合している
• Desired State Configuration（DSC） — Systems Manager State Manager に相当するが、PowerShell DSC を使用してサーバーの構成を宣言的に管理する
• Hybrid Runbook Worker — Azure Arc と連携して、オンプレミスサーバーに対しても Runbook を実行できる。Systems Manager のハイブリッド環境管理に相当

Azure Arc（AWS: 該当なし）

オンプレミス、エッジ、マルチクラウドのリソースを Azure のコントロールプレーンに統合し、一元管理するサービス。

AWS エンジニアが知っておくべき違い:

• AWS に直接の対応サービスがない — AWS Systems Manager でオンプレミスサーバーの管理は可能だが、Azure Arc は サーバー・Kubernetes クラスター・SQL Server・VMware 環境など、幅広いリソースタイプを Azure のリソースとして登録し、Azure Portal から統合管理できる
• Azure Policy・Monitor・Defender をオンプレに拡張 — Arc に登録されたリソースに対して、Azure Policy のコンプライアンス評価、Azure Monitor の監視、Microsoft Defender for Cloud のセキュリティ保護を適用できる
• GitOps ベースの Kubernetes 管理 — Arc 対応 Kubernetes クラスターに対して、Flux を使った GitOps 構成管理を Azure から一元的にデプロイ・監視できる
• マルチクラウド戦略の中核 — 他クラウド（AWS・GCP）上のリソースを Azure Arc に登録することで、Azure を統合管理プレーンとしたマルチクラウド運用が可能になる

Management Groups（AWS: Organizations）

複数の Azure サブスクリプションを階層的に管理し、ポリシーやアクセス制御を一括適用する仕組み。

AWS エンジニアが知っておくべき違い:

• Organizations の OU（組織単位）に相当 — 管理グループをネストしてツリー構造を作成し、上位で設定したポリシーや RBAC を下位のサブスクリプションに継承させる
• Azure Policy と統合 — 管理グループレベルで Azure Policy を割り当てることで、配下のすべてのサブスクリプションにガバナンスルールを強制できる。SCP + Config Rules の役割を Azure Policy が担う
• 最大 6 階層のネスト — ルート管理グループを含めて 6 階層までネスト可能

Azure Cost Management（AWS: Cost Explorer / Budgets）

Azure の利用コストを分析・最適化するサービスで、予算設定やコスト予測、推奨事項の提示を行う。

AWS エンジニアが知っておくべき違い:

• Cost Explorer + Budgets + Cost Anomaly Detection を統合 — AWS では別機能として提供されるコスト分析・予算管理・異常検知が、Azure Cost Management として統合されている
• AWS コストも管理可能 — Azure Cost Management は AWS アカウントの Cost and Usage Report を取り込んで、Azure と AWS のコストを単一のダッシュボードで分析できる（マルチクラウドコスト管理）
• Azure Advisor と連携 — Advisor のコスト最適化推奨事項と統合されており、未使用リソースの検出やリザーブドインスタンスの推奨が直接表示される

Azure Advisor（AWS: Trusted Advisor）

Azure 環境のベストプラクティスに基づく推奨事項を提示するサービス。

AWS エンジニアが知っておくべき違い:

• 5 カテゴリで推奨事項を提示 — コスト、セキュリティ、信頼性、オペレーショナルエクセレンス、パフォーマンスの 5 カテゴリ。Trusted Advisor の 5 カテゴリとほぼ対応する
• 追加料金なしで全機能を利用可能 — Trusted Advisor は Business / Enterprise サポートプランで全チェック項目が解放されるが、Azure Advisor は全サブスクリプションで無料利用可能
• 推奨事項のスヌーズ・却下が可能 — 対応不要な推奨事項を一定期間スヌーズしたり、完全に却下したりできる

Azure Activity Log（AWS: CloudTrail）

Azure サブスクリプション内のリソースに対する操作を記録する監査ログサービス。

AWS エンジニアが知っておくべき違い:

• 自動的に有効化される — CloudTrail はデフォルトで 90 日間のイベント履歴が確認可能だが、S3 への長期保存には明示的な証跡（Trail）の作成が必要。Azure Activity Log はサブスクリプション作成時に自動で有効化され、90 日間保持される
• Log Analytics ワークスペースに送信して長期保存・分析 — CloudTrail が S3 + Athena で分析するのに対し、Activity Log は診断設定で Log Analytics ワークスペースに送信し、KQL で分析する。Storage Account へのアーカイブも可能
• カテゴリベースのフィルタリング — 管理操作（Administrative）、サービス正常性（Service Health）、リソース正常性（Resource Health）、アラート、自動スケール、推奨事項などのカテゴリでフィルタリングできる

AWS との主要な違い

Azure Monitor の統合度

AWS では CloudWatch（メトリクス・ログ・アラーム）、X-Ray（分散トレーシング）、CloudWatch Logs（ログ管理）がそれぞれ事実上独立したサービスとして機能し、可観測性スタックを構築するには複数のサービスを組み合わせる必要がある。Azure Monitor はメトリクス、ログ（Log Analytics）、トレース（Application Insights）、アラートを単一のプラットフォームに統合しており、相互の連携がシームレスである。特に KQL を使った横断的なクエリは、CloudWatch Logs Insights と比較して表現力が高い。

IaC: Bicep と CloudFormation の設計思想

CloudFormation は JSON / YAML の汎用フォーマットを使用するのに対し、Bicep は Azure リソース定義に特化した DSL として設計されている。Bicep は型安全、自動補完、モジュール化に優れ、ARM JSON テンプレートの冗長さを大幅に削減する。また、Bicep はリソースグループ・サブスクリプション・管理グループ・テナントの 4 つのスコープでデプロイ可能であり、CloudFormation のリージョン単位デプロイよりも柔軟なスコープ制御ができる。

Azure Arc によるハイブリッド・マルチクラウド管理

Azure Arc は AWS に直接の対応がない Azure 独自の機能である。AWS でもオンプレミスサーバーの管理は Systems Manager で可能だが、Azure Arc はサーバーだけでなく Kubernetes クラスター、SQL Server、VMware 環境などを Azure のリソースとして統合し、Azure Policy・Monitor・Defender の適用対象に含められる。マルチクラウド環境を Azure をコントロールプレーンとして一元管理する戦略は、AWS にはないアプローチである。

ポリシー強制のタイミング

AWS Config Rules は主にリソースの構成変更を事後的に検出し、非準拠を通知・修復するモデルである。一方、Azure Policy は Deny 効果によってポリシー非準拠のリソース作成自体をブロックできるため、予防的なガバナンスが標準機能として組み込まれている。AWS で同等の予防的制御を行うには SCP やサービスコントロールポリシーとの組み合わせが必要になるが、Azure Policy はリソースプロパティレベルでの細かい制御が単一サービスで可能である。

Activity Log の自動有効化

CloudTrail はデフォルトでイベント履歴が確認できるものの、長期保存には証跡の作成と S3 バケットの設定が必要である。Azure Activity Log はサブスクリプション作成時に自動で有効化され、特別な設定なしで 90 日間のログが保持される。長期保存が必要な場合は診断設定で Log Analytics や Storage Account に送信するが、基本的な監査ログは初期設定不要で利用できる点が異なる。

サービス選定の指針