Kubernetes NetworkPolicy controls Pod to Pod; security groups for pods control Pod to AWS resources.

They work at different layers and are used together.

Security groups for pods

A SecurityGroupPolicy attaches an AWS security group to matching Pods using trunk ENIs. An RDS rule can then allow only that group instead of every Pod on the node.

NetworkPolicy on EKS

The VPC CNI can enforce Kubernetes NetworkPolicy itself (enable it on the add-on), or use Calico or Cilium. Default-deny plus explicit allows, as in Deck 1.

kind: SecurityGroupPolicy
spec:
  podSelector: {matchLabels: {role: db-client}}
  securityGroups: {groupIds: [sg-0123456789abcdef0]}

Limits

Needs supported instance types and has no support on Fargate-style isolation in the same way. Check the docs before designing around it.

Isolation: security groups for pods and network policy

There are two network access-control layers on EKS and they solve different problems. Kubernetes NetworkPolicy is evaluated inside the cluster's dataplane and controls which Pods can talk to which Pods (and to external CIDRs). It has no concept of AWS resources: it cannot say allow only these Pods to reach this RDS instance's security group.

Security groups for pods fills that gap. A SecurityGroupPolicy selects Pods by label and assigns an AWS security group to them using branch network interfaces (trunking). Because the Pod now has its own security group, you can write the RDS or ElastiCache rule to allow only that group, rather than the whole node's group, which would admit every Pod on the node. It narrows the blast radius at the AWS layer.

For Pod-to-Pod rules, the VPC CNI can now enforce Kubernetes NetworkPolicy natively when enabled on the add-on, and Calico or Cilium remain popular alternatives with richer features. Deck 5 covers policy hardening and Deck 7 covers Cilium in depth.

Gotchas: security groups for pods have instance-type and configuration requirements, and enabling it changes how Pod networking is wired, so test it in a staging cluster. And NetworkPolicy still needs the same default-deny baseline described in Deck 1 to be effective.