Amazon CloudWatchとは？現役AWSエンジニアが機能・料金・使い方を徹底解説

「EC2を立てたし、S3にデータも置いた。でも、本当にちゃんと動いているか確認するにはどうしたらいいんだろう…」
AWSを使い始めると、多くの方がこの不安にぶつかります。アプリケーションの稼働状況は、見ていなければ気づけず、問題が起きてから慌てて調べても、ログが残っていなければ原因究明すら難しい。障害が長引くほど、ユーザーへの影響とビジネスへのダメージは広がっていきます。
そこで登場するのがAmazon CloudWatch（アマゾン クラウドウォッチ）です。

この記事では、CloudWatchとは何か、どんな機能があるか、料金はいくらかかるか、そして実際にどこから手をつければいいかを、現役AWSエンジニアが解説します。「監視を始めたいけど何から手をつければいいかわからない」という方を中心に、CloudWatchの全体像をつかめる内容にまとめました。

この記事でわかること

• Amazon CloudWatchとは何か、なぜ必要なのか
• メトリクス・ログ・アラームなど主要5機能の役割
• 標準メトリクスとカスタムメトリクスの違い
• CloudWatchの料金と、無料枠でできること
• CloudWatchとCloudTrailの違い（監視と監査の使い分け）
• 監視を始めるための具体的な3ステップ

監修：HIROTO
AWS基盤のインフラ設計・構築から維持運用、チームマネジメントなどを幅広く担当するインフラエンジニア。

オンプレからのAWS移行、マルチアカウント化、新規基盤の設計構築などの実績に加え、並行してセキュリティ領域のPJではPLを担当。2025 All AWS Certifications Engineers。

運営元：ALH株式会社
ALH株式会社は、AWSパートナーネットワーク（APN）において、以下の認定を取得しているAWSパートナー企業です。

◆ AWS 1000 APN Certification Distinction
AWS認定資格の取得数が1,000件を超えたパートナーに与えられる認定

◆ AWS Training Partner
AWS公認の研修トレーニングを提供できるパートナー認定

◆ AWS Select Tier Services Partner
AWSサービスの構築・運用において一定の実績を持つパートナー認定

1. Amazon CloudWatchとは?｜まずは結論

Amazon CloudWatch（アマゾン クラウドウォッチ）は、AWSが提供するフルマネージドの監視・可観測性サービスです。

AWS上で動くEC2、Lambda、RDS、ECSなどのサービスのパフォーマンスデータ（メトリクス）やログを自動で収集し、異常を検知してアラームを発報したり、グラフで可視化したりすることができます。追加のサーバーを用意したり複雑なインストール作業をしたりする必要はなく、AWSアカウントを持っていれば即日使い始めることができます。

「可観測性（オブザーバビリティ）」という言葉を最近よく耳にする方も多いかもしれません。これは「システムの内部状態を外部から観測・把握できる能力」のことで、CloudWatchはAWS環境におけるその中核を担うサービスです。

1-1.CloudWatchの仕組み

CloudWatchの基本的な動作は「収集→監視→アクション→分析」の4フェーズで成り立っています。

AWSが自社インフラ側でデータを収集してくれるため、エージェントなしでもEC2のCPU使用率やRDSの接続数などの基本的なメトリクスが自動で記録されます。ただし、メモリ使用率やディスク使用率などOSレイヤーの情報は別途エージェントが必要です（詳細は第3章で解説します）。

1-2.CloudWatchが必要な理由

「監視がなければ、何が起きていても気づけない」状況を解決するのが、CloudWatchを入れる最大の理由です。 たとえば、EC2インスタンスのCPU使用率が100%に張り付いた状態になっても、監視していなければユーザーから問い合わせが来るまで気づけないことがあります。夜中に発生した障害を翌朝まで放置してしまうケースも珍しくありません。CloudWatchでアラームを設定しておけば、しきい値を超えた瞬間に通知が届き、迅速に対応できます。

また、AWSのマネージドサービス（RDS、ECS、Lambdaなど）はサーバーに直接アクセスできないため、CloudWatchが有力な監視手段になります。クラウドへの移行が進むほど、CloudWatchの重要性は高まります。

