Custom metrics published to CloudWatch can be configured at two resolutions: standard (60-second intervals) or high resolution (1-second intervals). While both resolutions are priced identically for metric storage, the critical cost difference lies in the volume of API calls required to publish the data. A metric published every second generates 60 times more API calls than one published every 60 seconds. At scale — across hundreds or thousands of custom metrics in a microservices architecture — this multiplier translates into substantial and avoidable API charges that accumulate month over month.
This inefficiency commonly arises when teams default to high-resolution publishing without evaluating whether sub-minute granularity is actually needed for their monitoring use cases. Many workloads — including capacity planning, cost analysis, and non-critical service monitoring — function perfectly well with standard or even lower resolution. Compounding the issue, high-resolution metric data is only retained at its full 1-second granularity for three hours before being automatically aggregated to coarser intervals. Teams may therefore be paying a premium in API costs for resolution they cannot even query historically. Additionally, if alarms are configured to evaluate high-resolution metrics at sub-minute intervals, those alarms carry a higher per-alarm charge compared to standard-resolution alarms.
VPC Flow Logs configured with the ALL filter and delivered to CloudWatch Logs often result in unnecessarily high log ingestion volumes — especially in high-traffic environments. This setup is rarely required for day-to-day monitoring or security use cases but is commonly enabled by default or for temporary debugging and then left in place. As a result, teams incur excessive CloudWatch charges without realizing the logging configuration is misaligned with actual needs.
By default, CloudWatch Log Groups use the Standard log class, which applies higher rates for both ingestion and storage. AWS also offers an Infrequent Access (IA) log class designed for logs that are rarely queried — such as audit trails, debugging output, or compliance records. Many teams assume storage is the dominant cost driver in CloudWatch, but in high-volume environments, ingestion costs can account for the majority of spend. When logs that are infrequently accessed are ingested into the Standard class, it leads to unnecessary costs without impacting observability. The IA log class offers significantly reduced rates for ingestion and storage, making it a better fit for logs used primarily for post-incident review, compliance retention, or ad hoc forensic analysis.
Engineers often enable verbose logging (e.g., debug or trace-level) during development or troubleshooting, then forget to disable it after deployment. This results in elevated log ingestion rates — and therefore costs — even when the detailed logs are no longer needed. Because CloudWatch Logs charges per GB ingested, persistent debug logging in production environments can create silent but material cost increases, particularly for high-throughput services.In environments with multiple teams or loosely governed log group policies, this issue can go undetected for long periods. Identifying and deactivating unnecessary debug-level logging is a low-risk, high-leverage optimization.
CloudWatch log groups often persist long after their usefulness has expired. In some cases, they are associated with applications or resources that are no longer active. In other cases, the systems may still be running, but the log data is no longer being reviewed, analyzed, or used by any team. Regardless of the reason, retaining logs that no one is monitoring or using results in unnecessary storage costs. If log data is not needed for operational visibility, debugging, compliance, or auditing purposes, it should either be deleted or managed with a shorter retention policy.
