はじめに
最近 Azure に触れる機会が増えてきたので、AWS と Azure の監視ツールについての比較をまとめてみました
筆者は普段 AWS を主に利用しているため、その視点から Azure の監視機能を見ていきます。
今回は、基本的な監視項目であるログ、トレース、メトリクスにフォーカスして比較していきます。
監視機能の主な分類
| AWS | Azure | |
|---|---|---|
| ログ | Amazon CloudWatch Logs | Azure Monitor Log |
| トレース | AWS X-Ray | Application Insights |
| メトリクス | Amazon CloudWatch (メトリクス機能) | Azure Monitor Metrics |
比較観点
- 導入方法
- コスト
- マルチクラウド対応
- セキュリティ・コンプライアンス
- 拡張性
各機能と観点ごとの比較
ログ
| サービス | 導入方法 | コスト | マルチクラウド対応 | セキュリティ・コンプライアンス | 拡張性 |
|---|---|---|---|---|---|
| Amazon CloudWatch Logs | 基本的にIAMロールを付与するだけで利用可能 ※EC2やオンプレミスサーバーの場合、追加でエージェントのインストール と通信経路の確保が必要 |
- 取り込み料金(1GBあたり) - ログ管理料金(1GBあたり) |
対応可 ※エージェントのインストールとIAMロールの付与、通信経路の確保が必要 |
- 機密データのマスキングに対応 - ログの暗号化管理可能(デフォルトで有効) - クロスアカウント制御可能 |
- Microsoft Sentinel, Splunk, Datadog などと連携が可能 - ログ分析機能を内蔵 - メトリクスの生成機能やX-Rayへの連携も可能 |
| Azure Monitor Log | ログ監視をするリソース側で設定の有効化が必要 ※一部サービスのリソースはデフォルトで有効化 |
- 1日あたりに保存するログの量(1GBあたり もしくは 事前に容量を購入) - 保存期間(ログの種類ごとに無料保存期間が設定されており、それを超過したときの追加料金) 補助ログ、基本ログ、分析ログの3種類があり、それぞれ料金が異なる |
対応可 ※エージェントのインストールとAzure Arc へのリソース登録が必要 |
- ログの自動暗号化 - サブスクリプション、リソースグループ、ワークスペースレベルでのアクセス制御が可能 - 監査データの普遍性担保 |
- Azure Monitor Log Analytics を用いた分析が可能 - SplunkやDatadog以外にも、Azure Stack Hub※1 があるシステムであれば連携が可能 - Event Hubsを用いたリアルタイム連携や Azure Logic Appsを用いたバッチ処理連携も可能 |
※1 Azure Stack Hub ****は Azure のサービスをオンプレミス環境で実行できるプロダクト
| サービス | 導入方法 | コスト | マルチクラウド対応 | セキュリティ・コンプライアンス | 拡張性 |
|---|---|---|---|---|---|
| AWS X-Ray | - IAMロールの付与 - (EC2/ECS/オンプレミスの場合)x-rayデーモンのインストール - コードの変更(lambdaでは監視レベルに応じて省略可) |
- トレースの記録件数 - トレースのスキャン件数と取得件数(スキャン対象になったトレースと、その中から実際に取得したトレースの件数) |
部分的に可能 ※OpenTelemetry 形式のデータをADOT Collector を利用することでX-Rayへ転送可能 ※2 コードにカスタムエージェントを埋め込むことでも対応可能(pythonならxray_recorder) |
- 自動暗号化対応 - データの完全性は担保されない - IAMロールに従ったアクセス制御やAmazon GurdDutyを用いた不正アクセス検出が可能 |
- x-rayのデータを直接外部のサービスに連携する機能は提供されていない - AWSのネイティブ監視には強力だが、ほかクラウドとの連携にはやや弱い |
| Application Insights | - 言語ごとに対応するパッケージをインストール - コードの変更 - 対象リソースの画面で Application Insights の有効化 |
- Azure Monitor log の料金と同様 ※実態はAzure Monitor へ保存されるログのため |
部分的に可能 ※専用のSDKを利用して送信する必要がある ※2 |
- EntraID を用いたアクセス制御が可能 - インストルメンテーション キー を仕様することで、ほかアカウントからのデータ転送も可能 - すべてのデータは暗号化して保存される |
- OpenTelemetry 形式 か Prometheus形式で連携が可能 - 外部サービス(Datadog や New relic)もデータの取り込み機能を提供 |
トレース
メトリクス
| 導入方法 | コスト | マルチクラウド対応 | セキュリティ・コンプライアンス | 拡張性 | |
|---|---|---|---|---|---|
| Amazon CloudWatch (メトリクス機能) | IAM ロールの設定 (EC2 でメモリ・ディスクを監視したい場合)エージェントのインストール (ECS でタスク数やコンテナ単位のメトリクスを監視したい場合)Container Insights の有効化 |
1 月あたりに CloudWatch へ送信するメトリクスの種類 1 月あたりの API リクエスト回数 |
OpenTelemetry 形式でちょくせ送信することが可能 Prometheus や Fluent Bit プラグイン で中間サービスにデータを送ることで連携することも可能 |
自動暗号化 GuardDuty での不正アクセス検知可能 IAM ロールベースのアクセス制御 |
OpenTelemetry 形式でのメトリクス統一が可能 他サービスへ連携する場合でも、Prometheus 形式や Fluent bit 形式、Grafana 形式での連携が可能 |
| Azure Monitor Metrics | 基本的に起動しただけでデータ収集が始まる ゲスト OS のメトリクスが必要な場合はエージェントのインストールが必要 |
1 月あたりに Azure Monitor へ送信するメトリクスの種類 1 月あたりの API リクエスト回数 |
エージェントをインストール後、Azure Arc の対象にすることでほかリソースと同様の監視が可能 収集されるデータは Azure の独自形式のため、ほかへの転用はできない |
自動暗号化 Azure RBAC を使用したアクセス制御に対応 |
CloudWatch や Datadog、New Relic への連携が可能 連携形式は JSON か API のレスポンス (OData) 形式 |
まとめ
検証を進めていると、AWS と Azure では監視形式の設計理念にかなり違いがあり、単純な比較が難しいことがわかりました。
どちらのクラウドプロバイダーも充実した監視ソリューションを提供していますが、アプローチが異なるため、適切な使い分けにはそれぞれの特徴をしっかり理解する必要があります。
ただ、両クラウドサービスとも外部監視サービス（Datadog、New Relic、Splunk など）への連携機能をサポートしています。基本的な考え方としては、まずはクラウドネイティブな監視ツールを活用し、特定の要件が満たせない場合にのみ外部サービスとの連携を検討するアプローチが良いのではないかと思います。
例外として、トレース機能については、AWS X-Ray は取り回しがやや難しい側面があるため、最初から OpenTelemetry 形式でデータを収集しておくと、将来的な連携や拡張性を考慮したときに安全だと感じました。