ERROR REFERENCE
EKS network policy setup failed in the VPC CNI
failed to setup network policy points at the
aws-network-policy-agent stage inside the aws-node
DaemonSet. It is a node-level EKS add-on or policy-enforcement failure,
not a reason to change the workload's IAM role first.
WHAT IT MEANS
The pod sandbox could not receive its network policy
Failed to setup default network policy for Pod Name <pod> and NameSpace <ns>: GRPC returned - Network policy agent returned - <nil>
The kubelet may surface this as FailedCreatePodSandBox and
retry with a new sandbox. The useful cause is in the network-policy-agent
and VPC CNI logs at the same timestamp, such as an eBPF, veth, kernel, or
PolicyEndpoint error.
NEXT CHECK
Inspect the node agent before changing the workload
-
Capture the pod, node, namespace, and timestamp. Keep
both the kubelet event and the matching
aws-nodelog. -
Read the network-policy-agent container:
Look for the nested eBPF, veth, kernel, or PolicyEndpoint error.kubectl -n kube-system logs daemonset/aws-node -c aws-network-policy-agent --since=15m -
Check the add-on prerequisites. Verify the VPC CNI
version,
enableNetworkPolicysetting, node OS/kernel, and thePolicyEndpointresources. If a retry succeeds, preserve both events and investigate a transient agent race before changing policy rules or IAM.
AUTOMATE THE TRIAGE
Keep the handoff in your normal workflow
SAM Doctor recognizes this network-policy-agent marker with medium confidence and points at the node-level evidence. It runs locally; no AWS access, no log upload.
python -m pip install sam-doctor
sam-doctor diagnose deployment.log --format markdown
RELATED
Related errors
- EKS VPC CNI could not set up pod networking — the broader sandbox wrapper when no policy-agent stage is named.
- EC2 could not create a network interface — use when the nested CNI cause is a complete CreateNetworkInterface response.
- EKS network policies — official prerequisites and supported configurations.