Why this matters
Logging and monitoring bills on AWS grow from many small choices: a debug line left on, a log group with no retention, a custom metric for every user ID, a dashboard nobody opens. CloudWatch Logs charges for ingest and storage. Custom metrics and alarms add their own charges, and traces add another stream. None of those choices looks large on its own. Together they turn observability into a monthly line item that finance asks about.
The usual failure is not a single bad setting. It is missing ownership. A team enables VPC Flow Logs, CloudTrail, Container Insights, and application logs in several accounts. Six months later no one knows which log group feeds which dashboard. Costs keep rising because ingest rises with traffic, not because anyone decided to collect more.
The goal is to keep signal, not to starve the team. Security and audit trails stay. Error logs and service level metrics stay. Debug logs, health checks, duplicate streams, and unused custom metrics go. Every change should have an owner and a review date.
Before you start
List the AWS accounts and regions in scope. Pull a recent bill from Billing and Cost Management and filter Cost Explorer by CloudWatch, CloudTrail, X-Ray, and any third-party monitoring service. Group by usage type if the chart allows it, so ingest and storage do not blur together.
Inventory log sources before you change retention. Check CloudWatch log groups, CloudTrail trails, VPC Flow Logs, AWS Config recorders, X-Ray sampling, and agent configuration on EC2 and containers. For each source, note the owner, the retention setting, and whether anyone queries it.
Agree on retention classes with security and engineering. Audit and security logs need a longer life than application debug logs. That does not mean keeping everything in CloudWatch Logs. S3 with lifecycle rules is cheaper for long-term archive and still searchable with the right tools.
Decide who can change retention, filters, and sampling. A short written rule prevents one team from shortening an audit log to fix a budget spike. Include security in the review.
How to do it
Work from the source outward. First set retention on existing log groups. Then stop noisy events before they reach CloudWatch. Then clean up metrics, alarms, dashboards, and traces. Automate a monthly review so the settings do not drift.
Keep a short exception list. Security logs, audit trails, and logs tied to an active incident stay as they are until the incident closes. For everything else, set a retention period and an ingest filter, then measure the effect over one billing cycle.
Use tags and account structure to your advantage. Tag log groups and resources by team, environment, and cost center where AWS supports it. If you run many accounts, use AWS Organizations and central logging accounts to see the whole picture, but do not centralize every debug stream.
Do not chase every line item at once. Pick the top few log groups by ingest, the custom metrics nobody reads, and the alarms that never fire. Fix those, verify the signal still works, then repeat.
- Map every log source. List CloudWatch log groups, CloudTrail trails, VPC Flow Logs, AWS Config, X-Ray, and agent configurations by account and region. Record the owner, retention, and daily ingest for each source. Flag sources with no owner or no query history for review.
- Set retention on every log group. In the CloudWatch console, open Log groups, select a group, choose Actions, then Edit retention setting. Match the period to the use: short for debug and access logs, longer for audit and security logs. For long-term audit data, export to S3 with a lifecycle policy and remove the CloudWatch copy.
- Cut noise at the source. Change production log levels from debug to info and keep debug behind a temporary switch. Drop health checks, readiness probes, and routine successful responses before they reach CloudWatch. Use CloudWatch agent include and exclude filters or application-side sampling to keep only useful events.
- Filter before you store. Use CloudWatch Logs subscription filters to send only selected events to Lambda, Kinesis Data Firehose, or OpenSearch. Create metric filters for error counts and latency instead of storing every line for later search. Keep the raw log group retention short when the downstream system is the real archive.
- Audit custom metrics and dimensions. Run ListMetrics or check the CloudWatch console for custom namespaces and find metrics no alarm or dashboard uses. Remove high cardinality dimensions such as user ID, request ID, or full URL from metric names. Put those details in logs instead, where you can sample and expire them.
- Tune alarms and dashboards. Delete duplicate alarms, alarms that never fire, and alarms that only feed a dashboard nobody opens. Use composite alarms to group related signals and reduce noise. Review dashboard widgets against the questions the team actually asks during incidents.
- Sample traces and slim agents. Set X-Ray sampling rules so high volume paths do not trace every request. Configure the CloudWatch agent to collect named log files and needed metrics, not whole directories. Remove agents and integrations for services you no longer run.
- Automate the guardrails. Use AWS Config rules to flag log groups without retention and AWS Budgets to alert on monitoring spend. Add a monthly review to the team calendar and check the top ingest sources. Tag new log groups and alarms at creation so the next review is easier.
How to check it worked
Open Cost Explorer after a full billing cycle and filter by CloudWatch, CloudTrail, X-Ray, and any third-party tool. Compare ingest and storage separately. A drop in storage with flat ingest means retention changed. A drop in ingest means filters or log levels worked.
In CloudWatch, check each log group for a retention value and compare stored bytes before and after. Use CloudWatch Logs Insights to confirm the events you still need are present. Search for a known error and a known audit event, not just any event.
Review the custom metrics list, alarm list, and dashboard list. The count should reflect what the team uses, not what was created during a launch. Ask one on-call engineer whether the remaining alarms still point to a runbook.
Watch the next bill for a shift to another service. If you send more logs to S3 or a third-party tool, the CloudWatch line may fall while another line rises. Check the whole observability spend, not one service in isolation.
Mistakes to avoid
Turning off CloudTrail, VPC Flow Logs, or security logs to save money is a bad trade. Scope those sources instead: pick the trails, VPCs, and event types you need. Keep the audit path intact and expire the noisy application logs first.
Setting retention and stopping there misses the larger charge. Ingest usually dominates before retention does. Lower log levels, drop health checks, and filter at the agent or subscription before you shorten retention on useful data.
High cardinality custom metrics are a quiet trap. A metric dimension for every user or request creates a series per value, and each series can carry a charge. Keep dimensions low cardinality and put unique identifiers in logs.
Sending the same logs to CloudWatch, S3, and a third-party tool without a reason adds work and spend. Pick a primary store for search and a separate archive for retention. If the bill is still unclear and you want an outside read, Cloudverg's Cloud cost audit, $4,500/month, is one option among others: a two-week read-only review that ranks savings. Check the fit before you book.
Frequently asked questions
How do I reduce CloudWatch Logs costs?
Start with a retention setting on every log group, then cut ingest at the source. Lower production log levels, drop health checks, and use subscription filters to send only useful events downstream. Move audit archives to S3 with lifecycle rules.
Does deleting logs from CloudWatch lower the bill?
Deleting stored events lowers storage charges for those events, but it does not undo ingest charges already billed. It can also remove evidence you need. Set retention and export what matters instead of deleting log groups in a rush.
Should I turn off VPC Flow Logs to save money?
Not blindly. Flow logs are often needed for security and network troubleshooting. Scope them to selected VPCs, subnets, or network interfaces, choose the right aggregation level, and send them to S3 with lifecycle rules if you do not query them daily.