Interactive · Amazon EKS worker-node networking

De-mystifying cluster networking for EKS worker nodes

One fixed diagram across two Availability Zones, stepped through the three API-endpoint access modes — public only, public + private, and private only. Each mode is shown in three sub-steps: how the worker node reaches the control plane, how the control plane reaches back to the node, and how a user (kubectl) reaches the cluster. The lesson to watch: the node → control-plane path changes with the mode, but control-plane → node (kubectl exec / logs) is always via the cross-account ENIs (X-ENIs). Blue flows are node → API; orange flows are API → node. Nothing on the canvas moves between stages; only the active path and the read-outs change. A faithful re-presentation of the AWS blog cited below.

1 Public endpoint only 2 Public + private endpoint 3 Private endpoint only
Stage 1 / 9

View
EKS worker-node ↔ control-plane networking across two AZs — a fixed topology whose active paths change per stage Amazon Route 53 (public DNS for the cluster API endpoint) and an AWS-managed VPC hosting the Kubernetes API server (reached via one cluster endpoint hostname) sit above your VPC. Your VPC spans two Availability Zones; each has a public subnet with a NAT gateway and a load balancer, and a private subnet with an EC2 worker node running kubelet and a cross-account ENI (X-ENI). Across the stages the diagram highlights node boot, Route 53 endpoint resolution, node-to-API registration and heartbeats, the API-to-node exec/logs return path via the cross-account ENIs (X-ENIs), the three endpoint access modes, and the three subnet configurations, while the geometry stays fixed. Amazon Route 53 cluster endpoint · DNS resolution 9A8B7C6D5E4F3A2B.gr7.us-east-1.eks.amazonaws.com public access → 3.128.94.20 (NLB) private access → 10.0.44.10 · 10.0.108.22 (X-ENIs) resolves — AWS-managed VPC · Kubernetes control plane Kubernetes API server kube-apiserver · 2+ nodes · multi-AZ private access public access Network Load Balancer AWS-managed Internet kubectl · admin / CI · CD (any network) VPN / Direct Connect Your VPC — 10.0.0.0/16 IGW Availability Zone A Public subnet (AZ-a) NAT gateway Load balancer Private subnet (AZ-a) EC2 worker node kubelet + node agent node IP · 10.0.40.15 Cross-account ENI X-ENI · EKS-managed 10.0.44.10 Availability Zone B Public subnet (AZ-b) NAT gateway Load balancer Private subnet (AZ-b) EC2 worker node kubelet + node agent node IP · 10.0.104.30 Cross-account ENI X-ENI · EKS-managed 10.0.108.22

Endpoint access

—

Endpoint access mode

Node → API—

DNS resolution

—

Route 53 public DNS → IP

Reachable from internet

—

Is the cluster API reachable from the public internet?

CLI / user access

—

How a user (kubectl) reaches the cluster API

Node → API path

—

—

API → Node path (exec / logs)

—

—

Notes

—

—

structural connection node → API flow API → node flow (exec / logs) cross-account ENIs (X-ENIs) control plane · Route 53

Static reference

Faithful to the AWS blog. Endpoint access mode and subnet configuration are two independent choices; the EKS-managed ENIs are always provisioned in your subnets, spread across the AZs.

Three endpoint access modes

Public endpoint only (default)
Nodes reach the public endpoint outside the VPC and need a public IP or a NAT route; cross-account ENIs (X-ENIs) are still provisioned for API-originated actions.
Public and private endpoints
In-VPC API requests resolve to the cross-account ENIs (X-ENIs) and reach the control plane inside your VPC; the public endpoint remains reachable from outside.
Private endpoint only
No public access; all API traffic originates from within the VPC or a connected network (VPN / Direct Connect) via the cross-account ENIs (X-ENIs).

Three VPC subnet configurations

Public subnets only
Nodes and load balancers co-located in public subnets, routed through the IGW, with mapPublicIpOnLaunch=true.
Public + private subnets (recommended)
Nodes in private subnets egress via a per-AZ NAT gateway; ingress load balancers sit in public subnets.
Private subnets only
Nodes in private subnets with no IGW; access requires a VPN or Direct Connect connection.

Route 53 and the cluster endpoint. The cluster API endpoint is a single DNS hostname resolved by public DNS. When you enable private access, EKS creates a Route 53 private hosted zone on your behalf, associates it with your VPC, and manages it — it does not appear in your account. In-VPC clients resolve the endpoint through it to the private cross-account ENI (X-ENI) IPs, so in-VPC traffic stays in-VPC. Since 2020, public DNS also returns those private IPs, so clients reaching in over VPN or Direct Connect (outside the VPC) can resolve the name too — neither mechanism is legacy. With public access, the same hostname resolves to the public IPs of the AWS-managed Network Load Balancer (NLB).