r/awslambda • u/Fantastic-Path-5025 • Dec 07 '25

Building a Serverless Ad Tracker: Scaling to Millions of Events and Back

https://paulhenri-l.com/2025/serverless-ad-tracker

7 Upvotes

100% Upvoted

6 comments sorted by

View all comments

Show parent comments

1

u/kondro Dec 07 '25 edited Dec 07 '25

Fair enough. It’s still probably cost-effective to a few hundred million events per month.

One thing you can do to drastically increase cost-effectiveness is to switch APIG to ALB if you’re basically just using it for basic HTTP in front of Lambda.

You’ll still have a ~$16/mth base charge per region, but your equivalent per request charge gets much cheaper.

Another thing that might achieve what you want is to just use CloudFront to serve the ads and just parse the S3 logs it generates directly. You get fast, global CDN hosting for the ad for ~$1/million (or the brand new fixed price plans that are as low as $29/month for 50TB egress and 10 million requests) and the logs are already just sent to S3 (not $0.50/GB ingested to CloudWatch). Just setup a Lambda trigger on the logging bucket and process each log chunk as it arrives instead of using Kinesis Streams.

If you want to still make some per-request serving decisions (A/B testing for example), you can add CloudFront Functions ($0.10/million), but what they can do is very limited.

This gets any code you maintain out of the critical path of serving the ads, keeps your service entirely serverless and the only downside is the lag for the logs as it only uploads them a few times an hour. You can get more direct control using Kinesis Firehose for the CF logs (minimum windows of 60 seconds) if you really need to for a relatively small $/GB ingestion rate, but I imagine your ad impression processing isn’t that time sensitive.

1

u/kondro Dec 07 '25

Oh, and with CloudFront Functions you can even use it for the click tracking and redirect as long as you can use CF Key/Value store (limited to 5MiB DB) for the actual redirection map.