GCP Hub & Spoke에서 FortiGate로 Spoke 간 통신 중앙 통제하기 – 피어링 구조를 바꾸지 않고 동서 트래픽 검사하기

작성자 정 만성 작성일 10월 30, 2026 조회수 7

안녕하세요. GS Neotek 정만성 입니다.
GCP에서 업무별로 프로젝트를 나누다 보면, 프로젝트(Spoke) 사이의 통신을 한곳에서 통제하고 기록해야 하는 요구가 자주 생깁니다.
이번 글에서는 Hub & Spoke 구조에서 FortiGate HA를 중앙 검사 지점으로 두고, Spoke 간 통신과 인터넷으로 나가는 트래픽을 모두 FortiGate로 통과시킨 구성을 정리했습니다.
실제로 구축하고 검증한 내용을 바탕으로, IP와 이름은 예시값으로 바꿨습니다.

한눈에 보기

전체 구성

Hub 프로젝트에는 4개의 VPC를 두고, FortiGate HA(Active-Standby) 2대가 각 VPC에 인터페이스를 하나씩 연결합니다.

각 Spoke 프로젝트는 Hub의 Trust VPC와만 VPC 피어링으로 연결합니다.
FortiGate 앞에는 내부 패스스루 부하 분산기(NLB)를 두고, 이 NLB를 커스텀 라우트의 다음 홉(next hop)으로 지정해 트래픽을 FortiGate로 보냅니다.

왜 NCC가 아니라 VPC 피어링 + FortiGate인가

GCP에서 여러 VPC를 허브 중심으로 묶는다고 하면 Network Connectivity Center(NCC)를 먼저 떠올리기 쉽습니다.
하지만 이번 요구사항은 “Spoke끼리 통신하되, 반드시 방화벽 검사를 거칠 것”이었고, 이 기준으로 보면 선택이 달라집니다.

토폴로지별 동작은 NCC 연결 토폴로지 공식 문서에 정리되어 있습니다.
즉 NCC를 쓰더라도 Spoke 간 통신을 검사하려면 결국 FortiGate 같은 방화벽이 필요합니다.
방화벽 비용은 어느 방식이든 똑같이 들고, 차이는 NCC 자체 요금이 더해지느냐입니다.

비용 비교 (공식 가격 기준)

NCC 요금은 Network Connectivity 가격 책정 공식 페이지 기준입니다(2026년 10월 확인).

Spoke 수에 따라 NCC를 쓸 때 추가되는 월 비용은 대략 이렇습니다(VPC Spoke 기준, Spoke 간 트래픽 월 1TiB 가정).

여기에 방화벽 비용은 두 방식 모두 똑같이 더해집니다.
참고로 Google Cloud Marketplace의 FortiGate PAYG 라이선스 요금은 vCPU 수에 따라 시간당 $0.36(1 vCPU)부터 $1.02(4~7 vCPU), $1.60(8~15 vCPU) 수준이며, VM 비용은 별도이고 HA라면 2대분이 필요합니다.

Spoke가 몇 개 수준이라면 피어링 + FortiGate로 추가 비용 없이 같은 목적을 달성할 수 있습니다.
반대로 Spoke가 많아져 피어링 수 한도나 라우트 관리가 부담되거나, VPN·Interconnect 같은 하이브리드 연결까지 한곳에서 관리해야 한다면 NCC를 검토할 만합니다.
결국 정답이 하나로 정해진 것은 아니고, 고객 환경의 규모와 요구사항에 맞춰 고르는 것이 중요합니다.

Spoke 간 통신을 FortiGate로 보내는 방법

1. 피어링은 전이되지 않는다는 점을 그대로 활용

VPC 피어링은 전이되지 않습니다.
Spoke A와 Spoke B가 각각 Hub와 피어링되어 있어도, A와 B는 서로의 경로를 알지 못해 직접 통신할 수 없습니다.
이 특성 덕분에 Spoke끼리 FortiGate를 우회하는 경로가 처음부터 존재하지 않습니다.
남은 일은 “A에서 B로 가는 길”을 FortiGate 쪽으로 만들어 주는 것뿐입니다.

2. Spoke 대역을 넓게 잡은 커스텀 라우트

Hub의 Trust VPC에 각 Spoke 대역을 /24로 넓게 잡은 커스텀 라우트를 만들고, 다음 홉을 FortiGate 앞의 NLB로 지정합니다.

# Hub Trust VPC: Spoke B 방향(넓은 대역) → FortiGate 앞 NLB
gcloud compute routes create to-spoke-b-via-fgt \
  --project=hub-project \
  --network=hub-trust-vpc \
  --destination-range=10.20.2.0/24 \
  --next-hop-ilb=fgt-trust-nlb \
  --next-hop-ilb-region=asia-northeast3 \
  --priority=700

# Hub Trust VPC: Spoke B 방향(넓은 대역) → FortiGate 앞 NLB
gcloud compute routes create to-spoke-b-via-fgt \
  --project=hub-project \
  --network=hub-trust-vpc \
  --destination-range=10.20.2.0/24 \
  --next-hop-ilb=fgt-trust-nlb \
  --next-hop-ilb-region=asia-northeast3 \
  --priority=700

Spoke의 실제 서브넷은 /28이고, 라우트는 /24로 잡은 것이 포인트입니다.

• Spoke A에는 피어링을 통해 /24 라우트만 전달되므로, B로 가는 트래픽은 NLB를 거쳐 FortiGate로 향합니다.
• Hub 안에서는 더 구체적인 Spoke B 서브넷 라우트(/28)가 우선하므로, FortiGate가 검사를 마친 트래픽은 피어링을 통해 B로 바로 전달됩니다.

3. 피어링에서 커스텀 라우트 주고받기

