Introducing the Amazon EKS Hybrid Nodes Gateway for Hybrid Kubernetes Networking

A new feature that automates networking between your EKS cluster VPC and on-premises pods in EKS Hybrid Nodes environments — this post covers how it works, how to deploy it with Helm, and the key constraints to check before you do.

haruki

Published May 9, 2026

Last modified May 9, 2026

Introduction

On April 21, 2026, AWS announced the general availability (GA) of the Amazon EKS Hybrid Nodes gateway, a new feature for hybrid Kubernetes environments using Amazon EKS Hybrid Nodes.

The gateway automates networking between your EKS cluster VPC and Kubernetes pods running on EKS Hybrid Nodes. It is available at no additional charge and is open source.

This post covers what changed, how to deploy the gateway, and what to consider before you do. If you run EKS Hybrid Nodes today and find yourself wrestling with on-premises network configuration, this is worth a read.

EKS Hybrid Nodes: A Quick Recap

EKS Hybrid Nodes became generally available at AWS re:Invent 2024 in December 2024. It lets you register on-premises or edge servers as nodes in an EKS cluster, so you can manage on-premises workloads using the same EKS tooling you already use in the cloud.

Before EKS Hybrid Nodes, running Kubernetes on-premises meant owning the full control plane — building it, patching it, upgrading it. With EKS Hybrid Nodes, AWS manages the control plane while your workloads stay on-premises. That matters for teams with low-latency requirements, data residency obligations, or regulatory constraints that make a full cloud migration impractical.

The EKS Hybrid Nodes gateway addresses the networking challenges that arise once you have hybrid nodes up and running.

What Changed

Even after connecting on-premises nodes to an EKS cluster, managing the network between the VPC and on-premises pods was still a manual job. The EKS Hybrid Nodes gateway automates it. Here is the before-and-after picture:

Area	Before	After
Pod CIDR routing	Manually added to on-premises routers	Managed automatically
VPC route table updates	Manual updates on every scale event	Automatically updated as workloads scale
Control plane to webhook traffic	Required separate network configuration	Enabled automatically
ALB / NLB / Prometheus connectivity	Configured individually	Connectivity ensured automatically
Coordination with networking teams	Required on every change	Minimized

The manual burden

With EKS Hybrid Nodes in place, you still had to handle these tasks manually:

Register pod CIDRs in on-premises routers
Update VPC route tables every time workloads scaled
Coordinate with networking teams to route control plane traffic to webhooks
Set up connectivity to ALB, NLB, and Amazon Managed Service for Prometheus individually

These were not one-time tasks. Every configuration change brought them back.

What the gateway automates

Deploy the gateway to EC2 instances using Helm and the following four traffic flows are handled for you.

1. Control plane to webhook communication

The Kubernetes API server can now reach webhook endpoints running on hybrid nodes. This matters if you run policy engines like OPA/Gatekeeper on-premises — without the gateway, those webhooks are unreachable from the control plane unless pod CIDRs are made routable in the on-premises environment.

2. Pod-to-pod traffic across cloud and on-premises

Pods on EC2 nodes in the VPC can communicate directly with pods on hybrid nodes, and vice versa. A frontend running in the cloud and a backend running on-premises can now live in the same cluster without extra network plumbing.

3. AWS service connectivity to hybrid pods

Application Load Balancers, Network Load Balancers, and Amazon Managed Service for Prometheus can reach pods on hybrid nodes. Load balancing and metrics collection work across the hybrid boundary without additional configuration.

4. Automatic VPC route table management

VPC route tables are updated automatically as workloads scale. No manual intervention is needed when pods are added or removed.

How the Gateway Works

Here is a high-level view of the architecture:

Gateway deployment

Two gateway pods run as a Deployment on labeled EC2 nodes, with pod anti-affinity ensuring they land on separate nodes. Kubernetes Lease-based leader election determines which pod is active. The active pod handles VPC route table updates and Cilium VTEP configuration. The standby continuously watches the VXLAN interface and CiliumNode objects, so failover completes in approximately 3–5 seconds.

VXLAN tunneling

The active pod creates a VXLAN interface (hybrid_vxlan0) with VNI 2 on UDP port 8472 (the Cilium default). It establishes a tunnel to each hybrid node by programming FDB entries, ARP entries, and routes on the interface. A node controller watches CiliumNode objects and adds or removes tunnels automatically as hybrid nodes join or leave the cluster. VPC route table entries pointing each hybrid pod CIDR to the active pod's primary ENI are maintained automatically.

