CloudWatchを中心に構築するAWS運用監視の設計アーキテクチャ|マルチアカウント対応

運営:リナックスマスター.JP(代表 宮崎智広)
HOME > Linux技術 リナックスマスター.JP(Linuxマスター.JP) > AWS(Amazon Linux) > CloudWatchを中心に構築するAWS運用監視の設計アーキテクチャ|マルチアカウント対応
「AWSのサービスがいつの間にか止まっていた。なぜ気づかなかったのか?」
「CloudWatchアラームは設定しているのに、通知が来るのが障害の30分後だった」

AWS運用監視を設計しようとすると、こういった状況に直面することがあります。
CloudWatchは強力なツールですが、個別のサービスにアラームを置くだけでは、設計としては半分にも届きません。

この記事では、CloudWatchを中心にaws運用監視のアーキテクチャを設計する方法を解説します。
メトリクス収集・ログ管理・アラート設計の3レイヤー構成と、マルチアカウント対応のCross-Account設定まで、実践的なパターンを紹介します。

この記事のポイント

・aws運用監視はメトリクス収集・ログ管理・アラート設計の3レイヤーで設計する
・マルチアカウント構成では Cross-Account Observability で中央集約する
・Composite Alarmで複数メトリクスの複合条件アラートを実装できる
・ダッシュボードは中央監視アカウントにまとめてチームで共有できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

AWS運用監視でCloudWatchを中心に設計する理由

AWSには監視に使えるサービスが複数あります。
CloudTrail、Config、X-Ray、GuardDutyなど、それぞれが異なる観点でシステムの状態を記録しています。

その中でCloudWatchが「中心」になる理由は、メトリクス・ログ・アラームの3つを1か所で扱えるからです。
EC2のCPU使用率もLambdaの実行時間もRDSのコネクション数も、CloudWatchメトリクスとして同じ仕組みで収集・確認できます。

CloudTrailはAPI操作の監査ログ、GuardDutyは脅威検知、Configはリソース設定の変更記録です。
これらはCloudWatchと連携させることで、イベント検知からアラーム通知、ダッシュボード表示まで一本の流れにまとめられます。

20年以上サーバー管理を続けてきた経験から言うと、監視ツールは「何が起きたか」より「いつ・何が変わったか」を記録する設計が先です。
CloudWatchはその両方をカバーできる、現時点でAWSの中心的な監視基盤です。

AWS運用監視アーキテクチャの3レイヤー構成

aws運用監視のアーキテクチャは、次の3レイヤーで設計するのが基本です。
レイヤー 役割 主なサービス
メトリクス収集 リソースの数値指標を時系列で記録 CloudWatch Metrics、CloudWatch Agent
ログ管理 アプリケーションとシステムのログを集約 CloudWatch Logs、Logs Insights
アラート・通知 しきい値超過・異常状態を検知して通知 CloudWatch Alarm、SNS、EventBridge
この3レイヤーを独立して設計するのではなく、連携して機能するように組み立てることが重要です。

1. メトリクス収集レイヤー

AWSのマネージドサービス(EC2、RDS、ALBなど)のメトリクスは、CloudWatchに自動的に送信されます。
ただし、EC2インスタンスの内部情報(メモリ使用率、ディスク使用量など)はデフォルトでは収集されません。

EC2内部のメトリクスを収集するには、CloudWatch Agentをインストールします。

# CloudWatch Agentのインストール(Amazon Linux 2023 / RHEL 9系) sudo dnf install -y amazon-cloudwatch-agent # 設定ウィザードを起動する sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard

設定ウィザードでは、収集するメトリクスとログの設定を対話形式で入力できます。
設定ファイルは `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json` に保存されます。

メモリとディスクを収集する最小構成の例は次のとおりです。

# /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json { "metrics": { "namespace": "CWAgent", "metrics_collected": { "mem": { "measurement": ["mem_used_percent"], "metrics_collection_interval": 60 }, "disk": { "measurement": ["disk_used_percent"], "resources": ["/"], "metrics_collection_interval": 60 } } } }

設定後、エージェントを起動します。

# CloudWatch Agentを起動・自動起動設定 sudo systemctl enable --now amazon-cloudwatch-agent # 動作確認 sudo systemctl status amazon-cloudwatch-agent

出力例(環境により異なります):

* amazon-cloudwatch-agent.service - Amazon CloudWatch Agent Loaded: loaded (/etc/systemd/system/amazon-cloudwatch-agent.service; enabled) Active: active (running) since ...

2. ログ管理レイヤー(CloudWatch Logs)

ログ管理では、CloudWatch Logsをログ集約の場所として使います。
CloudWatch Agentの設定でログファイルのパスを指定すれば、EC2のシステムログやアプリケーションログをCloudWatch Logsへ送信できます。

# CloudWatch Agentのログ設定(amazon-cloudwatch-agent.jsonに追加) { "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/messages", "log_group_name": "/ec2/system/messages", "log_stream_name": "{instance_id}", "retention_in_days": 30 }, { "file_path": "/var/log/secure", "log_group_name": "/ec2/system/secure", "log_stream_name": "{instance_id}", "retention_in_days": 90 } ] } } } }