Hub 쪽 피어링은 커스텀 라우트를 내보내고, Spoke 쪽 피어링은 가져오도록 설정합니다.

# Hub → Spoke 방향: 커스텀 라우트 내보내기
gcloud compute networks peerings update hub-to-spoke-a \
  --project=hub-project --network=hub-trust-vpc \
  --export-custom-routes

# Spoke → Hub 방향: 커스텀 라우트 가져오기
gcloud compute networks peerings update spoke-a-to-hub \
  --project=spoke-a-project --network=spoke-a-vpc \
  --import-custom-routes

# Hub → Spoke 방향: 커스텀 라우트 내보내기
gcloud compute networks peerings update hub-to-spoke-a \
  --project=hub-project --network=hub-trust-vpc \
  --export-custom-routes

# Spoke → Hub 방향: 커스텀 라우트 가져오기
gcloud compute networks peerings update spoke-a-to-hub \
  --project=spoke-a-project --network=spoke-a-vpc \
  --import-custom-routes

4. FortiGate 정책

Spoke 간 트래픽은 같은 인터페이스(port2)로 들어와 port2로 나가므로, port2 → port2 정책을 만들고 로그를 남깁니다.
돌아오는 트래픽도 같은 FortiGate를 거치도록 SNAT를 켰습니다.

config firewall policy
    edit 3
        set name "spoke-a-to-spoke-b"
        set srcintf "port2"
        set dstintf "port2"
        set srcaddr "spoke-a-net"
        set dstaddr "spoke-b-net"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set nat enable
    next
end

config firewall policy
    edit 3
        set name "spoke-a-to-spoke-b"
        set srcintf "port2"
        set dstintf "port2"
        set srcaddr "spoke-a-net"
        set dstaddr "spoke-b-net"
        set action accept
        set schedule "always"
        set service "ALL"
        set logtraffic all
        set nat enable
    next
end

실제 운영에서는 서비스(포트)를 필요한 것만 열어 정책을 좁히는 것을 권장합니다.

Spoke의 인터넷 egress도 중앙에서 통제하기

Spoke에서 인터넷으로 나가는 트래픽도 같은 방식으로 FortiGate를 거치게 했습니다.
다만 GCP 라우트는 도메인이 아니라 IP 대역만 지정할 수 있어서, 통제를 두 단계로 나눴습니다.

예를 들어 Google 서비스의 공개 대역 전체를 FortiGate로 보내고, FortiGate에서는 필요한 도메인만 허용하는 식입니다.
라우트는 넓게, 정책은 좁게 잡으면 대역이 바뀌어도 라우트를 자주 고칠 필요가 없습니다.

검증 결과

Spoke 간 통신은 Spoke VM에서 아래처럼 확인했습니다.

# Spoke A VM에서 실행
traceroute -n 10.20.2.2      # 첫 홉이 FortiGate trust 인터페이스인지 확인
curl -sI http://10.20.2.2:8080

# Spoke A VM에서 실행
traceroute -n 10.20.2.2      # 첫 홉이 FortiGate trust 인터페이스인지 확인
curl -sI http://10.20.2.2:8080

FortiGate에서는 세션 목록으로 같은 트래픽이 지나간 것을 확인할 수 있습니다.

diagnose sys session filter src 10.20.1.2 dst 10.20.2.2
diagnose sys session list

diagnose sys session filter src 10.20.1.2 dst 10.20.2.2
diagnose sys session list

구축하며 챙겨야 했던 부분

• 1. NLB 헬스체크 응답 설정
  NLB가 FortiGate를 정상 백엔드로 인식하려면 FortiGate가 헬스체크에 응답해야 합니다. FortiGate의 probe-response 기능(HTTP 8008 포트 등)을 켜고, 인터페이스에서 헬스체크 응답을 허용해야 합니다.
• 2. NLB 주소를 FortiGate가 받을 수 있게 하기
  Trust 쪽 NLB 주소를 FortiGate 인터페이스와 같은 서브넷에 두면 응답이 되지 않아, NLB용 작은 서브넷을 따로 만들고 FortiGate에 보조 IP로 지정했습니다.
• 3. 헬스체크 응답 경로 맞추기
  헬스체크가 들어온 인터페이스와 응답이 나가는 인터페이스가 다르면 헬스체크가 실패합니다. Google 헬스체크 대역으로 가는 응답은 들어온 인터페이스로 나가도록 정책 라우트를 추가했습니다.
• 4. FortiGate VM 라이선스의 vCPU 수
  검증 중 HA가 불안정해지는 현상이 있었는데, VM은 4 vCPU였지만 라이선스가 1 vCPU만 허용해 헬스체크 응답이 늦어진 것이 가장 유력한 원인으로 보였습니다. 머신 타입뿐 아니라 라이선스가 허용하는 vCPU 수도 함께 확인해야 합니다.

정리하며

• 장점: Spoke끼리는 피어링 구조상 우회할 길이 없고, 모든 동서·egress 트래픽이 FortiGate 한곳을 지나므로 정책과 로그를 일괄 관리할 수 있습니다. 새 Spoke는 피어링 하나와 라우트만 추가하면 같은 정책이 적용됩니다.
• 고려할 점: FortiGate가 모든 트래픽의 길목이 되므로 HA 구성, VM 사양과 라이선스, 헬스체크 설정을 꼼꼼히 챙겨야 합니다. 커스텀 라우트 개수도 늘어나므로 라우트 한도와 우선순위 관리 방안을 미리 정해 두는 것이 좋습니다.

피어링의 비전이성과 ILB 다음 홉 라우트만 잘 조합하면, 구조를 크게 바꾸지 않고도 GCP에서 Spoke 간 통신을 FortiGate로 중앙 통제할 수 있습니다.