Amazon CloudWatch ベストプラクティス

目次

全体設計の考え方
メトリクス
アラーム
ログ（CloudWatch Logs）
ダッシュボード
アプリケーション監視
マルチアカウント / 組織運用
コスト最適化
セキュリティ・ガバナンス
チェックリスト

1. 全体設計の考え方

目的から逆算する: 「何を検知したいか（ユーザー影響・SLO違反・コスト異常）」を先に決め、必要なメトリクス・ログ・トレースを選ぶ。取れるものを全部取るのは避ける。
3本柱を組み合わせる: メトリクス（傾向・アラート）、ログ（詳細調査）、トレース（X-Ray / Application Signals によるリクエスト経路の把握）を相互に行き来できるようにする。
シグナルの優先順位: ユーザー視点のシグナル（レイテンシ、エラー率、可用性）を最優先にし、CPUやメモリなどのリソース系は原因調査用として位置づける。
IaCで管理する: アラーム、ダッシュボード、ロググループ、メトリクスフィルターは CloudFormation / CDK / Terraform でコード化し、環境間の差異や手作業ミスを防ぐ。

2. メトリクス

収集

CloudWatch Agent を EC2 / オンプレに導入し、メモリ使用率・ディスク使用率など標準では取れないOSメトリクスを収集する。
設定ファイルは SSM Parameter Store に置き、Systems Manager 経由で一括配布する。
コンテナは Container Insights、Lambda は Lambda Insights を有効化する（コストとのバランスを確認）。

カスタムメトリクス

アプリ側からは Embedded Metric Format (EMF) でログに埋め込んで出力すると、PutMetricData のAPI呼び出しを減らせ、ログとメトリクスを同時に得られる。
ディメンションの設計に注意: ユーザーID・リクエストIDのような高カーディナリティな値をディメンションにしない。メトリクス数が爆発しコストが増大する。
名前空間は 会社名/サービス名 のように一貫した命名規則を決める。
高解像度メトリクス（1秒粒度）は本当に必要な箇所に限定する。

統計

レイテンシは 平均ではなくパーセンタイル（p90 / p99） で見る。平均は外れ値の影響を隠す。
割合を見たい場合は Metric Math でエラー率（エラー数 ÷ リクエスト数）を計算する。

3. アラーム

設計原則

アクション可能なアラームだけを作る: 通知を受けた人が何をすべきか明確でないアラームは作らない。対応手順（Runbook）へのリンクをアラームの説明欄に記載する。
症状ベースでアラートする: 「CPU 80%」より「エラー率上昇」「p99レイテンシ悪化」のようにユーザー影響に直結する指標でページングする。原因系は低優先度の通知に回す。
重大度を分ける: 即時対応（ページング）と翌営業日対応（チケット/チャット通知）でSNSトピックを分ける。

ノイズ削減

M out of N（データポイント数） を設定し、一瞬のスパイクで発報しないようにする（例: 5分中3データポイント）。
欠落データの扱い（TreatMissingData） を明示的に設定する。メトリクスが途絶えること自体が異常なケースでは breaching にする。
複合アラーム（Composite Alarm） で複数条件をまとめ、関連アラームの同時発報（アラームストーム）を抑える。
メンテナンス時は複合アラームの ActionsSuppressor などでアクションを抑制する。
季節性・周期性のある指標には 異常検知（Anomaly Detection） を使い、固定しきい値の調整地獄を避ける。

運用

アラームは定期的に棚卸しし、発報しても誰も対応しないアラームは削除またはしきい値見直し。
アクションに SNS → Chatbot（Slack / Teams）、Incident Manager、EventBridge などを組み合わせ、自動修復（SSM Automation 等）も検討する。

4. ログ（CloudWatch Logs）

構造化と出力

JSON形式の構造化ログを出力する。Logs Insights でのフィールド抽出・集計が容易になる。
共通フィールド（timestamp, level, service, request_id / trace_id など）を統一し、トレースとの相関を取れるようにする。
ログレベルを環境ごとに適切に設定し、本番で DEBUG を常時出さない。

保持とコスト