Cilium VTEP integration

The gateway creates a CiliumVTEPConfig custom resource that tells Cilium agents on hybrid nodes where to send VPC-bound traffic. When a pod on a hybrid node sends traffic to a VPC address, Cilium encapsulates it in a VXLAN packet and forwards it to the gateway.

This architecture explains two key constraints covered in the next section: VXLAN tunnels carry no encryption, and Cilium CNI with VTEP support is the only supported CNI.

Deployment

Prerequisites

Before installing the gateway, confirm the following:

Hybrid nodes use the EKS version of Cilium CNI with VTEP support enabled
Gateway nodes and other cloud nodes use the AWS VPC CNI
A private connection exists between your VPC and on-premises environment (AWS Direct Connect, AWS Site-to-Site VPN, or your own VPN)
Security groups on gateway EC2 instances and on-premises firewall rules allow UDP port 8472 inbound and outbound
The gateway has IAM permissions to manage VPC route tables (EKS Pod Identity is recommended):
- ec2:DescribeRouteTables
- ec2:CreateRoute
- ec2:ReplaceRoute
- ec2:DescribeInstances

Prepare gateway nodes

The gateway requires at least two nodes for high availability. Two provisioning options are supported.

EKS Auto Mode (recommended)

Create a NodePool and NodeClass to provision nodes automatically with the correct labels, taints, and source/destination check configuration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: hybrid-gateway
spec:
  advancedNetworking:
    sourceDestCheck: DisabledPrimaryENI   # Required for traffic forwarding
  role: YOUR_NODE_ROLE
  securityGroupSelectorTerms:
    - tags:
        aws:eks:cluster-name: YOUR_CLUSTER_NAME
  subnetSelectorTerms:
    - id: SUBNET_ID_1   # Use subnets in different AZs for redundancy
    - id: SUBNET_ID_2
