Amazon EKS — VPC Design for EKS

VPC Design for EKS

A well-designed VPC is the foundation of a reliable EKS cluster. Bad VPC design leads to IP exhaustion, connectivity issues, and security gaps that are painful to fix later.

---

Standard EKS VPC Layout

VPC: 10.0.0.0/16 (65,536 IPs)
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│  Public Subnets (for ALB, NAT GW, bastion)                  │
│  ┌─────────────────┐ ┌─────────────────┐ ┌──────────────┐  │
│  │ 10.0.0.0/20     │ │ 10.0.16.0/20    │ │ 10.0.32.0/20 │  │
│  │ AZ-a (4,096 IPs)│ │ AZ-b (4,096 IPs)│ │ AZ-c (4,096) │  │
│  │ NAT GW, ALB     │ │ NAT GW, ALB     │ │ NAT GW, ALB  │  │
│  └─────────────────┘ └─────────────────┘ └──────────────┘  │
│                                                             │
│  Private Subnets (for worker nodes and pods)                │
│  ┌─────────────────┐ ┌─────────────────┐ ┌──────────────┐  │
│  │ 10.0.128.0/18   │ │ 10.0.192.0/18   │ │ 10.1.0.0/18  │  │
│  │ AZ-a            │ │ AZ-b            │ │ AZ-c         │  │
│  │ (16,384 IPs)    │ │ (16,384 IPs)    │ │ (16,384 IPs) │  │
│  │ Nodes + Pods    │ │ Nodes + Pods    │ │ Nodes + Pods │  │
│  └─────────────────┘ └─────────────────┘ └──────────────┘  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

Why IP Addresses Matter So Much in EKS

Unlike other Kubernetes CNIs that use overlay networks, EKS VPC CNI assigns real VPC IP addresses to every pod. This means:

Example: 1 node with 10 pods
┌───────────────────────────────┐
│  Node: 10.0.128.5 (1 IP)     │
│  Pod:  10.0.128.10 (1 IP)    │
│  Pod:  10.0.128.11 (1 IP)    │
│  Pod:  10.0.128.12 (1 IP)    │
│  ...                          │
│  Pod:  10.0.128.19 (1 IP)    │
│                               │
│  Total: 11 IPs consumed       │
│  from the subnet CIDR         │
└───────────────────────────────┘

With 100 nodes and 30 pods each = 3,100 IPs. A /24 subnet (256 IPs) would be exhausted with just 8 nodes!

---

Subnet Sizing Guide

Subnet Size	Available IPs	Nodes (30 pods each)	Recommendation
/24	251	~8	Too small for most clusters
/20	4,091	~130	Good for small clusters
/19	8,187	~270	Good for medium clusters
/18	16,379	~540	Good for large clusters

Rule of thumb: Use at least /19 for private subnets. Use /20 for public subnets (they don’t run pods).

---

Required Subnet Tags

EKS and the AWS Load Balancer Controller use subnet tags to find the right subnets:

Public Subnets

kubernetes.io/role/elb = 1
kubernetes.io/cluster/<cluster-name> = shared

Private Subnets

kubernetes.io/role/internal-elb = 1
kubernetes.io/cluster/<cluster-name> = shared

---

Using an Existing VPC with eksctl

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: demo
  region: us-east-1

vpc:
  id: vpc-0abc123def456
  subnets:
    public:
      us-east-1a:
        id: subnet-0abc123
      us-east-1b:
        id: subnet-0def456
    private:
      us-east-1a:
        id: subnet-0ghi789
      us-east-1b:
        id: subnet-0jkl012

---

Common Mistakes

Mistake	Impact
/24 private subnets	IP exhaustion with VPC CNI
No NAT Gateway	Nodes can’t pull images or reach AWS APIs
Missing subnet tags	ALB/NLB can’t discover subnets
Single AZ	No high availability
Overlapping CIDRs with other VPCs	Can’t VPC peer or use Transit Gateway

---

Quick Reference

Component	Recommended CIDR
VPC	/16 (65,536 IPs)
Public subnets	/20 per AZ (4,096 IPs each)
Private subnets	/18 per AZ (16,384 IPs each)
Minimum AZs	2 (3 for production)

---

What’s Next?

Let’s understand EKS version management: Version Lifecycle.