Escolher a porta de entrada das APIs de uma empresa deixou de ser um detalhe de infraestrutura. Em 2026, com ataques a APIs a crescerem a par da adoção de microserviços, o gateway escolhido decide quanto se paga, quanto se aguenta em tráfego e quão exposta fica a organização a uma configuração mal feita. Este artigo compara três das opções mais usadas por equipas de engenharia e segurança: Kong Gateway, AWS API Gateway e Google Apigee. Analisamos preços reais a diferentes volumes de tráfego, resultados de desempenho publicados em testes independentes, funcionalidades de segurança e cenários de uso concretos para ajudar equipas portuguesas a escolher com dados, não com intuição.
Nenhum destes três produtos é novo, mas a forma como são usados mudou de forma notória nos últimos meses. Cada vez mais organizações não os escolhem apenas para expor uma API REST tradicional a clientes externos: usam-nos também como camada de controlo para tráfego interno entre dezenas de microserviços, para aplicar quotas a parceiros de negócio e, mais recentemente, para encaminhar e limitar pedidos dirigidos a modelos de inteligência artificial. Essa mudança de uso alarga a superfície que precisa de ser protegida e torna a escolha do gateway ainda mais relevante do que era há dois ou três anos.
O que são o Kong Gateway, o AWS API Gateway e o Apigee
Os três produtos resolvem o mesmo problema (controlar, proteger e observar o tráfego que entra numa API) mas partem de arquiteturas muito diferentes. O Kong Gateway nasceu como um proxy open source construído sobre o NGINX e o motor LuaJIT do OpenResty. Pode ser instalado gratuitamente em qualquer servidor, cluster Kubernetes ou nuvem, ou geríado através do Kong Konnect, o plano de controlo em SaaS da empresa para ambientes multi-cluster. Esta liberdade de implementação é a principal razão pela qual tantas equipas de plataforma europeias o escolhem quando precisam de evitar o aprisionamento a um único fornecedor de nuvem.
O AWS API Gateway segue a lógica oposta: é um serviço totalmente gerido e exclusivo da Amazon Web Services. Não existe versão para instalar num servidor próprio nem opção híbrida. Em troca dessa rigidez, a Amazon entrega escalabilidade automática, integração nativa com o IAM, o Cognito, o Lambda e o CloudFront, e uma fatura calculada exclusivamente por pedido processado. É a opção previsível para equipas já comprometidas com a AWS.
Já o Apigee, da Google Cloud, ocupa um espaço intermédio. Existe como Apigee X (totalmente gerido) e como Apigee hybrid, em que o tempo de execução corre em infraestrutura própria do cliente mas o plano de controlo continua alojado pela Google. É o produto com o motor de políticas mais rico dos três, pensado para setores regulados como banca, telecomunicações e administração pública, onde a auditabilidade de cada chamada API é uma exigência legal e não um extra.
Por que esta comparação importa em 2026
A escolha de gateway já não é apenas uma decisão de engenharia de plataforma. É também uma decisão de segurança de API, a categoria que a OWASP identifica como uma das superfícies de ataque que mais cresce à medida que as empresas fragmentam sistemas monolíticos em dezenas de microserviços. Cada endpoint exposto sem autenticação forte, sem limitação de taxa ou sem inspeção de tráfego é um ponto de entrada potencial para fuga de dados. O nosso artigo sobre a segurança de APIs em Node.js já mostrou como pequenas falhas de configuração se tornam vetores de ataque reais.
Ao mesmo tempo, o custo tornou-se um argumento de peso. Uma empresa que processe mil milhões de chamadas API por mês pode pagar valores muito diferentes consoante o gateway escolhido, uma diferença que, à escala, ultrapassa facilmente o salário anual de uma equipa inteira de engenharia. Juntar isto à pressão regulatória europeia sobre proteção de dados e à obrigação, cada vez mais comum, de manter registos de auditoria de tráfego API, faz desta escolha uma decisão que atravessa engenharia, segurança e finanças ao mesmo tempo.
Há ainda um terceiro fator, menos falado, que pesa cada vez mais nesta decisão: a velocidade a que uma equipa consegue publicar uma nova versão de uma API sem introduzir um erro de configuração. Um gateway mal escolhido para a maturidade da equipa que o vai operar tende a acumular exceções, regras temporárias e políticas duplicadas ao longo do tempo, exatamente o tipo de dívida técnica que mais tarde se transforma num incidente de segurança. Escolher bem à partida poupa meses de trabalho de limpeza mais tarde.
Tabela de especificações: Kong vs AWS API Gateway vs Apigee
A tabela seguinte resume as características técnicas essenciais dos três produtos, com base na documentação oficial de cada fornecedor e em análises de mercado publicadas em 2026.
| Característica | Kong Gateway | AWS API Gateway | Apigee |
|---|---|---|---|
| Modelo de implementação | Self-hosted ou Konnect (SaaS) | Totalmente gerido (só AWS) | Apigee X (gerido) ou hybrid |
| Licenciamento | Open source (Apache 2.0) + subscrição enterprise | Pay-per-request | Subscrição enterprise |
| Motor base | NGINX + LuaJIT (OpenResty) | Serviço proprietário AWS | Serviço proprietário Google |
| Multi-cloud / on-premise | Sim, corre em qualquer infraestrutura | Não, apenas AWS | Parcial (hybrid runtime) |
| Suporte GraphQL | Via plugin, com limitação de taxa consciente do schema | Requer AWS AppSync à parte | Tratado como HTTP genérico |
| Autenticação nativa | JWT, OAuth2, mTLS, key-auth via plugins | IAM, Cognito, Lambda authorizers | OAuth2, JWT, introspecção de tokens |
| Deteção de anomalias | Via integrações externas (Prometheus, Datadog) | GuardDuty + CloudTrail | Deteção de anomalias assistida por IA nativa |
| Gestão de certificados TLS | Manual ou Let’s Encrypt / PKI própria | AWS Certificate Manager, renovação automática | Certificados geridos + PKI própria em hybrid |
| Observabilidade | Prometheus, Grafana, Datadog, OpenTelemetry | CloudWatch, X-Ray | Analytics e dashboards de tráfego nativos |
| Free tier | OSS gratuito para sempre | ~1M pedidos/mês grátis nos primeiros 12 meses | Avaliação de 60 dias, sem tier gratuito permanente |
| Público-alvo típico | Startups e equipas multi-cloud | Equipas já comprometidas com AWS | Grandes empresas e setores regulados |
Preços reais a diferentes volumes de tráfego
O modelo de preços é onde os três produtos mais se distinguem. O AWS API Gateway cobra por pedido processado: cerca de 1,00 dólar por milhão de pedidos nas chamadas HTTP API e cerca de 3,50 dólares por milhão nas REST APIs mais antigas, segundo dados de mercado publicados em 2026. Isto torna a migração de REST API para HTTP API, dentro do próprio AWS, uma das poupanças mais fáceis de conseguir sem trocar de fornecedor.
O Kong, na sua versão open source, não tem custo de licenciamento: paga-se apenas a infraestrutura onde corre (servidores, cluster Kubernetes, balanceadores de carga). As funcionalidades empresariais avançadas, como plugins de segurança adicionais, analytics de nível corporativo e governação multi-região, são vendidas via subscrição do Kong Konnect, normalmente negociada por nó de gateway ou por volume de chamadas.
O Apigee posiciona-se claramente no segmento empresarial, com subscrições que arrancam nos 10 mil dólares mensais e sobem consoante o número de ambientes, o volume de chamadas e os módulos contratados.
| Volume mensal de chamadas | Kong (OSS + infraestrutura) | AWS API Gateway (HTTP API) | Apigee (Standard) |
|---|---|---|---|
| 1 milhão | ~10-30 dólares (apenas compute) | Grátis (dentro do free tier) | Incluído na subscrição base |
| 10 milhões | ~50-100 dólares | ~10 dólares | Incluído / a partir de 10 mil dólares/mês |
| 100 milhões | ~150-400 dólares | ~93 dólares | A partir de 10 mil dólares/mês |
| 1 mil milhões | ~500-1.500 dólares (infraestrutura escalada) | ~930 dólares | ~19.400 dólares/mês |
A diferença ao mil milhão de chamadas mensais é a mais reveladora: o AWS API Gateway fica perto dos 930 dólares, enquanto o Apigee Standard, com o pacote de ambiente completo, pode ultrapassar os 19 mil dólares mensais para o mesmo volume. Essa diferença de mais de 18 mil dólares por mês não é acidental: paga a governação central, o motor de políticas mais rico e as ferramentas de conformidade que o Apigee inclui de série. Para uma equipa que não precisa dessa profundidade de governação, o custo extra é dinheiro parado.
Benchmarks de desempenho: RPS e latência
Em testes de carga publicados em 2026 por analistas independentes de infraestrutura, o Kong Gateway destacou-se pela relação entre throughput e custo de hardware. Um dos testes mais citados reporta uma diferença de 31 vezes no número de pedidos por segundo (RPS) entre a configuração mais rápida do Kong e a configuração mais lenta testada no mesmo estudo, uma vantagem atribuída à sua base em NGINX e LuaJIT, que processa pedidos com baixo overhead de CPU.
O AWS API Gateway e o Apigee não competem diretamente nesse tipo de benchmark bruto porque a arquitetura é diferente: são serviços multi-tenant geridos pelo fornecedor, com escalabilidade automática embutida. Em troca de um RPS bruto mais baixo por instância comparável, entregam infraestrutura elástica sem que a equipa de engenharia tenha de dimensionar nós, gerir upgrades ou configurar balanceadores de carga. Um estudo de 2026 sobre ferramentas de gateway com testes de latência posicionou o Kong entre as opções mais rápidas em cenários self-hosted, enquanto o AWS API Gateway e o Apigee lideraram em cenários onde a prioridade era zero manutenção operacional.
Vale a pena notar que um número de RPS isolado diz pouco sem contexto. Uma instância única do Kong bem afinada pode processar mais pedidos por segundo do que uma configuração equivalente de outro produto, mas isso não significa que a experiência final do utilizador seja mais rápida: a latência de rede até à região mais próxima, o tempo de resposta do serviço a jusante e a eficiência da camada de cache pesam tanto ou mais do que o desempenho bruto do proxy. Por isso, qualquer decisão baseada só em benchmarks de RPS deve ser validada com testes de carga no cenário real da própria aplicação, e não apenas com números publicados por terceiros.
| Métrica | Kong Gateway | AWS API Gateway | Apigee |
|---|---|---|---|
| Latência típica adicionada | Baixa (proxy local, sem saltos extra de rede) | Variável (dependente de região e integração) | Moderada (processamento de políticas mais pesado) |
| Escalabilidade sob picos | Manual/automática via Kubernetes | Automática, nativa | Automática (Apigee X) / manual (hybrid) |
| Overhead de CPU por pedido | Baixo (LuaJIT) | Não aplicável (serverless) | Moderado a alto (motor de políticas) |
| Necessidade de tuning manual | Alta (equipa própria) | Nenhuma | Baixa a moderada |
Funcionalidades de segurança e autenticação
Nos três produtos, a segurança assenta em capas de políticas que podem ser combinadas, mas a profundidade varia. O Kong oferece segurança baseada em plugins: validação de JWT, OAuth2, autenticação por chave, restrição de IP, mTLS entre serviços e limitação de taxa, muitos deles disponíveis na versão open source. É um modelo modular que dá controlo total a quem tem conhecimento para o configurar corretamente, mas que também significa que uma má configuração de TLS ou de um plugin de autenticação pode expor microserviços internos sem que ninguém repare de imediato.
O AWS API Gateway integra-se nativamente com o IAM, o Cognito, autorizadores Lambda personalizados e o AWS WAF, o que facilita aplicar regras alinhadas com o OWASP API Security Top 10 diretamente na borda da rede. O nosso artigo sobre a evolução do OWASP Top 10 mostra como a configuração incorreta subiu de posição no ranking de riscos mais recente, precisamente o tipo de erro que endpoints públicos sem WAF ou com políticas de IAM demasiado permissivas continuam a cometer.
O Apigee tem o motor de políticas mais rico dos três: proteção contra ameaças em JSON e XML, quotas e limitação de taxa configuráveis, introspecção de tokens OAuth2/JWT e deteção de anomalias assistida por inteligência artificial. Essa profundidade reduz o risco de configuração inconsistente entre ambientes, mas exige uma equipa de plataforma madura para tirar partido de todas as camadas de governação sem criar gargalos no processo de publicação de novas APIs.
Gestão de certificados TLS e cifragem em trânsito
Como é self-hosted ou híbrido, o Kong deixa a estratégia de terminação TLS nas mãos da equipa que o opera. É comum ver organizações a terminar TLS no próprio Kong recorrendo a certificados do Let’s Encrypt ou a uma PKI interna, com liberdade total para configurar mTLS entre o gateway e os serviços a jusante. O AWS API Gateway simplifica este processo através do AWS Certificate Manager, que gere domínios personalizados e renova certificados automaticamente, retirando essa tarefa operacional da equipa de engenharia. O Apigee X segue uma lógica semelhante com certificados geridos e integração com os balanceadores de carga da Google Cloud, enquanto no modo hybrid os certificados do runtime ficam sob controlo da própria empresa, uma opção valiosa para quem precisa de cumprir requisitos de conformidade mais rígidos.
Integração com Kubernetes e arquiteturas cloud-native
Esta é, provavelmente, a área onde a diferença de filosofia entre os três produtos fica mais visível. O Kong tem um controlador Kubernetes nativo maduro, amplamente usado como Ingress Controller e, mais recentemente, também como implementação da Gateway API do Kubernetes. Isto permite a equipas de plataforma tratar o gateway como mais um recurso declarativo dentro do cluster, versionado em Git e implantado com as mesmas ferramentas de CI/CD que gerem o resto da aplicação.
O AWS API Gateway pode integrar-se com cargas de trabalho em contentores através do Application Load Balancer ou do AWS App Mesh, mas não foi desenhado como peça nativa de um cluster Kubernetes: funciona melhor como camada de entrada externa ao cluster. O Apigee hybrid foi construído precisamente para preencher essa lacuna em ambientes híbridos, correndo o runtime dentro de Kubernetes (incluindo GKE, mas também outros clusters) enquanto mantém o plano de controlo na Google Cloud, uma opção relevante para empresas portuguesas que operam parte da infraestrutura on-premise por exigências de residência de dados.
Novidades e lançamentos recentes (2025-2026)
Nos últimos meses, os três fornecedores concentraram investimento em direções distintas. A linha 3.x do Kong Gateway continuou a evoluir com melhorias de desempenho, um ecossistema de plugins mais amplo e suporte reforçado para mTLS e OpenTelemetry, respondendo à procura por observabilidade mais profunda na comunicação entre serviços. A empresa também tem investido no chamado AI Gateway, uma camada pensada para encaminhar e proteger tráfego dirigido a modelos de linguagem, refletindo a integração crescente entre APIs tradicionais e infraestrutura de inteligência artificial.
No lado da AWS, as atualizações recentes concentraram-se em reforçar as HTTP APIs (o tier mais barato e mais moderno), em integração mais próxima com o Lambda e o Step Functions, e em melhorias incrementais de logging e endpoints privados, alinhadas com arquiteturas de confiança zero. O Apigee, por seu lado, destacou em 2026 analytics assistidos por IA e uma integração mais estreita com as ferramentas de segurança da Google Cloud, além de simplificação dos processos de atualização dos runtimes híbridos, uma queixa recorrente de clientes empresariais em anos anteriores.
Erros de configuração mais comuns nos três gateways
A maioria dos incidentes de segurança envolvendo gateways de API não nasce de uma falha no próprio produto, nasce de uma configuração deixada por defeito ou copiada de um ambiente de testes para produção sem revisão. No Kong, o erro mais comum é publicar uma rota sem qualquer plugin de autenticação associado, algo fácil de acontecer quando uma equipa cria dezenas de rotas por scripts de infraestrutura como código e esquece de aplicar uma política global de autenticação obrigatória a todas elas. Outro erro recorrente é deixar o painel de administração do Kong acessível publicamente, uma porta de entrada que já foi explorada em vários incidentes documentados por investigadores de segurança.
No AWS API Gateway, o problema mais frequente é a combinação de um endpoint público com uma função Lambda que tem permissões de IAM demasiado amplas. A API em si pode estar bem configurada, mas se a função que ela invoca tiver acesso a recursos que não precisa, um pedido malicioso bem-sucedido tem um raio de ação muito maior do que deveria. Também é comum ver equipas a esquecer-se de ativar o registo detalhado no CloudWatch logo na criação da API, o que só se torna evidente quando já é tarde demais para investigar um incidente passado.
No Apigee, o risco mais típico é a inconsistência entre ambientes: uma política de segurança aplicada corretamente em produção mas esquecida no ambiente de testes, que depois acaba exposto à internet com dados reais durante um período de validação. A riqueza do motor de políticas do Apigee é uma vantagem, mas também significa que há mais superfície de configuração para manter sincronizada entre ambientes. Nos três casos, o denominador comum é o mesmo: a ferramenta oferece os controlos certos, mas a disciplina de aplicá-los de forma consistente continua a depender inteiramente da equipa.
Exemplos reais de utilização
Os três gateways aparecem em cenários de produção bem distintos, o que ajuda a perceber onde cada um encaixa melhor:
- Fintech multi-cloud: uma fintech europeia que distribui carga entre AWS e infraestrutura própria por exigências de residência de dados tende a escolher o Kong precisamente porque não fica preso a um único fornecedor de nuvem.
- Startup SaaS 100% AWS: uma equipa pequena que já usa Lambda, Cognito e DynamoDB ganha velocidade de entrega ao usar o AWS API Gateway, evitando gerir infraestrutura própria de gateway.
- Banco com exigências regulatórias: uma instituição financeira sujeita a auditorias frequentes beneficia do motor de políticas do Apigee e dos seus relatórios de conformidade nativos.
- Telco com tráfego GraphQL: uma operadora que expõe APIs GraphQL para parceiros tende a preferir o Kong pelo suporte a limitação de taxa consciente do schema.
- Administração pública com runtime on-premise: um organismo público que precisa de manter dados em território nacional mas quer governação centralizada opta frequentemente pelo Apigee hybrid.
- Marketplace com centenas de vendedores parceiros: uma plataforma de comércio eletrónico que expõe uma API para integrações de terceiros beneficia da limitação de taxa granular por parceiro que os três produtos suportam, mas costuma preferir o Kong quando precisa de aplicar regras diferentes por segmento de parceiro sem depender de um único fornecedor de nuvem.
Em todos estes cenários, o padrão repete-se: a escolha raramente depende só da tecnologia. Depende de onde já está o resto da infraestrutura, de que exigências regulatórias a organização enfrenta e de quanto tempo de engenharia existe disponível para operar o próprio gateway em vez de o consumir como serviço gerido.
Guia de migração entre gateways de API
Migrar de um gateway para outro raramente é um processo de um único passo, mas segue um padrão comum que reduz o risco de incidentes:
- Inventariar todas as rotas, políticas de autenticação e regras de limitação de taxa em uso no gateway atual.
- Mapear cada plugin ou política existente para o equivalente no gateway de destino (por exemplo, um Lambda authorizer da AWS corresponde a um plugin de autenticação personalizado no Kong).
- Recriar os certificados TLS e testar a cadeia de confiança no ambiente de destino antes de qualquer corte de tráfego.
- Implementar o novo gateway em paralelo, usando um subdomínio ou ambiente de staging isolado.
- Encaminhar uma fração pequena do tráfego real (5% a 10%) para o novo gateway e comparar métricas de latência e taxa de erro.
- Validar que os dashboards de observabilidade (Prometheus, CloudWatch ou Apigee Analytics, consoante o destino) recebem os mesmos sinais que o sistema antigo.
- Aumentar gradualmente a percentagem de tráfego migrado ao longo de vários dias, mantendo sempre a possibilidade de reverter.
- Desativar o gateway antigo apenas depois de um ciclo completo de faturação sem incidentes reportados.
O maior risco numa migração deste tipo não costuma ser técnico, mas de governação: perder o registo de uma política de segurança que existia há anos e ninguém documentou. Antes de qualquer corte, vale a pena confirmar que cada política mapeada tem um responsável identificado.
Prós e contras de cada gateway
Kong Gateway
- Prós: gratuito na versão open source, funciona em qualquer nuvem ou on-premise, desempenho elevado por instância, ecossistema de plugins extenso.
- Contras: exige equipa própria com conhecimento operacional, funcionalidades empresariais mais avançadas ficam atrás de subscrição do Konnect, observabilidade depende de integrações externas.
AWS API Gateway
- Prós: sem infraestrutura para gerir, escalabilidade automática, faturação previsível por pedido, integração nativa com todo o ecossistema AWS.
- Contras: aprisionamento total à AWS, suporte a GraphQL exige um serviço adicional (AppSync), custo por pedido pode disparar em REST APIs legadas.
Apigee
- Prós: motor de políticas mais profundo, analytics e deteção de anomalias nativos, opção híbrida para requisitos de residência de dados.
- Contras: preço claramente mais elevado a partir de volumes médios, curva de aprendizagem maior, sem tier gratuito permanente para produção.
Recomendações por caso de uso
Não existe um vencedor absoluto: existe o gateway certo para cada contexto. Para uma startup em fase inicial com orçamento apertado e sem equipa dedicada a plataforma, o AWS API Gateway costuma ser o caminho mais rápido, sobretudo se o resto da stack já vive na AWS. Para uma equipa de plataforma com conhecimento operacional que precisa de flexibilidade multi-cloud e quer evitar custos por pedido a longo prazo, o Kong Gateway self-hosted compensa o investimento inicial em configuração.
Uma instituição financeira ou operadora de telecomunicações sujeita a auditorias externas frequentes tende a justificar o custo mais elevado do Apigee pela profundidade da sua governação e pelos relatórios de conformidade que já vêm prontos. Uma empresa com requisitos de residência de dados na União Europeia que ainda assim quer um plano de controlo centralizado deve considerar o Apigee hybrid ou o Kong Konnect com runtime local. E uma equipa que já expõe APIs GraphQL para parceiros externos ganha mais com o Kong, dado o suporte nativo a esse protocolo sem precisar de contratar um serviço adicional.
Observabilidade e resposta a incidentes
A capacidade de detetar rapidamente um padrão de tráfego anómalo (um sinal clássico de tentativa de exploração de API) depende diretamente das ferramentas de observabilidade disponíveis. O Kong integra-se com Prometheus, Grafana, Datadog e OpenTelemetry, dando às equipas de segurança métricas e traces detalhados para investigação forense. O AWS API Gateway liga-se ao CloudWatch para logs e métricas, ao X-Ray para tracing distribuído e ao GuardDuty e CloudTrail para deteção de ameaças mais ampla, permitindo que equipas de SOC centradas em AWS centralizem a resposta a incidentes numa única consola.
O Apigee inclui de série dashboards de analytics e deteção de anomalias, algo particularmente valioso em setores onde a auditabilidade de cada chamada API é uma obrigação legal, não apenas uma boa prática. O nosso guia sobre firewalls de aplicação web complementa esta análise: um WAF bem configurado à frente de qualquer um destes três gateways reduz significativamente a superfície de ataque exposta a tentativas automatizadas de exploração.
Custo total de propriedade a três anos
Olhar apenas para o preço por chamada esconde custos escondidos que só aparecem ao fim de vários trimestres. No caso do Kong self-hosted, é preciso somar o tempo de engenharia gasto a manter, atualizar e escalar o cluster, algo que raramente aparece numa fatura mas que pesa no orçamento de uma equipa de plataforma. No AWS API Gateway, o custo tende a crescer de forma quase linear com o tráfego, o que é previsível mas pode tornar-se significativo em produtos com crescimento rápido de utilizadores. No Apigee, o investimento inicial mais alto tende a diluir-se ao longo do tempo em organizações que já precisavam de contratar ferramentas de governação e conformidade separadas, pois o produto substitui vários sistemas que, de outra forma, seriam comprados individualmente.
Na prática, uma equipa que compare apenas o preço por milhão de chamadas está a olhar para uma fração pequena da equação. O custo de oportunidade de manter uma equipa dedicada à operação do Kong, ou o custo de não ter analytics de conformidade prontos no Apigee, pesam tanto ou mais do que a linha de preço publicada.
Um exercício simples ajuda a tornar isto tangível: se uma equipa de plataforma gastar, em média, um dia de trabalho por semana a manter um cluster Kong (atualizações de segurança, ajuste de plugins, resolução de incidentes de configuração), esse tempo representa uma fração significativa do salário anual de um engenheiro sénior só dedicado a manter o gateway operacional. Comparado com isso, mesmo os 930 dólares mensais do AWS API Gateway a mil milhões de chamadas parecem baratos, desde que a equipa não precise das funcionalidades multi-cloud que só o Kong oferece. É esse cálculo, e não apenas a tabela de preços por chamada, que deveria decidir a escolha final.
Adoção de mercado em 2026
O Kong mantém uma das maiores comunidades open source entre gateways de API, com uma vasta coleção de plugins de segurança partilhados publicamente, templates de infraestrutura como código para Terraform e Helm, e casos de uso documentados para arquiteturas de confiança zero em microserviços. O AWS API Gateway beneficia da escala do próprio ecossistema AWS: qualquer equipa que já use IAM, Cognito ou CloudFront encontra documentação extensa e exemplos de referência prontos a adaptar. O Apigee continua mais forte em círculos empresariais e entre clientes já comprometidos com a Google Cloud, com blueprints oficiais para serviços financeiros, telecomunicações e setor público que privilegiam governação e conformidade acima de contribuições open source.
Para uma equipa portuguesa a decidir entre os três em 2026, o ecossistema disponível localmente também conta. É mais fácil encontrar engenheiros com experiência prática em AWS, dado o peso do fornecedor no mercado ibérico de cloud computing, do que encontrar especialistas dedicados ao ajuste fino de um cluster Kong em produção. Esse fator de disponibilidade de talento raramente aparece numa comparação técnica, mas influencia diretamente quanto tempo uma equipa demora a ficar autónoma na operação do gateway escolhido.
O veredito: qual gateway escolher
Se a prioridade é liberdade de infraestrutura e o menor custo possível a longo prazo, e a equipa tem capacidade operacional para o gerir, o Kong Gateway é a escolha com melhor relação entre desempenho e preço, sobretudo em cenários multi-cloud ou híbridos. Se a equipa já vive dentro do ecossistema AWS e quer entregar segurança de API sem contratar mais pessoas para operar infraestrutura, o AWS API Gateway continua a ser o caminho mais direto, com uma fatura de cerca de 930 dólares por mil milhões de chamadas HTTP API, a opção mais económica dos três a esse volume. Se a organização opera num setor regulado, com exigências de auditoria e conformidade que pesam mais do que o preço por chamada, o Apigee justifica o investimento mais elevado pela profundidade da sua governação, mesmo custando cerca de 20 vezes mais do que o AWS API Gateway ao mesmo volume de tráfego.
Não existe um gateway universalmente melhor. Existe o gateway que corresponde à maturidade operacional da equipa, ao orçamento disponível e ao nível de exigência regulatória do setor onde a empresa opera. Consultar a tabela de preços oficial do Kong antes de decidir ajuda a confirmar se os números acima ainda correspondem à realidade no momento da compra, já que os fornecedores ajustam planos com frequência.
Uma última nota prática: nenhuma destas escolhas é definitiva para sempre. É perfeitamente normal uma empresa começar com o AWS API Gateway enquanto valida um produto novo, e migrar para o Kong ou para o Apigee anos mais tarde, quando o volume de tráfego, os requisitos de conformidade ou a estratégia de multi-cloud da organização mudarem. O guia de migração descrito acima existe exatamente para tornar essa transição menos arriscada quando esse dia chegar.
Perguntas frequentes
O Kong Gateway é mesmo gratuito?
A versão open source é gratuita e pode ser usada em produção sem custos de licenciamento. Só se paga a infraestrutura onde corre e, opcionalmente, uma subscrição do Kong Konnect para funcionalidades empresariais como analytics avançado e governação multi-região.
O AWS API Gateway suporta GraphQL nativamente?
Não de forma completa. Para expor APIs GraphQL de forma nativa dentro da AWS é preciso recorrer ao AWS AppSync, o que normalmente significa combinar o API Gateway para REST/HTTP com o AppSync para GraphQL na mesma arquitetura.
Qual dos três é mais seguro por definição?
Nenhum é automaticamente mais seguro só por escolha de produto. A segurança depende da configuração: um Kong mal configurado é tão vulnerável como um endpoint AWS sem WAF ou um ambiente Apigee com políticas inconsistentes entre ambientes de teste e produção.
Vale a pena migrar do AWS API Gateway REST API para HTTP API?
Na maioria dos casos sim, porque o custo por milhão de pedidos é significativamente mais baixo nas HTTP APIs. É preciso confirmar antes que todas as funcionalidades usadas (autorizadores, integrações, mapeamentos) têm equivalente na versão mais recente.
O Apigee hybrid resolve problemas de residência de dados na União Europeia?
Ajuda, porque permite manter o runtime de processamento de tráfego em infraestrutura própria ou localizada na UE, mas o plano de controlo continua alojado pela Google. Empresas com requisitos muito estritos devem validar este detalhe com a sua equipa jurídica antes de decidir.
É possível usar mais do que um gateway ao mesmo tempo?
Sim, e é uma prática comum em empresas maiores: usar o AWS API Gateway para serviços internos na AWS e o Kong como camada de entrada multi-cloud para parceiros externos, por exemplo. A complexidade adicional só compensa quando há uma razão de negócio clara para essa separação.
O que acontece se eu não limitar a taxa de pedidos (rate limiting) em nenhum destes gateways?
Fica exposto a ataques de negação de serviço a nível de aplicação e a abuso de endpoints por scripts automatizados. Os três produtos suportam limitação de taxa nativamente, mas nenhum a ativa sozinho: é sempre uma configuração que a equipa tem de definir explicitamente.
Qual destes gateways lida melhor com tráfego dirigido a modelos de inteligência artificial?
O Kong tem investido especificamente num “AI Gateway” para encaminhar e proteger tráfego destinado a modelos de linguagem, uma funcionalidade mais recente que os outros dois ainda não replicam com a mesma profundidade nativa.