さらに最近では、AIが自動でメトリクスの異常を検知する「Anomaly Detection（異常検出）」機能も追加されています。手動でしきい値を設定しなくても、機械学習が正常な範囲を学習し、逸脱したときにアラームを発動させることができます。

アラームには3つの状態があります。

ALARMからOKに戻ったタイミングでも通知できるため、「障害が復旧したことを自動で通知する」という使い方も可能です。さらに「複合アラーム（Composite Alarm）」という機能を使えば、複数のアラームを組み合わせて「CPU使用率が高い、かつメモリ使用率も高い」という条件でのみ発報させることもできます。誤検知を減らしたい場合に有効です。

2-4. ダッシュボード（CloudWatch Dashboards）

ダッシュボードは、複数のメトリクスやログを一画面に並べて可視化するための機能です。

EC2のCPU使用率・メモリ使用率・レイテンシをひとつの画面で確認したり、複数のリージョンにまたがるリソースをまとめて表示したりできます。ウィジェットの追加・配置はコンソール上でドラッグ&ドロップで操作でき、特別な技術的知識がなくても作れます。

ダッシュボードの設計で大切なのは「誰が何のために見るか」を事前に決めること。インフラ担当者向けのサーバーリソース一覧と、マネージャー向けのシステム稼働率ダッシュボードでは、必要な情報が異なります。目的別にダッシュボードを分けておくのが実務でのセオリーです。

2-5. 【関連サービス】Amazon EventBridge（旧CloudWatch Events）

AWSサービスの状態変化をトリガーにして、Lambda関数の実行やSNS通知などのアクションを自動化できます。

かつては「CloudWatch Events」としてCloudWatchの一機能でしたが、現在はAmazon EventBridgeという独立したサービスになっています。CloudWatchの機能ではありませんが、監視とアクションの自動化をつなぐ役割としてセットで使われることが多いため、あわせて押さえておきたいサービスです。

「EC2インスタンスが停止したらSlackに通知する」「毎日午前2時にバッチ処理Lambdaを起動する」「CodePipelineのデプロイが完了したら担当者にメールを送る」といった運用の自動化に幅広く使われます。スケジュール式（cron形式）のイベントも設定できるため、定期バッチ処理のトリガーとしても活用できます。

2-6. ログ分析（CloudWatch Logs Insights）

CloudWatch Logs Insightsは、CloudWatch Logsに蓄積されたログをSQLライクなクエリで分析できる機能です。
「過去1時間のERRORログを件数順に並べる」「特定のIPアドレスからのアクセスを抽出する」「エラーレートが高いAPIエンドポイントを特定する」といった操作が、GUIから直感的に行えます。大量のログから素早く原因を特定したいときに非常に有効で、障害対応の時間を大きく短縮できます。

クエリの実行はスキャンしたデータ量に応じて課金されます（無料枠は5GBまで）。頻繁に使う場合はコストを意識しながら活用しましょう。

2. Amazon CloudWatchの主要5機能＋連携サービス

CloudWatchは単一のサービスではなく、複数の機能の集合体です。それぞれが役割を持ち、組み合わせることでシステム監視の基盤が整います。ここでは主要な5機能と、監視の自動化でセットで使われる連携サービスを解説します。

2-1. メトリクス（CloudWatch Metrics）

メトリクスとは、時系列で収集される数値データのことです。
EC2のCPU使用率、Lambdaの実行時間、RDSのデータベース接続数などがメトリクスとして記録されます。デフォルトでは5分間隔でデータポイントが蓄積され、グラフで確認できます。詳細モニタリングを有効化すると1分間隔になります（追加料金あり）。

メトリクスには「ネームスペース」と「ディメンション」という概念があります。EC2なら「AWS/EC2」というネームスペースのもとに、「InstanceId（インスタンスID）」などのディメンションで分類されます。複数のインスタンスがある場合でも、インスタンスIDで絞り込んで確認できます。
メトリクスのデータ保存期間は最大15ヶ月です。古いデータは解像度が下がる形で保持されます。具体的には、60秒未満のデータ（高解像度メトリクス）は3時間、1分データは15日、5分データは63日、1時間データは455日（15ヶ月）です。1分間隔で収集したデータも、15日を過ぎると5分解像度に、63日を過ぎると1時間解像度に集約されていきます。

2-2. ログ（CloudWatch Logs）

