Explanation
Why the waste happens and who it affects.
This setup is rarely required for day-to-day monitoring or security use cases but is commonly created with the ALL filter by templates or landing zone baselines, 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.
Billing model
The pricing dimensions that drive this cost.
CloudWatch Logs is billed based on:
Ingestion volume (per GB) - flow logs are billed as vended logs, at volume-tiered per-GB rates that depend on the destination (CloudWatch Logs, Amazon S3, or Amazon Data Firehose)
Storage (per GB per month) - ongoing charges for retained logs
How to detect
5 checks to find it in your estate.
- Identify VPC Flow Logs with a destination of CloudWatch Logs
- Check whether the log filter is set to ALL
- Review total ingestion volumes and associated CloudWatch Logs charges over time
- Evaluate whether full traffic logging is necessary or if ACCEPT or REJECT would suffice
- Confirm whether logs are used for active monitoring or compliance, or are remnants of prior debugging
How to fix
4 ways to remove the waste.
- Delete and recreate the flow log with an ACCEPT or REJECT filter (or a reduced custom record format) where appropriate, since a flow log's configuration cannot be changed after it is created
- Consider redirecting logs to S3 for lower-cost storage if detailed analysis is not required in CloudWatch
- Implement periodic audits of logging configurations to catch overly verbose setups
- Align logging retention and granularity with actual monitoring and compliance needs
Documentation
Vendor references for pricing and configuration.