マルチAZ構成で選ぶAWS監視サービスの比較と設計指針｜CloudWatchとDatadogの使い分け

運営：リナックスマスター.JP（代表 宮崎智広）
ＨＯＭＥ ＞ Linux技術 リナックスマスター.JP（Linuxマスター.JP） ＞ AWS(Amazon Linux) ＞ マルチAZ構成で選ぶAWS監視サービスの比較と設計指針｜CloudWatchとDatadogの使い分け
「AWSの監視ツール、何を入れればいいか分からない」
マルチAZ構成でシステムの冗長性を確保しても、監視設計が後付けになっているケースはよくあります。

この記事では、aws監視サービスの代表格であるCloudWatchと、外部SaaSのDatadogを比較し、マルチAZ環境に合った選定基準と設計指針を解説します。
EC2・RDS・ALBなどAWSリソースを中心に運用しているエンジニアを想定環境としています。

この記事のポイント

・CloudWatchはAWSリソースの標準メトリクス収集コストが低く、マルチAZ設計との親和性が高い
・DatadogはGCP・Azureを含むマルチクラウドや20台以上の環境で横断ダッシュボードが必要なときに強い
・選定の分かれ目は「AWS専用か否か」と「月次の監視コスト許容額」
・マルチAZ構成では可用性ゾーン別のアラート設計が監視品質を左右する


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

なぜマルチAZ環境でaws監視サービスの選定が重要なのか

マルチAZ構成は、1つのAZで障害が起きても別のAZで処理を継続させる設計です。
ただし冗長化しただけでは不十分で、「AZ単位でどこに問題が起きているか」を素早く特定できる監視の仕組みが必要です。

aws監視サービスを選ぶとき、次の3点が判断軸になります。

・AWSリソースを中心に監視するか、オンプレやGCPも含めたマルチクラウド監視が必要か
・チームの規模と月次の監視予算
・アラートの細かさとダッシュボードのカスタマイズ性

この3点の答えによって、CloudWatchで十分なケースとDatadogが必要なケースが分かれます。

AWS CloudWatchの特徴と得意な監視パターン

CloudWatchはAWSが提供するマネージド監視サービスです。
追加エージェントなしでEC2・RDS・ALB・Lambda・S3といったAWSリソースのメトリクスを標準で取得できます。

1. CloudWatchが標準で取得できるメトリクス

AWSリソースはデフォルトで基本メトリクスをCloudWatchへ送信します。
代表的なものは次のとおりです。

・EC2: CPUUtilization、NetworkIn/Out、StatusCheckFailed
・RDS: CPUUtilization、DatabaseConnections、FreeStorageSpace
・ALB: RequestCount、TargetResponseTime、HTTP 5XX
・ALB: HealthyHostCount（AZ別に取得可能）

特にマルチAZ環境では、ALBの HealthyHostCount を AZ 別に分割して監視することで、特定 AZ でのターゲット障害を素早く検知できます。

2. マルチAZ対応アラートの設計

CloudWatchアラームにはディメンション（Dimension）という絞り込み条件があります。
AvailabilityZone ディメンションを指定することで、AZ 単位のアラートを設定できます。


# CloudWatch CLI でマルチAZ別アラームを設定する例（出力例・環境により異なります）
aws cloudwatch put-metric-alarm \
  --alarm-name "ALB-HealthyHost-AZ-a" \
  --namespace AWS/ApplicationELB \
  --metric-name HealthyHostCount \
  --dimensions Name=TargetGroup,Value=targetgroup/my-tg/xxx \
                Name=AvailabilityZone,Value=ap-northeast-1a \
  --statistic Minimum \
  --period 60 \
  --threshold 1 \
  --comparison-operator LessThanThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:my-alert-topic
このように AZ を絞り込んでアラームを設定することで、「ap-northeast-1a の ALB ターゲットが全滅した」という事態を即座に通知できます。

3. CloudWatchの制限と注意点

CloudWatchはAWSリソースの監視には優れていますが、いくつか制限があります。