CloudWatch Logsは、アプリケーションやAWSサービスのログを収集・保存・検索するための機能です。
EC2上で動くアプリケーションのエラーログ、Lambdaの実行ログ、VPCフローログ、APIゲートウェイのアクセスログなどを一元管理できます。ログは「ロググループ（Log Group）」という単位で管理され、その中に時系列の「ログストリーム（Log Stream）」が作られる階層構造になっています。

アクセスログや障害ログを長期保存しておくことで、後から原因調査に活用できます。ただし、デフォルトでは保存期間が「無期限」に設定されているため、コスト管理の観点から必ず保存期間を設定することが重要です（詳細は第7章で解説します）。

関連記事

AWS Lambdaとは？できること・料金・つまずき所まで現役AWSエンジニアが解説

2026.7.16

2-3. アラーム（CloudWatch Alarms）

アラームは、メトリクスが設定したしきい値を超えたときに自動でアクションを起こす機能です。
「CPU使用率が5分間80%以上」「Lambdaのエラー率が1%を超えた」など、条件を設定しておくと、Amazon SNS（Simple Notification Service）経由でメール通知を送ったり、EC2インスタンスを自動停止・再起動したりできます。

3. 標準メトリクスとカスタムメトリクスの違い

CloudWatchのメトリクスには、最初から収集されるもの（標準メトリクス）と、設定しないと収集されないもの（カスタムメトリクス）の2種類があります。この違いを正しく理解しておかないと、「監視できていると思っていたのに、実は取れていなかった」という事態に陥ります。

3-1. 標準メトリクス｜最初から収集されるもの

標準メトリクスとは、AWSが自動で収集してCloudWatchに送信してくれるメトリクスのことです。
EC2であれば「CPU使用率（CPUUtilization）」「ネットワーク送受信量（NetworkIn/Out）」「ディスクI/O」など、インフラレベルの数値が自動で記録されます。追加設定は不要で、AWSアカウントで使い始めた瞬間から収集が始まります。

主なAWSサービスと取得できる標準メトリクスの例は以下のとおりです。

3-2. カスタムメトリクス｜エージェントで拡張するもの

カスタムメトリクスとは、標準では取得できない項目を追加で収集するための仕組みです。
最も代表的な例が「EC2のメモリ使用率」と「ディスク使用率」です。「当然取れているだろう」と思っている方が非常に多いのですが、これらはデフォルトでは収集されません。AWSはEC2インスタンスのハイパーバイザー（仮想化基盤）レイヤーのメトリクスしか取得できず、OS内部のメモリ使用率やディスク使用率には手が届かないためです。

これを解決するのがCloudWatch Agent（クラウドウォッチエージェント）です。EC2インスタンスにインストールすることで、以下の情報をCloudWatchに送信できるようになります。

• メモリ使用率・使用量
• ディスク使用率・空き容量
• スワップ使用率
• プロセス情報

エージェントはAWS公式が提供するため、無料でインストールできます。ただし、エージェントが収集して送信するメトリクスは「カスタムメトリクス」として扱われ、11個目以降から料金が発生します（1個あたり0.30 USD/月）。

メモリやディスクは重要度の高い監視項目なので、本番環境には必ずエージェントを入れてカスタムメトリクスを収集することをお勧めします。

4. Amazon CloudWatchの料金体系

「CloudWatchってどのくらいかかるの？」という疑問は、AWSを使い始めた方が必ずぶつかる疑問です。料金体系は複雑に見えますが、理解するポイントは「無料枠の範囲」と「課金が発生しやすい項目」の2点に絞られます。

4-1. 無料枠の内容

毎月リセットされる無料枠の範囲内であれば、費用は発生しません。

（出典：https://aws.amazon.com/jp/cloudwatch/pricing/）
開発環境や小規模なシステムであれば、無料枠の範囲だけでもかなりの監視が実現できます。まず無料の範囲でアラームとダッシュボードを設定して、CloudWatchの感触をつかんでから拡張していくのが賢い進め方です。

4-2. 有料部分の単価と内訳

無料枠を超えると、使った量に応じて課金されます（従量課金）。主な項目の単価は以下のとおりです（東京リージョン・2026年8月時点）。米国東部などのリージョンでは単価が異なるため、他サイトの解説と数値が違う場合はリージョンの違いを確認してください。

