CloudWatchの基本をCloud Practitioner向けに解説

AWS上にアプリを公開したら、動いているか、エラーが出ていないか、料金が増えていないかを確認する必要があります。その入口になるのがAmazon CloudWatchです。

結論

CloudWatchはAWSリソースのメトリクス、ログ、アラームを扱う監視サービスです。個人開発でも、Lambdaのエラー確認やAPIの実行回数確認に役立ちます。

3つの構成要素は役割が違います。Metrics は「数の推移」、Logs は「そのとき何が起きたか」、Alarm は「条件を満たしたら知らせる」です。

CloudWatch Metrics

Metricsは数値データです。Lambdaの実行回数、エラー数、実行時間、API Gatewayの4xx/5xx、CloudFrontのリクエスト数などを確認できます。

障害時は、まず「どのサービスでエラーが増えているか」をMetricsで見ます。

標準メトリクスとカスタムメトリクス

多くのAWSサービスは、利用者が何もしなくてもメトリクスをCloudWatchへ送ります。これが標準メトリクスです。一方、アプリケーション独自の値（処理件数、キューの滞留数など）を送りたい場合は、PutMetricData API でカスタムメトリクスとして送信します。

標準メトリクスの多くは追加料金なしで参照できますが、カスタムメトリクスは登録した数に応じて課金されます。東京リージョン、2026年8月時点の公開単価では、最初の 10,000 メトリクスまでが 1 メトリクスあたり月 0.30 USD です。「とりあえず全部カスタムメトリクスにする」設計はコストに直結します。

分解能と保持期間

メトリクスには分解能（resolution）の概念があります。

保持期間は分解能ごとに異なり、古いデータは自動的に粗い粒度へ集約されます。

「先月の1分刻みのグラフを見たい」といった要望は、この仕様上かなえられません。長期分析が必要なら、メトリクスをエクスポートして別に保管する設計が必要になります。

なお、Amazon EC2 の基本モニタリングは5分間隔で、追加料金はかかりません。1分間隔で取得する詳細モニタリングは有料オプションです。この対比は試験で問われやすい箇所です。

CloudWatch Logs

LogsはアプリケーションやLambdaが出力したログを確認する機能です。問い合わせAPIでエラーが起きた場合、LambdaのCloudWatch Logsを見ることで原因を調査できます。

Lambda は関数ごとに /aws/lambda/<関数名> というロググループを自動で作ります。ロググループの中にログストリームがあり、その中にログイベントが並ぶ、という3階層です。

保持期間はデフォルトで無期限

ここが個人開発で最も事故が起きやすい設定です。ロググループの保持期間は、明示的に設定しない限り「失効しない（Never expire）」になります。つまり放置すると保存量が増え続けます。

保持期間は 1 日から 10 年までの決められた値から選べます。AWS CLI では次のように設定します。

aws logs put-retention-policy \
  --log-group-name /aws/lambda/contact-api \
  --retention-in-days 30

ログのコスト構造

東京リージョン、2026年8月時点の公開単価では、ログの課金は取り込みと保存で別々に発生します。

取り込み単価が保存単価より二桁大きい点に注目します。コストを下げたいときに保持期間を短くするのは有効ですが、それ以上に効くのは「そもそも出力量を減らす」ことです。デバッグ用の詳細ログを本番でも出しっぱなしにすると、保存より取り込みで効いてきます。

たとえば月 1 GB のログを出し、30日保持する場合の概算は次の通りです。

取り込み 1 GB × 0.76 = 0.76 USD
保存     1 GB × 0.033 = 0.033 USD
合計     約 0.79 USD / 月

ログに出してはいけないもの

ログにメールアドレス全文や問い合わせ本文全文を出すのは危険です。個人情報や秘密情報はログに出さない設計にします。これは責任共有モデルにおける利用者側の責任にあたる部分で、CloudWatch Logs 側の設定でカバーできる話ではありません。

メトリクスフィルターでログを数値にする

「ログに特定の文字列が出た回数」を監視したい場合、メトリクスフィルターを使ってログからカスタムメトリクスを生成できます。生成したメトリクスにアラームを設定すれば、「ERROR が5分で3回以上出たら通知」といった監視が組めます。

ログを目視で追う運用から、条件で拾う運用へ移行する第一歩がこの機能です。

CloudWatch Alarm

Alarmは、指定した条件を満たしたときに通知する仕組みです。たとえばLambda Errorsが一定以上になったら通知する、といった使い方をします。

アラームは常に次の3状態のいずれかを取ります。

INSUFFICIENT_DATA は「異常」ではありません。呼び出しが少ないLambdaでは、データポイントが存在しない期間があるためこの状態になることがあります。これを異常と誤読しないことが運用上のポイントです。

アラームの通知先には Amazon SNS トピックを指定します。SNS からメールやチャットへ配信する構成が一般的です。料金は東京リージョン・2026年8月時点で、標準分解能のアラーム1つあたり月 0.10 USD、高分解能アラームは月 0.30 USD です。

MVPでは必須ではありませんが、アクセスが増えてきたら導入価値が高くなります。

CloudTrailやAWS Configとの違い

CloudWatchは監視とログ、CloudTrailはAPI操作履歴、AWS Configはリソース設定の変更管理に強いサービスです。試験ではこの違いが問われます。

「S3バケットが公開設定に変更された。誰が変更したか調べたい」なら CloudTrail、「公開設定になっているバケットを一覧したい」なら AWS Config、というように、問いの形で使い分けます。

このプロジェクトでの使い方

このサイトでは、問い合わせAPIのLambdaログ、Lambda Errors、API Gatewayの4xx/5xx、CloudFrontの4xx/5xxを確認対象にします。課金についてはCloudWatchではなく、AWS BudgetsとCost Explorerで確認します。

ロググループには保持期間を設定し、無期限のまま放置しない運用にします。

試験で問われるポイント

• CloudWatch Logsはログ確認に使う
• CloudWatch Metricsは数値監視に使い、標準メトリクスとカスタムメトリクスがある
• CloudWatch Alarmは条件付き通知に使い、通知先にはSNSを指定する
• EC2の基本モニタリングは5分間隔、詳細モニタリングは1分間隔で有料
• CloudTrailはAPI操作履歴に使う
• AWS Configは設定変更の追跡に使う

関連用語

• Amazon CloudWatch
• AWS CloudTrail
• AWS Config

次に読む記事

• CloudWatch・CloudTrail・AWS Configの違い
• LambdaのログをCloudWatchで確認する方法