AWS’s EKS case uses Envoy Gateway for namespace-scoped TCP access to Android devices, while its separate NGINX Ingress example verifies client certificates for HTTPS applications. Mutual TLS (mTLS) authenticates both sides of a connection using certificates; the right pattern depends on the traffic you need to protect.
Match the gateway to the traffic: Envoy handles the case’s TCP path for ADB; NGINX Ingress handles HTTPS application traffic.
AWS’s Envoy gateway for ADB on EKS
In a case study published November 6, 2026, AWS describes replacing a two-hop bastion path for its Cuttlefish virtual Android devices with a separate Envoy Gateway in each tenant namespace. Each gateway routes ADB traffic only to pods in its own namespace. A custom command-line tool contacts an authorization API, which checks the user’s identity-provider JWT and namespace assignment before returning connection details and a namespace-scoped certificate over HTTPS. AWS’s Cuttlefish case study
The JWT identifies the user and confirms their namespace assignment; the certificate identifies the namespace to the mTLS connection. AWS’s certificate naming convention uses <user-namespace>.eks.internal, which should not conflict with an organization’s DNS names.
The design also uses Amazon Kinesis Video Streams as a managed TURN relay for WebRTC media. That is a separate media route, not the ADB gateway: AWS says it replaced the deployment’s self-managed STUNner setup while retaining Cuttlefish’s default signaling server.
Prerequisites and certificate renewal
AWS’s design depends on namespace isolation, scoped role-based access control (RBAC), a default-deny NetworkPolicy in each tenant namespace, JWT validation by the custom API, AWS Private CA, and cert-manager with its AWS issuer plugin. Without default-deny network rules, traffic can bypass Envoy. The NetworkPolicy also limits which components can reach the ADB port.
AWS describes certificates with a 12-hour lifetime and a four-hour renewal window. With cert-manager’s usual renewal point at two-thirds of a certificate’s lifetime, renewal begins after eight hours, leaving four hours. Envoy Gateway receives renewed certificate material through SDS, the Secret Discovery Service, without a pod restart. In a namespace shared by multiple users, AWS says per-user certificates are needed for user-level attribution because the described certificate subject does not identify the user.
Where mTLS ends, and when NGINX fits
In the Cuttlefish design, mTLS ends at Envoy. The hop from Envoy to a pod is not encrypted by mTLS; AWS points to sidecars or certificates at the pod level when end-to-end mTLS is required. The ADB path also does not pass through AWS WAF in this design. The separate REST API is behind HTTPS and AWS WAF.
AWS’s NGINX Ingress guidance addresses a different job: client-certificate verification for HTTPS application traffic entering through Kubernetes Ingress. It uses Ingress annotations and a Kubernetes Secret with server and CA certificate material. AWS’s NGINX Ingress guidance
| Design choice | Envoy Gateway in the Cuttlefish case | NGINX Ingress in AWS guidance |
| Traffic | Namespace-scoped TCP proxying for ADB to pods | HTTPS application traffic through Ingress |
| Client-certificate setup | AWS Private CA, cert-manager, and the AWS issuer plugin issue short-lived namespace certificates | Ingress annotations enable client verification; a Kubernetes Secret holds certificate material |
| Certificate example | AWS describes 12-hour certificates and a four-hour renewal window | The example uses self-signed certificates for testing; AWS recommends AWS Private CA or an existing PKI for production |
Choose Envoy for the case’s namespace-scoped TCP path to ADB. Choose the NGINX example when the task is verifying client certificates for an HTTPS application. The NGINX example’s self-signed certificates are for testing, not production.
Results AWS reports
AWS reports that the previous bastion path took 3–4 minutes to install an application and 1–2 seconds for an ADB command round trip. In its Envoy deployment, AWS reports application installs under 30 seconds and ADB command completion under 100 milliseconds. It separately reports gateway latency under 50 milliseconds compared with a local setup. That gateway-latency figure is not the total ADB command time. These are AWS’s reported results for its deployment.
For WebRTC, AWS reports stable connections at peak usage and no manual route updates after pods moved between Availability Zones. It also says the managed TURN relay removed a custom token-exchange service and the need to maintain self-managed TURN servers.
