![[アップデート] Amazon CloudWatchがリソースのタグを用いてメトリクスモニタリングができるようになり、リソースの追加や変更に自動的に適応する動的なCloudWatchアラームを設定可能になりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-d6a3bc85cad6419960fbda152152cd8c/ba5841cea06b96f4933878762028b090/amazon-cloudwatch?w=3840&fm=webp)
[アップデート] Amazon CloudWatchがリソースのタグを用いてメトリクスモニタリングができるようになり、リソースの追加や変更に自動的に適応する動的なCloudWatchアラームを設定可能になりました
リソースに付与したタグを使ってCloudWatchアラームやダッシュボードを作成したい
こんにちは、のんピ(@non____97)です。
皆さんはリソースに付与したタグを使ってCloudWatchアラームやダッシュボードを作成したいなと思ったことはありますか? 私はあります。
従来CloudWatchアラームを設定する際にはリソースIDやデバイス名など、そのメトリクスのディメンションを明示的に指定してあげる必要がありました。
結果として、「本番環境のEC2インスタンスに対して共通的にCPU使用率80%でアラート通知を行う設定を仕込む」といったことはできませんでした。そのため、本番環境のEC2インスタンスが100台あるのであれば100個CloudWatchアラームを設定する必要がありました。1つのEC2インスタンスに5つ監視項目があるのであれば計500個設定が必要です。非常に手間ですね。
この手間は以下のようにCloudWatch Metrics Insightsアラームを用いることによって緩和することは可能でした。
しかし、当時はGROUP BYの組み合わせができなかったため、いずれかのメトリクスがアラート状態/OK状態になったタイミングでしかアクションを実行することができませんでした。そのため、アラーム通知を受け取ったら自身がマネジメントコンソールでGROUP BYで対象リソースを絞り込む運用が必要だったり、同時に複数台が閾値を超過したとしても一回しかアラームアクションが実行されなかったりと実際の運用としては中々厳しいものでした。
これが、2025年9月の以下アップデートにより、CloudWatch Metrics InsightsのGROUP BYでグループ単位のメトリクスの個別単位でCloudWatchアラームを設定することが可能になりました。
これにより、個々のメトリクス(正しくはコントリビューター)の状態が遷移したタイミングでアクションを実行することが可能になりました。
一方で、フィルター条件は変わらずディメンションの値を指定する必要がありました。つまりは「本番環境の」といった絞り込みをするためには都度リソースIDなど、リソースの物理的な情報を指定する必要がありました。
今回、Amazon CloudWatch Metrics Insightsでリソースのタグを用いてクエリ実行ができるようになりました。
これにより、本番環境用のリソースに付与したタグを用いて監視対象を絞り込むことが可能になりました。
従来では、同一の監視項目で同一の閾値であっても100個CloudWatchアラームの設定しなければならなかったものが1つのアラームで足りるようになったということです。env : prodとenv : devのタグの種別ごとに5項目の監視項目があったとしても10個です。設計/構築/テスト/運用の工数を大幅に減らせられます。
「たとえ100個だとしても同じようなCloudWatchアラームなのでれば、AWS CDKでループすれば今までも簡単にできたんじゃ？？」という声もあるかと思います。しかし、AWS CDKの場合は以下2つの問題を気にする必要があります。
- 一つのStack内に作成できるリソース数は500個までというクォータがある
- Stackを分割する場合、CloudWatchアラームのディメンションで指定するリソースの物理IDの受け渡し方法を考える必要がある
私の経験上、大量のリソースに対して複数のCloudWatchアラームを設定しようと簡単に500個というクォータにはタッチしてしまいます。
しかもタグで指定が可能ということは、リソースをリストアする際にタグが一致するように指定することでCloudWatchアラーム側を再設定する必要がなくなるというメリットもあります。
個人的にはこれは神アップデートです。re:Invent級アップデートです。
実際に試します。
いきなりまとめ
- タグを用いてCloudWatch Metrics Insightsアラームを作成することで、リソースの追加や変更に自動的に適応する動的なCloudWatchアラームを設定が可能になった
- 同一のメトリクス名、同一の閾値、同一のアクションのCloudWatchアラームを設定する手間の削減につながる
- 物理リソース情報を指定する方式と比較して、リソースIDの変更を伴う変更があったとしても、タグが一致していればCloudWatchアラームの設定が不要となるメリットがある
- コスト的なデメリットも特にない
- 事前にテレメトリのリソースタグの有効化が必要
- 有効化してから実際に使用できるようになるまで最大3時間ほどかかることがある
- テレメトリのリソースタグは追加料金なしで使用可能
- 有効化前のメトリクスや、GROUP BYで指定したタグが設定されていない場合はメトリクスのラベルは
Otherとなる - 検証した限り、タグの値の変更はサポートしていない
やってみた
検証環境
検証環境用に2台のAmazon Linux 2023のEC2インスタンスを用意しました。
それぞれのEC2インスタンスに付与しているタグは以下のとおりです。
> aws ec2 describe-tags --filters "Name=resource-type,Values=instance" --query 'Tags[*].[ResourceId,Key,Value]' --output table
-------------------------------------------------
| DescribeTags |
+----------------------+--------+---------------+
| i-0083cc67a3f0f1899 | Name | psql-client |
| i-0083cc67a3f0f1899 | env | dev |
| i-0083cc67a3f0f1899 | test | test |
| i-0083cc67a3f0f1899 | test2 | test2 |
| i-0083cc67a3f0f1899 | test3 | test3 |
| i-0083cc67a3f0f1899 | test4 | test4 |
| i-0083cc67a3f0f1899 | test5 | test5 |
| i-0083cc67a3f0f1899 | test6 | test6 |
| i-0e3b2df10bad6f2ac | Name | fsxl-client |
| i-0e3b2df10bad6f2ac | env | dev |
+----------------------+--------+---------------+
テレメトリのリソースタグの有効化
それでは、CloudWatchの設定でテレメトリのリソースタグの有効化を有効にします。
有効化に際して追加の料金は発生しません。
You can enable resource tags for telemetry at no additional cost.
CloudWatchのコンソールからテレメトリでリソースタグを有効にするのテレメトリのリソースタグを有効にします。
以下文言から上述に記載の「本番環境のEC2インスタンスに対して共通的にCPU使用率80%でアラート通知を行う設定を仕込む」ということはできそうな予感がしますね。
AWS リソースタグをテレメトリデータに追加して、詳細なモニタリングダッシュボードを作成し、トラブルシューティングワークフローを簡素化します。
テレメトリのリソースタグを有効にすると、次のことが可能になります:
- リソースタグによるメトリクスのフィルタリングとグループ化を行う
- タグベースのメトリクスインサイトクエリを使用してアラームを作成する
最大3時間ほどかかるようなので注意しましょう。
ちなみにこちらの設定をする際には以下の権限が必要のようです。
To enable resource tags on telemetry, you must be signed in to an IAM principal that has the iam:CreateServiceLinkedRole, resource-explorer-2:CreateIndex, resource-explorer-2:CreateManagedView and resource-explorer-2:CreateStreamingAccessForService permissions.
有効化自体はすぐに完了しました。
CloudWatch Metrics Insightsのクエリビルダーからリソースに付与したタグを用いてメトリクスを確認
CloudWatch Metrics Insightsのクエリビルダーからリソースに付与したタグを用いてメトリクスを確認します。
GROUP BYにtag.NameとNameタグの値でグルーピングをしてみます。
実際のクエリは以下のとおりです。
SELECT MAX(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) GROUP BY tag.Name
CPUUtilization fsxl-clientやCPUUtilization psql-clientメトリクス名の隣にNameタグの値が記載されていますね。
GROUP BYには以前からInstanceIdやImageIdなども指定可能でしたが、NameタグでGROUP BYとすることで、より直感的に把握ができますね。
WHEREもタグで指定することが可能なことがクエリビルダーのサジェストから分かります。
CloudWatchアラームの設定
こちらでCloudWatchアラームを設定しましょう。
先ほどのクエリでCloudWatchアラームを作成します。
内容としては「いずれかのEC2インスタンスでCPU使用率が50%以上かどうかを監視する」というCloudWatchアラームになります。
作成したCloudWatchアラームを確認すると、2つのコントリビューターが認識されていることが分かりますね。
CloudWatchアラームの動作確認
fsx-clientでのstressコマンド実行
CloudWatchアラームの動作確認をします。
まず、fsxl-clientでstressコマンドを叩いてCPUに負荷をかけます。
[ec2-user@ip-10-10-0-11 ~]$ stress -c 1
stress: info: [2715] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
すると、CloudWatchアラームの状態がアラーム状態になりました。コントリビューターCPUUtilization 2 - fsxl-clientの状態もアラーム状態となっていますね。
CloudWatchアラームのアクションの追加
個々のコントリビューターの状態が遷移したタイミングで指定したアクションが行われるかどうか確認するために、アラームとOKの通知アクションを設定します。
fsx-clientでのstressコマンド終了
この状態でstressコマンドを終了します。
履歴からコントリビューターのアクションが行われたことが分かりますね。
通知先を確認すると、閾値が超過していたfsxl-clientが閾値を下回ったことが分かります。
これは良いですね。通知も分かりやすいです。
fsx-clientでのstressコマンド実行
再度fsxl-clientでstressコマンドを叩いてCPUに負荷をかけます。
すると、またコントリビューターCPUUtilization 2 - fsxl-clientがアラーム状態となりました。
このタイミングで通知も来ました。
psql-clientでのstressコマンド実行
次にpsql-clientでstressコマンドを叩いてCPUに負荷をかけます。
続いて、コントリビューターCPUUtilization 1 - psql-clientがアラーム状態となりました。
通知も正常に来ています。
ということで、確かに個別のコントリビューターごとに独立してアラート/OKのアクションを実行できることを確認しました。最高ですね。
CloudWatch Metrics Insightsアラームを使ったからといって、個別にメトリクスを指定する従来のCloudWatchアラームと料金は変わりません。どちらもメトリクス数に対して課金が発生します。
- メトリクスアラームでは、アラームのメトリクス式に記載した各メトリクスに対して料金が発生します (Metric Math を使用して最大 10 メトリクス)。
- Metrics Insights のクエリアラームでは、クエリで分析された各メトリクスに対して料金が発生します。
- 他のデータソースからのクエリアラームでは、クエリによって返される各メトリクスに対して料金が発生します。
- Metrics Insights のクエリと追加メトリクスの両方を組み合わせたアラームでは、クエリで分析した各メトリクスと、アラームのメトリクス式に記載されている他のすべてのメトリクスについて料金が発生します。
Standard Resolution Metrics Alarm Cost Cost for metrics listed directly(/alarm/month) $0.10 per alarm metric Cost for Metrics Insights queries(/alarms/month) $0.10 per metrics analyzed
個人的には「とりあえずCloudWatch Metrics Insightsアラームを使う」形にシフトしても良いのではないかと思うぐらいです。
タグの変更
ふと、途中でタグが変わった場合に上手く追従できるのか気になりました。
psql-clientをかつてpsql-clientだったものに変更します。
変更して10分ほど経過しましたが、特にクエリ結果には反映されませんでした。
既存のアラームのコントリビューターラベルも変わりありません。
CloudWatchアラームのコントリビューターラベルに使われているのが原因なのでしょうか?
test5というタグの値をtest5からtest5ですに変更します。
これでGROUP BYにtag.test5を付与してクエリを実行しましたが、ラベルにtest5と付与されてしまっていますね。
AWS公式ドキュメントにはタグの検出に最大3時間かかることがあると記載がありますが、タグを変更してから既に4時間経過しています。
Missing tags after enabling telemetry enrichment
After you enable the feature, CloudWatch begins enriching telemetry with tags. CloudWatch can take up to 3 hours to discover all your tags for enrichment.
途中でのタグの値の変更はサポートされていないのかもしれません。これは注意した方が良さそうですね。
ちなみに、テレメトリでリソースタグを有効にする前のメトリクスはラベルがOtherと表現されていました。
env : prodのタグを付与されたEC2インスタンスを追加
続いて、env : prodのタグを付与されたEC2インスタンスを追加します。
> aws ec2 describe-tags --filters "Name=resource-type,Values=instance" --query 'Tags[*].[ResourceId,Key,Value]' --output table
-----------------------------------------------------------------
| DescribeTags |
+----------------------+--------+-------------------------------+
| i-0083cc67a3f0f1899 | Name | かつてpsql-clientだったもの |
| i-0083cc67a3f0f1899 | env | dev |
| i-0083cc67a3f0f1899 | test | test |
| i-0083cc67a3f0f1899 | test2 | test2 |
| i-0083cc67a3f0f1899 | test3 | test3 |
| i-0083cc67a3f0f1899 | test4 | test4 |
| i-0083cc67a3f0f1899 | test5 | test5です |
| i-0083cc67a3f0f1899 | test6 | test6 |
| i-08786fe45910556cc | Name | al2023 |
| i-08786fe45910556cc | env | prod |
| i-0e3b2df10bad6f2ac | Name | fsxl-client |
| i-0e3b2df10bad6f2ac | env | dev |
+----------------------+--------+-------------------------------+
この状態でCloudWatch Metrics InsightsのWHERE句でtag.env = 'dev'を指定します。
SELECT MAX(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) WHERE tag.env = 'dev' GROUP BY tag.Name, tag.env
はい、先ほど追加したEC2インスタンスはクエリ結果に含まれていませんね。
それではWHEREにtag.env = 'prod'に変更します。
SELECT MAX(CPUUtilization) FROM SCHEMA("AWS/EC2", InstanceId) WHERE tag.env = 'dev' GROUP BY tag.Name, tag.env
すると、先ほど追加したEC2インスタンスがクエリ結果に表示され、env : devのEC2インスタンスは表示されなくなりました。
これで、タグを用いたフィルタリングもできることが分かりました。
ただし、WHEREの指定を外すと急に1つのメトリクスしか表示されなくなりました。
GROUP BYにInstanceIdを指定するとようやく表示されました。ただし、envタグの値が表示されていません。
新しいサービスなので挙動はまだ不安定なのでしょうか。
リソースの追加や変更に自動的に適応する動的なCloudWatchアラームを設定したい時に
Amazon CloudWatchがリソースのタグを用いてメトリクスモニタリングができるようになったアップデートを紹介しました。
特に今まで同一のメトリクス名、同一の閾値、同一のアクションであっても大量にCloudWatchアラームを設定することに頭を悩まされていた方は非常に嬉しいアップデートではないでしょうか。
- タグを用いて簡単かつ柔軟にアラーム対象のメトリクスを指定することが可能
- コスト的なデメリットは特にない
と、個人的に最高のアップデートです。
リソースの追加や変更に自動的に適応する動的なCloudWatchアラームを設定可能になったので積極的に使っていきましょう。
先日のアップデートCloudWatch Metrics Insightsのクエリ期間が2週間に拡張されたので、少し前の状況と照らし合わせながら確認するといったことも行いやすいでしょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
