Lessons Learned Scaling to 1 Million Lambda Functions
How ProGlove scaled its serverless SaaS platform from thousands to over a million AWS Lambda functions, and the quota, cost and architecture lessons learned.
ProGlove built its Insight platform, which connects smart barcode scanners to digital workflows, as a fully serverless SaaS with a dedicated AWS account per tenant. This account-per-tenant model gave clear security boundaries and cost transparency early on, but scaling to thousands of accounts and over a million Lambda functions surfaced problems invisible at small scale. CloudFormation StackSets for bulk deployment and a Step Functions-based account factory became core to handling growth.
As the fleet grew, synchronized schedules across hundreds of accounts (all using the same rate(5 minutes) expression) caused a self-inflicted DDoS on internal APIs; the fix was introducing jitter and staggered offsets so scheduled work spreads out over time. Observability costs followed a similar pattern: a few dollars per account seemed negligible until thousands of accounts turned it into a major line item, with log/metric forwarding—not compute—as the real cost driver, prompting the team to prioritize which data got shipped centrally.
Perhaps the sharpest lesson was that 'idle' still costs money: routing EventBridge events to Lambda through SQS meant constant queue polling charges even for inactive tenants. Removing SQS from that path, monitoring AsyncEventsDropped and ConcurrentExecutions instead, and consolidating failures into a centralized DLQ enabled true scale-to-zero economics—at the cost of extra discipline to preserve tenant isolation.