In EKS 1.31+, AWS has moved to a new authentication method called IAM Access Entries which replaces the old aws-auth ConfigMap approach. This seems to be why you can't access your cluster.
EKS Automode - Fargate do not support GPU or FPGA instrance.
but Automode provide managed node (not self-managed node!)
Internet User requests https://app.example.com
│
▼ DNS Resolution (Route53)
[1] Resolves to single Multi-AZ ALB (Alias A-record)
│
▼ Traffic enters VPC through Internet Gateway (IGW)
[2] Single Multi-AZ ALB distributes traffic across AZs:
│
├─ ALB Interface (AZ-a, 10.0.1.x)
├─ ALB Interface (AZ-b, 10.0.2.x)
├─ ALB Interface (AZ-c, 10.0.3.x)
└─ ALB Interface (AZ-d, 10.0.4.x)
│
▼ ALB forwards internally within VPC (targets healthy nodes)
[3] Private Subnet (EKS worker nodes receive traffic):
│
├─ EKS Nodes-a (10.0.10.x)
├─ EKS Nodes-b (10.0.11.x)
├─ EKS Nodes-c (10.0.12.x)
└─ EKS Nodes-d (10.0.13.x)
│
▼ Kubernetes Networking (CNI & kube-proxy)
[4] Kubernetes Service routes to target Pods
│
▼
[5] Pods process request and generate response
│
▼ Response sent back (same route reversed)
Pods → Nodes → Single ALB → IGW → Internet User
EKS Engress Traffic flow
Private Subnet Pods (e.g., 10.0.10.x in AZ-a)
│
▼ Outbound traffic initiated
Private Subnet Route Table
│ (points to NAT gateway in public subnet AZ-a)
▼
Public Subnet (10.0.1.x in AZ-a)
│
▼ NAT Gateway (with associated Elastic IP)
Public Subnet NAT Gateway (EIP-a)
│
▼
Internet Gateway (IGW)
│
▼
External Internet Service (e.g., Amazon ECR, Docker Hub)
why do we need EIP, NAT gateway for each AZ for EKS?
Deploying a NAT Gateway in each Availability Zone (AZ) ensures that private subnet traffic doesn't cross AZ boundaries when accessing the internet, reducing cross-AZ data transfer costs. If a NAT Gateway serves private subnets in other AZs, traffic crosses AZ boundaries, incurring additional network charges. Therefore, deploying NAT Gateways per AZ minimizes cross-AZ traffic and associated costs.
Detailed Explanation
When you deploy Kubernetes (EKS) nodes in private subnets, outbound internet access is achieved through NAT gateways. The AWS best practice is deploying one NAT Gateway per Availability Zone (AZ). The main reason behind this recommendation is to minimize inter-AZ (cross-AZ) data transfer costs.
Here's the exact reason, step by step:
✅ Scenario 1: NAT Gateway per AZ (Recommended)
If each Availability Zone has its own NAT Gateway, the traffic pattern is:
vbnetCopyEditAZ-a Pod → AZ-a Private Subnet → AZ-a NAT Gateway (Public Subnet) → Internet
AZ-b Pod → AZ-b Private Subnet → AZ-b NAT Gateway (Public Subnet) → Internet
AZ-c Pod → AZ-c Private Subnet → AZ-c NAT Gateway (Public Subnet) → Internet
AZ-d Pod → AZ-d Private Subnet → AZ-d NAT Gateway (Public Subnet) → Internet
🔹 Cost Implication:
NO Cross-AZ Traffic.
Outbound traffic stays within the same Availability Zone, avoiding cross-AZ data transfer charges.
What Happens if NAT Gateways are Shared (Fewer NAT Gateways)?
If you share NAT Gateways across Availability Zones, the traffic may flow as follows:
Example scenario (shared NAT Gateway):
cssCopyEditAZ-b Pod → AZ-b Private Subnet → (Cross AZ boundary!) → AZ-a NAT Gateway → Internet
AZ-c Pod → AZ-c Private Subnet → AZ-a NAT Gateway (cross-AZ) → Internet
AZ-d Pod → AZ-d Private Subnet → AZ-a NAT Gateway (Public Subnet in AZ-a) → Internet
This introduces additional costs because:
AWS charges for cross-AZ network traffic within the same region if traffic traverses multiple Availability Zones.
Your NAT Gateway traffic crossing AZ boundaries directly results in higher monthly AWS bills, especially noticeable at large scale or significant network activity.
AWS Cross-AZ Cost Example:
Within Same AZ (No Extra Cost):
cssCopyEditAZ-a Pod (private subnet) → NAT Gateway AZ-a (same AZ) → No cross-AZ charges
Cross-AZ Example (Extra Cost):
cssCopyEditAZ-b Pod → AZ-a NAT Gateway (crossing from AZ-b to AZ-a)
└─ incurs cross-AZ data charges
As per AWS pricing:
Cross-AZ traffic typically costs ~$0.01 per GB transferred. Small for minor traffic, substantial for large-scale or data-intensive workloads.
Recommended Architecture by AWS (Why One NAT Gateway per AZ?):
AWS clearly states deploying NAT gateways per AZ:
Deployment Method
Cross-AZ Traffic
Cost Efficiency
Availability
NAT Gateway per AZ (recommended)
🚫 No Cross-AZ charges
✅ Cost-effective at scale
✅ High availability
Shared NAT Gateway
⚠️ Cross-AZ traffic charges
🟡 Increased cost at scale
🟡 Lower AZ independence
Thus, AWS explicitly recommends placing one NAT Gateway per Availability Zone in its official documentation for cost-efficiency and redundancy.
Key Reasons for AWS Best-Practice Setup (NAT Gateway per AZ):
Cost Savings: Reduces cross-AZ data transfer charges, which can scale significantly at high volume.
Performance and Latency: Reduces unnecessary cross-AZ latency.
Availability: AZ-specific NAT Gateways eliminate single points of failure; if one AZ fails, others remain unaffected.
Conclusion
Deploying NAT gateways in every Availability Zone is AWS's recommended strategy for managing network traffic in EKS clusters. It optimizes cost, enhances availability, and ensures efficient networking within your Kubernetes environment.