・EC2内部のメモリ使用率・ディスク使用率は標準では取得できない（CloudWatch Agentの追加インストールが必要）
・オンプレサーバーやGCPなど他クラウドのリソースは標準では対象外
・ログクエリは CloudWatch Logs Insights で可能だが、Datadog に比べると記述量が多くなる傾向がある

EC2 のメモリ監視が必要な場合は、CloudWatch Agent を別途インストールします。

Datadogの特徴とマルチクラウド対応の強み

Datadogはサードパーティのフルスタック監視SaaSです。
AWS以外にGCP・Azure・オンプレミスも同一ダッシュボードで管理でき、マルチクラウド移行中の環境で特に力を発揮します。

1. Datadogエージェントのインストールと基本設定

EC2インスタンスにDatadogエージェントをインストールすると、メモリ・ディスク・プロセスなどの詳細なホストメトリクスが取得できます。


# RHEL系（Amazon Linux 2023）へのDatadogエージェントインストール（出力例・環境により異なります）
DD_AGENT_MAJOR_VERSION=7 DD_API_KEY=<YOUR_API_KEY> DD_SITE="datadoghq.com" \
  bash -c "$(curl -L https://s3.amazonaws.com/dd-agent-distrib/scripts/install_script_agent7.sh)"

# インストール後の確認
systemctl status datadog-agent
# Active: active (running) と表示されれば正常に起動しています
エージェントインストール後は、AWSインテグレーション設定でCloudWatchメトリクスをDatadogへ取り込むことも可能です。

2. マルチAZ環境でのダッシュボード設計

Datadogでは availability-zone タグを使って、AZ 別にメトリクスをフィルタリングできます。
AWS インテグレーションを設定すると、EC2・RDS などのリソースに自動でAZタグが付与されます。

ダッシュボードのウィジェットで次のようなクエリを書くと、AZ 別の CPU 使用率を並べて表示できます。


# Datadogダッシュボード クエリ例（出力例・環境により異なります）
avg:aws.ec2.cpuutilization{availability-zone:ap-northeast-1a} by {host}
avg:aws.ec2.cpuutilization{availability-zone:ap-northeast-1c} by {host}
特定 AZ だけ CPU が高騰しているケースを視覚的に把握できます。

3. Datadogのコストと適した規模感

Datadogは監視対象ホスト数に応じた従量課金です。
Infrastructure プランはホスト1台あたり月15ドル前後（2026年時点の目安）かかります。

EC2を10台以内で運用し、AWS以外のインフラを持たない構成では、CloudWatchのほうがコストを抑えられるケースが多いです。
一方で、GCPやオンプレを含む20台以上の環境では、Datadogの統合ダッシュボードが運用効率を上げます。

aws監視サービスの選定に迷う場合は、監視の前提となるLinuxサーバー構築の「型」を体系的に学ぶことで判断基準が明確になります。
AWSとAmazon Linuxを使ったLinuxサーバー構築の基礎から始めるのも一つの方法です。

CloudWatchとDatadogの比較

比較項目 CloudWatch Datadog
AWSリソースの標準メトリクス 追加不要で取得可 AWSインテグレーション設定が必要
EC2メモリ・ディスク監視 エージェント追加で可能 エージェントで標準取得
マルチクラウド対応 AWS専用（他クラウドは別途設定） GCP・Azure・オンプレも対応
AZ別監視 ディメンション指定で設定可 タグフィルターで設定可
ダッシュボードのカスタマイズ性 標準機能で対応可 高い（グラフ種類・相関分析が豊富）
月次コスト（EC2を10台運用時の目安） メトリクス・アラーム数による従量（数百円から） ホスト数による従量（150ドル前後）
向いている規模 AWS専用・小中規模 マルチクラウド・中大規模

どちらを選ぶか｜構成規模・チーム・予算別の判断基準

選定の基準を整理します。
CloudWatchを選ぶ場合:
・運用環境がAWS専用で、他クラウドへの移行予定がない
・EC2台数が10台以下で、追加の監視コストを最小化したい
・ALB・RDS・Lambda の標準メトリクスで障害検知が完結する構成

