No caso Cuttlefish da AWS no Amazon EKS, o Envoy Gateway faz proxy de conexões TCP do ADB para pods dentro de cada namespace; o exemplo separado da AWS com NGINX Ingress verifica certificados de cliente em aplicações HTTPS. A AWS publicou o relato do caso em 6 de novembro de 2026 e descreveu sua própria implantação, com esses dois padrões voltados a fluxos diferentes. Leia o estudo de caso da AWS.
mTLS, ou TLS mútuo, autentica os dois lados de uma conexão usando certificados. Na arquitetura do Envoy, ele protege a conexão até o gateway, mas não o trecho entre o Envoy e o pod.
Regra prática: escolha o padrão pelo tráfego: Envoy para o proxy TCP de ADB limitado ao namespace; NGINX Ingress para autenticação por certificado em aplicações HTTPS.
Como o Envoy encaminha o ADB no Amazon EKS
A arquitetura descrita pela AWS usa uma instância do Envoy Gateway em cada namespace de usuário. Um cliente passa por uma ferramenta de linha de comando e uma API personalizada: a API valida o token JWT, que identifica o usuário e sua atribuição de namespace, e retorna os dados de conexão e um certificado associado ao namespace. O Envoy encaminha o tráfego ADB apenas para pods daquele namespace.
A separação depende de controles dentro do cluster. A AWS pressupõe isolamento entre namespaces, permissões RBAC com escopo e políticas de rede do Kubernetes (NetworkPolicy) configuradas para negar o tráfego por padrão. Sem essa negação padrão, o tráfego pode contornar o gateway. As políticas também restringem quais componentes podem acessar a porta do ADB.
O caminho de mídia é outro: a AWS usa o Amazon Kinesis Video Streams como relay TURN para WebRTC. TURN retransmite o tráfego de mídia quando a conexão direta entre os participantes não é possível. No relato, a AWS diz que essa mudança substituiu o STUNner autogerenciado e dispensou um serviço personalizado de troca de tokens por credenciais TURN. A implantação manteve o servidor de sinalização padrão do Cuttlefish.
Identidade e renovação dos certificados
No desenho da AWS, o JWT identifica o usuário e ajuda a validar seu namespace; o certificado curto identifica o namespace na conexão mTLS. A AWS usa o AWS Private CA com o cert-manager e o plugin emissor da AWS. O nome comum do certificado segue o padrão <user-namespace>.eks.internal; a organização precisa evitar conflito com seu próprio DNS.
Os certificados têm validade de 12 horas, com renovação prevista dentro das 4 horas finais. O cert-manager normalmente inicia o processo após dois terços da validade, ou seja, depois de 8 horas. O Envoy Gateway recebe o material renovado por meio do SDS, sem reiniciar o pod. Em namespaces compartilhados, certificados individuais por usuário permitem atribuição mais granular, segundo a AWS, porque o nome do certificado descrito no caso não identifica cada pessoa.
Envoy e NGINX atendem fluxos diferentes
O Envoy do caso Cuttlefish é um proxy TCP com escopo por namespace, voltado ao ADB. Já a orientação da AWS para NGINX Ingress trata de verificação de certificados de cliente no tráfego HTTPS de uma aplicação. Ela usa anotações no Ingress e um Secret do Kubernetes com certificados e material de CA. Consulte a orientação da AWS para NGINX Ingress.
| Aspecto | Envoy Gateway no caso Cuttlefish | NGINX Ingress na orientação da AWS |
| Tráfego | TCP para conexões ADB com pods | HTTPS para aplicações |
| Escopo | Uma instância por namespace de usuário, com encaminhamento para pods daquele namespace | Verificação de certificado de cliente na entrada de uma aplicação |
| Certificados | AWS Private CA com cert-manager e o plugin emissor da AWS | O exemplo usa certificados autoassinados em um Secret do Kubernetes |
| Uso dos certificados | Certificado de curta duração associado ao namespace | A AWS limita os certificados autoassinados do exemplo a clusters de teste e recomenda AWS Private CA ou uma PKI existente para produção |
O limite de confiança do caso Envoy fica no próprio gateway: a AWS afirma que o trecho entre Envoy e pod não é protegido por mTLS. Para exigir mTLS de ponta a ponta, a AWS aponta o uso de sidecars ou certificados nos pods. No caminho de dados do ADB descrito, a proteção depende do mTLS até o Envoy, das políticas de rede e do isolamento entre namespaces; a API REST separada usa HTTPS e AWS WAF.
Resultados que a AWS relata
A AWS compara o caminho anterior, com dois saltos por bastion, ao acesso via Envoy. No percurso anterior, a instalação de aplicativos levava de 3 a 4 minutos e cada ida e volta de um comando ADB durava de 1 a 2 segundos. No percurso com Envoy, a AWS relata instalações em menos de 30 segundos e comandos ADB concluídos em menos de 100 ms. Separadamente, informa latência do gateway inferior a 50 ms em comparação com a configuração local. Esse último valor é uma medida de latência do gateway, não a duração total de cada comando ADB.
Para WebRTC, a AWS relata conexões estáveis nos picos de uso e ausência de atualizações manuais de rotas após a mudança de pods entre zonas de disponibilidade. São resultados da implantação descrita pela empresa.
