If you’re running AWS Lambda, you probably assume you only pay for the logs your own code explicitly writes. But what if I told you that every single Lambda invocation generates a report log in CloudWatch, even if your function’s code is completely silent?
And yes, you are being charged for every single one.
Take a look at your CloudWatch logs for any Lambda function. You’ll see these three lines for every execution:
START RequestId: ...END RequestId: ...REPORT RequestId: ... Duration: X ms Billed Duration: Y ms Memory Size: Z MB Max Memory Used: W MB
These REPORT logs are system-level, INFO logs generated by the Lambda service itself. While they’re useful for debugging or optimizing your function’s memory, most of the time—especially in high-traffic production environments—they just become expensive noise.
Doesn’t sound like much? Let’s do the math.
The $4/Month Cost You Didn’t Know You Had
Let’s break down the cost for a single, moderately busy function.
These START, END, and REPORT logs total about 262 bytes of data.
- Log Size: 262 bytes per invocation
- Traffic: 1,000,000 executions per day
- CloudWatch Ingestion Price: $0.50 per GB (us-east-1)
Here’s the calculation(Amazon CloudWatch Pricing):
- Daily Log Ingestion: 262 bytes/execution × 1,000,000 executions/day = 262,000,000 bytes = ~262 MB per day
- Monthly Log Ingestion: 262 MB/day × 30.5 days/month = 7,991 MB = ~8 GB per month
- Monthly Cost: 8 GB/month × $0.50/GB = **$4.00 per month**
That’s $4 per month for a single function, just for logs you probably aren’t even using.
Now, scale that. What if you have 50 functions like this? That’s $200/month. What if your function handles 10 million executions per day? That’s $40/month for that one function.
This is a classic “death by a thousand cuts” cloud cost. If you aren’t actively using these logs to optimize memory, you are paying for data you don’t need.
The Solution: Suppress the System Logs
The fix is surprisingly simple. You just need to tell Lambda to stop sending you INFO-level system logs. You can do this by setting the system log level to WARN or ERROR.
This change will suppress the START, END, and REPORT logs entirely, while still allowing your own application’s logs (e.g., console.log or print()) to come through.
The Catch: This feature only works if your Lambda function’s log format is set to JSON. If you’re still using the default plain Text format, this setting will be ignored.
How to Implement the Fix
You can make this change in the AWS CDK, AWS CLI, CloudFormation, or any other IaC tool. more examples
For AWS CDK (TypeScript)
When defining your function, set the loggingConfig property.
import * as lambda from 'aws-cdk-lib/aws-lambda';
new lambda.Function(this, 'MyFunction', {
// ... other properties
runtime: lambda.Runtime.NODEJS_20_X,
handler: 'index.handler',
code: lambda.Code.fromAsset('lambda'),
// --- THIS IS THE FIX ---
loggingConfig: {
logFormat: lambda.LogFormat.JSON,
systemLogLevelV2: lambda.SystemLogLevel.WARN,
},
// --- END FIX ---
});For AWS CLI
You can update an existing function directly from your terminal.
aws lambda update-function-configuration \
--function-name MyFunction \
--logging-config '{"LogFormat": "JSON", "ApplicationLogLevel": "INFO", "SystemLogLevel": "WARN"}'(Note: ApplicationLogLevel controls your code’s log level, while SystemLogLevel controls the Lambda service’s logs. We only want to suppress the system logs.)
Here’s a high-quality blog post based on the topic you provided.
A Simple Change for Real Savings
This is one of the easiest cost-saving changes you can make. By adding two lines of configuration, you can eliminate a constant, unnecessary data stream and reduce your CloudWatch bill every month.
Take a few minutes, check your high-traffic functions, and stop paying for log noise you don’t use.