Un'azienda sta creando un servizio che richiede la crittografia end-to-end in transito, in modo che il traffico non venga decifrato tra il client e il backend del servizio. Il servizio utilizza gRPC su porta TCP 443 e deve supportare migliaia di connessioni simultanee. Il backend viene eseguito su un cluster Amazon EKS con Kubernetes Cluster Autoscaler e Horizontal Pod Autoscaler abilitati. È richiesto il Mutual TLS per l'autenticazione bidirezionale tra i client e il backend. Quale soluzione soddisfa questi requisiti?

L'opzione corretta soddisfa tutti i requisiti. La crittografia end-to-end e il Mutual TLS (mTLS) richiedono che il traffico non venga decifrato dal bilanciatore di carico. Un Network Load Balancer (NLB) con un listener TCP sulla porta 443 inoltra il traffico direttamente ai pod senza terminare la connessione TLS, consentendo ai pod di gestire la decrittografia e l'autenticazione mTLS. L'AWS Load Balancer Controller è essenziale per integrare l'NLB con i servizi EKS, consentendo l'instradamento diretto agli IP dei pod e supportando la scalabilità automatica di Kubernetes (HPA e Cluster Autoscaler). Le opzioni che utilizzano un Application Load Balancer (ALB) sono errate perché un ALB terminerebbe la connessione TLS, impedendo la crittografia end-to-end e il mTLS gestito dai pod. L'opzione con NLB e listener TLS è errata perché anche un listener TLS su NLB termina la connessione TLS. Inoltre, registrare l'Auto Scaling Group dei nodi come target non consente l'instradamento diretto ai pod e non supporta la scalabilità granulare a livello di pod.