---
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: hybrid-gateway
spec:
  template:
    metadata:
      labels:
        hybrid-gateway-node: "true"
    spec:
      nodeClassRef:
        group: eks.amazonaws.com
        kind: NodeClass
        name: hybrid-gateway
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["on-demand"]
        - key: eks.amazonaws.com/instance-category
          operator: In
          values: ["c", "m", "r"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
        - key: kubernetes.io/os
          operator: In
          values: ["linux"]
      taints:
        - key: hybrid-gateway-node
          effect: NoSchedule

Managed node groups

If you are not using EKS Auto Mode, create a managed node group with a custom launch template that disables the source/destination check at boot:

1
2
3
4
5
6
7
8
9
10
aws eks create-nodegroup \
  --cluster-name YOUR_CLUSTER_NAME \
  --nodegroup-name YOUR_CLUSTER_NAME-gateway-nodes \
  --subnets SUBNET_ID_1 SUBNET_ID_2 \
  --node-role YOUR_NODE_ROLE_ARN \
  --instance-types INSTANCE_TYPE \
  --scaling-config desiredSize=2,maxSize=2,minSize=2 \
  --labels hybrid-gateway-node=true \
  --taints "key=hybrid-gateway-node,effect=NO_SCHEDULE" \
  --launch-template "name=YOUR_CLUSTER_NAME-gateway-lt,version=1"

For launch template creation steps, see the official documentation .

Install with Helm

EKS Auto Mode

1
2
3
4
5
6
7
8
helm install eks-hybrid-nodes-gateway \
  oci://public.ecr.aws/eks/eks-hybrid-nodes-gateway \
  --version 1.0.0 \
  --namespace eks-hybrid-nodes-gateway \
  --create-namespace \
  --set vpcCIDR=VPC_CIDR \
  --set podCIDRs=POD_CIDRS \
  --set routeTableIDs=ROUTE_TABLE_IDS

Managed node groups

Add autoMode.enabled=false; all other parameters are the same:

1
2
3
4
5
6
7
8
9
helm install eks-hybrid-nodes-gateway \
  oci://public.ecr.aws/eks/eks-hybrid-nodes-gateway \
  --version 1.0.0 \
  --namespace eks-hybrid-nodes-gateway \
  --create-namespace \
  --set autoMode.enabled=false \
  --set vpcCIDR=VPC_CIDR \
  --set podCIDRs=POD_CIDRS \
  --set routeTableIDs=ROUTE_TABLE_IDS

The --version value above reflects the version at the time of writing. Check the ECR Public Gallery for the latest version.

Required Helm values

Value	Description
vpcCIDR	CIDR block of your EKS cluster VPC (e.g., 10.0.0.0/16)
podCIDRs	Comma-separated pod CIDRs used by Cilium on hybrid nodes (e.g., 10.100.0.0/16,10.101.0.0/16)
routeTableIDs	Comma-separated VPC route table IDs to program (e.g., rtb-0abc1234,rtb-0def5678)

Verify the installation

Check pod status — Confirm two pods are running:

1
kubectl get pods -n eks-hybrid-nodes-gateway

Check leader election — Confirm a leader has been elected:

1
kubectl get lease -n eks-hybrid-nodes-gateway

The current leader appears in the HOLDER column.

Health check — Confirm the leader pod is healthy:

1
2
kubectl port-forward -n eks-hybrid-nodes-gateway LEADER_POD_NAME 8088:8088 &
curl -s http://localhost:8088/healthz

An HTTP 200 response means the gateway is running normally.

Before You Deploy: Considerations and Best Practices

Constraints

No traffic encryption The VXLAN tunnels created by the gateway do not encrypt traffic. As covered in "How the Gateway Works," VXLAN handles tunneling, not encryption. If you need encryption in transit, use AWS Direct Connect with MACsec or a VPN connection.

One gateway per cluster Each gateway deployment serves a single EKS cluster. If you run multiple clusters with hybrid nodes, deploy a separate gateway for each one.

Cilium CNI with VTEP support is required The gateway requires the EKS version of the Cilium CNI with VTEP support enabled on hybrid nodes. Other CNI plugins are not supported. If your environment uses a different CNI today, migrating to Cilium is a prerequisite.

Best practices

Spread nodes across Availability Zones At least two gateway nodes are recommended for high availability. Place each node in a subnet in a different Availability Zone so an AZ failure does not affect both pods. This is why the NodePool and managed node group examples in "Deployment" both reference subnets from separate AZs.

Size instances for your expected throughput The gateway handles all traffic between the VPC and on-premises, so the instance's network bandwidth becomes the throughput ceiling. Estimate your expected traffic volume before selecting an instance type. The sample NodePool configuration uses general purpose, compute optimized, and memory optimized families (c, m, r) from the 5th generation and later.

Cost

The gateway itself carries no additional charge. The costs you will incur are:

Item	Notes
EC2 instance charges	For the nodes running the gateway
Data transfer fees	For traffic between the VPC and on-premises
EKS Auto Mode management fees	Only when using EKS Auto Mode

See the Amazon EKS pricing page for details.

Closing Thoughts

To me, the biggest win here is cutting the coordination overhead with networking teams. Getting EKS Hybrid Nodes running is one thing; getting the pod network routable afterward is where things tend to stall. The gateway addresses that directly.

That said, two constraints are worth flagging before you commit: Cilium CNI with VTEP support is required, and VXLAN tunnels carry no encryption. If your environment uses a different CNI today, or if your security requirements demand in-transit encryption, factor that work into your plan. Review "Before You Deploy" before going further.

For teams already running EKS Hybrid Nodes, a staging environment deployment is a reasonable first step. No additional charge and an open-source codebase mean there is little reason not to try it.

References

# amazon-eks # kubernetes # network

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Introducing the Amazon EKS Hybrid Nodes Gateway for Hybrid Kubernetes Networking

haruki

Introduction

EKS Hybrid Nodes: A Quick Recap

What Changed

The manual burden

What the gateway automates

1. Control plane to webhook communication

2. Pod-to-pod traffic across cloud and on-premises

3. AWS service connectivity to hybrid pods

4. Automatic VPC route table management

How the Gateway Works

Gateway deployment

VXLAN tunneling

Cilium VTEP integration

Deployment

Prerequisites

Prepare gateway nodes

EKS Auto Mode (recommended)

Managed node groups

Install with Helm

EKS Auto Mode

Managed node groups

Required Helm values

Verify the installation

Before You Deploy: Considerations and Best Practices

Constraints

Best practices

Cost

Closing Thoughts

References