EC2詳細モニタリングの入れ忘れ、もう起きない。CloudWatchの有効化ルールをやってみた

はじめに

サーバ増設のたびに「詳細モニタリングの有効化」を手順書に書いて、1台ずつポチポチ有効化する。そんな運用をしていて、うっかり入れ忘れたことはありませんか。

これまでEC2の詳細モニタリングは、起動時のオプションで指定するか、起動後に手動（またはCLI/IaC）で有効化するしかなく、台数が増えるほど「入れ忘れ」の温床になっていました。

2026年3月のアップデートで、CloudWatchに「有効化ルール」（テレメトリルール）という機能が追加され、タグや組織単位で対象を決めて、EC2詳細モニタリングを一括かつ自動で有効化できるようになりました。今回はタグで対象を絞ったルールを実際に作って、既存・新規のインスタンスが勝手に詳細モニタリングONになる様子を確かめます。

• What’s New
• ドキュメント

詳細モニタリングのおさらい

EC2のモニタリングには2種類あります。

5分間隔だと、CPU使用率のスパイクを捉えきれなかったり、アラームの検知が最大数分遅れたりします。本番環境では詳細モニタリングを標準にしているケースが多いはずで、だからこそ「新しいインスタンスで入れ忘れる」事故が起きます。

料金は東京リージョンでインスタンスあたり月額数百円程度（メトリクス数ベースの従量課金）です。【2026/08/31現在】

新機能: テレメトリの有効化ルール

今回のアップデートで追加された「有効化ルール」は、CloudWatchコンソールの「取り込み」（Ingestion）画面から作成します。公式ドキュメント上は「テレメトリ設定（telemetry configuration）」という機能群の一部として説明されていますが、コンソールにこの名前は出てこないので、画面で探すときは「取り込み」→「有効化ルール」タブと覚えてください。ポイントは3つです。

1. Organizations利用時は「組織全体」「OU」「アカウント」の3階層でスコープを選べ、タグやリージョンで対象をさらに絞り込める（単一アカウントではタグ＋リージョンで指定）
2. ルール作成時点の既存インスタンスと、それ以降に起動する新規インスタンスの両方に効く
3. 全商用リージョンで利用可能

組織スコープを使えば、マルチアカウント環境で「全アカウントのEC2は詳細モニタリング必須」という標準を仕組みで担保できます。本記事では単一アカウントで完結するタグスコープを検証します。

やってみた

検証構成は次のとおりです。タグ env=test で対象を絞った有効化ルール konishi-test-rule を作り、タグあり・なしのインスタンスで挙動を見ます。

準備: タグあり・なしのEC2を用意

t3.microを2台起動します。konishi-test-target にはタグ env=test を付け、konishi-test-other はタグなしです。起動直後は両方とも基本モニタリング（5分間隔）であることを確認しておきます。

有効化ルールを作る

初回のみ: リソース検出の有効化

「取り込み」画面を初めて使う場合、ルールを作る前にリソース検出の有効化を求められます。これは有効化ルールが対象リソース（今回ならEC2インスタンス）を自動で見つけるための仕組みで、有効化すると内部的にAWS Configのサービスリンクレコーダーが作成されます。通常のAWS Configレコーダーとは別枠で、この検出に使われる設定項目（CI）には課金されません。すでにAWS Configを使っている環境でも設定が衝突しない設計になっています。

ルールの作成

リソース検出を有効化したら、CloudWatchコンソールの左ナビゲーションから「取り込み」を開き、「テレメトリを設定」をクリックすると「データソースを選択」ダイアログが表示されます。CloudTrailやELB、S3など対応サービスがカードで並んでいるので、「Amazon EC2」の「テレメトリを設定」を選びます。

あとは3ステップのウィザード（範囲を指定 → データオプションを選択 → プレビューと作成）です。ステップ1「範囲を指定」の設定値は次のとおりです。

ここで気をつけたいポイントが2つありました。

1つ目はルール名は作成後に変更できないこと。デフォルトで EC2-Instance-TurnOnDetailedMetrics-<日時> という名前が自動入力されますが、後からリネームできないので、命名規則がある環境では作成前に上書きしておきましょう。

2つ目は、公式ドキュメントには「Organization / OU / アカウント」の3階層からルールスコープを選ぶ手順が載っていますが、Organizations未使用の単一アカウントではスコープ選択自体が表示されないことです。実際の画面では「タグ＋対象リージョン」で範囲を決めるシンプルな構成でした。画面の注記にも「このリージョンの現在および将来のデータソースのテレメトリのみを有効にします」とあるとおり、ルールはリージョン単位で効きます。

既存インスタンスが自動で「詳細」になった

