DEV Community

Amira Abidi
Amira Abidi

Posted on

AWS EKS Networking: Understanding What Happens Behind the Cluster

#kubernetes #aws #devops #cloud

When I started working with Amazon EKS, I initially focused on the Kubernetes layer:

  • Pods
  • Deployments
  • Services
  • Ingress
  • HPA

But running Kubernetes on AWS quickly raises another question:

What actually happens at the network level?

How does a pod communicate with another pod?
How does Internet traffic reach the application?
How does a pod connect to Amazon RDS?

While building my LibraryCorner platform, I spent time understanding how Kubernetes networking interacts with AWS networking.

Here are the main concepts I found important.

1. EKS runs inside an AWS VPC

The first thing to understand is that an EKS cluster is connected to an AWS VPC.

The VPC provides the underlying network for the cluster and its AWS resources.

A simplified architecture looks like this:

                    Internet
                       │
                       ▼
               AWS Load Balancer
                       │
                       ▼
                Kubernetes Service
                       │
                       ▼
                      Pods
                       │
              ┌────────┴────────┐
              ▼                 ▼
             EKS               RDS
           workloads         PostgreSQL
Enter fullscreen mode Exit fullscreen mode

This means that understanding EKS also requires understanding basic AWS networking.

2. Public and private subnets

A common architecture separates public-facing resources from private workloads.

Internet
   │
   ▼
Public subnet
   │
   ▼
Load Balancer
   │
   ▼
Private subnet
   │
   ▼
EKS workloads
Enter fullscreen mode Exit fullscreen mode

The application workloads don't need to be directly exposed to the Internet.

This separation reduces the attack surface and makes the architecture easier to control.

3. What does the NAT Gateway do?

Private workloads may still need outbound Internet access.

For example, a pod may need to reach an external API or download something.

A NAT Gateway provides this outbound path:

Private subnet
      │
      ▼
NAT Gateway
      │
      ▼
Internet Gateway
      │
      ▼
Internet
Enter fullscreen mode Exit fullscreen mode

The important distinction is:

NAT Gateway enables outbound connectivity. It does not make the private workload directly reachable from the Internet.

4. How do Pods get network connectivity?

With the Amazon VPC CNI, Kubernetes pods can receive IP addresses from the VPC network.

Conceptually:

VPC
 │
 ├── EKS Node
 │     ├── Pod → IP
 │     ├── Pod → IP
 │     └── Pod → IP
 │
 └── RDS → IP
Enter fullscreen mode Exit fullscreen mode

This creates a strong relationship between Kubernetes and the AWS network.

It also means that IP address availability matters when scaling an EKS cluster.

More pods can mean more demand for available IP addresses and subnet capacity.

5. How does Internet traffic reach a Pod?

Pods are ephemeral, so we don't want clients connecting directly to individual pod IPs.

Instead, Kubernetes and AWS provide abstractions for routing traffic.

A simplified request path is:

User
 │
 ▼
AWS Load Balancer
 │
 ▼
Kubernetes Service
 │
 ▼
Pod
 │
 ▼
Application
Enter fullscreen mode Exit fullscreen mode

The Load Balancer provides an external entry point, while the Kubernetes Service provides a stable way to reach a group of pods.

If a pod is recreated, the Service can continue routing traffic to the available pods.

6. EKS and RDS

LibraryCorner uses Amazon RDS for PostgreSQL.

The application communicates with the database through the VPC:

EKS Pod
   │
   │ PostgreSQL
   ▼
Amazon RDS
Enter fullscreen mode Exit fullscreen mode

The database does not need to be publicly accessible.

Security rules can restrict database access so that only the required application traffic is allowed.

For example:

Allowed:
EKS → RDS : 5432

Not allowed:
Internet → RDS : 5432
Enter fullscreen mode Exit fullscreen mode

This is a simple but important security principle:

Only expose what needs to be exposed.

7. Multi-AZ and networking

For the production-oriented architecture of LibraryCorner, I used multiple Availability Zones.

              AWS Region
                  │
        ┌─────────┴─────────┐
        │                   │
       AZ-A                AZ-B
        │                   │
    EKS nodes           EKS nodes
        │                   │
        └─────────┬─────────┘
                  │
                 RDS
Enter fullscreen mode Exit fullscreen mode

Multi-AZ architecture requires thinking about subnet placement, routing, IP capacity and resource availability across zones.

Networking is therefore part of the architecture, not just a configuration detail.

8. The lesson I took from this

Before working on EKS networking, I tended to think about Kubernetes mainly in terms of:

Pods
Services
Deployments
Ingress
Enter fullscreen mode Exit fullscreen mode

Now I see a larger picture:

AWS VPC
   │
   ├── Subnets
   ├── Routes
   ├── Security Groups
   ├── NAT
   │
   └── EKS
        │
        ├── Nodes
        ├── Pods
        └── Services
Enter fullscreen mode Exit fullscreen mode

Kubernetes networking on AWS cannot really be understood independently from AWS networking.

That was one of the most useful lessons from building my EKS platform.

Conclusion

Building an EKS platform is not only about deploying containers.

You also need to understand the network underneath them:

  • VPCs
  • Subnets
  • Route tables
  • NAT Gateways
  • Security Groups
  • Load Balancers
  • Kubernetes Services
  • Pod networking
  • Availability Zones
  • RDS connectivity

For me, understanding these layers was another step from "I can deploy an application" toward "I understand the infrastructure that makes the application work."

This article is part of my LibraryCorner Cloud/DevOps project, where I progressively build and document a containerized application platform on AWS.

Top comments (0)