Pod security groups in Amazon EKS Auto Mode: setup and capacity limits

Check cluster and Region requirements

The feature is for EKS Auto Mode clusters running Kubernetes 1.36 or later in AWS Regions where Auto Mode is supported. AWS announced Pod security groups for Auto Mode on November 11, 2026, with no additional charge for the feature itself; that does not remove charges for the cluster, compute, or networking resources you use.

When an existing cluster is upgraded to 1.36 or later, the control-plane components that implement the feature start after the control plane's next restart, which can take several minutes. Do not assume a policy is ready as soon as the version changes; wait for policy resolution and check the workload state.

Separate node-wide and per-Pod security groups

In Auto Mode, SecurityGroupPolicy binds one or more existing EC2 security groups to selected Pods and enforces their rules at the Pod through a branch network interface. Different Pods on the same node can therefore use different groups; Pods that neither match a policy nor have an explicit policy-backed resource claim continue to use the node's security groups.

NodeClass podSecurityGroupSelectorTerms has a different scope: it assigns one security group set to every Pod on nodes using that NodeClass, so it does not separate applications on the same node. SecurityGroupPolicy selects existing groups; it does not create security groups or add ingress rules for you.

Check the API and policy matching before migrating

The Auto Mode per-Pod API is eks.amazonaws.com/v1 and uses securityGroupSelectorTerms. The Amazon VPC CNI resource for clusters outside Auto Mode is vpcresources.k8s.aws/v1beta1 and uses securityGroups.groupIds. Both resources are named SecurityGroupPolicy, but they are different APIs and their manifests are not interchangeable; neither API enforces the other one on a different node type.

At most one policy can match a Pod; Auto Mode rejects a Pod that matches multiple policies, so keep selectors disjoint. At least one of podSelector or serviceAccountSelector is required; when both are set, a Pod must match both to be selected.

Keep the two security group limits distinct

The security group selector terms resolve into one set, and a policy can resolve no more than 16 groups; this is only the resolution ceiling. The branch interface is also subject to the account's security-groups-per-network-interface quota, which defaults to five. If the resolved count is over the account quota but no more than 16, SecurityGroupsResolved can still be True while interface creation later fails with ENICreationFailed.

More than 16 resolved groups produces SecurityGroupsResolved=False with sg_quota_exceeded. AWS also recommends no more than five distinct SecurityGroupPolicy resources targeting Pods on the same node to avoid scheduling latency and increased CPU and memory use in Karpenter and kube-scheduler. Policy count, resolved group count, and the interface quota are separate limits.

Configure rules for the traffic you need

Security groups on the branch interface are enforced for traffic to and from a Pod, including traffic between Pods on the same node. If Pods covered by the same policy need to communicate, add a self-referencing ingress rule only for the required protocols and ports; do not open all ingress traffic as a troubleshooting shortcut.

A fixed set of node-local paths bypasses Pod security group enforcement: the EC2 instance metadata service (IMDS), the EKS Pod Identity Agent, kubelet health and readiness probes from the node IP, and CoreDNS. These exceptions cannot be configured. On an IPv6 cluster with the default enableV4Egress setting enabled, Pod IPv4 egress is forwarded through the node's primary interface and uses the node's security groups, not the Pod's.

Plan interface capacity, networking, and permissions

Branch network interfaces use node ENI slots and reduce maxPods available for regular Pods. Auto Mode recalculates interface capacity for new nodes, but does not retroactively update nodes that have already joined; those nodes can keep accepting Pods against their old capacity, leaving some Pods waiting for an interface. Plan a controlled node replacement or rollout for adoption rather than deleting production nodes without a capacity plan.

The feature works only with Auto Mode's built-in networking; alternate CNI and network policy plugins are not supported. In addition to AmazonEKSNetworkingPolicy, the cluster IAM role needs ec2:CreateNetworkInterfacePermission to associate branch interfaces. Without it, interface creation can fail.

Troubleshoot by status, then clean up before disabling Auto Mode

Start by checking whether a newly created Pod has the resource claim injected by the webhook, then inspect status.securityGroups and SecurityGroupsResolved on the policy. If resolution is False, use no_sgs_matched, sg_quota_exceeded, invalid_spec, or resolution_error to narrow the cause. True means the groups resolved; it does not mean the branch interface is ready. Pods matched by a policy whose resolution fails stay pending instead of falling back to the node’s security groups.

If a Pod has a claim but no interface, inspect its ResourceClaim and Warning events for ENICreationFailed, then check the account interface quota, cluster-role permissions, and whether the security group belongs to the cluster VPC. You can also check whether the controller has created the ResourceClaimTemplate. Fix the cause before trying again; repeated failures can result in SecurityGroupIsolated.

If you later disable Auto Mode, AWS recommends gracefully terminating workloads protected by these policies while Auto Mode is still enabled, then removing the policies and waiting until none remain in the cluster. This gives the controller time to release branch interfaces and remove their finalizers.