すべてのロググループに保持期間を設定する（デフォルトは無期限保存）。
長期保存が必要なログは S3 へエクスポート、またはサブスクリプションフィルターで Firehose 経由で S3 に送り、ライフサイクルで Glacier 系へ移行する。
参照頻度の低いログには Infrequent Access ログクラス を検討する（一部機能に制約あり）。
取り込み量（GB）が主なコスト要因なので、不要なログ・冗長なログは出力元で削る。

分析と検知

Logs Insights の頻出クエリは保存して共有する。
メトリクスフィルター でログ中のエラーパターンをメトリクス化し、アラームにつなげる。
Live Tail を使うとデプロイ直後や障害時にリアルタイムでログを確認できる。
ログの異常検知・パターン分析機能で、未知のエラーパターンの出現を把握する。

セキュリティ

機密性の高いロググループは KMSで暗号化 する。
データ保護ポリシー で個人情報・認証情報などのマスキングを有効にする。
ロググループへのアクセスは IAM で最小権限にし、閲覧者と管理者を分ける。

5. ダッシュボード

用途別に作る: 経営/サービス概要用、オンコール用、サービス別詳細用など、見る人と目的ごとに分ける。
上から「ユーザー影響（ゴールデンシグナル: レイテンシ・トラフィック・エラー・サチュレーション）」→「依存サービス」→「リソース」の順に配置する。
アラームのステータスウィジェットを置き、現在の健全性が一目で分かるようにする。
変数（ダッシュボード変数） を使い、環境やインスタンスを切り替えられる汎用ダッシュボードにする。
マルチアカウント・マルチリージョンの場合は クロスアカウントオブザーバビリティ で監視用アカウントに集約する。

6. アプリケーション監視

Application Signals で、サービスごとのレイテンシ・エラー・可用性を自動計測し、SLO を定義してエラーバジェットを管理する。
X-Ray / OpenTelemetry（ADOT） で分散トレースを取得し、マイクロサービス間のボトルネックを特定する。
Synthetics（Canary） で外形監視を行い、ユーザーより先に障害を検知する。重要なユーザーフロー（ログイン、購入など）をスクリプト化する。
RUM（Real User Monitoring） でフロントエンドの実ユーザー体験（ページロード時間、JSエラー）を計測する。
Internet Monitor でインターネット経路起因の可用性・パフォーマンス劣化を把握する。

7. マルチアカウント / 組織運用

クロスアカウントオブザーバビリティ で監視アカウントにメトリクス・ログ・トレースを集約する。
AWS Organizations と組み合わせ、新規アカウント作成時に監視設定が自動適用される仕組み（StackSets等）を用意する。
タグ付け規約（環境、サービス、オーナー）を統一し、ダッシュボードやコスト分析で活用する。

8. コスト最適化

コスト要因	対策
ログ取り込み量	不要ログの削減、ログレベル調整、Infrequent Access クラス
ログ保存量	保持期間設定、S3へのエクスポート
カスタムメトリクス数	高カーディナリティなディメンションを避ける、不要メトリクスの削除
API呼び出し（PutMetricData / GetMetricData）	EMFの活用、バッチ送信、ダッシュボードの自動更新間隔の見直し
アラーム数	不要アラームの棚卸し、複合アラームで集約
Logs Insights クエリ	時間範囲・ロググループを絞ってスキャン量を削減
Container Insights / Synthetics 等	有効化範囲・実行頻度を必要最小限に

Cost Explorer で CloudWatch のコストを使用タイプ別に定期確認する。
請求アラーム（Billing Alarm）または AWS Budgets で予期せぬコスト増を検知する。

9. セキュリティ・ガバナンス

IAMポリシーで CloudWatch / Logs の操作権限を最小化する（特にロググループ削除や保持期間変更）。
VPCエンドポイント（PrivateLink） を使い、プライベートサブネットからインターネットを経由せずに送信する。
CloudTrail で CloudWatch の設定変更を監査する。
AWS Config ルールで「保持期間未設定のロググループ」「暗号化されていないロググループ」などを検出する。

10. チェックリスト

0件のページ