（出典：https://aws.amazon.com/jp/cloudwatch/pricing/）

4-3. 料金が高くなりやすいパターンとコスト削減のコツ

CloudWatchの料金で「思ったより高い」と感じやすいのは主に3つのパターンです。

① ログの取り込み量が多い／保存期間を設定していない
CloudWatch Logsのコストは「取り込み」と「保存」の2つに分かれます。影響が大きいのは取り込み側です。取り込み料金（0.76 USD/GB）は不要なログを出力した時点で確定してしまい、あとからログを削除しても戻りません。まずは不要なDEBUG／INFOログを出力しない、送信元でフィルタするといった対策が最も効果的です。

保存側は、CloudWatch Logsがデフォルトで「保存期間：無期限」に設定されているため、システムが稼働し続ければログが増え続け、ストレージ料金（0.033 USD/圧縮GB/月。AWSは非圧縮データに対して約15%に圧縮されることを目安としています）がかかり続けます。

② カスタムメトリクスを増やしすぎる
カスタムメトリクスは無料枠の10個を超えると1個あたり0.30 USD/月。50個作れば課金対象は40個で月12ドル、100個なら90個で月27ドルになります（1ドル=150円換算でそれぞれ約1,800円・約4,050円）。「念のため全部取っておこう」という発想でメトリクスを増やすと、後からコスト削減が難しくなります。本当に監視が必要な指標を事前に選定してから設定しましょう。

③ 詳細モニタリングを全インスタンスに適用する
詳細モニタリング（1分間隔）はデフォルト（5分間隔）よりもコストが高くなります。全インスタンスに適用するのではなく、本番環境の重要サービスに限定する運用が現実的です。

5. CloudWatchとCloudTrailの違いは？

「CloudWatchとCloudTrailって何が違うの？」という質問はよく聞かれます。名前が似ているので混乱しやすいのですが、役割はまったく異なります。
一言でいえば、CloudWatchは「今、システムで何が起きているか」を監視し、CloudTrailは「誰が、いつ、どのAWS操作をしたか」を記録します。

具体的なシナリオで考えると違いが明確になります。

• 「EC2のCPUが突然100%になった」を検知したい → CloudWatchのアラーム
• 「誰かが本番のEC2インスタンスを誤って削除した」を調査したい → CloudTrailのAPIコール履歴

セキュリティとコンプライアンスの観点では、この2つを組み合わせて使うのが基本です。CloudTrailのログをCloudWatch Logsに転送し、特定のAPIコール（たとえばEC2インスタンスの削除）をトリガーにアラームを発動させる、という連携構成も実務でよく使われます。

6. Amazon CloudWatchの始め方｜3ステップで進める

「どこから手をつければいいかわからない」という声はよく聞きます。私がおすすめする導入の流れを3ステップで紹介します。いきなり完璧な監視体制を作ろうとするのではなく、小さく始めて徐々に広げるアプローチが長続きします。

Step 1：監視計画を立てる（コンソールを開く前にやること）

設定を始める前に「何を、なぜ監視するか」を言語化します。ここを省略してコンソールをいきなり開くと、「とりあえずCPUのアラーム設定したけど、しきい値どうすればいいかわからない」という状態になります。
最低限決めておくべき項目：

• 監視対象：どのAWSサービス（EC2・RDS・Lambda等）を対象にするか
• 監視指標：CPU使用率？エラー率？レスポンスタイム？
• しきい値：何%・何件を超えたらアラームを鳴らすか（いきなり完璧な数値でなくてもOK。最初は緩めに設定して後から調整する）
• 通知先：誰に・どの手段で知らせるか（メール、Slack、PagerDutyなど）
• ログの保存期間：何日・何ヶ月保持するか

最初から全部完璧にする必要はありません。「まずEC2のCPU使用率だけアラームを設定する」という進め方が、おすすめです。

Step 2：アラームを設定する

CloudWatchコンソールの左メニューから「アラーム」→「アラームの作成」を選びます。

1. 監視するメトリクスを選択（例：EC2 > CPUUtilization）
2. インスタンスIDでフィルタリングして対象を絞る
3. しきい値の条件を設定（例：期間5分の平均値が80%以上）
4. 通知アクションを設定（例：新しいSNSトピックを作成してメールアドレスを登録）
5. アラーム名を入力して作成完了

