Amazon EKS Now Supports Customer-Routed Control Plane Egress
A deep dive into customer-routed control plane egress for Amazon EKS—a new feature that lets you route control plane egress traffic, including admission webhook callbacks and OIDC provider lookups, through your own VPC instead of the AWS-managed network path. This article walks through how it works under the hood, what to check before you enable it, and where it makes a practical difference.
Introduction
On June 18, 2026, AWS announced customer-routed control plane egress for Amazon EKS. This feature lets you route control plane egress traffic through your own VPC, giving you full control over the network path.
If you operate EKS clusters, you may have run into a familiar problem: the control plane couldn't reach an OIDC provider that only exists on your internal network, or an admission webhook server sitting in a private subnet. This update addresses that gap directly.
This article covers what changed, which organizations benefit most from this feature, how the underlying architecture works, and how to enable it. It's written for infrastructure and platform engineers running EKS, as well as anyone evaluating security or compliance requirements.
What Changed
Many EKS users have probably never given much thought to the control plane's outbound traffic. In fact, calls to admission webhooks and lookups against OIDC providers have always traveled through a network path managed by AWS, not through your own VPC.
| Item | AWS_MANAGED (previous) | CUSTOMER_ROUTED (new) |
|---|---|---|
| Who manages the egress path | AWS | You |
| Reaching private OIDC providers or webhook servers | Required workarounds such as exposing a public endpoint | Reachable directly through your VPC routing |
| Control over route tables and security groups | Not available to you | Fully configurable by you |
Previous Limitations
For organizations with strict data perimeter or compliance requirements—financial services, healthcare, and government agencies, for example—having control plane egress traffic flow through a network path outside their own management was a recurring audit and governance concern. And if you wanted the control plane to reach an internal identity provider or webhook server that lives only inside your VPC, there was simply no path to it; the only workaround was to expose the endpoint publicly.
How customer-routed control plane egress Solves This
Setting
controlPlaneEgressMode to CUSTOMER_ROUTED routes the following three types of traffic through your VPC:| Traffic type | Description |
|---|---|
| Admission webhook callbacks | Calls to MutatingAdmissionWebhook and ValidatingAdmissionWebhook |
| OIDC provider lookups | Requests to the OIDC discovery endpoint |
| Aggregated API server requests | Requests forwarded to an aggregated API server |
You now control everything along that path: the route table, the security groups, and which egress device—a NAT gateway, a Transit Gateway, or otherwise—the traffic flows through. Note that communication between the control plane and worker nodes (the kubelet API on port 10250) is outside the scope of this feature and continues to use the cluster ENI as before. What's affected is specifically outbound traffic to external endpoints.
This feature is available at no additional cost, in every AWS Region where Amazon EKS is available.
Which Organizations Need This Feature
customer-routed control plane egress isn't something every EKS user needs—it delivers the most value to organizations with specific requirements. Before you consider adopting it, it helps to check whether your situation actually fits.
This feature is most useful for organizations with data perimeter or compliance requirements—financial services, healthcare, and government, for example—or those whose internal identity provider or admission webhook server only exists inside their VPC and can't be exposed externally, or those who want to audit and observe control plane egress traffic through VPC Flow Logs. On the other hand, for general workloads without regulatory requirements, or environments where the OIDC provider and webhooks in use are already publicly reachable, there's little benefit to adopting it.
Switching to CUSTOMER_ROUTED mode also shifts responsibility for maintaining control plane connectivity to you, and it's a change you can't undo. The next section covers these considerations in detail.
Architecture Overview
Let's take a closer look at what customer-routed control plane egress actually changes under the hood.
The key point is that this feature doesn't create any new network interfaces. EKS already creates cross-account network interfaces (ENIs) in your VPC subnets for control plane-to-node communication. CUSTOMER_ROUTED mode simply changes how those existing interfaces are used: outbound traffic from the Kubernetes API server now flows through that ENI into your VPC's route table, and from there through an egress device—a NAT gateway, a Transit Gateway, or a firewall appliance—to reach the external endpoint.
It's also worth noting that name resolution, not just routing, follows your VPC's DNS configuration. Your VPC's DHCP options set must include
AmazonProvidedDNS, which lets the control plane resolve names in Route 53 private hosted zones and reach on-premises DNS forwarded through Route 53 Resolver endpoints. At the same time, if your webhook or OIDC provider uses a public DNS name, the resolver also needs to handle public DNS resolution.If you're running an IPv6 cluster, you need separate egress paths for IPv4 and IPv6. The control plane ENIs are assigned both IPv4 and IPv6 addresses, so you'll need a default route (0.0.0.0/0) to an egress device such as a NAT gateway for IPv4, and a default route (::/0) to an IPv6 egress device such as an egress-only internet gateway for IPv6.
What to Check Before You Migrate
Now that we've covered the architecture, let's walk through what you need to confirm before actually switching to CUSTOMER_ROUTED. The most important point by far is that this switch is a one-way operation.
It's a One-Way Operation
Switching to CUSTOMER_ROUTED mode is a one-way operation. Once you enable it, you can't revert to AWS_MANAGED—this applies whether you set it at cluster creation or change it later with the
update-cluster-config command on an existing cluster. We strongly recommend validating thoroughly in a test environment before applying this to a production cluster.Network Connectivity Is Your Responsibility
In CUSTOMER_ROUTED mode, you're responsible for ensuring the control plane can reach the endpoints it needs. A missing egress path, overly restrictive network ACLs, or incorrect security group rules can cause control plane operations themselves—admission webhook calls and OIDC authentication, for example—to fail. Before switching, confirm the following:
| Check | What to verify |
|---|---|
| Egress path | Does the default route to your webhook server or OIDC provider (0.0.0.0/0 for IPv4, ::/0 for IPv6) point to an egress device such as a NAT gateway? |
| Security groups | Does the cross-account ENI allow outbound traffic on the ports it needs (typically port 443)? |
| Network ACLs | Do they allow outbound traffic, plus the inbound ephemeral port range (1024–65535) for return traffic? |
| DNS resolution | Does your VPC's DHCP options set include AmazonProvidedDNS, and can it resolve public DNS names if needed? |
What's Outside the Scope of This Feature
Switching to CUSTOMER_ROUTED doesn't route every piece of control-plane-related traffic through your VPC. The kubelet API traffic remains out of scope, as noted earlier, and EKS Capabilities such as ArgoCD, ACK, and KRO run on separate AWS-managed infrastructure—traffic from those controllers isn't routed through your VPC by this feature either. And since the control plane architecture is identical on Standard and Auto Mode clusters, this feature behaves the same way on both.
Observability After Switching
Enabling VPC Flow Logs on your cluster subnets lets you observe egress traffic that now routes through your VPC, including calls to webhook and OIDC endpoints. If Flow Logs aren't enabled, this traffic won't be logged at all, so it's worth turning them on at the same time you make the switch.
Setup Steps
Once you've confirmed the checklist from the previous section, you're ready to enable the feature. We'll walk through configuring it on a new cluster, switching an existing cluster, and enforcing it organization-wide.
Enabling It on a New Cluster
Using the AWS CLI, specify
controlPlaneEgressMode=CUSTOMER_ROUTED in the resourcesVpcConfig of the create-cluster command.1
2
3
4
5
6
aws eks create-cluster \
--name <cluster-name> \
--role-arn arn:aws:iam::<account-id>:role/<role-name> \
--resources-vpc-config "subnetIds=<subnet-id-1>,<subnet-id-2>,securityGroupIds=<security-group-id>,controlPlaneEgressMode=CUSTOMER_ROUTED" \
--kubernetes-network-config "ipFamily=ipv4" \
--region <region-code>
For an IPv6 cluster, specify
ipFamily=ipv6, and make sure you also have an egress-only internet gateway for IPv6 traffic in addition to a NAT gateway for IPv4.If you're creating the cluster from the AWS Management Console, just switch Control plane egress to Customer routed on the networking configuration page. In AWS CloudFormation, you can do the same by setting
ControlPlaneEgressMode: CUSTOMER_ROUTED in ResourcesVpcConfig.As of this writing (June 2026), the Terraform AWS Provider doesn't yet support this field. If you manage your clusters with Terraform, you'll either need to wait for a supporting release or configure this setting through the AWS CLI or console instead.
Switching an Existing Cluster
If you already have a cluster running, you can switch it using the
update-cluster-config command.1
2
3
4
aws eks update-cluster-config \
--name <cluster-name> \
--resources-vpc-config "controlPlaneEgressMode=CUSTOMER_ROUTED" \
--region <region-code>
You can check the progress of the update with
describe-update.1
2
3
4
aws eks describe-update \
--name <cluster-name> \
--update-id <update-id> \
--region <region-code>
The update type is
ControlPlaneEgressUpdate, and it's complete once the status shows Successful. This typically finishes within about 10 minutes.Enforcing This Organization-Wide with an IAM Condition Key and SCP
If you operate EKS across multiple accounts, the
eks:controlPlaneEgressMode IAM condition key lets you require CUSTOMER_ROUTED to be specified whenever a cluster is created or updated. This condition key applies to the eks:CreateCluster and eks:UpdateClusterConfig actions. Here's an example SCP that denies any request that doesn't specify CUSTOMER_ROUTED:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RequireCustomerRoutedControlPlane",
"Effect": "Deny",
"Action": [
"eks:CreateCluster",
"eks:UpdateClusterConfig"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"eks:controlPlaneEgressMode": "CUSTOMER_ROUTED"
}
}
}
]
}
Applying this policy as an AWS Organizations SCP enforces
CUSTOMER_ROUTED mode for every new and updated cluster across your organization.Verifying Connectivity After Setup
Once the switch is complete, verify that the control plane can communicate as expected.
| Check | Command / method |
|---|---|
| Current egress mode | aws eks describe-cluster --name <cluster-name> --query "cluster.resourcesVpcConfig.controlPlaneEgressMode" |
| Cluster status | aws eks describe-cluster --name <cluster-name> --query "cluster.status" (should be ACTIVE) |
| Webhook connectivity | Create a resource that triggers an admission webhook and confirm it's processed successfully |
| Node registration | Run kubectl get nodes and confirm nodes have joined the cluster |
| IRSA | Confirm that a pod using an IAM role can assume that role as expected |
If all of these checks pass, the migration is complete. If you run into errors with webhook calls or OIDC authentication, go back to the checklist in the previous section and review your route table and security group configuration.
Use Cases
With that background in place, let's look at a few concrete scenarios where this feature makes a real difference.
Integrating with Private Admission Webhooks
When you deploy a policy engine like OPA (Open Policy Agent) or Kyverno as an admission webhook, you often want to keep the webhook server out of the public internet and in a private subnet. Previously, you had to expose the webhook server externally in some form for the control plane to reach it. With CUSTOMER_ROUTED mode, control plane egress traffic flows through your own VPC routing, so you can keep the webhook server in a private subnet and still receive callbacks on port 443 or whatever port you configure.
Connecting to an Internal Identity Provider over OIDC
This feature also helps when you want to use an OIDC provider that lives only on your internal network—Keycloak or Active Directory Federation Services (ADFS), for instance—for IAM role authentication (IRSA) or cluster authentication. Previously, the control plane had no path to an internal identity provider, so you had to expose the OIDC endpoint publicly. Now, by routing through your VPC and, if needed, a Transit Gateway, the control plane can reach the OIDC discovery endpoint without exposing it externally at all.
Connecting to On-Premises Environments
If you connect to an on-premises network through AWS Direct Connect or a VPN, you can extend that same reach to webhook servers or OIDC providers running on-premises. By extending your route table through a Transit Gateway and a Direct Connect gateway, you can build a setup where the control plane reaches on-premises resources over a private path end to end. For organizations that keep their identity infrastructure on-premises, this makes hybrid cloud-and-on-premises operations considerably simpler.
Summary
This article covered Amazon EKS's customer-routed control plane egress. By letting you control control plane egress traffic through your own VPC, this update makes it possible to integrate with private OIDC providers and admission webhook servers that were previously unreachable—expanding the options available to organizations with data perimeter or compliance requirements.
That said, this feature isn't something every EKS user needs. If you do adopt it, make sure you fully understand that responsibility for control plane connectivity shifts to you, and that switching to CUSTOMER_ROUTED is a one-way operation you can't undo—validate it in a test environment before applying it to production. The feature itself is available at no additional cost, in every AWS Region where Amazon EKS is available.
Keep in mind that the Terraform AWS Provider doesn't support this field yet; if you manage clusters with Terraform, you'll need to configure this setting through the AWS CLI or console until a supporting release ships.
References
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article