Arquitetura serverless AWS para integrações: quando vale, o que montar e o que vigiar

A documentação da AWS ensina a criar uma função Lambda em dez minutos. O que ela não diz é se a sua integração deveria estar numa Lambda — ou se você está prestes a montar a arquitetura errada com ferramentas certas.

Este post é o conteúdo de decisão que falta entre o tutorial e o whitepaper: quando serverless ganha de servidor tradicional em cargas de integração, quais componentes montar, como eles se encaixam num fluxo real de webhook e onde os projetos sangram dinheiro. Você sai daqui com o trade-off explícito, não com mais um passo a passo.

Integração é carga intermitente por natureza: pico de webhook na promoção de sexta, job de sincronização às 3h da manhã, rajada de pedidos às 11h e silêncio depois. Servidor tradicional cobra as 24 horas do dia; serverless cobra o uso.

A regra operacional cabe em uma linha: quanto mais intermitente e orientado a eventos, mais serverless ganha; quanto mais contínuo, mais container ganha. Empresas médias costumam ter os dois padrões convivendo — e a resposta certa é híbrida, não ideológica.

Uma arquitetura serverless AWS para integrações gira em torno de poucos serviços, cada um com um papel que não se negocia:

• API Gateway + Lambda — a porta de entrada. O API Gateway recebe o HTTP do webhook; a Lambda valida assinatura, checa idempotência, enfileira e responde 200 rápido. Ela não processa nada pesado: responder primeiro e processar depois é o contrato.
• SQS com DLQ — o amortecedor. A fila desacopla recepção de processamento. Se o ERP cair por dez minutos, o evento espera na fila em vez de se perder. A dead-letter queue recebe o que falha de forma repetida — mensagem venenosa com endereço para investigar, reproduzir e corrigir.
• SNS — o fan-out. Quando o mesmo evento ("pedido criado") precisa alimentar estoque, fiscal e notificação, você publica uma vez e cada assinante consume a sua fila. Sem isso, vira três integrações penduradas no mesmo webhook.
• EventBridge — o relógio e o roteador. Agendamentos (cron) e roteamento de eventos por regra. Rotinas noturnas, warmers e limpezas moram aqui.
• S3 — a zona de aterrissagem. Payload grande, arquivo de catálogo, log de integração: vai para o S3, e a fila carrega só a referência.
• Secrets Manager — o cofre. Token OAuth do marketplace, chave de API do ERP. Segredo em variável de ambiente versionada em repositório é incidente com data marcada.
• CloudFront — a borda. Terminação pública e cache do que pode ser servido longe da origem.

No abstrato, todo mundo concorda com o desenho. O valor está na ordem das operações:

Três decisões carregam o design:

1. Validar a assinatura antes de qualquer coisa. Webhook sem validação de assinatura é endpoint público aceitando ordens de quem quiser.
2. Responder 200 antes de processar. O parceiro quer confirmação de recebimento, não o resultado da sua integração. O processamento pesado roda no worker, não no caminho da resposta.
3. Deduplicar o evento na entrada. Toda plataforma de webhook reenvia. Se você não checa o ID do evento antes de enfileirar, o reenvio vira processamento duplo lá na frente.

Esse é o mesmo esqueleto que sustenta integrações de marketplace, pagamentos e agentes de IA — a variação está nas pontas, não no meio. O post sobre integração com o marketplace do Mercado Livre mostra esse fluxo aplicado a estoque multicanal.

Sem número de vendedor aqui — a fatura depende do seu volume. O que interessa é o modelo: você paga por invocação, por tempo de execução e por tráfego de saída. Em carga intermitente, o custo acompanha a atividade: semana parada custa quase nada, semana de pico paga o pico.

Os três vetores que encarecem serverless sem ninguém perceber:

• Retry sem DLQ — mensagem quebrada reprocessada para sempre é dinheiro saindo todo mês disfarçado de "pico de uso".
• Processamento longo síncrono — Lambda rodando minutos esperando um ERP lento; o certo é enfileirar e processar assíncrono.
• Chamada de modelo sem idempotência — o item mais caro da lista, abaixo.

E a pergunta "quanto custa rodar agente de IA na AWS?" tem uma resposta honesta: a orquestração (API Gateway, filas, agendamentos) tende a ser detalhe na fatura — o custo real mora nas chamadas de LLM, cobradas por token. A arquitetura certa existe justamente para não chamar modelo duas vezes para o mesmo evento: cache, deduplicação e fila bem usadas são economia direta. O raciocínio completo de custos está em quanto custa implementar um agente de IA.

Retentativa de webhook é comportamento padrão, não exceção. Sem idempotência por ID de evento, o reenvio do parceiro vira baixa dupla de estoque ou cobrança repetida. Deduplicação é regra de negócio, não otimização técnica — aprofundamos em idempotency for webhooks (EN).

Fila não conserta worker lento; só muda o lugar da espera. Sem monitorar backlog e escalar o consumidor, você trocou "erro visível" por "atraso invisível" — escrevemos sobre isso em queues are not a silver bullet (EN).

A integração chama o ERP, o ERP demora, a função estoura o limite de execução, o evento volta para a fila, tenta de novo, chama o ERP de novo. O antídoto é sempre o mesmo: reconhecer rápido, processar assíncrono e definir política de retentativa consciente em vez de aceitar o padrão da plataforma.

A primeira invocação paga o preço do boot. Para webhook e job agendado, irrelevante. Para API síncrona sensível a latência, pesa. Mitigações existem (concorrência provisionada, aquecimento), mas quando a carga é constante o caminho certo costuma ser mover aquele trecho para container — ECS Fargate escala por métrica e não tem esse problema.

Não é arquitetura de slide. Operamos infraestrutura AWS em produção com Terraform e Pulumi versionados: ECS Fargate, Lambda e Lambda@Edge, API Gateway, SQS/SNS com DLQ, EventBridge, S3, Secrets Manager, CloudFront, DocumentDB, VPC e Route53.

Dois detalhes mostram a filosofia:

• Plataforma orientada a eventos com SDK tipado. Schemas YAML descrevem os eventos; o SDK gera a publicação em SNS automaticamente. O time declara o evento, e a infraestrutura de eventos se monta sozinha. Isso mata a classe de bug "publicou no tópico errado" — e é o mesmo princípio que defendemos em event-driven systems without folklore (EN).
• Cache warmer agendado. EventBridge dispara Lambda em horário programado para aquecer o cache de vídeos HLS antes do pico. Carga intermitente mais agendamento: o caso de uso de livro didático do serverless.

E a parte que ninguém vende: testes de integração e IaC versionado. Serverless sem pipeline é nuvem desorganizada — você trocou um servidor por dez serviços que ninguém sabe como foram provisionados.

A pergunta "quando terceirizar infraestrutura AWS" tem resposta de adulto, em três cenários:

• Faça interno se você já tem cultura de IaC, plantão e mais de um ou dois projetos de integração por trimestre — o contexto acumula e vira ativo do time.
• Contrate se o time é pequeno e as integrações são muitas: o custo de manter dez serviços AWS na cabeça de uma pessoa supera o custo do projeto pronto.
• Meio-termo (nosso favorito): o estúdio monta a fundação — padrões de webhook, filas com DLQ, IaC, testes de integração — e o time interno assume a operação com documentação viva. É assim que estruturamos projetos de automação de workflows e software sob medida.

Para AWS em empresas médias, a decisão raramente é "serverless ou não" — é "qual parte da carga em serverless, qual parte em container, e quem segura o padrão". A distribuição errada custa caro nos dois sentidos: fatura e confiabilidade.