Backend de app mobile na AWS: quando trocar API Gateway por AppSync, Cognito e Lambda

AWS AppSync combina GraphQL, autorização via Cognito e lógica em Lambda num único endpoint, mas decidir trocar o API Gateway tradicional por ele exige entender onde cada peça entra e o que muda no custo.

Nota da redação: a descrição do funcionamento da WebSocket API tradicional do API Gateway (uso de connectionId no DynamoDB, handlers $connect/$disconnect, tratamento de GoneException) não pôde ser confirmada em documentação oficial da AWS entre as fontes consultadas para este artigo, que tratam do AppSync. O leitor deve verificar esse comportamento na documentação do API Gateway antes de usar essa comparação como base de decisão técnica.

AWS AppSync combina GraphQL, autorização via Cognito e lógica em Lambda num único endpoint, mas decidir trocar o API Gateway tradicional por ele exige entender onde cada peça entra e o que muda no custo.

Por que repensar o backend do app mobile

Quem desenha o backend de um app mobile na AWS costuma montar API Gateway na frente, um Lambda por rota atrás e Cognito como provedor de autenticação. A documentação do AWS AppSync descreve uma rota alternativa: um único endpoint que fala GraphQL, já integrado com Cognito e com espaço para lógica em Lambda quando ela faz falta. A pergunta que importa não é qual serviço é melhor, mas em que momento trocar a stack tradicional compensa.

Um endpoint no lugar de uma rota por tela

A proposta central do AppSync, segundo a própria documentação, é acessar dados de uma ou várias fontes a partir de um único endpoint GraphQL, e até combinar múltiplas APIs GraphQL numa API mesclada (merged API). Para quem já construiu backend de app mobile no API Gateway, isso resolve um problema conhecido: a tela inicial de um app típico precisa de perfil, feed e contador de notificações, três formatos de dado diferentes.

Com API Gateway, isso normalmente vira três rotas (/profile, /feed, /notifications), três integrações Lambda e três round trips no 4G do usuário, ou um Lambda agregador escrito à mão para juntar tudo numa chamada só. Com GraphQL, o cliente mobile manda uma única query pedindo exatamente os campos das três telas, e o AppSync resolve cada campo contra a fonte certa por trás. O ganho não é teórico: é menos chamada de rede num app que roda em conexão instável.

Cognito entra pronto, sem authorizer escrito à mão

A documentação lista controle de autorização embutido, com suporte a chave de API, IAM, Amazon Cognito, provedores OpenID Connect e autorização via Lambda para lógica customizada. Na prática, isso significa escolher o modo de autorização no console do AppSync e apontar para o user pool do Cognito, sem escrever o código que valida token JWT a cada requisição, algo que no API Gateway também existe via Cognito authorizer, mas que no AppSync já nasce acoplado à própria API.

Para regra de negócio que o grupo do Cognito não cobre (liberar um campo só para assinante do plano pago, por exemplo), a mesma documentação aponta o authorizer via Lambda como saída. A lógica de autorização fica centralizada num só lugar da API, em vez de duplicada em cada função Lambda atrás de cada rota REST.

Lambda não desaparece, só muda de função

O AppSync oferece suporte a JavaScript e TypeScript para escrever a lógica de negócio dos resolvers, o que cobre buscas simples direto numa tabela do DynamoDB. Mas quando o resolver precisa chamar uma API de pagamento, disparar um processo assíncrono ou rodar regra mais complexa, o Lambda continua sendo a peça usada como data source atrás do resolver.

Nesse ponto a rotina muda pouco: a função ainda tem limite de concorrência e tempo de execução próprios para monitorar, igual já acontecia atrás do API Gateway. O que muda é o ponto de entrada: em vez de ser acionado direto por uma rota do API Gateway, o Lambda é acionado pelo resolver do AppSync como mais uma fonte de dados entre outras.

Dados em tempo real sem gerenciar conexão WebSocket

Desde 13 de março de 2025 o AppSync Events oferece uma API de PubSub em tempo real sobre WebSockets, segundo a documentação. É a parte que mais interessa a quem já tentou construir chat, notificação ao vivo ou placar em tempo real num app mobile usando WebSocket API do API Gateway: nesse modelo tradicional, é preciso guardar o connectionId numa tabela do DynamoDB, escrever handler para $connect e $disconnect em Lambda, e tratar GoneException quando o app tenta mandar mensagem para uma conexão que já caiu.

A própria documentação do AppSync remete a um guia específico, "Publish events via WebSocket", para o detalhamento de como funciona a publicação e entrega de eventos nesse modelo de pub/sub. Vale a pena consultar esse guia antes de desenhar a arquitetura de tempo real, porque o comportamento de entrega para clientes desconectados (se há ou não alguma forma de reentrega) muda a decisão de usar ou não o AppSync Events como única fonte de verdade para dados que não podem se perder, como histórico de chat.

O preço é por milhão de chamada, não por hora de servidor

Segundo a documentação, o AppSync cobra por milhões de requisições e atualizações, com a cache como um custo adicional à parte. Duas exceções valem registrar: chamada que falha por erro de autorização ou autenticação não é cobrada, e chamada que depende de chave de API não é cobrada quando a chave está ausente ou inválida.

A diferença de unidade de cobrança em relação ao API Gateway é o detalhe que costuma pegar quem migra sem calcular: uma query GraphQL que resolve cinco campos vindos de cinco fontes diferentes conta como uma requisição para o AppSync, mas pode disparar cinco invocações de Lambda por trás, cada uma com seu próprio custo de execução. O gasto não desaparece, só se reorganiza entre as camadas.

Quando não vale trocar o API Gateway por AppSync

App mobile pequeno, com três ou quatro telas que batem numa única tabela do DynamoDB, raramente ganha com a troca: o time passa a precisar desenhar schema GraphQL e mapear resolver para um problema que REST simples já resolvia. A economia de round trip que justifica o GraphQL aparece quando as telas combinam formatos de dado bem diferentes, não quando o app é uma lista de CRUD.

Recursos de API Privada com integração a AWS WAF, também citados na documentação como parte do AppSync, fazem sentido para backend que atende cliente corporativo com exigência de isolamento de rede. Para o app de consumo comum, esse controle extra é complexidade operacional sem contrapartida. A decisão, no fim, depende de quantas fontes de dado diferentes uma mesma tela do app precisa juntar, não de qual serviço parece mais moderno.

Fonte: Documentação do AWS AppSync