All posts
Kubernetes

EKS Network Policies With the VPC CNI: Default Deny, Admin Policies, and the Limits to Know

By

November 2, 2026

6 min read

The VPC CNI enforces Kubernetes network policies natively, and from version 1.21 adds cluster-wide admin policies that namespace owners can't override. How the tiers are evaluated, a default-deny setup, and the limits: EC2 Linux nodes only, 24 port-protocol combinations per CIDR, and pods without an owner.

EKS
Network Policies
VPC CNI
Kubernetes
Security

By default every pod in a Kubernetes cluster can reach every other pod and anything on the network. Network policies change that, and on EKS the VPC CNI enforces them itself, without installing Calico or Cilium.

Two kinds of policy

NetworkPolicy

ClusterNetworkPolicy (admin)

Scope

One namespace

The whole cluster, or selected namespaces

Owned by

Application teams

Platform or security team

Can be overridden by a namespace policy

n/a

No, in the Admin tier; yes, in the Baseline tier

Requires

VPC CNI with network policy enabled

VPC CNI 1.21 or later

Want a second opinion on this for your system?

Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.

How traffic is evaluated

  1. Admin-tier cluster policies, lowest priority number first. A Deny ends evaluation; an Allow accepts; a Pass hands the decision to namespace policies.

  2. Namespace NetworkPolicies, which can only be more restrictive than what the Admin tier allowed or passed.

  3. Baseline-tier cluster policies: defaults that namespace policies may override.

  4. Anything still unmatched is denied.

A default-deny setup

  • An Admin-tier Deny protecting sensitive namespaces from every other namespace.

  • A Baseline-tier default: deny ingress from other namespaces, allow DNS and the cluster's ingress controller.

  • Per-namespace policies, owned by each team, for the traffic their services actually need.

  • An allow rule for the instance metadata service only for pods that still use the node role; pods on Pod Identity or IRSA don't need it.

Limits to know

  • Policies apply on EC2 Linux nodes only, not on Fargate or Windows nodes.

  • At most 24 port-and-protocol combinations per CIDR across all policies; selectors that resolve to the same CIDR all count.

  • Enforcement is optimized for pods owned by a controller (Deployment, StatefulSet, Job). Standalone pods may not be enforced reliably.

  • A Service's port must match the container port.

  • Only the primary interface is covered: chained plugins such as Multus and IPv4 egress from IPv6 pods aren't.

  • Replacing another policy engine: remove it first, then replace the nodes it ran on, since leftover rules can remain.

hoolco Monthly Review

Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.

As of November 2, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.