Amazon SNSは通知の仲介役です。SNSトピックにメールアドレスを登録しておくと、アラームが発動したときに自動でメールが届きます。登録時に確認メールが届くので、必ず承認するようにしてください。
最初のアラームはここまででOKです。

Step 3：ダッシュボードで一元管理する

アラームが設定できたら、次は日常的にシステムの健康状態を確認できるダッシュボードを作ります。「CloudWatchダッシュボード」→「ダッシュボードの作成」でダッシュボード名を入力し、ウィジェットを追加します。最初に入れておくと便利なウィジェットの例：

• EC2インスタンスのCPU使用率（折れ線グラフ）
• RDSのDB接続数（折れ線グラフ）
• LambdaのエラーカウントとThrottles（棒グラフ）
• ALBのリクエスト数・レスポンスタイム（折れ線グラフ）

複数のリソースを一画面で見られるようになることで、「今日のシステムは健全か」を毎朝1分で確認できます。カスタムダッシュボードは月3個まで無料で使えます。

7. CloudWatchを使ううえで知っておきたい注意点

実際に使い始めると「こんな落とし穴があったのか」と気づくことがあります。事前に把握しておくことで、無駄なコストやトラブルを防げます。

7-1. ログの保存期間は必ず設定する

前述のとおり、CloudWatch Logsのデフォルトは保存期間が無期限です。 そのせいでシステムが稼働し続ければログが増え続け、気づいたら月数千円のストレージ料金が発生していた、というケースは珍しくありません。

対策として、ロググループごとに保存期間を設定します。CloudWatchコンソールで「ロググループ」を開き、対象のロググループの「アクション」から「保存期間の変更」を選ぶだけです。設定できる期間は1日から10年、無期限まで20種類以上が用意されています（1日・1週間・1ヶ月・1年などが代表的な選択肢です）。

長期保存が必要なログは、S3への自動エクスポートも検討してください。ただし、CloudWatch Logsの保存料金は圧縮後のデータに対する課金のため、S3の標準クラス（0.025 USD/GB/月程度）へ移すだけでは保存料金の差はごくわずかです。

意味のあるコスト削減になるのは、S3のライフサイクル設定でS3 Glacier Instant RetrievalやS3 Glacier Deep Archive（東京リージョンで0.002 USD/GB/月程度）へ移行する場合で、長期保管のコストを大幅に下げられます。「解析用にCloudWatch Logsへ数週間だけ残し、それ以降はGlacier系へ退避させる」という設計がおすすめです。

7-2. メモリ・ディスク監視にはエージェントが必要

EC2インスタンスのメモリ使用率とディスク使用率は、標準メトリクスに含まれていません。「監視できていると思っていたのに、実はできていなかった」というミスが現場でも非常に多いポイントです。
CloudWatch Agentをインスタンスにインストールすることで解決します。エージェントの設定ファイルは「構成ウィザード」からGUIで作成でき、AWS Systems Managerのパラメータストアに保存して複数インスタンスへ一括配布することもできます。インスタンスの台数が多い場合は、Systems Managerと組み合わせて一元管理するのがおすすめです。

7-3. メトリクスは削除できない

一度作成したカスタムメトリクスは、CloudWatchコンソールから削除できません。データポイントが2週間以上送信されないとコンソールの表示から消えますが、厳密な意味での削除はできない仕様です。

試験的にカスタムメトリクスをいくつも作ってしまうと、料金が発生し続けたり「どれが現在使っているメトリクスかわからない」という混乱を招いたりします。 作成前に命名規則（例：サービス名_環境_指標名）を決めておくことを強くおすすめします。

よくある質問（FAQ）

Q1. CloudWatchは無料で使えますか？
A. 無料枠の範囲内であれば費用はかかりません。カスタムメトリクス10個・標準解像度アラーム10個・カスタムダッシュボード3個・ログのデータ取り込み5GBなどが毎月の無料枠として提供されます（内訳は変更される場合があるため、最新の条件はAWS公式料金ページでご確認ください）。EC2やRDSなどAWSサービスが自動で送信する標準メトリクスはすべて無料です。小規模なシステムであれば、無料枠だけでも基本的な監視が十分実現できます。

