AWS Lambda Support
Reducing AWS Lambda CloudWatch logging costs.
For many serverless accounts, CloudWatch Logs ingestion costs more than the Lambda compute itself. Chatty debug logs, full request bodies and logs that never expire pile up. We find the biggest sources and cut them without making incidents harder to debug.
When You Need This
The situations where this work pays for itself.
Signs it is time
- CloudWatch Logs appears among your top cost lines in Cost Explorer
- Functions log entire events, payloads or stack traces on every call
- Log groups have no retention and years of old data
- High-volume functions log a line per record or per request
- You need metrics from logs but not every raw line
What you get
- A ranked list of log groups by ingestion cost
- Retention and log level settings in infrastructure as code
- Code changes that reduce log volume while keeping context
- A cost comparison from Cost Explorer after the change
How we do it
A clear, safe process you can follow along with.
1. Find which log groups cost money
We use Cost Explorer with usage type filters and the IncomingBytes metric per log group to rank log groups by ingestion, so work starts with the few groups that matter.
2. Set retention everywhere
Lambda creates log groups with no expiry. We set a retention period per environment based on your needs, and apply it by infrastructure as code so new functions cannot skip it.
3. Use structured logging and log levels
Lambda advanced logging controls support JSON logs and a system and application log level per function. We set production to INFO or WARN and keep DEBUG a switch you can turn on temporarily.
4. Remove noisy log lines
We remove full event dumps, per-record logging inside loops and repeated stack traces, and replace them with one summary line per invocation with identifiers.
5. Sample what must stay verbose
For very high-volume paths we log a sample of successes and all failures, and use embedded metric format or custom metrics for counts instead of log lines.
6. Choose the log class and archive path
For logs rarely queried we can use the Infrequent Access log class, and export or subscribe to S3 for long-term needs. Check current feature limits, as some features are not available in that class.
7. Verify savings and debuggability
We compare IncomingBytes before and after, and run a failure drill to confirm the trace ID, request ID and error context are still in the logs.
Mistakes we help you avoid
Common ways this goes wrong, and what we do instead.
Turning logging off
You will regret it during the next incident. Reduce volume and keep errors and identifiers.
Fixing retention only
Retention cuts storage but not ingestion, which is usually the larger part. Both need work.
Logging sensitive data
Full payloads can contain personal data or tokens. Trimming them also reduces compliance risk.
Leaving DEBUG on after an incident
A temporary debug level becomes a permanent cost. We make it an easy toggle with an alarm or reminder.
Frequently Asked Questions
Why is my CloudWatch Logs bill so high for Lambda?
Almost always ingestion from verbose logging, often from a few high-traffic functions. The IncomingBytes metric per log group shows exactly where.
What is the default log retention for Lambda?
Log groups created by Lambda keep logs indefinitely unless you set a retention period, so storage grows without limit.
Can Lambda send logs somewhere cheaper?
Lambda can write to a log group of your choice, and you can use subscription filters or exports for archives. The right target depends on how you query them.
Want Help With Reducing AWS Lambda CloudWatch logging costs?
Schedule an appointment. Tell us about your environment and we will outline the safest, highest-value approach.
Schedule Appointment › No commitment required