I'm comparing ingress options for managed Kubernetes platforms such as EKS, AKS, and GKE. The AWS Load Balancer Controller is common on EKS, but I'm concerned about TLS termination at the ALB. If the ALB terminates TLS, traffic from the ALB to the target pod may be plaintext unless HTTPS is configured for the backend. Even when HTTPS is used, the ALB does not properly verify the backend certificate hostname, so a self-signed or expired pod certificate might not cause a connection failure. This is for a Zero Trust and PCI DSS compliance requirement, so I need encryption and meaningful workload identity verification throughout the path. What ingress or gateway architecture is commonly used, and what would you recommend for genuine end-to-end TLS or mTLS?
4 Answers
For a straightforward setup, Traefik has been reliable across multiple cloud providers and supports Gateway API. Envoy Gateway is also a solid choice if you want a modern proxy-oriented design. If you stay with the AWS controller, you can provision an NLB and terminate TLS at an in-cluster ingress using cert-manager, then add mesh mTLS for service-to-service traffic.
You can use an application gateway or ALB with backend HTTPS, but that is still TLS offload followed by re-encryption, not fully authenticated end-to-end TLS. If compliance requires every hop to authenticate the next one, terminate TLS in the cluster and use mTLS for internal workloads rather than expecting the external load balancer to provide that guarantee.
There isn’t one universal choice. On EKS, the AWS Load Balancer Controller is still very common; on AKS, teams often use NGINX or Azure’s application gateway products; and on GKE, the built-in ingress or Gateway API is widely used. Traefik, Envoy Gateway, and Cilium are popular cloud-neutral alternatives. The right decision depends more on your TLS and identity requirements than on raw popularity.
The important distinction is encryption versus authentication. You can configure the AWS load balancer to use HTTPS to the target group, but the backend certificate is not strongly validated, so that provides re-encryption without proving the identity of the pod. For strict compliance, use an NLB in passthrough mode and terminate TLS inside the cluster, or use a service mesh such as Istio or Linkerd for workload mTLS. Envoy Gateway with Gateway API is another good option for a newer deployment.
That’s the concern: encryption without authentication isn’t enough for our Zero Trust and PCI DSS requirements. A certificate that is expired or self-signed might not be rejected by the load balancer.