AWS setzt im Cuttlefish-Fall auf Amazon EKS Envoy Gateway für TCP-Verbindungen mit ADB. AWS’ separates Beispiel mit NGINX Ingress prüft dagegen Client-Zertifikate für HTTPS-Anwendungen. Die am 6. November 2026 veröffentlichte AWS-Fallstudie beschreibt den eigenen Einsatz und dessen Ergebnisse.
mTLS steht für gegenseitiges TLS: Beide Seiten einer Verbindung weisen ihre Identität mit Zertifikaten nach. Im EKS-Fall sichert mTLS die Verbindung vom Client bis zum Envoy-Gateway ab.
Envoy führt ADB-Verbindungen in den passenden Namespace
Bei Googles konfigurierbarem virtuellem Android-Gerät Cuttlefish läuft der ADB-Verkehr über einen TCP-Proxy. AWS beschreibt dafür je Mandanten-Namespace eine eigene Envoy-Gateway-Instanz, die nur zu Pods in diesem Namespace weiterleitet. Eine eigene API prüft das JWT des Nutzers und dessen Namespace-Zuordnung. Anschließend gibt sie über HTTPS Verbindungsdaten und ein Namespace-Zertifikat zurück.
Die WebRTC-Medienverbindung nutzt einen anderen Pfad: AWS beschreibt Amazon Kinesis Video Streams als verwaltetes TURN-Relay. Damit ersetzte der Dienst im Fallbeispiel den selbst betriebenen STUNner. AWS berichtet von stabilen Verbindungen während hoher Auslastung und davon, dass nach Pod-Verschiebungen zwischen Availability Zones keine manuellen Routenanpassungen nötig waren.
Voraussetzungen und Zertifikatswechsel
Das Envoy-Muster setzt isolierte Namespaces, eingeschränkte RBAC-Berechtigungen und eine Default-Deny-NetworkPolicy in jedem Mandanten-Namespace voraus. „Default Deny“ bedeutet, dass Netzwerkverkehr zunächst gesperrt ist und nur ausdrücklich erlaubte Verbindungen passieren. Ohne diese Regeln kann Verkehr das Gateway umgehen. Außerdem gehören die JWT-Prüfung durch die eigene API, AWS Private CA, cert-manager und dessen AWS-Aussteller-Plugin zum beschriebenen Aufbau.
Ohne Default-Deny-Regeln ist Envoy nicht der einzige mögliche Weg zum ADB-Port.
AWS beschreibt Zertifikate mit zwölf Stunden Laufzeit und einem Erneuerungsfenster von vier Stunden. cert-manager erneuert sie üblicherweise nach zwei Dritteln der Laufzeit, also nach acht Stunden. Envoy Gateway erhält die aktualisierten Zertifikate über SDS, ohne dass ein Neustart des Pods nötig ist. Das Zertifikat kennzeichnet den Namespace; für eine genauere Zuordnung einzelner Nutzer in gemeinsam genutzten Namespaces nennt AWS nutzerspezifische Zertifikate als Möglichkeit.
Wo mTLS endet und wann NGINX Ingress passt
In AWS’ Cuttlefish-Aufbau endet mTLS am Envoy-Gateway. Der anschließende Weg vom Gateway zum Pod ist nicht mit mTLS verschlüsselt. Eine NetworkPolicy beschränkt, welche Komponenten den ADB-Port erreichen dürfen. Für mTLS bis zum Pod nennt AWS Sidecars oder Zertifikate auf Pod-Ebene als mögliche Ergänzungen. Der ADB-Datenpfad hat in diesem Aufbau keinen AWS WAF; die separate REST-API liegt hinter HTTPS und AWS WAF.
AWS’ NGINX-Ingress-Anleitung für Amazon EKS behandelt einen anderen Verkehrstyp: Client-Zertifikatsprüfung für HTTPS-Anwendungen hinter einem Kubernetes-Ingress. Die Anleitung nutzt dafür Ingress-Annotationen und ein Kubernetes-Secret mit Serverzertifikat, privatem Schlüssel und CA-Zertifikat.
| Merkmal | Envoy Gateway im Cuttlefish-Fall | NGINX Ingress in der AWS-Anleitung |
| Verkehr | TCP-Verbindungen für ADB zu Pods | HTTPS-Verkehr zu Anwendungen |
| Einsatz | Eigene Gateway-Instanz je Mandanten-Namespace | Client-Zertifikatsprüfung am Anwendungs-Ingress |
| Zertifikate | AWS Private CA mit cert-manager und AWS-Aussteller-Plugin | Selbstsignierte Zertifikate im Beispiel für Testcluster |
| Grenze oder Hinweis | mTLS endet am Envoy-Gateway | Für den Produktionseinsatz empfiehlt AWS AWS Private CA oder eine vorhandene PKI |
Welche Leistungswerte AWS berichtet
Für den früheren Weg über einen Bastion-Host nennt AWS drei bis vier Minuten für Anwendungsinstallationen und eine bis zwei Sekunden pro ADB-Rundlauf. Im Envoy-Aufbau dauerten Installationen laut AWS weniger als 30 Sekunden; ADB-Kommandos wurden in weniger als 100 Millisekunden abgeschlossen. Separat berichtet AWS eine Gateway-Latenz von weniger als 50 Millisekunden im Vergleich zu einer lokalen Einrichtung. Diese Werte beziehen sich auf unterschiedliche Messgrößen.
Für Amazon Kinesis Video Streams nennt AWS aktive Signalisierungskanäle, Signalisierungsnachrichten und TURN-Streaming-Minuten als Abrechnungsgrößen. Die Fallstudie beziffert keine konkreten Kosten.
