Collection method by cloud provider
| Cloud | Method | Best for |
|---|---|---|
| AWS | Firehose | Most CloudWatch logs (recommended, ~3x cheaper) |
| AWS | Lambda agent | Specific types: ALB, CloudFront, CloudTrail |
| Azure | Functions | Event-driven from Event Hub |
| Azure | Alloy | Event Hub with flexible processing |
| GCP | Alloy + Pub/Sub | All GCP logs |
AWS recommendation by use case
| Scenario | Method | Why |
|---|---|---|
| High log volumes, cost-sensitive | Firehose | ~3x cheaper, better scalability |
| CloudWatch Logs, RDS, VPC Flow | Firehose | Native integration, managed |
| ALB access logs | Lambda agent | Firehose doesn’t support yet |
| CloudFront logs | Lambda agent | Firehose doesn’t support yet |
| CloudTrail audit logs | Lambda agent | Firehose doesn’t support yet |
Script
Here’s a summary of your log collection options.
For AWS, Firehose is the recommended method for most CloudWatch logs. It’s about three times cheaper than Lambda and handles high volumes with better scalability. Use it for your application logs, RDS logs, and VPC Flow Logs.
Lambda handles specific log types that Firehose doesn’t support yet: ALB access logs, CloudFront logs, and CloudTrail audit logs.
For Azure, Functions with Event Hub work great for serverless shops. Alloy gives you more power if you need flexible processing from Event Hub.
For GCP, there’s really one path: Alloy subscribing to Pub/Sub. No serverless shortcut here.
And if you’re running multi-cloud, AWS plus Azure plus GCP, Alloy becomes incredibly valuable. One collector, one configuration language, consistent processing across all your clouds.