One thing that happens quietly in a lot of AWS environments is metric growth.
At first, enabling more CloudWatch metrics feels like the right decision. More visibility usually sounds better than less visibility.
But over time, many teams end up collecting far more monitoring data than they actually use operationally.
Some metrics never get checked.
Some never trigger alerts.
Some exist only because they were enabled years ago and nobody revisited them.
The result is usually:
<ul>
<li>higher CloudWatch costs</li>
<li>noisier dashboards</li>
<li>harder-to-manage monitoring environments</li>
</ul>
What makes this difficult is that the growth happens gradually, so the operational overhead often goes unnoticed for a long time.
I came across a solid breakdown recently covering ways to reduce unnecessary CloudWatch metrics without losing important visibility:
<a href="https://www.kubeblogs.com/cloudwatch-metrics-optimization/" target="_blank" rel="noopener nofollow">https://www.kubeblogs.com/cloudwatch-metrics-optimization/</a>

DevOps Daily

Many AWS teams accumulate far more CloudWatch metrics than they actually use, leading to higher costs, noisier dashboards, and harder-to-manage monitoring setups. The growth happens gradually, making it easy to overlook. The post highlights the problem and points to a resource covering ways to reduce unnecessary CloudWatch metrics without sacrificing important visibility.

Most Teams Collect More CloudWatch Metrics Than They Actually Need