AWS Load Balancer Controller: ALB for HTTP, NLB for TCP
The AWS Load Balancer Controller runs in your cluster and reconciles Kubernetes objects into AWS load balancers. An Ingress (class alb) becomes an Application Load Balancer for HTTP, HTTPS and gRPC, with host and path rules. A Service of type LoadBalancer using the controller becomes a Network Load Balancer for TCP, UDP and TLS. It needs IAM permissions, supplied through Pod Identity or IRSA.
Target type matters. In instance mode traffic goes to a NodePort on any node and is forwarded by kube-proxy, adding a hop and obscuring the client IP. In IP target mode the load balancer registers Pod IPs directly, which works because Pods have routable VPC addresses. It skips the extra hop, balances per Pod and preserves the source address, so it is generally preferred. Press the right arrow to see the flow.
Two production details avoid dropped requests during rollouts. Pod readiness gates make a Pod not Ready until the load balancer reports its target healthy, so a rolling update does not remove old Pods before new targets are registered. And deregistration delay should be matched with your application's graceful shutdown.
Cost note: each ALB and NLB has an hourly charge plus usage charges. Share one ALB between many Ingresses with IngressGroups rather than creating one per Service.