AWS Transit Gateway로
중앙 집중형 방화벽 구축하기

안녕하세요. AWS 환경이 커지다 보면 DMZ, PRD, MGMT 등 VPC가 계속 늘어나게 됩니다. 이때 가장 고민되는 것이 바로 **"보안 통제"**입니다.

‍

모든 VPC마다 NAT Gateway와 방화벽을 두자니 비용이 감당이 안 되고, 관리는 더더욱 힘들죠. 이럴 때 사용하는 정석 아키텍처가 바로 **Transit Gateway(TGW)**와 AWS Network Firewall을 이용한 중앙 집중형 검사 모델입니다.

‍

오늘은 모든 트래픽(VPC 간 통신 + 인터넷 아웃바운드)을 한 곳에서 검사하고 통제하는 아키텍처를 구축해 보겠습니다.

‍

1. 아키텍처 목표

우리가 만들 구조의 핵심은 다음과 같습니다.

‍

모든 길은 TGW로: DMZ, PRD, MGMT 등 모든 Spoke VPC는 TGW에 연결됩니다.

무조건 검사: VPC 간 통신이든, 인터넷으로 나가는 트래픽이든 일단 Network Firewall을 거쳐야 합니다.

출구는 하나: 인터넷으로 나가는 모든 트래픽(Egress)은 검사 후 DMZ VPC의 NAT Gateway를 통해서만 나갑니다.

‍

2. 사전 준비: 네트워크 구성 (CloudFormation)

먼저 기본 뼈대가 되는 VPC와 TGW를 생성합니다. (실습에서는 편의상 CloudFormation을 사용하지만, 개념 이해를 위해 수동 설정 기준으로 설명할게요.)

‍

Spoke VPC 3개:

eks-dmz-vpc (172.16.0.0/16): 외부 통신의 관문.

eks-prd-vpc (172.17.0.0/16): 실제 서비스(WEB/WAS/DB).

eks-mgmt-vpc (172.18.0.0/16): 관리용.

‍

Transit Gateway: 모든 VPC를 연결하는 허브 (eks-tg-01).

‍

3. 핵심 구축 단계

이 아키텍처의 핵심은 **"라우팅 테이블을 어떻게 꼬아서(?) 트래픽을 방화벽으로 밀어넣느냐"**입니다.

Step 1. AWS Network Firewall 생성

먼저 검문소를 세웁니다.

‍

규칙 그룹(Rule Group) 생성: 테스트용으로 모든 트래픽을 허용(Allow All)하는 Stateful 규칙을 만듭니다.

방화벽 정책(Policy) 생성: 위 규칙 그룹을 포함하는 정책을 만듭니다.

방화벽(Firewall) 배포:

VPC를 따로 만들지 않고, TGW가 있는 리전의 서브넷을 지정하여 배포합니다.

중요: 방화벽이 생성되면 VPC endpoint ID (또는 Attachment ID)가 생성됩니다. 나중에 라우팅 테이블에서 써야 하니 꼭 복사해 두세요!

Step 2. TGW 라우팅 테이블 분리 (여기가 제일 중요!)

TGW에는 두 개의 라우팅 테이블이 필요합니다. 하나는 "검사받으러 가는 애들용", 다른 하나는 "검사 끝나고 돌아오는 애들용"입니다.

‍

1) Spoke VPC용 라우팅 테이블 (tgw-spoke-domain-rtb)

역할: “어디를 가려고 하든 일단 방화벽으로 가라!”

연결(Associations): DMZ, PRD, MGMT VPC Attachment.

라우팅(Routes): 모든 목적지(0.0.0.0/0 등)의 타겟을 Network Firewall Attachment로 설정합니다.

‍

2) Firewall용 라우팅 테이블 (tgw-firewall-domain-rtb)

역할: “검사 끝났으니 이제 진짜 목적지로 가라.”

연결(Associations): Network Firewall Attachment.

전파(Propagations): DMZ, PRD, MGMT VPC. (이렇게 하면 각 VPC로 가는 경로가 자동으로 학습됩니다) .

Step 3. 각 VPC 라우팅 테이블 수정

마지막으로 각 VPC 내부의 라우팅 테이블을 수정하여 TGW로 트래픽을 보냅니다.

‍

PRD / MGMT VPC: 0.0.0.0/0 (모든 트래픽) → Transit Gateway.

DMZ VPC:

Private Subnet: 0.0.0.0/0 → NAT Gateway (인터넷으로 나가기 위해).

Public Subnet: 0.0.0.0/0 → IGW (인터넷 게이트웨이)

주의: DMZ Public Subnet은 외부에서 들어오는 트래픽(ALB 등)을 받아야 하므로 IGW 경로가 필수입니다.

‍

4. 트래픽 흐름 확인 (검증)

이제 패킷이 어떻게 이동하는지 머릿속으로 그려봅시다.

시나리오 1: PRD 서버가 인터넷으로 나갈 때 (Egress)

서버 업데이트 등을 위해 외부 인터넷에 접속하는 경우입니다 .

PRD VPC: "인터넷 가고 싶어" (0.0.0.0/0) → TGW로 전달.

TGW (Spoke RTB): "일단 방화벽 들렀다 와" → Network Firewall로 전달.

Network Firewall: (패킷 검사 수행) "통과!" → 다시 TGW로 반환.

TGW (Firewall RTB): "인터넷으로 가려면 출구인 DMZ로 가야지" (0.0.0.0/0 경로 확인) → DMZ VPC로 전달.

DMZ VPC: 내부 라우팅에 따라 NAT Gateway를 타고 인터넷으로 나감 (SNAT).

시나리오 2: PRD 서버가 MGMT 서버와 통신할 때 (East-West)

VPC끼리 통신할 때도 똑같이 방화벽을 거치게 됩니다.

PRD VPC: "MGMT(172.18.x.x)랑 통신할래" → TGW로 전달.

TGW (Spoke RTB): "일단 방화벽 들렀다 와" → Network Firewall로 전달.

Network Firewall: 검사 후 TGW로 반환.

TGW (Firewall RTB): "MGMT VPC가 목적지네?" → MGMT VPC로 전달.

‍

Tip: 같은 VPC 내부 통신 (예: PRD Web → PRD DB)은 TGW까지 가지 않고 VPC 내부에서 직접 통신하므로 방화벽 검사를 받지 않습니다.

마치며

이 아키텍처는 설정이 조금 복잡해 보이지만, 한 번 구축해 두면 **"어떤 VPC를 추가하든 보안 정책을 한 곳에서 중앙 통제"**할 수 있다는 엄청난 장점이 있습니다.

‍

보안팀은 Network Firewall 정책만 관리하면 되고, 인프라팀은 VPC 연결만 신경 쓰면 되니 R&R 분리에도 아주 좋죠. 엔터프라이즈 환경을 고려 중이라면 꼭 한번 적용해 보시길 추천합니다!