Toda API pública precisa de uma portaria: alguém que confere credenciais, segura os apressadinhos, direciona cada visitante e anota quem entrou. Dá para construir isso dentro da aplicação, e é assim que nascem os backends inchados de responsabilidades transversais. O API Gateway da AWS tira essa portaria do seu código e a transforma em serviço gerenciado (aws.amazon.com/api-gateway).

O que a portaria faz por você

• Roteamento: /pedidos para a Lambda, /catalogo para o container no ECS, /legado para a VPC. Uma fachada, vários fundos, e a liberdade de trocar o fundo sem mudar o contrato.
• Autenticação na porta: JWT do Cognito validado antes de tocar seu código, authorizers customizados em Lambda para regras próprias, IAM para chamadas internas. A requisição inválida morre na portaria, sem custar processamento seu.
• Throttling e cotas: limites por cliente (usage plans + API keys) e proteção geral contra rajadas: o rate limiting como configuração, não como código.
• Observabilidade de borda: logs estruturados de acesso, métricas por rota e tracing desde o primeiro milissegundo.
• Cache e validação: respostas cacheadas na borda e schemas rejeitando payload malformado antes do backend.

A escolha dentro da escolha: HTTP API vs REST API

O serviço tem duas gerações, e a escolha errada custa dinheiro:

• HTTP API (a segunda geração): ~70% mais barata, mais rápida, JWT nativo, CORS simples. Cobre a grande maioria dos casos modernos. Comece por ela.
• REST API (a original): mais cara, e com os recursos que só ela tem: API keys/usage plans, cache gerenciado, validação de request, transformações de payload, endpoints privados. Se você precisa cobrar por plano de uso ou validar schema na borda, é ela.

A regra prática: HTTP API por padrão; REST API quando um recurso específico justificar. (E para streaming/tempo real, existe a variação WebSocket.)

E quando o gateway NÃO é a resposta

Honestidade de arquitetura: se sua API é um serviço em containers com tráfego alto e constante, um Application Load Balancer faz o roteamento básico por uma fração do custo por requisição. O API Gateway se paga quando você usa a portaria de verdade: auth na borda, throttling por cliente, múltiplos backends, serverless. Colocá-lo na frente de tudo "por padrão" é gasto sem função.

A conta muda de novo em volume extremo: o preço por milhão de requisições parece pequeno até os bilhões chegarem. Faça a conta do platô, como sempre.

Os tropeços clássicos

1. Timeout de 29 segundos: o gateway não espera mais que isso (30s no HTTP API). Operação longa atrás dele precisa virar assíncrona: responde 202, processa na fila, notifica depois.
2. Lógica de negócio na portaria: transformações VTL complexas e authorizers fazendo trabalho de aplicação viram um backend escondido, impossível de testar direito. Portaria autentica e roteia; negócio é do serviço.
3. Configuração no console: rotas e authorizers clicados são o ClickOps de sempre. Gateway se declara como código (o próximo artigo da série cobre o CloudFormation).
4. Sem stages e sem canary: o gateway suporta ambientes e deploy canário nativamente; ignorar isso é jogar fora a rede de segurança que já está paga.
5. CORS na tentativa e erro: o clássico. Declare no gateway (é uma linha no HTTP API) e pare de sofrer.

O desenho que recomendamos

Para a maioria dos produtos na AWS: HTTP API na frente, JWT validado na borda, throttling geral configurado, rotas para Lambda (eventos e colas) e ECS (núcleo da API), tudo em código com stages por ambiente. A portaria fazendo o trabalho de portaria, e o seu código fazendo só o que é dele.

Montar essa borda (com os authorizers e limites certos para o seu modelo de clientes) é parte do nosso serviço de Cloud e Infraestrutura.

Sua aplicação ainda valida token e conta requisições por dentro? Descreva a API para a IA da Rabelo Digital, aqui no canto da tela, e ela desenha a portaria equivalente. Sem formulário, sem espera.

---

Leia também

• CloudFormation: a AWS declarada em código
• Amplify: do front à nuvem em minutos (e os limites disso)
• Lambda: serverless sem sustos