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>

A community for DevOps, Kubernetes, Docker, Terraform, AWS, Linux, CI/CD, and Platform Engineering. Share tutorials, blogs, tools, and real-world experiences to learn and grow together.

KubeBlogs

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 points to a resource covering strategies to reduce unnecessary CloudWatch metrics while preserving meaningful visibility.

Most Teams Collect More CloudWatch Metrics Than They Actually Need