Firma tworzy usługę, która wymaga kompleksowego szyfrowania w transporcie, tak aby ruch nie był deszyfrowany między klientem a zapleczem usługi. Usługa wykorzystuje gRPC przez TCP port 443 i musi obsługiwać tysiące równoczesnych połączeń. Zaplecze działa na klastrze Amazon EKS z włączonymi Kubernetes Cluster Autoscaler i Horizontal Pod Autoscaler. Wzajemne TLS jest wymagane do dwukierunkowego uwierzytelniania między klientami a zapleczem. Które rozwiązanie spełnia te wymagania?

Poprawna odpowiedź to wdrożenie AWS Load Balancer Controller i użycie Network Load Balancer (NLB) z odbiornikiem TCP na porcie 443, który przekazuje ruch bezpośrednio do adresów IP Podów. NLB działa na warstwie 4 (TCP), co pozwala na kompleksowe szyfrowanie (end-to-end encryption), ponieważ nie deszyfruje ruchu TLS. Obsługuje tysiące równoczesnych połączeń i jest kompatybilny z gRPC przez TCP. Wzajemne TLS (mTLS) jest możliwe, ponieważ NLB nie ingeruje w sesję TLS, umożliwiając klientowi i zapleczu negocjację mTLS. AWS Load Balancer Controller automatyzuje zarządzanie NLB i jego integrację z Kubernetesem, kierując ruch bezpośrednio do Podów, co jest efektywne w środowisku EKS z autoskalowaniem. Pozostałe opcje są nieprawidłowe: Application Load Balancer (ALB) deszyfruje ruch TLS na warstwie 7, co narusza wymóg kompleksowego szyfrowania. Rejestrowanie grupy Auto Scaling zarządzanej grupy węzłów EKS jako cel jest nieefektywne dla ruchu kierowanego do Podów, ponieważ ruch musiałby przechodzić przez węzły, a następnie być przekierowywany do Podów, co jest mniej optymalne niż bezpośrednie kierowanie do Podów przez NLB.