ProGlove escala para 1 milhão de Lambdas com isolamento por conta AWS

A AWS detalhou como a ProGlove, fabricante alemã de wearables industriais, alcançou a marca de mais de 1 milhão de funções AWS Lambda distribuídas por milhares de contas AWS dedicadas — uma por cliente. O caso, publicado no AWS Architecture Blog, revela como decisões arquiteturais radicais de isolamento, combinadas com automação pesada e gestão agressiva de custos de observabilidade, permitiram escalar uma plataforma SaaS B2B sem estourar orçamento nem quotas de serviço.

Contexto: por que isolar cada cliente em uma conta AWS dedicada

A ProGlove adotou o modelo one-account-per-tenant (uma conta por inquilino) desde o início. A troca: sobrecarga operacional inicial por fronteiras de segurança rígidas, quotas de serviço independentes e atribuição de custos transparente por cliente.

Benefícios tangíveis do isolamento rígido

• Segurança: falha ou comprometimento em uma conta não vaza dados de outros tenants.
• Quotas independentes: limites de concorrência Lambda, DynamoDB ou EventBridge não são compartilhados.
• FinOps nativo: a fatura AWS de cada conta reflete exatamente o consumo daquele cliente.
• Conformidade: facilita aderência a LGPD, GDPR e contratos enterprise que exigem segregação física/lógica.

O modelo funcionou bem até ~50 contas. A partir daí, provisionamento manual travou releases e estourou quotas de serviço (limites de StackSets, Organizations, CloudFormation). A resposta foi automação de ponta a ponta.

Arquitetura técnica: Step Functions, EventBridge e DynamoDB por conta

Dentro de cada conta de cliente, a ProGlove roda 5 a 15 funções Lambda orquestradas por AWS Step Functions. O fluxo padrão:

1. Leitores de scanner enviam dados via API Gateway / IoT Core.
2. Step Functions coordena ingestão, validação, enriquecimento e persistência.
3. Dados brutos e processados vão para Amazon DynamoDB (tabelas por tenant).
4. Eventos de negócio são emitidos para um Amazon EventBridge bus compartilhado (cross-account) consumido pelo plano de analytics central da ProGlove.

Código de exemplo: definição de estado Step Functions (resumido)

{
  "Comment": "Pipeline de ingestão ProGlove per-tenant",
  "StartAt": "ValidarLeitura",
  "States": {
    "ValidarLeitura": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:ValidateReading",
      "Next": "PersistirDynamoDB"
    },
    "PersistirDynamoDB": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:region:account-id:function:PersistToDynamoDB",
      "Next": "EmitirEventoNegocio"
    },
    "EmitirEventoNegocio": {
      "Type": "Task",
      "Resource": "arn:aws:events:region:account-id:rule/AnalyticsBusPutEvents",
      "End": true
    }
  }
}

Esse padrão garante que a lógica de negócio rode isolada, enquanto o barramento de eventos centralizado permite analytics agregado sem quebrar o isolamento de dados.

Automação em escala: Organizations + StackSets + Step Functions

Para eliminar provisionamento manual, a equipe construiu um pipeline único que cria e atualiza todas as contas:

• AWS Organizations: gestão hierárquica de contas, SCPs (Service Control Policies) e billing consolidado.
• CloudFormation StackSets: implantação de stacks idênticas (IAM, Lambda, Step Functions, DynamoDB, EventBridge rules) em milhares de contas alvo.
• Step Functions (nível master): orquestra o fluxo de onboarding — cria conta, aguarda prontidão, dispara StackSet, valida saúde, registra no catálogo interno.

Gargalo de throughput do StackSets e a colaboração com AWS

StackSets padrão não sustentava a taxa de deploy necessária para milhares de contas. A ProGlove trabalhou diretamente com engenheiros de serviço da AWS para aumentar o throughput do StackSets (otimizações internas de concorrência, throttling e retries). Resultado: o mecanismo passou a "ventilar" mudanças por milhares de contas que juntas hospedam o milhão de Lambdas.

Compromisso aceito: rollouts via StackSets permanecem mais lentos que deploy CloudFormation em conta única. A equipe considerou o trade-off aceitável dado o ganho em isolamento, visibilidade de custo e consistência operacional.

Gargalos operacionais: quotas, "thundering herd" e custos de observabilidade

Auto-DDoS via cron jobs sincronizados

Agendadores cron disparavam a mesma função em todas as contas no mesmo segundo, gerando picos de concorrência que pareciam ataque DDoS autoinfligido. A solução não usou Reserved Concurrency nem Provisioned Concurrency (custo alto). Em vez disso:

• Jittered execution windows: janelas de execução aleatórias (ex: 0-15 min) por conta.
• Triggers event-driven: migração de agendamento fixo para eventos S3, SQS ou EventBridge nativos.

Resultado: carga regional suavizada sem capacidade provisionada ociosa.

Explosão de logs e métricas: a conta da observabilidade

Cada Lambda emite logs (CloudWatch Logs) e métricas (CloudWatch Metrics). Multiplicado por milhares de contas e 1 milhão de funções, o volume ameaçou dominar a fatura. Medidas adotadas:

Arraste para o lado para ver toda a tabela.

Segundo o blog da AWS, essas mudanças reduziram o custo ocioso por conta para menos de US$ 1/mês.

Lições do mercado: Capital One, DoorDash e o padrão de automação disciplinada

A experiência da ProGlove não é isolada. Dois casos públicos reforçam o mesmo padrão:

Arraste para o lado para ver toda a tabela.