ログが集まったら、CloudWatch Logs Insightsで検索・分析できます。

例えば、SSHログイン失敗を確認するクエリは次のようになります。

# Logs Insightsのクエリ例(SSHログイン失敗) fields @timestamp, @message | filter @logStream like /secure/ | filter @message like /Failed password/ | sort @timestamp desc | limit 100

ログの保持期間はロググループごとに設定できます。
コスト管理の観点から、保持期間が不要に長くなっていないかを定期的に確認することをお勧めします。

3. アラート・通知レイヤー

アラートはCloudWatch AlarmとSNSを組み合わせて設計します。
基本的な流れは「CloudWatch Alarm → SNS Topic → メール・Slackなどへ通知」です。

CLIでアラームを作成する例を紹介します。

# CPU使用率80%超過のアラームを作成する aws cloudwatch put-metric-alarm \ --alarm-name "EC2-High-CPU-web01" \ --alarm-description "CPU usage exceeded 80%" \ --metric-name CPUUtilization \ --namespace AWS/EC2 \ --statistic Average \ --period 300 \ --threshold 80 \ --comparison-operator GreaterThanOrEqualToThreshold \ --evaluation-periods 2 \ --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \ --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:ops-alert \ --ok-actions arn:aws:sns:ap-northeast-1:123456789012:ops-alert

`--evaluation-periods 2` は「2回連続でしきい値を超えたらアラーム状態にする」という設定です。
一時的なスパイクで誤検知が多い場合は、この値を3~5に増やすとノイズを減らせます。

マルチアカウント対応のCloudWatch設計

本番環境・開発環境・ステージング環境を別アカウントで管理している構成では、各アカウントのCloudWatchを個別に確認するのは現実的ではありません。
AWSのCross-Account Observability機能を使うと、複数のアカウントのメトリクス・ログ・トレースを中央監視アカウントから一元管理できます。

1. Organizations連携とCross-Account Observabilityの設定

Cross-Account Observabilityの設定は「監視アカウント(Monitoring Account)」と「ソースアカウント(Source Account)」の2か所で行います。

# 監視アカウント側:他のアカウントからのデータ受信を許可する aws cloudwatch put-metric-stream \ --name monitoring-account-link \ --include-linked-accounts-metrics # ソースアカウント側:監視アカウントへのリンクを作成する aws oam create-link \ --label-template "$AccountEmail" \ --resource-types "AWS::CloudWatch::Metric" "AWS::Logs::LogGroup" \ --sink-identifier "arn:aws:oam:ap-northeast-1:MONITORING_ACCOUNT_ID:sink/SINK_ID"

リンク作成後、監視アカウントのCloudWatchコンソールから各ソースアカウントのメトリクスを確認できます。
ソースアカウントを追加するたびに同じ手順を繰り返します。

2. 中央監視アカウントでのダッシュボード集中管理

中央監視アカウントにCloudWatchダッシュボードを作成し、複数アカウントのメトリクスを1画面で表示できます。

# クロスアカウントのメトリクスを含むダッシュボードを作成する例 aws cloudwatch put-dashboard \ --dashboard-name "MultiAccount-Overview" \ --dashboard-body '{ "widgets": [ { "type": "metric", "properties": { "metrics": [ ["AWS/EC2", "CPUUtilization", "InstanceId", "i-0123456789abcdef0", {"accountId": "SOURCE_ACCOUNT_ID_1"}], ["AWS/EC2", "CPUUtilization", "InstanceId", "i-abcdef0123456789", {"accountId": "SOURCE_ACCOUNT_ID_2"}] ], "period": 300, "title": "マルチアカウント CPU使用率" } } ] }'

ダッシュボードのウィジェットに `"accountId"` を指定することで、ソースアカウントのメトリクスを監視アカウントのダッシュボードに表示できます。

Composite Alarmで複合条件のアラートを設計する

通常のCloudWatch Alarmは1つのメトリクスに対して1つのしきい値を設定します。
しかし実際の障害では「CPUが高い」だけでなく「CPU高負荷かつメモリが枯渇している」という複合条件で判断したいケースがほとんどです。

Composite Alarmを使うと、複数のアラームをAND・OR条件で組み合わせられます。

# 個別アラームを先に作成する # (CPU高負荷アラーム) aws cloudwatch put-metric-alarm \ --alarm-name "web01-high-cpu" \ --metric-name CPUUtilization \ --namespace AWS/EC2 \ --statistic Average \ --period 300 \ --threshold 80 \ --comparison-operator GreaterThanOrEqualToThreshold \ --evaluation-periods 2 \ --dimensions Name=InstanceId,Value=i-0123456789abcdef0 # (メモリ高使用率アラーム) aws cloudwatch put-metric-alarm \ --alarm-name "web01-high-memory" \ --metric-name mem_used_percent \ --namespace CWAgent \ --statistic Average \ --period 300 \ --threshold 90 \ --comparison-operator GreaterThanOrEqualToThreshold \ --evaluation-periods 2 \ --dimensions Name=InstanceId,Value=i-0123456789abcdef0 # 両方が ALARM 状態のときだけ通知する Composite Alarm を作成する aws cloudwatch put-composite-alarm \ --alarm-name "web01-critical-combined" \ --alarm-description "CPU 80%超かつメモリ 90%超" \ --alarm-rule 'ALARM("web01-high-cpu") AND ALARM("web01-high-memory")' \ --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:ops-critical

