How it works
Complexity: Simple | Infrastructure: Serverless | Latency: Event-driven
Specific log types collected with Lambda
| Log type | Format | Key insights |
|---|---|---|
| ALB Access Logs | Space-delimited | Request latency, targets, status codes |
| CloudFront Logs | Tab-separated | Edge locations, cache hits |
| S3 Access Logs | Space-delimited | Bucket access patterns |
| CloudTrail | JSON | API activity, audit |
Trade-offs
| Pros | Cons |
|---|---|
| Event-driven, automatic | Higher cost for high volumes |
| Serverless (no infrastructure) | Format parsing required |
| Custom transformation possible | ~3x more expensive than Firehose |
Documentation
View the full documentation. Learning path coming soon!
Script
The Lambda agent, also known as lambda-promtail, handles specific log types that Firehose doesn’t support yet.
Several AWS services write logs that need Lambda collection. ALB access logs give you HTTP request details: latency, status codes, which backend handled the request.
CloudFront logs show CDN performance: edge locations, cache hit rates.
CloudTrail logs every AWS API call: who did what, when, and from where.
Here’s how it works: you deploy a Lambda function that triggers on events. When these logs are available, Lambda processes them, parsing the format and adding labels, and then forwards them to Loki in Grafana Cloud.
The beauty is serverless simplicity. No EC2 instances to patch, no containers to manage.
Lambda scales automatically with your log volume. You can customize the processing logic to fit your needs.
Trade-offs? Lambda has execution costs. For high log volumes, Firehose is about three times cheaper. And you’ll need to configure parsing for each log format since ALB logs are space-delimited, CloudFront is tab-separated, and CloudTrail is JSON.