EKS Custom Networking 도입 시 Security Group, 이 부분을 놓치면 서비스가 죽는다

🤖 AI Assisted Content
이 글은 AI(Claude, Anthropic)의 도움을 받아 작성되었습니다.
작성자가 내용을 검토하고 편집했으나, AI가 초안 작성 및 구성에 참여했음을 밝힙니다.

들어가며

EKS 클러스터를 운영하다 보면 IP 고갈 문제로 Secondary CIDR을 붙이고 VPC CNI의 Custom Networking을 도입하는 시점이 옵니다. Pod를 별도 서브넷으로 빼서 Primary CIDR의 IP를 아끼는 구성이죠.

그런데 막상 전환하고 나면 이런 증상이 줄줄이 터지기 시작합니다.

• Pod가 MongoDB에 붙지 못함
• Pod에서 S3, ECR, STS 같은 AWS API 호출이 타임아웃
• 멀쩡하던 서비스 간 통신이 알 수 없는 이유로 끊김

대부분의 원인은 보안그룹(SG)입니다. 그것도 "분명 열어뒀는데 왜 안 되지?" 싶은 묘한 형태로 막힙니다. 이 글은 그 이유를 VPC CNI의 SNAT 동작 원리부터 실제 SG 변경 포인트까지 한 번에 정리합니다.

핵심 원리: VPC CNI는 "VPC 밖"으로만 SNAT 한다

AWS 공식 문서 원문부터 보겠습니다.

By default, when a pod communicates to any IPv4 address that isn't within a CIDR block that's associated to your VPC, the VPC CNI translates the pod's IPv4 address to the primary private IPv4 address of the primary ENI of the node.

풀어 말하면 이렇습니다.

• Pod → 인터넷(VPC 밖): 노드의 Primary ENI IP로 SNAT 됨
• Pod → VPC 내부 리소스: SNAT 되지 않음. Pod IP(Secondary CIDR)가 그대로 Source IP

여기서 함정이 시작됩니다. MongoDB, VPC Endpoint, ALB, 다른 Pod... 이 모든 목적지가 VPC 내부입니다. 즉 Pod가 이들에게 말을 걸 때 Source IP는 노드 IP가 아니라 Secondary CIDR에 속한 Pod IP입니다.

왜 서비스가 죽는가

기존 Security Group 규칙을 한 번 떠올려보세요. 거의 대부분 이렇게 생겼을 겁니다.

ingress {
  from_port   = 27017
  to_port     = 27017
  protocol    = "tcp"
  cidr_blocks = [data.aws_vpc.this.cidr_block]  # ← 이것!
  description = "MongoDB from VPC"
}

data.aws_vpc.this.cidr_block은 Primary CIDR 딱 하나만 반환합니다. Secondary CIDR은 포함되지 않습니다. 즉, 이 규칙은 사실상 이렇게 해석됩니다.

"Primary CIDR 대역의 클라이언트만 MongoDB에 접근 가능"

그런데 Custom Networking 이후 Pod IP는 Secondary CIDR이고, SNAT도 되지 않아 그대로 패킷에 찍힙니다. 결과는 명확합니다. 전부 차단.

변경이 필요한 SG 체크리스트

아래 기준으로 훑으면 됩니다.

"이 SG를 향해 Pod가 먼저 말을 거는가?" — Yes면 수정 필요.

⚠️ 반드시 수정해야 하는 SG

1. VPC Endpoint SG
Pod가 S3, ECR, STS, Logs, SSM 등을 호출할 때 사용. 전부 Pod가 클라이언트.

Before: TCP 443  from  VPC Primary CIDR
After : TCP 443  from  VPC Primary CIDR + Pod CIDR
        (또는 Source = 노드 SG)

2. MongoDB / RDS / ElastiCache 등 DB SG
DB 클라이언트는 100% Pod입니다. 여기서 막히면 서비스 장애 직결.

Before: TCP 27017  from  VPC Primary CIDR
After : TCP 27017  from  VPC Primary CIDR + Pod CIDR

🤔 케이스 바이 케이스로 판단할 SG

3. 내부 ALB Frontend SG
외부 사용자만 호출한다면 그대로 둬도 됩니다. 단 Pod 간 호출에서 내부 ALB를 경유하는 구조(MSA에서 흔함)라면 Source IP가 Pod CIDR이 됩니다. 이 경우 Pod CIDR 추가 필요.

4. EKS Node SG
Self(Node SG) 참조로 걸려있는 Pod-to-Pod, CoreDNS 룰은 Pod ENI가 노드 SG를 상속한다는 전제에서 그대로 유효합니다. VPC CNI 1.8.0 이상이면 ENIConfig의 securityGroups를 지정하지 않을 때 자동으로 노드 SG가 Pod ENI에 상속됩니다.

