AWS監視設計の要点は、CloudWatchに情報を集めることではなく、利用者影響を検知し、担当者が復旧まで動ける仕組みを作ることです。可用性・遅延・エラー・飽和を起点に、通知、初動手順、復旧確認まで一体で設計し、本番公開前に発報テストを行います。
AWS監視設計で最初に決めること
AWS監視は、監視対象の一覧ではなく「どの状態を、誰が、何分以内に確認し、どう復旧させるか」から設計します。CPU使用率やエラー件数を可視化しても、対応者と判断基準が決まっていなければ、障害からの復旧にはつながりません。
監視の目的を利用者影響から整理する
最初に、サービスや業務ごとの重要度を整理します。すべてのシステムを同じ基準で24時間監視すると、費用と運用負荷が必要以上に増えるためです。
発注者側で決めたい項目は次のとおりです。
- 利用者が使えない状態を何分まで許容できるか
- 応答速度がどの程度悪化したら業務に影響するか
- 夜間・休日にも即時対応が必要か
- 売上、契約、決済、出荷などに直結する機能はどれか
- データ欠損や二重処理をどのように確認するか
- 復旧後に誰が利用再開を判断するか
可能であれば、SLO（サービスの信頼性について社内で定める目標値）も設定します。例えば「月間のAPI成功率」「主要画面の応答時間」「バッチ処理の完了時刻」などです。契約上の保証であるSLAとは分けて考え、まずは利用者と事業にとって意味のある目標を置きます。
監視対象は4種類に分ける
監視漏れを防ぐには、対象を次の4種類に分けると整理しやすくなります。
| 監視の種類 | 確認すること | 代表的な手段 | 発注者が決める事項 |
|---|---|---|---|
| 外形監視 | 利用者と同じ経路でサービスを使えるか | CloudWatch Synthetics、Route 53ヘルスチェック | 対象URL、実行間隔、許容応答時間 |
| アプリケーション監視 | 処理が正しく完了したか | CloudWatch Logs、カスタムメトリクス、X-Ray | 重要処理、エラーコード、成功条件 |
| インフラ監視 | サーバーやデータベースが飽和していないか | CloudWatch Metrics、CloudWatch Agent | CPU、メモリ、容量、接続数の基準 |
| 変更・セキュリティ監視 | 不審な操作や設定変更がないか | CloudTrail、AWS Config、GuardDuty、EventBridge | 通知対象、確認担当、証跡の保存期間 |
外形監視とは、Web画面やAPIへ定期的にアクセスし、利用者が実際に使える状態かを確認する方法です。サーバーが起動していても、認証やデータベース接続が壊れていれば利用できないため、インフラ監視だけでは障害を見逃します。
一方、CloudWatchだけでセキュリティ監視のすべてを完結させることはできません。脅威検知にはGuardDuty、設定評価にはAWS Configなどを組み合わせ、可用性監視と責任範囲を分けて設計します。
通知を受けた後の体制まで設計する
監視設計時には、次の運用条件も決めます。
| 項目 | 決める内容 |
|---|---|
| 対応時間 | 平日日中のみ、夜間休日を含む、24時間365日など |
| 一次対応者 | 社内担当者、保守会社、開発会社、運用会社など |
| 目標時間 | 通知の確認開始、原因調査開始、暫定復旧の目安 |
| エスカレーション | 一次対応で解決できない場合の連絡先と判断条件 |
| 復旧権限 | 再起動、切り戻し、スケール変更を実施できる担当者 |
| 事業側連絡 | 顧客告知や社内周知を判断する責任者 |
発注のご相談を受ける開発会社の立場では、「監視を入れてほしい」という依頼だけでは見積もりを確定できません。夜間対応の有無、対象環境、通知後の調査範囲、復旧作業の権限によって、必要な設計と運用費が大きく変わるためです。
CloudWatchの監視項目とアラーム条件
監視項目は、可用性、遅延、エラー、飽和の4観点を優先します。AWSが提供する全メトリクスにアラームを設定するのではなく、利用者影響を直接示す指標から選ぶことが重要です。
AWSサービス別の主な監視項目
| AWSサービス・機能 | 優先する監視項目 | 設計上の注意点 |
|---|---|---|
| ALB | ターゲットの5XX、ALB自身の5XX、応答時間、正常ホスト数 | 5XXは件数とリクエスト総数に対する割合を併用する |
| EC2 | ステータスチェック、CPU、メモリ、ディスク使用率 | メモリとディスクは標準メトリクスに含まれず、CloudWatch Agentが必要 |
| ECS・Fargate | CPU、メモリ、稼働タスク数、タスク停止 | 必要タスク数を下回る状態や再起動の反復を確認する |
| Lambda | Errors、Duration、Throttles、同時実行数 | エラー率、タイムアウト直前の処理時間、再試行の影響を見る |
| RDS | CPU、空きストレージ、接続数、空きメモリ、レプリカ遅延 | 固定閾値だけでなく、容量減少や接続増加の傾向も見る |
| SQS | 最古メッセージの経過時間、滞留件数、デッドレターキュー | 件数だけでなく、業務上許容できる処理遅延を基準にする |
| API Gateway | 5XX、4XX、Latency、IntegrationLatency | 利用者側エラーとバックエンド側エラーを分ける |
| CloudFront | 5XX率、キャッシュヒット率、オリジン応答 | 配信障害とオリジン側障害を切り分けられるようにする |
| バッチ処理 | 開始、終了、失敗、処理件数、完了時刻 | プロセスの稼働ではなく、業務処理の完了を監視する |
EC2の基本モニタリングは多くのメトリクスが5分間隔で、詳細モニタリングを有効にすると1分間隔になります。ただし、監視間隔を短くするほど常に有効とは限りません。許容停止時間や費用とのバランスから決めます。
閾値は正常値と利用者影響から決める
アラームの閾値は、他社事例やテンプレートをそのまま使うのではなく、次の順序で決めます。
- 許容できない利用者影響を定義する
- 通常時と繁忙時のメトリクスを確認する
- 影響が始まる水準に暫定閾値を置く
- WarningとCriticalを分ける
- 運用後の誤検知と見逃しを記録して調整する
Warningは性能劣化や障害の予兆、Criticalは利用不能や重要処理の失敗など、即時確認が必要な状態です。Criticalだけを夜間通知し、Warningは翌営業日に確認する設計も可能です。
遅延は平均値だけでなく、p95やp99も確認します。p95とは、応答時間を速い順に並べたときに95％が収まる値です。平均値では、一部の利用者だけが極端に遅い状態が見えにくくなります。
低トラフィックのサービスでは、エラー率だけを使うと1件のエラーで100％になることがあります。反対に、大量トラフィックでは件数だけだと重要度を判断できません。そのため、エラー件数、エラー率、最低リクエスト数を組み合わせます。
評価期間と欠損データを設計する
CloudWatchアラームでは、閾値に加えて評価期間、必要な違反回数、欠損データの扱いを設定します。例えば「直近5回の評価のうち3回が閾値超過」のようなM out of N方式を使うと、一時的なスパイクによる誤検知を抑えられます。
ただし、死活監視や決済失敗など、短時間でも影響が大きい指標は1回の違反で通知する場合があります。すべてを同じ条件にしてはいけません。
欠損データについても、指標の性質で扱いを変えます。
- 常に送られるはずの死活信号が欠損した場合は、異常として扱う
- エラー発生時だけ記録される指標の欠損は、正常として扱う場合がある
- バッチ実行結果の欠損は「未実行」の可能性があるため、別途監視する
- メトリクス送信自体の障害を見つけるため、最終受信時刻を確認する
同じ原因から複数のアラームが発生する場合は、Composite Alarm（複数のアラーム状態をまとめて判定する機能）で通知を集約できます。通知数を減らすだけでなく、原因候補を絞りやすくなる点も利点です。
AWS監視を実装する手順
実装は「調査、設計、構築、通知連携、障害テスト、引き継ぎ」の順に進めます。アラームを作成した時点では完成ではなく、担当者が通知を受け取り、復旧を確認できることを受け入れ条件にします。
手順1．現状と重要業務を調査する
最初にAWSアカウント、リージョン、システム構成、運用体制を棚卸しします。複数アカウントを利用している場合は、監視データを集約するアカウントやアクセス権限も確認します。
依頼前に用意できるとよい情報は次のとおりです。
- AWSの構成図と利用サービス一覧
- 本番、検証、開発環境の区分
- 重要な画面、API、バッチ処理の一覧
- 過去の障害、問い合わせ、性能問題
- 通常時と繁忙時のアクセス規模
- 現在の通知先と保守契約
- 夜間・休日対応の要否
- ログの保存期間と監査要件
- 再起動や切り戻しを行える担当者
資料がそろっていなくても調査から依頼できますが、その分の工数が必要です。複数社へ提案を依頼する場合は、RFP（提案依頼書）で対象範囲と運用条件をそろえると比較しやすくなります。詳しくは、RFPの作り方｜システム開発の依頼準備も参考にしてください。
手順2．監視項目表と通知ルールを作る
監視対象ごとに、指標、閾値、評価期間、重要度、通知先、初動を一覧化します。これを監視項目表として発注者と開発会社の共通資料にします。
| 記載項目 | 内容の例 |
|---|---|
| 対象 | 本番API、決済バッチ、管理画面など |
| 検知内容 | 5XX率上昇、処理未完了、容量不足など |
| 判定条件 | 閾値、評価期間、違反回数、欠損時の扱い |
| 重要度 | Critical、Warning、Info |
| 通知先 | オンコール、チャット、メール、チケット |
| 初動 | ダッシュボード確認、ログ調査、切り戻し判断 |
| 復旧条件 | 成功率回復、キュー解消、外形監視成功など |
オンコールとは、障害通知を受けて所定時間内に対応を開始する当番体制です。チャットへ通知するだけなのか、電話を含む呼び出しと応答確認まで行うのかを明確にします。
手順3．メトリクス、ログ、ダッシュボードを実装する
CloudWatch Metrics、Logs、Alarms、Dashboardsを中心に実装します。必要に応じて、イベント振り分けにEventBridge、通知にSNS、操作証跡にCloudTrail、分散処理の追跡にX-Rayを組み合わせます。
アプリケーションログは、時刻、環境、ログレベル、リクエストID、処理名、結果、安定したエラーコードを項目として持たせます。文章だけのログより、項目ごとに検索できる構造化ログの方が原因調査と集計に適しています。
ただし、次の情報はログへ不用意に残してはいけません。
- パスワードや秘密鍵
- アクセストークンやセッション情報
- クレジットカード情報
- 不要な個人情報
- リクエスト本文に含まれる機密データ
ロググループごとに保持期間を設定し、長期保管が必要な監査ログはS3への保管も検討します。無期限保存を初期値にすると、データ量の増加に伴って費用が膨らみやすくなります。
また、設定はIaC（インフラ設定をファイルで管理し、同じ内容を再現できるようにする方法）で管理するのが基本です。手作業だけで設定すると、本番と検証環境の差異や、担当者の退職後に変更理由が分からなくなる問題が起こりやすいためです。
手順4．通知文とランブックを用意する
通知には、少なくとも次の情報を含めます。
- システム名、AWSアカウント、環境、リージョン
- 発生時刻と重要度
- 何がどの値を超えたか
- 想定される利用者影響
- ダッシュボードとログへのリンク
- ランブックへのリンク
- エスカレーション先
ランブックとは、障害時の確認・復旧手順をまとめた運用手順書です。原因を断定する資料ではなく、最初に何を確認し、どの条件で次の担当者へ引き継ぐかを示します。
ランブックには、直近のデプロイ確認、ログの絞り込み方、再起動や切り戻しの条件、実行してはいけない操作、復旧判定を記載します。自動復旧を導入する場合は、実行回数の上限、失敗時の停止条件、実行履歴も必要です。
手順5．障害テストと受け入れ確認を行う
本番公開前には、テスト用のエラーや閾値超過を発生させ、検知から復旧確認まで通して試験します。設定画面上でアラームが存在するだけでは、通知先の誤りや権限不足を発見できません。
受け入れ時のチェックリストは次のとおりです。
- メトリクスとログが想定した間隔で届く
- アラームが想定時間内に異常状態へ変わる
- 正しい担当者へ通知される
- 通知文からダッシュボードと手順書を開ける
- 担当者が初動とエスカレーションを実行できる
- 復旧後に正常状態へ戻ったことを確認できる
- 通知経路が停止した場合の代替手段がある
- IaC、監視項目表、ランブックが納品される
- 発注者側が設定と運用方法の説明を受ける
監視設定そのものだけでなく、通知経路も監視対象です。メールやチャット連携が切れていないか、定期的なテスト通知で確認します。
AWS監視の費用相場・期間と外注先の選び方
AWS監視の費用は、初期構築費、AWS利用料、監視運用費の3つに分けて比較します。初期費用だけが安くても、ログ量や24時間対応によって月額費用が高くなる場合があります。
初期構築の費用と期間の目安
以下は一般的な目安です。既存構成の複雑さ、対象数、ドキュメントの状態、障害試験の範囲によって変わります。
| 依頼範囲 | 費用の目安 | 期間の目安 | 主な内容 |
|---|---|---|---|
| 現状診断・改善計画 | 20万〜80万円 | 1〜3週間 | 構成調査、監視漏れ、通知体制、改善優先順位の整理 |
| 小規模な監視構築 | 50万〜150万円 | 2〜6週間 | 単一環境、主要メトリクス、通知、基本ダッシュボード |
| 中規模な監視基盤 | 150万〜400万円 | 1〜3か月 | 複数サービス、ログ監視、外形監視、IaC、ランブック |
| 大規模・複数アカウント対応 | 400万〜1,000万円以上 | 3〜6か月以上 | 集約監視、権限設計、複数チーム連携、詳細な障害試験 |
Webサービス自体の新規開発、AWS基盤の全面再構築、セキュリティ監視センターの構築は通常別費用です。「監視構築一式」という見積もりでは、どこまで含むのかを確認してください。
月額の監視運用費は、平日日中の通知確認と一次調査で月10万〜50万円程度、24時間365日のオンコールや復旧作業まで含めると月30万〜150万円以上になることがあります。これは一般的な幅であり、障害件数、応答時間、対象システム数、専任体制の有無で大きく変わります。
保守契約に監視対応を含める場合は、通知確認だけなのか、原因調査、暫定復旧、恒久対応まで含むのかを分けてください。契約と見積もりの確認項目は、システム保守費用の相場｜契約・見積もりの見方でも解説しています。
CloudWatchのAWS利用料を見積もる
CloudWatchの利用料は、主に次の要素で決まります。
- ログの取り込み量と保存量
- Logs Insightsによる検索量
- カスタムメトリクス数
- アラーム数と種類
- ダッシュボード数
- 外形監視の実行回数
- APIリクエストやデータ転送
- 複数アカウント・リージョンの監視構成
小規模システムでは月数千円〜数万円程度から始まることがありますが、中規模以上では月数万円〜数十万円、ログ量が多いシステムではそれ以上になる場合があります。特に、デバッグログの常時出力や高頻度アクセスの本文記録は費用増加の要因です。
AWSの料金はリージョンや機能によって異なり、改定されることもあります。見積もりでは現在の公式料金を使い、「1日当たりのログ量」「保持期間」「カスタムメトリクス数」など、数量の前提を提示してもらいましょう。
見積書で確認する項目
見積もりは合計額だけでなく、成果物と対象外を比較します。
- 現状調査とヒアリングが含まれているか
- 監視項目表と重要度の設計が含まれているか
- CloudWatch Agentやアプリ側のログ改修が含まれているか
- IaCによる設定管理が含まれているか
- ダッシュボード、通知連携、ランブックが含まれているか
- テスト用障害による発報試験が含まれているか
- AWS利用料の試算条件が示されているか
- 本番導入後の閾値調整期間があるか
- 夜間休日の対応範囲と追加料金が明確か
- 納品後に誰が設定を変更できるか
よくある見積もり差は、アラーム数の違いだけではありません。一方は通知設定だけ、もう一方はログ改修、障害試験、ランブック、運用引き継ぎまで含むことがあります。項目数ではなく、障害発生後にどこまで動ける状態を納品するのかで比較してください。
外注先を見極める質問
開発会社やAWS支援会社には、次の質問をすると実務能力を確認しやすくなります。
- 利用者影響をどの指標で検知しますか
- 閾値を決めるためにどのデータを確認しますか
- 誤検知が多い場合はどのように改善しますか
- アプリケーションログの改修まで対応できますか
- アラームとダッシュボードをIaCで納品できますか
- 発報テストと復旧確認をどの範囲で行いますか
- 夜間通知後の一次調査と復旧は誰が担当しますか
- CloudWatchの月額利用料をどう試算しますか
- AWSアカウントや設定の所有権は発注者側に残りますか
- 運用開始後のレビュー方法と頻度はどうしますか
CPUやメモリのアラーム一覧だけを提案する会社より、重要業務、利用者影響、通知後の初動まで質問する会社の方が、運用を前提とした設計を期待できます。既存のAWS環境を診断したうえで監視を設計したい場合は、開発のご相談はこちらからご相談ください。
よくある失敗と回避策
| よくある失敗 | 起きる問題 | 回避策 |
|---|---|---|
| CPU監視だけで完了する | 業務処理の失敗や画面障害を検知できない | 外形監視とアプリケーション監視を優先する |
| すべての通知をCriticalにする | 通知疲れで重要な障害を見落とす | 重要度別に通知先と対応時間を分ける |
| 他システムの閾値を流用する | 誤検知または検知漏れが増える | 通常値、繁忙値、許容影響から決める |
| 通知テストをしない | 本番障害時に担当者へ届かない | 公開前と定期運用で発報試験を行う |
| 自動復旧を優先しすぎる | 根本原因やデータ不整合を隠す | 対象、回数上限、停止条件、履歴を設計する |
| ログを無期限保存する | CloudWatch利用料が増え続ける | 用途ごとに保持期間を設定する |
| 個人情報をログへ残す | 情報漏えい時の影響が拡大する | マスキング、項目制限、権限管理を行う |
| 納品後の担当が不明確 | 閾値や通知先が更新されない | 保守責任者と定期レビューを契約に含める |
監視は一度構築して終わりではありません。リリース後のアラーム件数、誤検知、検知できなかった事象、平均確認時間、平均復旧時間を月次または障害後にレビューします。機能追加や構成変更時には、監視項目とランブックも更新する必要があります。
まとめ
- AWS監視設計は、検知だけでなく通知、初動、復旧確認まで一体で考えます
- 可用性、遅延、エラー、飽和を優先し、利用者影響に近い指標から監視します
- 閾値は通常値、繁忙時の値、許容できない影響を基に決めます
- CloudWatch Metrics、Logs、Alarmsに加え、外形監視やCloudTrailなどを目的別に組み合わせます
- 実装後はテスト用障害を発生させ、通知経路と担当者の行動まで確認します
- 初期構築費、AWS利用料、月額の監視運用費を分けて見積もります
- 外注時は監視項目表、IaC、ランブック、障害試験、引き継ぎを成果物として確認します
- 誤検知、検知漏れ、対応時間を継続的にレビューして改善します
よくある質問
AWS監視では最初に何を設定すべきですか？
最初は、主要画面やAPIの可用性、応答時間、エラー、リソース飽和を監視します。CPUなどのインフラ指標だけでなく、外形監視や重要処理の成功件数など、利用者影響を直接確認できる指標を優先してください。
CloudWatchアラームの閾値はどう決めますか？
通常時と繁忙時の実測値を確認し、業務上許容できない影響が始まる水準から暫定値を決めます。運用開始後は誤検知と見逃しを記録し、閾値、評価期間、必要な違反回数を調整します。
EC2のメモリ使用率はCloudWatchで監視できますか？
監視できますが、EC2の標準メトリクスにはメモリ使用率が含まれません。CloudWatch Agentを導入し、必要なIAM権限と収集設定を追加して、カスタムメトリクスとして送信します。
AWS監視の外注では何を納品してもらうべきですか？
監視項目表、CloudWatchの設定、IaC、ダッシュボード、通知ルール、ランブック、障害テスト結果を基本成果物として確認します。加えて、設定変更方法、AWS利用料の試算、運用開始後の閾値調整範囲も明確にしてください。