VeUP
← All case studies
AWS Lambda · Lambda streaming ingest
Feroot logo

Hardening a ~3-billion-events/month client-side threat-detection pipeline on AWS

AdvisoryTarget-state architecture design & costed POCCost-optimization deep diveStreaming ingest & data-lake designMarketplace listing launchManaged billing & resell
3 billion
browser-side telemetry events a month, at peak scale
Costed plan
every reliability and cost driver paired with a fix
AWS LambdaAmazon API GatewayAmazon KinesisAmazon OpenSearch

The compute plane of Feroot’s threat-detection pipeline is AWS Lambda end to end: an API Gateway-fronted ingest function landing browser events onto Amazon Kinesis, and ~15–20 consumer functions processing the streams into Amazon OpenSearch aggregates — at up to ~3 billion events a month. VeUP mapped that Lambda-primary architecture end to end, identified Lambda as the pipeline’s largest cost driver, and scoped the patterns that bend cost per event down without giving up freshness.

The challenge

Serverless compute made the platform possible — no fleet to size for half-billion-event customer spikes — but at this volume its economics become the architecture’s central question. VeUP’s cost mapping put Lambda (both the write path onto the streams and the read path consuming them) at the top of the pipeline’s spend, with the surrounding failure modes compounding it: hot Kinesis shards concentrating invocations, OpenSearch write-amplification multiplying downstream work, and entitlement rejections arriving only after the functions had already run. The platform needed its serverless spine kept — and made efficient.

The solution

VeUP mapped the full production path — Amazon API Gateway → Lambda ingest → Kinesis Data Streams (raw + enriched) → ~15–20 Lambda consumers → OpenSearch hourly aggregates, with Firehose → S3 replay — and scoped a plan that attacks Lambda cost at its causes rather than its symptoms. Upstream, edge throttling and entitlement enforcement at API Gateway stop invocations for traffic the platform will reject; de-skewed Kinesis partition keys spread consumer invocations evenly so concurrency tracks real load, not shard luck. Within the functions, the plan scopes batch-size and concurrency tuning on the stream consumers and an append-only write pattern into OpenSearch that eliminates the update-churn each consumer was paying for. Per-ARN FinOps instrumentation ties every function’s spend to its throughput, making cost per ingested event a tracked KPI — with the success criteria holding sub-60–90-second freshness and near-zero drops at peak while the cost curve bends.

Production outcomes

KPIResult
Serverless compute planeA fully Lambda-primary pipeline — one ingest function plus ~15–20 stream consumers — sustaining up to ~3 billion events/month with no servers in the data path.
Cost transparencyLambda identified and quantified as the dominant cost driver, with per-ARN spend telemetry scoped so every function’s cost-per-event is measured, trended, and owned.
Efficiency leversInvocation-avoidance at the edge, de-skewed shard distribution, consumer batch tuning, and removal of OpenSearch update-churn — each mapped to a measured reliability or cost driver in the modernization plan.
Lessons & continuationAt streaming scale, the cheapest Lambda invocation is the one that never happens — push rejection upstream of compute; and tune consumers against de-skewed streams first, because no batch-size setting can fix a hot shard.
AWS services in production
AWS Lambda (ingest + stream consumers)Amazon API GatewayAmazon Kinesis Data StreamsAmazon Kinesis Data FirehoseAmazon S3Amazon OpenSearch ServiceAmazon CloudWatch