CloudWatchの3つの主な用途は次の通りだ。

1．ログファイル収集

　CloudWatchは、ログデータを収集して管理するための機能を備える。イベント（システムにおける状態の変化や変更）に応じてコードを実行するサーバレスコンピューティングサービス「AWS Lambda」が生成する全ログファイルがCloudWatchに送信される。

　リレーショナルデータベースサービス「Amazon Relational Database Service」（Amazon RDS）や仮想マシン（VM）サービス「Amazon Elastic Compute Cloud」（Amazon EC2）のインスタンスから、ログファイルをCloudWatchに転送することもできる。

　CloudWatchの単一のインタフェースでログファイルの表示や管理を可能にしたり、個々のEC2インスタンスの管理画面を開くことなくトラブルシューティングをしたりできる。

2．リアルタイム監視

　CloudWatchは実行中のAWSサービスのリアルタイム監視機能を備える。容量管理やランタイムパフォーマンスに関心のあるチームは、CloudWatchで以下のようなさまざまなメトリクス（システムのパフォーマンスに関するデータ）を監視できる。

• EC2インスタンスのメモリ使用量
• Elastic Block Store（EBS）ボリュームの読み書き操作
• APIエンドポイントのリクエスト数
• AWS Lambda関数のエラー率

　メトリクスのデータは最大15カ月間保持可能で、AWSコンソールから簡単にデータの表示やグラフ化が可能だ。

3．アラームとオートスケーリング

　CloudWatchの特筆すべき機能はアラート機能だ。監視したいメトリクスのしきい値を設定し、超えた場合にアラームを作動させることができる。アラームが作動すると、メールやテキストメッセージ、AWSの通知サービス「Amazon Simple Notification Service」（Amazon SNS）を通じて関係者に通知する。Amazon SNSのアラームシステムは自動化されており、管理者はシステムのパフォーマンスの低下をエンドユーザーが感じる前に解決できる。

　CloudWatchのしきい値とアラームは、AWSリソースの自動スケーリングツール「AWS Auto Scaling」と連携できる。例えばEC2インスタンスのメモリ不足やAWS Lambda関数の処理能力不足が発生した場合、CloudWatchのアラームがAWS Auto Scalingへの命令となり、追加のリソースを割り当てる。

CloudWatchとCloudTrailを組み合わせる

　CloudWatchとCloudTrailは異なる目的で設計された、2つの独立したツールだ。CloudTrailはCloudTrailと違い、実行中のAWSサービスのメトリクスを扱わず、特定のユーザーやAWSサービスが、AWSサービスに加えた設定変更の履歴を全て記録する。管理者はCloudWatchとCloudTrailを組み合わせて利用できる。

　例えばCloudTrailはログイン失敗の記録を保持する。ログインの失敗が異常に多い場合、AWSアカウントの乗っ取りの兆候だと考えられる。管理者がCloudTrailのログをCloudWatchへ送ることで、通常以上にログイン失敗が多発しているかどうかを追跡できる。1分間のログイン失敗の回数がCloudWatchで設定したしきい値を超えれば、セキュリティチームへアラートが送られ、迅速な対策が可能になる。

CloudTrailとCloudWatchの価格

　CloudTrailは各AWSサービスで発生したイベントの履歴を、ストレージサービス「Amazon S3」で作成したバケットに保存する。CloudTrailの利用料金は無料だが、Amazon S3のストレージの利用には料金がかかる。

　Amazon CloudWatchの価格は、監視するメトリクスの量やメトリクスの発生頻度によって変動する。CloudWatchには無料枠があり、超過すると追加料金がかかる。2024年7月時点でのCloudWatchのアジアパシフィック（東京）の利用料金の例は以下の通りだ。

• ログデータの取り込みは1GB当たり0.76ドル。
• 最初の1万メトリクスの監視は0.30ドル。
• ダッシュボード1つ当たり月額3.00ドル。
• アラームのメトリクス1つ当たり月額0.10ドル。

　AWSは公式Webサイトで、5つのEC2インスタンスで実行されるアプリケーションの7つのメトリクスを追跡するためには、約10.5ドルのコストがかかると例示している。