EKS Outbound 컨트롤 관련해서 궁금한 점이 있습니다.

Q1. EKS 아웃바운드 컨트롤 관련해서 노드단 SG 설정, ACL, Nfirewall 외 다른 방안이 있을까요? 서비스 메시 방식으로 Lattice를 활용하여 서비스간 통신을 제어하는 방안도 EKS 클러스터에서 많이 고려를 하고 있습니다. 서비스 네트워킹 방식으로 통제하면 여러 VPC와 서비스를 연결하는 중앙 서비스 네트워크를 구성 하 실 수 있습니다. 그리고 Pod Level에서 Network Policy를 구성하시거나 Egress Gateway를 구성하여 아웃바운드 컨트롤을 하실 수 있습니다.

1. 노드 레벨 제어 (SG 보안 그룹 or ACL) • EKS 노드에 적용된 보안 그룹으로 아웃바운드 규칙 제한 • 특정 IP 범위나 포트로 제한
2. VPC 레벨 제어 (AWS Network Firewall) • 전용 서브넷에 Network Firewall 배치 • 상태 기반 트래픽 검사 및 필터링 • 도메인 기반 필터링 (허용/차단 목록)
3. AWS Lattice로 클러스터 or 서비스간 트래픽 제어(서비스간 통신이기에 외부간 통신은 NatGateway가 더 적합) • EKS 클러스터의 모든 아웃바운드 트래픽을 VPC Lattice로 라우팅 • VPC Lattice에서 허용된 외부 서비스로만 트래픽 전달 • 서비스 정의 및 라우팅 규칙을 통해 아웃바운드 트래픽 제어
4. 포드 레벨 제어 (Kubernetes Network Policy) • k8s의 자체적으로 내장된 Network policy 활용 • 포드 간 통신 및 외부 통신 정책 적용 • 네임스페이스별, 레이블별 세밀한 제어 가능

Q2. 퍼블릭/프라이빗 서브넷 구분 외 DMZ별도 영역구분하고, 프록시(포워드) 서버 구성해서 UTM, WAF 등 쓰는게 일반적인가요? 질문 주신 방법이 표준적으로 활용되고 있는 아키텍처 입니다. 아래 링크에서 보실 수 있듯이, 방화벽을 Public subnet에 구성하여 네트워크를 통제 하는 구성입니다. https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/secure-outbound-network-traffic/restricting-outbound-traffic.html

다만, 많은 Account와 vpc를 소유하고 있는 경우 Transit gateway를 두고, 각 vpc들을 연결하여 중앙에 inspection vpc or Egress vpc를 두어서 관리를 하는것이 효율적일 수 있습니다. https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/using-nat-gateway-with-firewall.html