The Scale You Don't See in Demos

When you first build a serverless system, you think in single digits. A handful of Lambda functions, maybe a few dozen at most. But what happens when your platform operates thousands of AWS accounts and deploys over one million Lambda functions into production, each isolated to a single customer?

ProGlove, the company behind smart wearable barcode scanning solutions, faced exactly this challenge. Their AWS-based SaaS platform, Insight, started with the standard serverless playbook—SQS for decoupling, EventBridge for events, DynamoDB for storage. But as they grew from 1 to 1,000+ accounts, they discovered that many "best practices" break at scale.

This is their story, distilled into lessons you can apply before you hit the pain.

Phase 1: The Simple Origins (0 → 1,000 Functions)

In the beginning, everything worked beautifully. Each microservice followed a consistent structure: 5–15 Lambda functions coordinated by Step Functions, with EventBridge routing and DynamoDB as the primary store. AWS CloudFormation StackSets felt like a superpower—one deployment operation updates many accounts simultaneously.

But the first trap was hidden in plain sight: idle costs. Even with serverless, "idle" doesn't mean zero cost. Lambda functions consuming events from EventBridge through an SQS queue constantly poll the queue, even when no messages exist. At single-digit scale, this is negligible. At 1,000 accounts, it becomes a line item you can't ignore.

Key insight: Scale-to-zero isn't just a nice-to-have. It's a financial necessity.

Phase 2: The First 50 Accounts – Real Problems Emerge

Growing to 50 tenant accounts forced three deliberate architectural decisions:

1. Automated Account Factory

Manual provisioning doesn't scale. ProGlove built an automated account factory on top of AWS Organizations: a Step Functions workflow in the management account handles the full lifecycle—creating the account, applying SCPs, bootstrapping IAM roles, and triggering initial StackSet deployments. New tenant accounts go from request to ready in under 15 minutes at near-zero incremental cost.

2. The Quota Isolation Superpower

One underappreciated advantage of the account-per-tenant model is quota separation. Each account gets its own Lambda concurrent execution limit, API Gateway throttle, and service quotas. In a shared-account model, a single noisy tenant could exhaust shared concurrency and cause cascading failures. With account isolation, that class of problem simply doesn't exist.

3. Observability Costs Hit Hard

At $3 per account per month for forwarding CloudWatch logs to a third-party observability platform, the cost felt insignificant. But at thousands of accounts, that $3/account/month becomes an impactful expense. ProGlove learned to treat per-account observability costs with the same scrutiny as compute costs. By differentiating high- and low-priority data, they brought observability costs down to ~$0.70 per account, and near-zero for inactive accounts.

Phase 3: The Self-DDoS Problem

When hundreds of backend service instances simultaneously access other services, the resulting request volume can resemble a coordinated attack. ProGlove experienced this firsthand: a massive metric spike where their own functions overwhelmed internal APIs.

Root cause: Synchronized schedules. Every Lambda used the same 5-minute rate expression, aligned to the top of the minute across thousands of accounts.

Solution: Request scattering—a standardized internal library enforcing jitter, randomized batch offsets, and staggered updates across all scheduled functions.

Rule of Thumb: Never do the same thing at the same time everywhere.

Phase 4: Rethinking Architectural Patterns for Scale-to-Zero

The most painful lesson: traditional SQS "best practices" increased costs at scale. The fix was radical:

  • Remove SQS from the EventBridge → Lambda path. Instead of polling queues, use metric-driven safety—monitor AsyncEventsDropped and ConcurrentExecutions to stay within quotas without losing events.
  • Centralize the DLQ. Polling individual Dead Letter Queues in every account reintroduced the same cost issues. Routing failures to a single centralized DLQ eliminated polling costs, though it required extreme discipline to maintain data isolation (using AWS account ID as tenant ID).

Phase 5: Industrializing the Deployment Engine

At 1 million Lambda functions, CloudFormation StackSets hit a performance ceiling. ProGlove began building their own internal deployment system—until the AWS CloudFormation service team stepped in. By engaging early and often, they influenced the roadmap and prioritized StackSet stability improvements.

They also built a deployment tracking service that aggregates StackSet events through EventBridge, with a central Step Functions state machine acting as a "single-pane-of-glass" for failures and retries.

Phase 6: Mature Governance and FinOps

The Mono-Repo Strategy

ProGlove consolidated 20 microservices into a single mono-repo. This enabled:

  • Consistent tooling and security scanning across 1M+ functions
  • Coordinated runtime and library upgrades through a single source of truth
  • Guaranteed compatibility through the CI/CD chain

The "Almost-Zero" Reality

Even with a scale-to-zero mandate, "zero" is often "almost-zero." Monitoring introduces costs—CloudWatch Alarms, external observability tools. But by aggressively optimizing, they reduced idle cost for inactive accounts to less than $1 per month.

Think Beyond the Obvious Services

Before writing a Lambda function, ask whether a native AWS service integration already solves the problem. Services like EventBridge Pipes, AppSync, and SQS FIFO can remove entire categories of custom code. Serverless Land is an excellent starting point for discovering patterns you may not have considered.

Limitations and Caveats

  • Account-per-tenant model isn't suitable for every scenario. It increases management overhead and requires robust automation. If your tenant count is under 20, the complexity may not be worth it.
  • Centralized DLQ introduces a potential data isolation breach. You must treat AWS account IDs as tenant IDs and enforce strict access controls.
  • Third-party observability costs can spiral. Always negotiate per-account pricing or consider self-hosted alternatives for high-volume scenarios.

Next Steps for Your Learning

  1. Audit your current serverless architecture for idle polling costs. Can you remove SQS from EventBridge → Lambda paths?
  2. Implement jitter and request scattering in any scheduled Lambda functions.
  3. Explore native AWS integrations before writing custom code. Check Serverless Land for patterns.
  4. Consider a mono-repo if you manage multiple microservices—consistency at scale is a force multiplier.

For a deeper look into how data platforms are evolving alongside serverless, see our piece on Microsoft's 2026 Database Vision. And if you're curious about how AI-driven recommendation systems handle intent at scale, read How Airbnb Built a Destination Recommendation Model That Actually Understands Your Travel Intent.

This article is based on the original post on the AWS Architecture Blog.

AWS Lambda serverless architecture diagram scaling to 1 million functions across thousands of accounts Technical Structure Concept

Cloud cost optimization dashboard showing observability spend per account in multi-tenant SaaS platform IT Technology Image

Developer workstation with AWS console open showing CloudFormation StackSets deployment automation Software Concept Art

This content was drafted using AI tools based on reliable sources, and has been reviewed by our editorial team before publication. It is not intended to replace professional advice.