ルールを作成して待つと、konishi-test-target の詳細モニタリングが自動で有効になりました。反映までの所要時間は12秒ほどでした。なお公式ドキュメントには、ルールは内部的にAWS Configで対象リソースを検出してから適用され、初回の検出には最大24時間かかる場合があると記載されています。すぐ反映されなくても焦らず待ちましょう。

AWS CLI経由でCloudWatchメトリクスを見ると、konishi-test-target のデータポイントが1分間隔になっていることも確認できました。

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-03xxx \
  --start-time "$(date -u -v-40M +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 60 --statistics Average \
  --region ap-northeast-1 \
  --query 'sort_by(Datapoints,&Timestamp)[].Timestamp' \
  --output text | tr '\t' '\n'

2026-08-31T13:03:00+09:00
2026-08-31T13:04:00+09:00
2026-08-31T13:05:00+09:00
2026-08-31T13:06:00+09:00
2026-08-31T13:07:00+09:00
2026-08-31T13:08:00+09:00
2026-08-31T13:09:00+09:00
2026-08-31T13:10:00+09:00

一方、タグなしの konishi-test-other は基本モニタリングのままです。タグでの絞り込みがきちんと効いています。

AWS CLI経由でCloudWatchメトリクスを確認しても、データポイントは5分間隔になっています。

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-04xxx \
  --start-time "$(date -u -v-40M +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 60 --statistics Average \
  --region ap-northeast-1 \
  --query 'sort_by(Datapoints,&Timestamp)[].Timestamp' \
  --output text | tr '\t' '\n'

2026-08-31T13:05:00+09:00
2026-08-31T13:10:00+09:00
2026-08-31T13:15:00+09:00
2026-08-31T13:20:00+09:00
2026-08-31T13:25:00+09:00
2026-08-31T13:30:00+09:00
2026-08-31T13:35:00+09:00
2026-08-31T13:40:00+09:00

新規起動でも自動で「詳細」になった

次に、タグ env=test 付きで3台目 konishi-test-new を起動します。起動時に詳細モニタリングは指定しません。

起動後すぐ、何も操作していないのに詳細モニタリングが有効になりました。「新しく建てたサーバの入れ忘れ」がこれで仕組みごと消せます。

気になる挙動を確かめた

実運用を想定して、境界っぽい挙動をいくつか確認しました。

ルール作成後にタグを後付けしたら？

有効化されます。ルール作成後に、タグなしで動いていたインスタンス（konishi-test-other）へ env=test を後付けしたところ、自動で詳細モニタリングが有効になりました。ルール作成時点のスナップショットではなく、タグの変化を継続的に見て適用してくれる動きです。

タグを外したら基本に戻る？

戻りません。タグを外しても詳細モニタリングは有効のままで、当然課金も続きます。ルールはあくまで「有効化」だけを行う片方向の仕組みで、対象から外れたリソースを無効化まではしてくれません。基本に戻したい場合は、インスタンスのモニタリング設定から手動で無効化する必要があります。

手動で無効化したらルールが再有効化する？

再有効化されます。タグが付いたままのインスタンスの詳細モニタリングを手動で無効化してみたところ、ルールが検知して再び有効化されました。ルールが「あるべき状態」を維持し続けてくれるので、誰かがうっかり無効化しても勝手に直る、というのは運用上ありがたい挙動です。

まとめると: 対象から外すときは順序に注意

後半の2つの挙動を組み合わせると、意図的に詳細モニタリングをやめたいときの正しい手順は「①タグを外す → ②手動で無効化する」の順になります。タグが付いたまま手動で無効化してもルールに戻されてしまい、タグを外しただけでは有効（課金継続）のまま、というわけです。

料金の注意

詳細モニタリング自体の料金は従来どおり発生します。有効化ルールという機能自体は無料ですが、ルールのスコープを雑に広げると「気づいたら全インスタンスで課金されていた」という事故につながります。特にenv=prod のような広いタグ条件を指定する場合や、組織全体を対象にする場合は、対象台数×月額を事前に見積もっておきましょう。

また前述のとおり、タグを外しても詳細モニタリング（と課金）は自動では止まりません。対象から外したインスタンスは手動での無効化を忘れずに。

まとめ

• CloudWatchの有効化ルール（テレメトリルール）で、EC2詳細モニタリングをタグや組織の単位で一括自動有効化できるようになった
• 既存インスタンスにも新規インスタンスにも効くので、監視設定手順から「詳細モニタリング有効化」のステップを丸ごと消せる
• 組織スコープを使えば、マルチアカウント環境の監視標準化にも使える

インスタンス追加のたびに手順書とにらめっこしていた方は、ぜひ試してみてください。

参考

• AWS What’s New: CloudWatch org enablement for EC2 metrics
• Telemetry config rules（CloudWatchユーザーガイド）