Een bedrijf bouwt een service die end-to-end-encryptie tijdens transport vereist, zodat verkeer niet wordt gedecrypteerd tussen de client en de servicebackend. De service gebruikt gRPC via TCP-poort 443 en moet duizenden gelijktijdige verbindingen ondersteunen. De backend draait op een Amazon EKS-cluster met de Kubernetes Cluster Autoscaler en Horizontal Pod Autoscaler ingeschakeld. Mutual TLS is vereist voor tweeweg-authenticatie tussen clients en de backend. Welke oplossing voldoet aan deze vereisten?

De correcte oplossing is het implementeren van de AWS Load Balancer Controller met een Network Load Balancer (NLB) en een TCP-listener op poort 443. Dit is omdat de vereiste "end-to-end-encryptie" en "verkeer niet wordt gedecrypteerd tussen de client en de servicebackend" betekent dat de load balancer geen TLS-terminatie mag uitvoeren. Een NLB met een TCP-listener stuurt het versleutelde verkeer direct door naar de backend-pods, waardoor de end-to-end-encryptie behouden blijft. gRPC via TCP-poort 443 en duizenden gelijktijdige verbindingen zijn ook goed te verwerken door een NLB. De AWS Load Balancer Controller integreert naadloos met EKS en stuurt verkeer direct naar de IP-adressen van de pods, wat cruciaal is voor dynamische Kubernetes-omgevingen met autoscaling. Mutual TLS wordt dan afgehandeld door de backend-service zelf. De optie met een Application Load Balancer (ALB) is onjuist omdat een ALB standaard TLS-terminatie uitvoert, wat in strijd is met de end-to-end-encryptievereiste. De opties die de Auto Scaling group van de EKS managed node group als target registreren, zijn onjuist omdat dit verkeer naar de nodes stuurt in plaats van direct naar de pods, wat de complexiteit verhoogt en de voordelen van directe pod-routing via de Load Balancer Controller tenietdoet.