The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →EKS networking starts with the VPC: its subnets provide the address space and routes that nodes and Pods use, while the Amazon VPC CNI connects Pods to that network. Separately, the Kubernetes API endpoint serves control-plane access, and Services or Ingress resources provide paths to applications. Understanding those separate paths makes it easier to plan IP capacity, choose traffic controls, and expose workloads safely.
What does the VPC provide to an EKS cluster?
An Amazon EKS cluster runs in a VPC. AWS requires at least two subnets in different Availability Zones for cluster creation, and the VPC must have enough IP addresses for the cluster, its nodes, and other Kubernetes resources. Those are baseline requirements, not a guarantee that a subnet has enough free addresses for a particular workload scale.
As an Amazon Associate I earn from qualifying purchases.
Subnets, route tables, security groups, network ACLs, and egress paths determine which AWS services, external endpoints, and other networks nodes and Pods can reach. Plan the routes and controls around the actual destinations your workloads need. If the cluster VPC will connect to other VPCs, avoid overlapping address ranges; overlap can make routing ambiguous or prevent connectivity.
Free tools Windows power users keep installed
One-click scans. No signup required.
Address capacity is a scaling constraint as well as a cluster-creation concern. Nodes and Pods consume addresses from the network, so estimate growth before choosing subnet sizes. AWS’s EKS networking requirements and networking overview explain the VPC and subnet prerequisites.
#1 Best Overall
How do Pods get IP addresses in EKS?
On EC2 nodes, the Amazon VPC CNI runs as an add-on on each node. It creates and attaches network interfaces and assigns private VPC addresses to Pods. In the standard AWS underlay model, a Pod’s address is part of the VPC network, rather than an address that exists only inside a separate overlay.
This model makes Pod networking visible to VPC routing and security controls, but it also means Pod scale has an IP-capacity dimension. A cluster can have room for more Kubernetes objects and still run short of usable VPC addresses. AWS describes the VPC CNI as the default EKS-supported networking plugin for this model.
Address-capacity options
- Plan larger or additional subnets: reserve sufficient VPC address space for nodes, Pods, and other resources before deployment.
- Prefix delegation: can increase the number of addresses available to a node, but it is a configuration choice with compatibility and operational considerations, not an automatic remedy for every subnet constraint.
- Custom networking and subnet selection: can direct Pod addresses to selected subnets, which can help with address planning but adds configuration decisions.
- IPv6: changes the address-family design and has platform and feature constraints; it should be evaluated before cluster creation.
These choices depend on the VPC CNI configuration and version. EKS Auto Mode includes Pod networking capabilities, changing which networking functions AWS manages compared with a cluster where you configure the VPC CNI add-on directly. Check the current AWS VPC CNI configuration guidance and your cluster’s add-on setup before adopting a particular mode.
Recommended Free Tools
Should an EKS cluster use IPv4 or IPv6?
EKS uses IPv4 for Pods and Services by default. The cluster IP family is selected when the cluster is created and cannot later be changed for that cluster. A change of family therefore requires creating another cluster and moving workloads; it is not an in-place setting change.
EKS does not support dual-stacked Pods or Services. AWS documents IPv6 cluster networking with additional constraints, including no Windows support and a requirement for Nitro-based EC2 nodes or Fargate. Validate the current requirements for the exact node type and services in use before choosing IPv6. AWS has also introduced dual-stack EKS API endpoint capabilities at different times; endpoint address behavior should not be confused with dual-stack Pod or Service support.
- Choose IPv4 if your existing address plan and workload compatibility favor it, while sizing VPC and subnet capacity for expected growth.
- Consider IPv6 when its address model fits your environment and every required node platform and integration is compatible.
- Treat the address-family choice as a cluster-lifecycle decision because changing it means migrating workloads to a new cluster.
How is Kubernetes API access different from application traffic?
The Kubernetes API server endpoint is the control-plane path used by administrative clients and cluster components to communicate with the EKS control plane. It is not the address or load balancer through which users reach an application running in a Pod.
EKS endpoint access can be public, private, or configured to use both paths. With private access enabled, EKS creates a Route 53 private hosted zone and associates it with the cluster VPC. DNS resolution and the cluster security-group rules are part of reaching that private endpoint. Choose endpoint access based on where cluster clients run and how they are permitted to reach the VPC.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Application traffic follows a separate path, commonly through a Kubernetes Service or Ingress and an AWS load balancer. Changing API endpoint access does not expose an application, and creating an application load balancer does not grant a client access to the Kubernetes API.
Which controls govern traffic inside and around the cluster?
Different controls operate at different scopes. Kubernetes NetworkPolicy governs Pod traffic at IP and port level and is namespace-scoped. Security groups for Pods apply AWS security-group controls to selected Pod traffic, including access to AWS services. Node security groups and VPC routing controls operate at the network-interface and VPC level. They complement rather than replace one another.
| Control | Primary scope | What to verify |
|---|---|---|
| Kubernetes NetworkPolicy | Pod traffic, using IP and port rules within namespace-oriented policy boundaries | AWS documents VPC CNI support for standard and admin network policies from VPC CNI version 1.21.0. The documented policy support applies to Amazon EC2 Linux nodes, not Fargate or Windows nodes. |
| Security groups for Pods | AWS security-group rules for selected Pods, useful for controlling access to AWS resources | Confirm the required VPC CNI mode, add-on version, and traffic-path configuration for the specific use case. |
| Node security groups and VPC controls | Traffic at the node or VPC boundary, including routed and egress traffic | Check security-group rules, route tables, network ACLs, and destination requirements together. |
A NetworkPolicy is not a substitute for a security group when the goal is AWS-resource access, and a security group is not a namespace-level policy language. Before relying on either, confirm that the node platform and deployed CNI version support the feature and that the relevant traffic actually traverses the control.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.How does traffic reach an EKS workload from outside?
For AWS load balancing, the main decision is whether the workload needs Layer 4 TCP or UDP forwarding, or Layer 7 HTTP application routing. A Kubernetes Service of type LoadBalancer can provision a Network Load Balancer (NLB). An Ingress can provision an Application Load Balancer (ALB) for HTTP-oriented routing through the AWS Load Balancer Controller.
| Option | Layer and traffic | Typical target choices | Workload fit |
|---|---|---|---|
| Network Load Balancer | Layer 4; TCP or UDP | Instance targets send traffic to nodes; IP targets send it to Pod IPs where supported. | Use for transport-level forwarding when HTTP path- or host-based routing is not the requirement. |
| Application Load Balancer | Layer 7; application routing through Ingress | Target mode and placement support depend on the controller and cluster networking configuration. | Use when HTTP application routing is needed. |
With the VPC CNI, AWS documents support for EC2 IP or instance targets and Fargate IP targets through the AWS Load Balancer Controller. Target support differs with alternate CNI configurations. For IPv6 Pods, AWS documents load balancing with IP targets rather than instance targets. Check current controller and CNI compatibility before selecting target mode.
Best Value
Decide how the load balancer should be reached
Choose whether the load balancer should be internal to the VPC or internet-facing, then select the appropriate subnets and routing. The required exposure is a separate decision from protocol and target type: an NLB can provide TCP or UDP forwarding without being public, while HTTP routing does not by itself determine whether an ALB is internal or internet-facing.
AWS recommends the AWS Load Balancer Controller for new NLBs. Replacing existing controller-managed load balancers can create multiple NLBs and may cause downtime, so treat a controller change as a migration rather than a harmless toggle.
What should be decided before creating the cluster?
- Map the VPC and subnets. Confirm at least two subnets in different Availability Zones, enough free address capacity, non-overlapping ranges for connected VPCs, and routes for required destinations.
- Select the address family. Decide IPv4 or IPv6 based on node platforms, workload compatibility, connectivity needs, and migration cost; the choice cannot be changed on the same cluster.
- Plan Pod address allocation. Estimate node and Pod growth and decide whether standard CNI allocation, prefix delegation, or custom networking fits the available subnet space.
- Set the API endpoint access model. Decide whether cluster clients need public access, private access from the VPC, or both, and configure DNS and security-group reachability accordingly.
- Choose traffic controls by purpose. Use NetworkPolicy for supported Pod-level segmentation and security groups or VPC controls for AWS and network-boundary access.
- Choose workload exposure. Determine internal versus internet-facing reachability, L4 versus HTTP routing, target type, and whether workloads run on EC2 or Fargate.
- Check managed component versions and ownership. Verify the VPC CNI and AWS Load Balancer Controller versions and configuration. In Auto Mode, account for the networking and load-balancing capabilities AWS manages.
For detailed implementation requirements, consult AWS documentation for EKS VPC and subnet requirements, VPC CNI configuration and modes, API server endpoint access, IPv6 networking, Kubernetes network policies, and NLB routing. The exact supported options can vary with cluster configuration and add-on versions.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