💡 만약 Pod ENI에 별도 SG(SG-POD-01 등)를 분리하기로 했다면 Self 참조 룰을 전부 재설계해야 합니다.

5. Admission Webhook Pod로 들어오는 9443
Webhook을 호출하는 주체는 API Server(EKS Managed ENI)이고, EKS Managed ENI는 Primary CIDR 안에 있습니다. 따라서 기존 Source = VPC CIDR 규칙으로도 동작은 합니다. 다만 의미상 Source = Cluster SG 참조로 바꾸는 것이 더 정확한 관례입니다.

✅ 건드리지 않아도 되는 SG

6. ALB Backend SG
AWS Load Balancer Controller가 IP Target 모드에서 Pod ENI SG(기본값: 노드 SG)에 from ALB SG 인바운드를 동적으로 주입합니다. 이건 컨트롤러가 알아서 해줍니다.

권장 패턴: CIDR 대신 SG 참조

Pod CIDR을 일일이 나열하는 방식은 당장은 간단하지만, Secondary CIDR을 확장하거나 Pod 서브넷을 추가할 때마다 SG 룰을 다시 손봐야 하는 부담이 있습니다. 가능하면 SG 참조 방식으로 통일하는 것을 권장합니다.

# Before (CIDR 나열)
cidr_blocks = [
  "10.0.0.0/16",    # Primary
  "100.64.0.0/16",  # Pod Secondary
]

# After (SG 참조)
security_groups = [aws_security_group.eks_node.id]

SG 참조 방식의 장점은 명확합니다. Pod ENI에 노드 SG가 자동으로 붙기 때문에 "이 SG 달고 있는 애는 다 허용" 이라는 규칙 하나로 Primary든 Secondary든 전부 커버됩니다. 나중에 Pod 서브넷을 아무리 늘려도 SG 룰은 그대로입니다.

ENIConfig securityGroups 동작의 중요한 팩트

VPC CNI 버전별로 기본 동작이 다릅니다. 공식 문서 원문입니다.

If you don't specify a valid security group... version 1.8.0 or later of the Amazon VPC CNI plugin for Kubernetes, then the security groups associated with the node's primary elastic network interface are used.

정리하면,

• VPC CNI ≥ 1.8.0 → ENIConfig에서 securityGroups 생략 시, 노드 Primary ENI의 SG가 Pod ENI에 상속
• VPC CNI < 1.8.0 → VPC 기본 SG가 붙음 (예상 못 한 동작의 원인이 되기 쉬움)

도입 전 반드시 VPC CNI 애드온 버전을 확인하세요.

실전 체크리스트

Custom Networking 전환 전 아래 항목을 미리 점검하면 장애 없이 넘어갈 수 있습니다.

• VPC CNI 애드온 버전이 1.8.0 이상인가
• VPC Endpoint SG에 Pod CIDR 또는 노드 SG 참조가 추가됐는가
• MongoDB/RDS 등 DB SG에 Pod CIDR 또는 노드 SG 참조가 추가됐는가
• 내부 ALB를 Pod가 호출하는 흐름이 있다면 ALB SG에도 Pod CIDR이 반영됐는가
• Terraform에서 data.aws_vpc.*.cidr_block만 참조하는 SG 룰이 남아있지 않은가
• Pod ENI에 별도 SG를 쓸 계획이라면, Self 참조 기반 룰을 전부 재설계했는가

마무리

Custom Networking 자체는 IP 고갈 문제에 대한 깔끔한 해답이지만, Pod의 Source IP가 바뀐다는 단 하나의 사실 때문에 기존 SG 설계 전반을 다시 들여다봐야 하는 작업입니다. 특히 Terraform에서 관용적으로 써오던 data.aws_vpc.this.cidr_block이 Primary CIDR만 반환한다는 점, 그리고 VPC CNI가 VPC 내부 트래픽은 SNAT 하지 않는다는 점 두 가지만 기억해도 대부분의 장애를 예방할 수 있습니다.

핵심 한 줄 요약:

"Pod가 클라이언트로 참여하는 모든 SG에, Pod의 Secondary CIDR(또는 노드 SG 참조)를 추가하라."

다음 단계로는 AWS_VPC_K8S_CNI_EXTERNALSNAT 설정과 NAT Gateway 비용 최적화, 그리고 SecurityGroupPolicy(Security Groups for Pods)를 활용한 Pod별 SG 분리 전략도 함께 살펴보면 좋습니다.

참고 자료

• Customize the secondary network interface in Amazon EKS nodes (AWS Docs)
• Deploy Pods in alternate subnets with custom networking (AWS Docs)
• Enable outbound internet access for Pods (AWS Docs)
• EKS Best Practices Guides - Custom Networking