Why Does Istio Ingress Gateway Show EXTERNAL-IP Pending on EKS? Solutions Explained

Istio Ingress Gateway and Load Balancer

Istio Ingress Gateway is essentially an Envoy proxy deployed as a Kubernetes Deployment and exposed via a Service of type LoadBalancer. In an AWS EKS cluster this triggers the creation of a Classic Load Balancer (CLB) or Network Load Balancer (NLB) that forwards external traffic to the gateway pods.

Common Reasons for EXTERNAL-IP Pending

AWS resource quota limits – the account may have reached the maximum number of load balancers allowed in the region.

Subnet configuration issues – worker nodes reside in subnets that are not correctly labeled or lack required routes.

Insufficient IAM permissions – the IAM role attached to the worker nodes does not have permission to create load balancers.

Service annotation errors – incorrect or missing annotations on the Istio Ingress Service prevent proper provisioning.

Subnet Configuration: The Key

Among the causes, subnet mis‑configuration is the most frequent and easily overlooked. Kubernetes relies on specific subnet tags to decide which subnets can host a load balancer.

Public Subnet

Used when the load balancer must be reachable from the Internet. The subnet’s route table must point to an Internet Gateway (IGW) and the subnet must carry the tag kubernetes.io/role/elb=1.

Private Subnet

Used for internal‑only load balancers. The subnet must have a NAT Gateway or NAT instance for outbound AWS API calls and be tagged kubernetes.io/role/internal-elb=1.

Shared Subnet Tag

Tag kubernetes.io/cluster/<cluster-name>=shared marks the subnet as part of the EKS cluster, allowing Kubernetes to select it for either public or private load balancers.

Case Study: Resolving EXTERNAL-IP Pending

The following error was observed:

FailedBuildModel due to unable to resolve at least one subnet (0 match VPC and tags: [kubernetes.io/role/internal-elb])

This indicates that Kubernetes could not find any subnet labeled kubernetes.io/role/internal-elb=1 when attempting to create an internal load balancer.

Solution Steps

Identify the IDs of the private subnets used by the EKS cluster.

Add the required tags to those subnets:

kubernetes.io/role/internal-elb: 1

kubernetes.io/cluster/<cluster-name>: shared

After applying the correct tags, Kubernetes can locate suitable subnets, create the internal load balancer, and the Service’s EXTERNAL-IP transitions from pending to a reachable address.

Conclusion

When configuring an Istio Ingress Gateway on EKS, proper subnet tagging is essential. Understanding the distinction between public and private subnets and applying the Kubernetes tags kubernetes.io/role/elb, kubernetes.io/role/internal-elb, and kubernetes.io/cluster/<cluster-name>=shared prevents the common EXTERNAL-IP pending issue and ensures a functional load‑balancing entry point.