AWS eks: Document PreferSameNode traffic distribution and PreferClose rename
Summary
Adds documentation for the Kubernetes 1.35 PreferSameNode service traffic distribution option, the PreferClose-to-PreferSameZone rename, fallback behavior, benefits, risks, and a comparison table with PreferSameZone.
Security assessment
The change is purely about cost optimization and latency via locality-based traffic routing (PreferSameNode/PreferSameZone). It discusses fallback behavior and load balancing, not authentication, encryption, or any vulnerability. No security weakness or incident is referenced.
Evidence
+`PreferSameNode` extends locality routing one step further. It was introduced as an alpha feature in Kubernetes 1.33 and made generally available in Kubernetes 1.35 ([KEP-3015](https://github.com/kubernetes/enhancements/issues/3015)). It directs kube-proxy to preferentially route traffic to endpoints running on the **same node** as the client Pod. The fallback chain is:
Diff
diff --git a/eks/latest/best-practices/cost-opt-networking.md b/eks/latest/best-practices/cost-opt-networking.md index 81ecee4ae..a8fcf2155 100644 --- a//eks/latest/best-practices/cost-opt-networking.md +++ b//eks/latest/best-practices/cost-opt-networking.md @@ -76,0 +77,4 @@ Introduced in Kubernetes 1.30 and made generally available in 1.33, [Traffic Dis +###### Naming update (Kubernetes 1.35): + +In Kubernetes 1.35 ([KEP-3015](https://github.com/kubernetes/enhancements/issues/3015)), `PreferClose` was deprecated and renamed to `PreferSameZone`. `PreferClose` remains a functional alias for backward compatibility. The same update also introduced a new value, `PreferSameNode`, described below. + @@ -113,0 +118,83 @@ To overcome this challenge: +#### PreferSameNode + +`PreferSameNode` extends locality routing one step further. It was introduced as an alpha feature in Kubernetes 1.33 and made generally available in Kubernetes 1.35 ([KEP-3015](https://github.com/kubernetes/enhancements/issues/3015)). It directs kube-proxy to preferentially route traffic to endpoints running on the **same node** as the client Pod. The fallback chain is: + + * same-node + + * same-zone + + * any healthy endpoint cluster-wide + + + + +This is particularly useful for: + + * **DaemonSet-style services** (node-local DNS, log collectors, local caches) where a Pod runs on every node + + * **Ultra low-latency workloads** that benefit from eliminating all physical network hops + + * **Node-local service patterns** (for example, DaemonSet-backed services accessed via ClusterIP) where co-located communication eliminates network traversal, reducing latency for chatty microservice interactions + + + + +The following code example shows how to enable same-node traffic distribution for a Service: + + + apiVersion: v1 + kind: Service + metadata: + name: local-cache + namespace: platform + spec: + trafficDistribution: PreferSameNode + selector: + app: local-cache + type: ClusterIP + ports: + - protocol: TCP + port: 6379 + targetPort: 6379 + +##### Benefits + + * Lower latency when a local endpoint is available—traffic stays within the node’s network stack, avoiding physical network traversal. When falling back to remote endpoints, latency is equivalent to default routing. + + * No cross-AZ data transfer costs while local or same-zone endpoints are available. If all local or zonal endpoints are unavailable, traffic silently falls back to cluster-wide routing, which might incur standard inter-AZ charges. + + * Safe fallback — unlike `internalTrafficPolicy: Local`, traffic is never dropped. If no same-node endpoint is available, it gracefully falls back to same-zone and then cluster-wide endpoints. + + + + +##### Risks and considerations + + * Requires Pods on most or all nodes — `PreferSameNode` is only effective when server Pods are broadly distributed (DaemonSets or high-replica Deployments). If Pods are concentrated on a few nodes, most clients will fall back to remote endpoints, negating the benefit. + + * Node-level load imbalance — nodes receiving more inbound traffic will disproportionately load their local endpoint, potentially creating hotspots. HPA can scale Pod count globally but does not control which node new Pods land on. + + * Not a hard guarantee — `PreferSameNode` is a preference, not a strict policy. If your use case _requires_ traffic to never leave the node (for example, for compliance or data sovereignty), use `internalTrafficPolicy: Local` instead - but accept that traffic will be dropped when no local endpoint exists. + + * Rolling updates can cause temporary fallback — when a local Pod is terminated during a rolling update, traffic from that node falls back to remote endpoints until the replacement Pod passes readiness checks. + + * `internalTrafficPolicy: Local` and `externalTrafficPolicy: Local` take precedence. If you configure both at the same time and no local endpoints are available, the service drops traffic. + + * Update `kube-proxy` to version 1.35 or later. + + + + +##### Choosing between `PreferSameZone` and `PreferSameNode` + +The following table compares PreferSameZone with PreferSameNode across key dimensions. + +Criteria | `PreferSameZone` | `PreferSameNode` +---|---|--- +**Primary goal** | Reduce cross-AZ data transfer costs | Minimize latency; eliminate all network hops +**Pod distribution needed** | Pods spread across zones | Pods on most/all nodes (DaemonSets ideal) +**Fallback chain** | Same-zone, then any healthy | Same-node, then same-zone, then any healthy +**Cost savings** | Eliminates inter-AZ charges | Same (eliminates inter-AZ charges); additional benefit is lower latency +**Overload risk** | Zone-level hotspots | Node-level hotspots +**Best workload fit** | Standard multi-AZ Deployments | DaemonSets, node-local caches, high-replica services +