Collection method by cloud provider
| Cloud | Method | Log types |
|---|---|---|
| AWS | Lambda agent | S3-based: ALB, CloudFront, CloudTrail |
| AWS | Firehose | CloudWatch-based: app logs, RDS, VPC Flow |
| Azure | Functions | Event Hub logs |
| Azure | Alloy | Blob storage, Log Analytics |
| GCP | Alloy + Pub/Sub | All GCP logs |
AWS recommendation by log type
| Log type | Method |
|---|---|
| ALB access logs | Lambda agent |
| CloudFront logs | Lambda agent |
| CloudTrail audit logs | Lambda agent |
| CloudWatch Logs | Firehose |
| RDS instance logs | Firehose |
| VPC Flow Logs | Firehose |
Script
Here’s a summary of your log collection options.
For AWS, you have two methods that cover different log types. The Lambda agent handles S3-based logs: ALB access logs, CloudFront logs, CloudTrail audit logs. Firehose handles CloudWatch-based logs: your application logs, RDS logs, VPC Flow Logs. The key is knowing where your logs live. S3-based logs use Lambda, CloudWatch-based logs use Firehose.
For Azure, Functions with Event Hub work great for serverless shops. Alloy gives you more power if you need Log Analytics queries or blob storage access.
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.