Q2. EC2のメモリ使用率はCloudWatchで監視できますか？
A. 監視できますが、デフォルトでは収集されません。CloudWatch Agentをインストールする必要があります。CPUなどの標準メトリクスとは異なり、メモリ使用率はOS内部の情報のため、エージェント経由での収集が必要です。本番環境には必ずエージェントを入れておくことをおすすめします。

Q3. CloudWatchとCloudTrailの違いは何ですか？
A. CloudWatchは「AWSリソースの状態をリアルタイムで監視する」パフォーマンス監視サービスです。CloudTrailは「誰がいつどのAWS APIを呼び出したかを記録する」操作監査サービスです。前者は障害検知・パフォーマンス改善に、後者はセキュリティ監査・コンプライアンス対応に使います。両者を組み合わせることで、より強固な監視体制が構築できます。

Q4. CloudWatchの料金を抑えるにはどうすればいいですか？
A. 主に3つの対策が有効です。①まず不要なDEBUG／INFOログを出力しない・送信元でフィルタするなどで取り込み量を減らす②ロググループの保存期間を設定して不要なストレージコストを削減する③カスタムメトリクスの数を必要最小限に絞る。加えて、詳細モニタリング（1分間隔）を本番環境の重要サービスに限定するのも有効です。なお、ログの取り込み料金は「出力した時点で確定する」ため、取り込み量の削減が最も即効性があります。

Q5. オンプレミスのサーバーもCloudWatchで監視できますか？
A. 可能です。CloudWatch Agentをオンプレミスのサーバーにインストールすることで、メトリクスやログをCloudWatchに送信できます。ただし、AWSのマネージドサービスのように自動連携はされないため、設定の手間がかかります。オンプレミスとAWSを混在させている環境では、CloudWatchを監視の一元化ツールとして活用する事例も増えています。

おわりに｜CloudWatchはAWS運用の「土台」となるサービス

CloudWatchは、AWS環境を安定稼働させるための土台です。メトリクス、ログ、アラームなどの各機能を理解することは大切ですが、実務ではさらに「システムの状態を可視化する」「異常にいち早く気づく仕組みを作る」「コストと監視範囲のバランスをとる」などの考え方が重要になります。 本記事のポイントをまとめます。

• CloudWatchとは、AWSのフルマネージド監視サービス。追加サーバー不要で即日使える
• 主要5機能は、メトリクス・ログ・アラーム・ダッシュボード・Logs Insights（＋連携サービスのEventBridge）
• 標準メトリクス（CPUやネットワークなど）は自動収集されるが、メモリ・ディスクの監視にはエージェントが必要
• 料金は小規模なら無料枠で十分。ただしログ取り込み量とカスタムメトリクスの数には注意が必要
• CloudTrailとの違いは、CloudWatchが「パフォーマンス監視」、CloudTrailが「操作の監査記録」
• 始め方は、監視計画の策定、アラーム設定、ダッシュボード作成の3ステップ

まずは、標準メトリクスを確認し、無料枠の範囲で基本的なアラームを一つ設定してみること。そして、システムの要件に合わせて必要なログを収集し、ダッシュボードで状態を可視化すること。この基本を押さえるだけでも、AWS環境の運用保守性は大きく高まります。

参考リンク

• Amazon CloudWatch（AWS公式）
• Amazon CloudWatch の料金（AWS公式）
• CloudWatch の概念：メトリクスの保持期間・詳細モニタリング（AWS公式ドキュメント）
• CloudWatch エージェントのインストール：メモリ・ディスクの収集（AWS公式ドキュメント）
• AWS CloudTrail（AWS公式）
• Amazon S3 の料金：S3 Glacier Deep Archive など（AWS公式）
• AWS 無料利用枠（AWS公式）

いずれも2026年8月時点の情報です。料金・仕様・提供状況は改定される場合があるため、最新情報は各公式ページでご確認ください。

関連記事

【初心者向け】 Amazon ECSの基本概念をわかりやすく解説してみた

2025.1.14

AWS Lambdaとは？できること・料金・つまずき所まで現役AWSエンジニアが解説

2026.7.16

【2026年最新】Amazon EC2とは？インスタンスタイプの選び方と料金体系を現役AWSエンジニアが解説

2026.7.27

AWS S3 ストレージクラス8種はどう選ぶ？料金で損しない使い分けを現役エンジニアが解説

2026.8.4