멀티 테넌트 Hub-Spoke 환경에서의 Spoke 간 통신 차단 문의

Transit Gateway의 Route Table 격리 패턴을 사용하면 Spoke 간 통신을 라우팅 레벨에서 원천 차단할 수 있습니다.

핵심 설계 원칙

각 Spoke VPC는 오직 Hub VPC와만 통신 가능해야 하며, Spoke↔Spoke 간 직접 통신은 경로 자체가 존재하지 않아야 합니다.

TGW Route Table 구성

Route Table을 2개로 분리합니다:

• Hub-RT: Hub VPC Attachment와 Association. 모든 Spoke VPC CIDR이 Propagation으로 등록됩니다.
• Spoke-RT: 모든 Spoke VPC Attachment와 Association. Hub VPC CIDR만 Static Route로 등록합니다.

Spoke-RT의 라우팅 규칙:

• Hub VPC CIDR → Hub VPC Attachment (Static Route)
• 0.0.0.0/0 → Blackhole

Hub-RT의 라우팅 규칙:

• Tenant-A VPC CIDR → Tenant-A Attachment (Propagation)
• Tenant-B VPC CIDR → Tenant-B Attachment (Propagation)

가장 중요한 포인트는 Spoke-RT에서 다른 Spoke VPC의 Route Propagation을 비활성화하는 것입니다. 경로 자체가 없으므로 Spoke 간 통신이 원천 차단됩니다.

100+ 테넌트 확장 시 고려사항

• 단일 TGW당 최대 5,000개 Attachment를 지원하므로 100개 테넌트는 충분합니다.
• TGW당 Route Table은 기본 20개까지 가능합니다. 위 패턴처럼 Spoke를 하나의 RT로 공유하면 2개만 필요하므로 한도 문제가 없습니다.
• 테넌트별 VPC CIDR은 IPAM(VPC IP Address Manager)으로 체계적으로 할당하세요. Overlapping CIDR이 발생하면 TGW 라우팅이 불가합니다.
• 테넌트 온보딩 시 VPC 생성 → TGW Attachment → Route 설정을 CloudFormation StackSets 또는 Terraform으로 자동화하는 것을 권장합니다.

추가 보안 계층

라우팅 격리만으로도 Spoke 간 통신은 차단되지만, Defense in Depth 관점에서 다음을 추가로 고려하세요:

• Hub VPC에 AWS Network Firewall을 배치하여, Spoke에서 Hub로 들어오는 트래픽을 L7 레벨에서 검사할 수 있습니다.
• Hub VPC의 서비스에 테넌트별 Security Group을 적용하면 애플리케이션 레벨에서도 격리가 강화됩니다.
• VPC Flow Logs를 활성화하고 Athena로 분석하면 테넌트 간 비정상 통신 시도를 탐지할 수 있습니다.