AWS detalhou como a ProGlove, fabricante de wearables industriais, escalou sua plataforma SaaS para mais de um milhão de funções Lambda, usando isolamento por conta, CloudFormation StackSets e políticas agressivas de scale-to-zero. O custo ocioso ficou abaixo de US$ 1 por mês por conta.
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.
Leia também · há 2 meses
Proxy cache Envoy e Valkey atinge 1,5M RPS no DoorDash
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.
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.
Quem escreveu
Dagmar Cirino · Editor-chefe
Especialista em tecnologia, criador de conteúdo e fundador do portal Mercado de TI e Casa do Dev. Analiso tendências de mercado, Inteligência Artificial e carreira, entregando informações precisas, transparentes e acessí...
