Comparing Private Networking Architectures in EKS, AKS and GKE

Introduction

A Kubernetes cluster running on private subnets is not necessarily fully private. A true private Kubernetes design must consider API server exposure, public access to worker nodes, Pod IP allocation and routing, and outbound connectivity. EKS, AKS, and GKE handle these areas differently, especially in how Pods integrate with the underlying cloud network. Understanding these differences is essential for building secure production clusters.

Private Kubernetes Cluster Definition

Private Kubernetes networking has multiple independent layers, including the API server, worker nodes, and outbound connectivity. A cluster can have private worker nodes while still exposing the Kubernetes API publicly. Likewise, a private API server does not automatically mean the cluster has no internet access. Services such as NAT Gateway, Azure Firewall, or Cloud NAT can still provide outbound connectivity. Therefore, a fully isolated cluster requires all of these layers to be designed and restricted separately.

Amazon EKS Private Networking

Amazon EKS integrates Kubernetes closely with Amazon VPC networking.

EKS supports both public and private Kubernetes API endpoints. When public access is disabled and private access is enabled, Kubernetes API traffic must originate from the VPC or a connected network such as VPN, Transit Gateway, Direct Connect, or a bastion environment. AWS also creates managed private DNS for the endpoint.

A private-only endpoint can be configured with eksctl:

EKS Pod Networking

EKS normally uses the AWS VPC CNI. If the subnet is 10.10.1.0/24, the node might have

10.10.1.10  IP address and Pod A: 10.10.1.21 Pod B: 10.10.1.22

Pod addresses are allocated through ENIs attached to EC2 worker nodes. Therefore, Pods are strongly integrated with the VPC address space.

This provides excellent VPC native routing, but subnet IP availability and ENI limits become important when clusters grow.

Fully Private EKS

Putting nodes in private subnets does not remove internet access if those subnets have:

0.0.0.0/0 -> NAT Gateway

For environments that require no outbound internet access, AWS supports fully private EKS architectures using VPC endpoints.

Endpoints can be

EKS -> ECR API endpoint

EKS -> ECR DKR endpoint

EKS -> S3 Gateway endpoint

EKS -> STS endpoint

EKS -> EC2 endpoint

EKS -> CloudWatch endpoint

eksctl can create fully private clusters in which workloads access required AWS services via VPC endpoints rather than the public internet.

Azure AKS Private Networking

AKS approaches networking differently, particularly when using Azure CNI Overlay.

A private AKS control plane typically looks like:

AKS Control Plane ->Private Endpoint ->VNet ->AKS Node Subnet ->Nodes->Overlay Pods

The API server can be exposed privately while the worker nodes remain inside the Azure VNet.

Azure CNI Overlay:

Consider:

VNet: 10.20.0.0/16

Node subnet: 10.20.1.0/24

Pod CIDR: 192.168.0.0/16

A node might receive: 10.20.1.4

while a Pod receives: 192.168.1.10

The Pod, therefore, does not consume an IP address from the VNet node subnet.

When overlay Pod traffic leaves the cluster, AKS translates the source to the node IP.

Pod 192.168.1.10 -> SNAT -> Node 10.20.1.4 -> Database 10.30.1.20

This is important when configuring NSGs and firewalls because the external resource can see the node address rather than the original overlay Pod address.

Creating Private AKS

Run the command to create a private AKS cluster

AKS currently supports multiple outbound architectures, including Standard Load Balancer, NAT Gateway, user-defined routing, and network-isolated options.

An enterprise deployment might therefore use:

AKS Nodes -> UDR -> Azure Firewall -> Internet

Google GKE Private Networking

GKE uses another model: VPC native networking with alias IP ranges.

A typical architecture is:

GKE Control Plane -> Private Service Connect-> VPC -> Private Nodes -> Alias IP -> Pods

Google documents Private Service Connect as the modern infrastructure used for private communication between the GKE control plane and cluster nodes.

GKE Pod Networking

Take the example below

Node subnet:10.30.0.0/20 ->Pod secondary range: 10.40.0.0/16 -> Node IP: 10.30.0.4 -> Pod IP 10.40.1.5

Unlike AKS Overlay, the Pod address is part of GCP’s VPC native networking model.

GKE assigns Pod addresses from VPC alias IP ranges, making them natively routable within the VPC.

This makes communication such as:

GKE Pod -> Compute Engine -> Cloud SQL

is straightforward from a routing perspective.

Sufficient secondary address space must be planned for cluster growth.

Creating Private GKE

Run the command to create a private GKE cluster

gcloud container clusters create gke-private \

  –region=asia-south1 \

  –enable-ip-alias \

  –enable-private-nodes \

  –enable-private-endpoint

GKE separates node isolation from control-plane isolation. Google also supports DNS based control plane access and recommends DNS based endpoints for many modern security architectures.

Private GKE nodes have no external IP addresses. If workloads require internet access, Cloud NAT can provide outbound connectivity:

GKE Private Node ->VPC ->Cloud NAT ->Internet

Without NAT, private nodes have limited internet connectivity. Private Google Access can instead provide access to Google APIs and services without requiring external node addresses.

Key Benefits

1. Private API endpoints and private worker nodes reduce direct internet exposure and minimize the attack surface.
2. Traffic can be restricted using Security Groups, NSGs, firewall rules, routes, Network Policies, VPNs, and private connectivity.
3. Workloads can access services privately via AWS VPC Endpoints/PrivateLink, Azure Private Endpoints, and GCP Private Google Access/Private Service Connect.

Conclusion

EKS, AKS, and GKE all support private Kubernetes architectures, but their networking models differ significantly. EKS depends heavily on VPC native ENI networking, AKS Overlay separates Pod addressing from the VNet, while GKE uses VPC native alias IP ranges. A secure design should evaluate the API server, worker nodes, Pod networking, egress, and private service access independently rather than treating the private cluster as a single setting.

Drop a query if you have any questions regarding EKS, AKS, or GKE, and we will get back to you quickly.