AWS と GCP の監視・運用サービスを比較してみた（CloudWatch / Cloud Monitoring ほか）
GCP×AWS 比較シリーズ第10弾（最終回）。今回は 監視・運用（オブザーバビリティ） を俯瞰する。
AWS は CloudWatch がメトリクス・ログ・アラートを一手に担う のに対し、GCP は Cloud Operations（旧 Stackdriver） という傘の下に Monitoring / Logging / Trace… と機能が分かれている。この構成差を軸に整理する。
1. 全体マップ（用語対応）
| 役割 | AWS | GCP（Cloud Operations） |
|---|---|---|
| メトリクス・監視 | CloudWatch（Metrics / Alarms） | Cloud Monitoring |
| ログ収集・検索 | CloudWatch Logs | Cloud Logging |
| 分散トレース | X-Ray | Cloud Trace |
| エラー集約 | （CloudWatch + 自前） | Error Reporting |
| プロファイリング | CodeGuru Profiler | Cloud Profiler |
| 監査ログ（操作履歴） | CloudTrail | Cloud Audit Logs |
| 構成変更の追跡 | AWS Config | Asset Inventory（資産/変更履歴） |
| ダッシュボード | CloudWatch Dashboards | Monitoring Dashboards |
| アラート通知 | CloudWatch Alarms + SNS | Alerting Policy + 通知チャネル |
| 稼働監視（外形） | CloudWatch Synthetics | Uptime Checks |
構成差：AWS は CloudWatch にメトリクス＋ログ＋アラートが集約。GCP は Monitoring（メトリクス・アラート）と Logging（ログ）が別サービスとして明確に分かれている。
2. メトリクス・監視：CloudWatch ↔ Cloud Monitoring
| 観点 | AWS CloudWatch | GCP Cloud Monitoring |
|---|---|---|
| 標準メトリクス | 各サービスが自動送信 | 各サービスが自動送信 |
| カスタムメトリクス | PutMetricData | カスタム指標 / OpenTelemetry |
| アラート | Alarm（しきい値）→ SNS | Alerting Policy → 通知チャネル |
| 通知先 | SNS（メール/Lambda/SQS等） | Email / Slack / PagerDuty / Pub/Sub / Webhook |
| ダッシュボード | CloudWatch Dashboards | Monitoring Dashboards |
| 外形監視 | Synthetics | Uptime Checks |
| 横断監視 | クロスアカウント可 | Metrics Scope（複数プロジェクトを1か所で監視） |
GCP は複数プロジェクトを Metrics Scope で束ねて1ダッシュボードで見られる。マルチプロジェクト構成（[階層編]参照）と相性が良い。
# GCP：稼働監視（Uptime Check）やアラートは主にコンソール/IaCで作る。
# 通知チャネルの一覧確認など
gcloud alpha monitoring channels list
gcloud monitoring dashboards list
3. ログ：CloudWatch Logs ↔ Cloud Logging
| 観点 | AWS CloudWatch Logs | GCP Cloud Logging |
|---|---|---|
| 収集 | ロググループ / ログストリーム | ログバケット（_Default / _Required） |
| クエリ | Logs Insights（独自構文） | Logging クエリ言語（フィルタ式） |
| 自動収集 | エージェント / Lambdaは自動 | GCP内サービスは自動でLoggingに集約 |
| 転送（連携） | サブスクリプションフィルタ → Kinesis等 | ログシンク（Sink） → GCS / BigQuery / Pub/Sub |
| 長期分析 | S3エクスポート → Athena | BigQueryへSinkして直接SQL分析 |
| 保持期間 | ロググループ単位 | バケット単位 |
GCP の強みは ログシンク：ログをそのまま BigQuery に流して SQL 分析したり、GCS に長期保管したり、Pub/Sub で外部連携したりがルール1つで組める。AWS の「サブスクリプションフィルタ→Kinesis→…」より素直。
# GCP：ログを読む（gcloud logging read）
gcloud logging read 'resource.type="cloud_run_revision" severity>=ERROR' \
--limit=20 --format=json
# ログをBigQueryへ流すSinkを作成
gcloud logging sinks create my-sink \
bigquery.googleapis.com/projects/MY_PROJECT/datasets/logs_dataset \
--log-filter='severity>=WARNING'
# AWS：Logs Insights でクエリ
aws logs start-query \
--log-group-name /aws/lambda/my-fn \
--start-time ... --end-time ... \
--query-string 'fields @timestamp, @message | filter @message like /ERROR/'
4. 監査ログ：CloudTrail ↔ Cloud Audit Logs
「誰が・いつ・何のAPIを叩いたか」の記録。セキュリティ/コンプラの要。
| 観点 | AWS CloudTrail | GCP Cloud Audit Logs |
|---|---|---|
| 何を記録 | API操作履歴 | API操作履歴 |
| 種別 | 管理イベント / データイベント | 管理アクティビティ / データアクセス / システムイベント / ポリシー拒否 |
| デフォルト | 管理イベントは記録 | 管理アクティビティは常時ON（無効化不可） |
| データアクセス | 明示的に有効化（課金） | 明示的に有効化（量が多く課金対象） |
| 保存先 | S3 + CloudTrail Lake | Cloud Logging（＝Loggingの一部として扱う） |
大きな違い：GCP の監査ログは Cloud Logging の中にある（別サービスではない）。だから前述の Sink で BigQuery に流して監査分析、がそのまま使える。
共通点：データアクセスログは量・コストが大きいので、必要なリソースだけ有効化するのが定石。
5. トレース・プロファイル・エラー
| 役割 | AWS | GCP |
|---|---|---|
| 分散トレース | X-Ray | Cloud Trace |
| エラー集約・通知 | （自前 / DevOps Guru） | Error Reporting（例外を自動グルーピング） |
| CPU/メモリ profiling | CodeGuru Profiler | Cloud Profiler |
| 計測の標準 | OpenTelemetry対応 | OpenTelemetry（推奨経路） |
どちらも OpenTelemetry で計装するのが今の標準。アプリ側を OTel で書いておけば、バックエンドを X-Ray / Cloud Trace どちらにも向けやすい（マルチクラウド移行性◎）。
6. 構成・資産の管理
| 役割 | AWS | GCP |
|---|---|---|
| 構成変更の追跡 | AWS Config（リソース構成の履歴・ルール準拠) | Cloud Asset Inventory（資産の一覧・変更履歴・エクスポート） |
| 準拠ルール | Config Rules | 組織ポリシー（[IAM編]参照）/ Security Health Analytics |
| IaC | CloudFormation / CDK | Deployment Manager / （実務はTerraform主流） |
実務では GCP・AWS とも Terraform で書くことが多い。GCP純正の Deployment Manager より Terraform が一般的。
7. 監視設計の基本フロー（共通）
- メトリクスでしきい値監視 → アラート → Slack/PagerDuty等へ通知
- ログを集約 → Sink/Export で BigQuery/S3 に流して長期分析
- トレースで遅延・ボトルネックを特定
- 監査ログでセキュリティ・コンプラ対応
8. まとめ
| 役割 | AWS | GCP | 覚え方 |
|---|---|---|---|
| メトリクス/アラート | CloudWatch | Cloud Monitoring | GCPはMetrics Scopeで複数PJ横断 |
| ログ | CloudWatch Logs | Cloud Logging | SinkでBigQuery直結分析が強い |
| 監査 | CloudTrail | Cloud Audit Logs | GCPはLoggingの一部・管理ログは常時ON |
| トレース | X-Ray | Cloud Trace | どちらもOpenTelemetry |
| エラー集約 | （自前） | Error Reporting | GCPは標準で例外グルーピング |
| 構成管理 | AWS Config | Asset Inventory | IaCは両方Terraformが主流 |
3行まとめ
- AWS は CloudWatch にメトリクス＋ログ＋アラートが集約、GCP は Monitoring と Logging が別サービス。
- GCP の ログシンク → BigQuery 直結分析 と 監査ログがLoggingの一部 が効きどころ。
- トレースは両方 OpenTelemetry が標準。計装をOTelで書けばマルチクラウド移行性が上がる。
シリーズ一覧（完）
これで GCP×AWS 比較シリーズは全10記事。
- [GCP のリソース階層を AWS と比較する（Organization / Folder / Project 編）]
- [GCP と AWS で比較する IAM とポリシー継承の仕組み]
- [GCP CLI を AWS CLI と比較する（gcloud / gsutil / bq 編）]
- [GCP の API 管理サービスを AWS API Gateway と比較する]
- [Cloud Run と AWS Fargate を比較する（コンテナ実行基盤編）]
- [AWS と GCP の主要コンピューティングサービスを比較してみた]
- [AWS と GCP の主要ストレージサービスを比較してみた]
- [AWS と GCP の主要データベースサービスを比較してみた]
- [AWS と GCP の主要ネットワークサービスを比較してみた]
- [AWS と GCP の監視・運用サービスを比較してみた]（本記事）