Composite Alarmを使うと、個別アラームの誤検知を減らしながら、本当に危険な状態だけを通知できます。
夜間のアラート疲れを防ぐために、緊急度の高いアラームには Composite Alarm を使うことをお勧めします。

AWSのAmazon Linux環境でのEC2構築から始めたい方は、AWSセミナーの詳細ページもご確認ください。

よくある設計ミスとトラブルシューティング

1. アラームが INSUFFICIENT_DATA 状態のまま変わらない

アラームが `INSUFFICIENT_DATA` 状態のまま変わらない場合は、次の2点を確認してください。

・CloudWatch AgentがEC2インスタンスで正しく動作しているか
・IAMロールにCloudWatchへのメトリクス送信権限(`cloudwatch:PutMetricData`)が付与されているか

# メトリクスが届いているか確認する aws cloudwatch get-metric-statistics \ --namespace CWAgent \ --metric-name mem_used_percent \ --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \ --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ) \ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \ --period 300 \ --statistics Average

出力例(環境により異なります):

{ "Datapoints": [ { "Timestamp": "2026-11-08T06:00:00Z", "Average": 42.3, "Unit": "Percent" } ], "Label": "mem_used_percent" }

`Datapoints` が空配列の場合は、メトリクスが届いていないのでエージェント側の設定を確認してください。

2. Cross-Account監視でメトリクスが表示されない

Cross-Account設定後にメトリクスが表示されない場合は、ソースアカウント側のリンク状態を確認します。

# ソースアカウント側でリンクの状態を確認する aws oam list-links # 出力例 { "Items": [ { "Arn": "arn:aws:oam:ap-northeast-1:SOURCE_ID:link/LINK_ID", "Id": "LINK_ID", "Label": "source-account@example.com", "ResourceTypes": ["AWS::CloudWatch::Metric"], "SinkArn": "arn:aws:oam:ap-northeast-1:MONITORING_ID:sink/SINK_ID" } ] }

リンクが存在するにもかかわらずメトリクスが表示されない場合は、監視アカウント側のSinkポリシーでソースアカウントのIDが許可されているか確認してください。

3. アラーム通知が届かない

アラーム通知が届かない場合は、SNS Topicのサブスクリプションが確認済み状態(`Confirmed`)になっているか確認します。

# SNS Topicのサブスクリプション状態を確認する aws sns list-subscriptions-by-topic \ --topic-arn arn:aws:sns:ap-northeast-1:123456789012:ops-alert

出力例(環境により異なります):

{ "Subscriptions": [ { "Protocol": "email", "Endpoint": "ops-team@example.com", "SubscriptionArn": "arn:aws:sns:ap-northeast-1:...", "TopicArn": "arn:aws:sns:ap-northeast-1:...", "Owner": "123456789012" } ] }

`SubscriptionArn` の値が `PendingConfirmation` のままであれば、確認メールのリンクを操作してサブスクリプションを有効にしてください。

まとめ

CloudWatchを中心にaws運用監視のアーキテクチャを設計するポイントをまとめます。
やりたいこと 設定内容・コマンド
EC2のメモリ・ディスクを収集する amazon-cloudwatch-agent + 設定ファイルでメトリクス指定
ログをCloudWatchに集約する CloudWatch Agent のlogs設定でfile_pathを指定
CPU高負荷を検知して通知する aws cloudwatch put-metric-alarm でSNSアクションを設定
複合条件でアラートを設計する aws cloudwatch put-composite-alarm でAND/OR条件を設定
複数アカウントを中央集約で監視する aws oam create-link でCross-Accountリンクを設定
複数アカウントのダッシュボードを統合する put-dashboardのmetrics定義にaccountIdを指定
aws運用監視で重要なのは、メトリクス収集・ログ管理・アラート設計を最初から3レイヤーで設計することです。
あとから追加していくと、設定が散在してどこで何を監視しているかが分からなくなります。

マルチアカウント構成では、Cross-Account Observabilityを使って中央監視アカウントにメトリクスとログを集約することで、全体像を一か所で把握できます。
Composite Alarmを組み合わせると、ノイズを減らしながら本当に重大な異常だけを検知する設計に仕上がります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
AWS環境での実践的なサーバー構築から運用管理まで、体系的に学べるセミナーを開催しています。
詳細は下記のページでご確認ください。
>> AWS(Amazon Linux)実践セミナーの詳細はこちら

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録

運営

リナックスマスター.JP(代表 宮崎智広)

株式会社イーネットマーキュリーが運営するLinux教育サイトです。代表の宮崎智広は現役のLinuxサーバー管理者として20年以上の実務経験を持ち、累計3,100名以上のエンジニアを指導してきました。実践型のLinuxセミナーや無料マニュアルの配布を通じてLinux人材の育成に取り組んでいます。