A AWS compartilhou recentemente a experiência da ProGlove, que conseguiu escalar sua plataforma SaaS para operar mais de um milhão de funções AWS Lambda distribuídas em milhares de contas de clientes. O segredo? Um modelo de tenancy radical (uma conta por cliente), automação extrema com CloudFormation StackSets e uma disciplina de custos que mantém o gasto ocioso abaixo de US$ 1 por mês por conta.
- Isolar cada cliente em sua própria conta AWS melhora segurança e custo, mas exige automação pesada.
- CloudFormation StackSets + Step Functions permitem gerenciar milhares de contas a partir de um único pipeline.
- Disparos simultâneos de funções podem causar um “DDoS autoinfligido”; resolva com janelas aleatórias (jitter).
- Custos de observabilidade explodem na escala; consolide logs e filas para manter ocioso abaixo de US$ 1/mês.
O modelo de isolamento radical: uma conta por cliente
A ProGlove optou por isolar cada cliente em uma conta AWS separada. Essa decisão arquitetural trouxe três benefícios principais: fronteiras de segurança mais rígidas, cotas de serviço independentes e atribuição clara de custo por cliente. Cada conta hospeda um punhado de microsserviços — tipicamente de 5 a 15 funções Lambda — orquestrados por uma máquina de estado do Step Functions.
O fluxo de trabalho ingere leituras de scanners, persiste os dados no Amazon DynamoDB e emite eventos de negócio para um barramento central do Amazon EventBridge, consumido pelo plano analítico da ProGlove. A escolha trouxe previsibilidade, mas também introduziu atrito operacional quando a base ultrapassou 50 contas.
Automação para gerenciar milhares de contas
O provisionamento manual tornou-se inviável. A equipe combinou AWS Organizations, Step Functions e CloudFormation StackSets em um fluxo de trabalho que cria e atualiza cada conta a partir de um único pipeline de CI/CD. A colaboração com engenheiros de serviço da AWS depois aumentou a taxa de transferência do StackSet, permitindo propagar mudanças entre milhares de contas que, juntas, hospedam mais de um milhão de funções Lambda.
StackSets como motor da escala
Os StackSets permitem implantar templates do CloudFormation em múltiplas contas e regiões de forma centralizada. A ProGlove usou essa capacidade para garantir consistência, reduzir erros manuais e acelerar deploys. A limitação original de taxa foi superada com ajustes internos da AWS, viabilizando o modelo para milhares de contas.
Desafios de escala: quando a automação vira ameaça
Nem tudo foi simples. As primeiras políticas de acionamento baseadas em cron fizeram com que a mesma função disparasse simultaneamente em todas as contas, gerando um “DDoS autoinfligido”. A correção veio com janelas de execução aleatórias (jitter) e triggers orientados a eventos, que suavizaram a carga regional sem necessidade de concorrência reservada.
Custos de observabilidade sob controle
Cada função Lambda emitia logs e métricas; multiplicado por milhares de contas, o volume ameaçava dominar a fatura. A ProGlove consolidou falhas de alta prioridade em uma fila central de dead-letter e removeu filas SQS ociosas. Com isso, o gasto ocioso por conta caiu para menos de US$ 1 por mês.
Lições que ecoam no mercado
O caso da ProGlove não é isolado. A Capital One padronizou práticas de deploy, observabilidade e governança para operar cargas Lambda em grande escala, reforçando que padronização operacional é pré-requisito para escala técnica. Já a DoorDash migrou para serverless com disciplina de automação, mantendo mais de 10 milhões de chamadas diárias de API sem estourar limites de concorrência.
A experiência da ProGlove sugere um padrão: comece com um modelo de tenancy que imponha limites rígidos, automatize cada ação de infraestrutura desde o início e trate o gasto de observabilidade como uma restrição de escala de primeira classe. A visibilidade de custo e cota direciona as escolhas arquiteturais muito antes dos gargalos aparecerem.
| Desafio | Solução adotada |
|---|---|
| Provisionamento manual de contas | StackSets + Step Functions + Organizations |
| Disparo simultâneo de funções (auto-DDoS) | Janelas de execução aleatórias (jitter) |
| Explosão de custos de observabilidade | DLQ central, remoção de filas ociosas |
| Limitação de taxa do StackSet | Ajuste de throughput em parceria com a AWS |
Arraste para o lado para ver toda a tabela.
Perguntas Frequentes (FAQ)
Por que a ProGlove escolheu uma conta por cliente?
Para obter isolamento de segurança, cotas independentes e atribuição clara de custos. Cada cliente opera em seu próprio perímetro, evitando interferências e simplificando a cobrança.
Como gerenciar milhares de contas AWS sem enlouquecer?
Automação total com StackSets, Organizations e Step Functions. Um pipeline único cria e atualiza todas as contas, garantindo consistência e reduzindo a carga operacional.
O que é “auto-DDoS” e como evitar?
É quando cron jobs idênticos disparam funções simultâneas em muitas contas, sobrecarregando o sistema. A solução é introduzir aleatoriedade (jitter) nos horários de execução.
Como manter o custo baixo com tantas funções Lambda?
Com políticas agressivas de scale-to-zero e consolidação de observabilidade. A ProGlove reduziu o custo ocioso para menos de US$ 1 por mês por conta, eliminando componentes desnecessários e centralizando falhas.
Essa arquitetura serve para qualquer empresa?
É recomendada para cenários que exigem isolamento forte entre tenants, como SaaS B2B com requisitos de segurança elevados. A troca é maior complexidade operacional, que deve ser compensada com automação madura.