TargetGroupのUnHealthyHostCountをCloudWatchアラームで監視する場合、AZの概念の含まれないメトリクスを選んだほうが良い

リファレンスの以下部分の、

UnHealthyHostCount
異常と見なされるターゲットの数。

レポート条件: ヘルスチェックが有効になっている場合にレポートされます

統計値: 最も有用な統計値は Average、Minimum、および Maximum です。

[Dimensions] (ディメンション):

TargetGroup, LoadBalancer

TargetGroup, AvailabilityZone, LoadBalancer

ここ。

TargetGroup, LoadBalancer

TargetGroup, AvailabilityZone, LoadBalancer

下の方のAZを含むメトリクスだと、メトリクスで指定していないAZでターゲットが起動したときに、データが取れなくなる。
上の方のメトリクスを使えば、AZは気にしなくなるので、ターゲットがどのAZで起動していようと、データが取れなくなることはない。

CloudWatchアラームで、複合アラームを使わない場合、メトリクスとして指定できるのは1つなので、AZが含まれるメトリクスを指定してしまうと、対象でないAZでターゲットが起動したときにデータが取れない。

ECSでタスク1だと、タスクが起動するたびにAZが変わるので、タスク再起動時にデータが取れない状態になりうる。

CloudWatchで上記の下の方、AZを含まないメトリクスを指定する場合は以下をたどる

AWS名前空間
AWS/ApplicationELB
↓
メトリクス
AppELB 別、TG 別メトリクス
※ここでAZと表記があるものを避ける
↓
AppELB 別、TG 別メトリクス
↓
対象のALB/TargetGropの、UnHealthyHostCountを選択

そもそもECSの監視手法としてTargetGroupのUnHealthyHostCountを利用するのが適切か、検証が必要そう
同様に、起動中のタスク数、のチェックも有効なのかどうか。
Route53ヘルスチェックとかCloudWatch Synthetics使えばいいんだけどNW要件とかシステム的に無理とかだと工夫が必要