Scaling to 1 million Lambda functions (AWS / ProGlove)

An AWS Architecture Blog case study (Ben Freiberg, AWS SA; Julius Blank, SRE; 2026-06-29) on how ProGlove scaled a multi-tenant SaaS to 1 million Lambda functions across thousands of AWS accounts. It is the spoke’s first serverless-ops-at-scale source — a different compute substrate from the Kubernetes-heavy corpus, but it lands on the same “seams, not components” lesson: at scale the hard problems are isolation, scheduling, cost, and deployment across a fleet, not any single function. T3: AWS-published vendor case study (promotes Lambda), but the operational lessons are concrete and not Lambda-specific.

The architecture

• One AWS account per tenant — each customer gets dedicated Lambda, Step Functions, EventBridge, and DynamoDB, for security isolation and transparent per-tenant cost.
• Microservices of 5–15 Lambda functions coordinated by Step Functions.
• Deployment via CloudFormation StackSets for parallel infra updates across accounts.

The operational lessons

• Quota isolation = blast-radius control. Account separation gives each tenant independent Lambda concurrency limits and API Gateway throttles, so a “noisy tenant” can’t cascade into others — the multi-account form of the reliability isolation the spoke’s seams thesis prizes.
• The self-DDoS discovery (the jitter lesson). Hundreds of scheduled functions sharing an identical rate(5 minutes) expression fired in lockstep, creating internal spikes that looked like a DDoS. Fix: add jitter / randomized batch offsets — “never do the same thing at the same time everywhere.” A clean SRE gem (and the same anti-synchronization rule a good cron scheduler follows — reflexively, the discipline this hub’s own scheduled jobs use by offsetting their minute).
• Cost as a first-class operational constraint. At a million functions, idle costs dominate: they removed SQS polling, replaced per-account dead-letter queues with a centralized DLQ, and cut observability cost from $3 → $0.70 per account by tiering data by priority. A cost dimension the spoke’s reliability/observability pillars hadn’t yet foregrounded.
• Deployment hits ceilings before capacity does. StackSets couldn’t keep up at 1M functions, so they built custom deployment tracking on EventBridge + Step Functions (and the AWS partnership fed the StackSets roadmap) — the declarative-deploy pillar stressed at serverless-fleet scale.
• Monorepo governance. Consolidating 20 microservices into one repository enforced consistent tooling, security scanning, and coordinated runtime upgrades across all functions — the golden-path move applied to a serverless fleet (and the ops face of dev-tooling-wiki’s monorepo trade-off).

The takeaway

“Scaling from 0 to 1M Lambda functions across thousands of AWS accounts is a question of efficiency, not capacity.” The platform gives unlimited functions; the engineering is in isolation, scheduling, cost, and deployment discipline across the fleet.

Related

serverless · site-reliability-engineering · service-level-objectives · internal-developer-platform · gitops · platform-ops · kubernetes