Amazon CloudWatch

解決する課題

• システムが今どんな状態かを知りたい
• 異常を自動で検知して通知/対処したい
• ログを一元的に集めて調べたい

主要概念と用語

• メトリクス: 時系列の数値（標準メトリクス / カスタムメトリクス）
• 名前空間 / ディメンション: メトリクスの分類・絞り込み
• アラーム: しきい値超えで ALARM 状態 → アクション（SNS/Auto Scaling）
• ログ（ロググループ/ストリーム）/ Logs Insights: 収集とクエリ分析
• ダッシュボード: 可視化
• CloudWatch Agent: OS内部の指標（メモリ等）やログを送る

仕様・制限・クォータ

• 標準は5分間隔、詳細モニタリングで1分間隔
• カスタムメトリクスは任意の粒度で送信可
• ログは保持期間を設定（無期限も可）

内部の仕組み

各サービスがメトリクスを自動送信し、CloudWatchが時系列で保持します。アラームは一定期間メトリクスを評価し、OK / ALARM / INSUFFICIENT_DATA の状態を持ちます。EC2の標準メトリクスにメモリ/ディスク使用率は含まれません（ハイパーバイザから見えないため）。これらは CloudWatch Agent を入れてカスタムメトリクスとして送ります。

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

• アラーム → SNS通知 / Auto Scaling で自動対応
• ログを集約し Logs Insights で横断分析
• 重要指標をダッシュボード化
• 異常検知（Anomaly Detection）や複合アラームで誤検知を低減

運用・監視・トラブルシュート

• 監視対象の取りこぼし → Agent設定 / IAM権限を確認
• アラームが鳴らない → 評価期間・データ欠損（INSUFFICIENT_DATA）を確認
• コスト増 → カスタムメトリクス/ログ保持/高解像度の使い過ぎを点検

コスト

• メトリクス数・ログ取り込み量・ダッシュボード・アラーム数で課金
• 不要な高解像度・長期ログ保持を抑えると効く

セキュリティ

• ログの暗号化（KMS）とアクセス制御（IAM）
• 監査は CloudTrail、構成変更は AWS Config と役割分担

Well-Architected の観点

• 運用上の優秀性: 観測性と自動化の中核
• 信頼性: 異常検知→自動復旧（Auto Scaling/復旧アクション）
• パフォーマンス効率: ボトルネックの可視化

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# CPU使用率80%超で通知するアラームを作成
aws cloudwatch put-metric-alarm \
  --alarm-name high-cpu \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --statistic Average --period 300 --evaluation-periods 2 \
  --threshold 80 --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:alerts

# ログをLogs Insightsでクエリ（エラー件数の集計など）
aws logs start-query --log-group-name /aws/lambda/resize-image \
  --start-time 1717200000 --end-time 1717203600 \
  --query-string 'fields @timestamp,@message | filter @message like /ERROR/'