Datadogを選ぶ場合:
・GCP・Azure・オンプレを含むマルチクラウド環境を1画面で管理したい
・EC2台数が20台以上で、ホスト別のプロセス監視やAPMが必要
・ログとメトリクスを相関させた根本原因分析（RCA）まで行いたい

「AWS専用かつ小中規模」ならCloudWatch、「マルチクラウドかつ詳細なプロセス監視が必要」ならDatadogが合います。
どちらの場合も、マルチAZ構成では可用性ゾーン別のアラート設計を最初に行うことが重要です。

マルチAZ監視設計の基本構成パターン

マルチAZ環境での監視設計では、次の3つのレイヤーを分けて考えます。
レイヤー1: AWSリソース層（CloudWatch標準メトリクス）
ALBの HealthyHostCount、RDSのDatabaseConnections、EC2の StatusCheckFailed を AZ 別に監視します。
このレイヤーはCloudWatchで対応するのが最も効率的です。

レイヤー2: OS層（CloudWatch Agent または Datadogエージェント）
EC2内部のメモリ使用率・ディスク使用率・プロセス稼働状況を監視します。
CloudWatch AgentとDatadogエージェントはどちらでも対応できますが、マルチクラウドを含む環境ではDatadogのほうが設定を一元化しやすいです。

レイヤー3: アプリケーション層（カスタムメトリクス）
HTTPレスポンスタイム・エラー率・キューの滞留数など、アプリ固有の指標をカスタムメトリクスとしてCloudWatchまたはDatadogへ送信します。

この3レイヤーをそれぞれ整理してから監視ツールを選ぶと、ツール選定の判断がしやすくなります。

トラブルシュート｜監視の盲点とよくある設定ミス

1. マルチAZで片側のAZだけ監視が抜ける

CloudWatchアラームを設定する際、AvailabilityZone ディメンションを指定し忘れると、全AZ合算の数値だけを監視することになります。
ap-northeast-1a の ALB ターゲットが全滅していても、ap-northeast-1c が正常なら合算値は閾値を超えず、アラームが発報されないケースがあります。

対処: AZ 別のアラームをそれぞれ設定する、または CloudWatch Composite Alarm で複数条件を組み合わせて設計します。

2. Datadogエージェントのタグ付け漏れ

Datadogでマルチ環境を管理するとき、EC2インスタンスに availability-zone タグが付いていない場合があります。
AWS インテグレーションの設定で「EC2タグを取得する」オプションが有効になっているか確認してください。

3. CloudWatch Agentのメモリメトリクスが取得できない

CloudWatch Agent の設定ファイル（/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json）に mem_used_percent の設定が含まれていないケースがあります。


# CloudWatch Agent 設定ファイルの mem 項目を確認する例（出力例・環境により異なります）
python3 -c "
import json
with open('/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json') as f:
    cfg = json.load(f)
keys = cfg.get('metrics', {}).get('metrics_collected', {}).keys()
print(list(keys))
"
# ['cpu', 'disk', 'mem', 'net', ...] と表示されれば mem が含まれています
設定ファイルに mem が含まれていない場合は、ウィザードで再設定するか、手動でJSONを編集してから CloudWatch Agent を再起動します。

本記事のまとめ

選定条件 推奨サービス
AWS専用・EC2台数10台以下 CloudWatch（コスト優先）
マルチクラウド・EC2台数20台以上 Datadog（統合管理優先）
マルチAZ別のアラート設計 CloudWatch（AvailabilityZoneディメンション）
プロセス・APM・ログ相関分析 Datadog（高度な可視化）
EC2メモリ・ディスク監視 どちらでも可（エージェント追加で対応）
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
AWSとAmazon Linuxを使ったサーバー構築・運用設計を2日間で学べるLinuxMasterセミナーがあります。
マルチAZ設計・監視設計を含む実践的なカリキュラムで、現場で通用する知識が体系的に身につきます。
＞＞ AWSとAmazon Linuxを学ぶ詳細はこちら

関連記事

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

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

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

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

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

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

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

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

運営

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

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