AWS has outlined how ProGlove, an industrial-wearables manufacturer, was able to scale its SaaS platform to run more than one million AWS Lambda functions spread across thousands of dedicated customer accounts.
In an AWS Architecture Blog post, the team credits its one-account-per-tenant model, extensive automation with CloudFormation StackSets, and aggressive scale-to-zero policies for keeping idle costs below one US dollar per month per account.
ProGlove chose to isolate each customer in its own AWS account, trading additional operational overhead for stronger security boundaries, independent service quotas, and clear per-customer cost attribution.
AWS states that the decision introduced operational friction once the platform surpassed 50 accounts.
Inside each customer account was a handful of microservices, typically five to fifteen Lambda functions coordinated by a Step Functions state machine that ingested scanner readings, persisted them in Amazon DynamoDB, and emitted business events to a shared Amazon EventBridge bus consumed by ProGlove’s analytics plane.
Manual provisioning had slowed releases and exposed service-quota ceilings, so the engineers combined AWS Organizations, Step Functions, and CloudFormation StackSets into a workflow that creates and updates every account from a single pipeline. The team said collaboration with AWS service engineers later increased StackSet throughput so the mechanism could fan changes across thousands of accounts that together host more than one million Lambda functions.
Source: AWS
AWS reports that Quotas were not the only scaling challenge. Early cron-style schedules triggered the same function in every account at identical times, producing what the engineers describe as a self-inflicted DDoS.
They replaced the rigid timers with jittered execution windows and event-driven triggers, smoothing regional load without resorting to reserved concurrency or provisioned capacity.
Observability costs followed a similar trajectory. Each Lambda function emitted logs and metrics; multiplied across thousands of accounts, the resulting volume threatened to dominate the bill. ProGlove consolidated high-priority failures into a central dead-letter queue and removed unused Amazon SQS queues. According to the blog, these changes reduced per-account idle spend to under one US dollar.
Similar operational concerns have emerged elsewhere. Capital One has described standardising deployment, observability and governance practices as necessary to operate Lambda workloads consistently across large organisations, arguing that technical scale also requires operational standardisation.
The AWS post also notes that automation brought its own compromises. StackSet rollouts remained slower than single-account CloudFormation deployments, and centralising logs reduced some per-tenant granularity. The team considered those compromises acceptable given the improvements in isolation, cost visibility and operational consistency.
ProGlove’s experience suggests a pattern: start with a tenancy model that enforces hard boundaries, automate every infrastructure action early, and treat observability spend as a first-class scaling constraint. DoorDash’s serverless migration notes similar themes, highlighting that disciplined automation kept more than ten million daily API calls from overrunning concurrency limits. While the tactics differ, the common thread is that cost and quota visibility drive architectural choices long before capacity crunches appear.