EKS Tutorials: Types of Security Groups Created or Used in an EKS Cluster

When you set up an Amazon EKS (Elastic Kubernetes Service) cluster, AWS automatically creates and/or requires several security groups to manage access to the control plane, worker nodes, and other associated components.

Here’s a complete breakdown of the types of Security Groups involved during an EKS cluster setup:

🔐 Types of Security Groups Created or Used in an EKS Cluster

1. EKS Control Plane Security Group (Optional/Custom)

• Purpose: Controls communication from the control plane to worker nodes (EC2/EKS-managed).
• Traffic direction: Egress traffic from control plane → worker nodes (TCP 443 by default).
• When it’s defined: You specify this group when creating a cluster using the vpcConfig.securityGroupIds.

✅ This group is not created automatically – it’s the one you pass in during setup.

2. EKS Managed Node Group Security Group (Auto-created by EKS)

• Created when: You launch a managed node group.
• Purpose: Controls traffic between nodes and from the nodes to the control plane.
• Includes ingress rules for:
  • Node-to-node communication
  • Control plane-to-node communication

⚠️ This security group is automatically associated with your EC2 worker nodes.

3. Cluster Shared Node Security Group (Created Automatically)

• Purpose: Used for:
  • Worker node communication (pods across nodes)
  • Internal services
• Managed by EKS: You cannot delete this manually.
• Shared across multiple node groups in the cluster.

This SG ensures pods and services across nodes in the cluster can communicate securely.

4. Fargate Pod Execution Role SG (if using Fargate)

• If you’re using Fargate profiles, you need to define a security group that controls the network interfaces attached to the Fargate pods.
• This group handles pod-level network access when no EC2 nodes are used.

5. Load Balancer Security Group (Optional)

• For services of type LoadBalancer, AWS creates an ELB (Classic/NLB/ALB).
• This SG controls traffic from the internet or other services to the service endpoints.

Summary Table

🧠 Best Practices

• Always restrict Control Plane SG to only allow required ports (like 443).
• Tag all SGs with kubernetes.io/cluster/<cluster-name> = owned for EKS to manage them.
• Use Network Policies inside the cluster for fine-grained pod-to-pod security.
• Monitor SGs with AWS Config to ensure compliance.

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.