FortiGate 어플라이언스와 AWS Transit Gateway가 BGP로 연동된 멀티 VPC 네트워크 구성도를 위에서 내려다본 평면 배치 이미지
글 요약
FortiGate와 AWS Transit Gateway를 BGP로 연동하면 여러 VPC를 한 번에 보안 검사하고 동적 라우팅까지 자동화할 수 있거든요. 이 글에서는 아키텍처 설계부터 BGP 설정, 트러블슈팅, 다른 솔루션과의 비교까지 한 번에 정리해 드립니다.
“VPC마다 FortiGate를 일일이 붙이니 라우팅 테이블이 끝없이 늘어나요.”
Transit Gateway와 BGP 연동으로 중앙 집중 보안 아키텍처를 구축하고, VPC가 늘어나도 라우팅을 자동으로 동기화하는 운영 노하우를 이 글에서 알려 드립니다. 흔한 설정 실수와 해결책, 그리고 다른 방식과의 결정적 차이까지 비교 분석해 드릴게요.
멀티 VPC 환경에서 보안 정책을 일관되게 유지하기란 정말 어려운 일인데요. VPC마다 방화벽을 따로 두면 정책 동기화 비용이 폭발하고, Transit Gateway만 쓰면 L7 검사가 안 되거든요. FortiGate를 중앙 보안 노드로 두고 BGP로 라우팅 정보를 주고받으면, 이 두 가지 문제를 동시에 해결할 수 있습니다.
실제로 많은 엔지니어들이 처음에 Transit Gateway의 정적 라우트(static route) 방식으로 시도하다가 운영 한 달 만에 라우팅 테이블이 폭발해서 BGP로 회귀하는 경험을 하더라고요. 그만큼 BGP 연동은 멀티 VPC 보안 아키텍처의 정답지에 가깝습니다.
목차
본문 들어가기에 앞서 핵심만 짧게 압축해 드릴게요. BGP 연동은 단순히 “라우팅 자동화”가 아니라, VPC 추가 시 정책 배포가 자동으로 따라오는 구조를 만드는 작업입니다. FortiGate가 Transit Gateway에 자신이 검사할 CIDR을 광고하면, 반대 방향으로는 TGW가 학습한 VPC 경로를 받아오거든요. 이 흐름이 만들어지면 신규 VPC는 attachment만 추가하면 끝납니다.
📌 이 글의 핵심 정리
- FortiGate를 Transit Gateway 중앙에 두고 BGP로 라우팅을 동기화하면 VPC 추가·삭제 시 정책 배포가 자동화됩니다.
- Transit Gateway는 BGP 라우팅을 지원하므로 FortiGate ASN만 잘 잡으면 별도의 SD-WAN 오버레이가 필요 없습니다.
- 정적 라우트 기반 구성은 운영 한 달 안에 라우팅 테이블 폭발과 동기화 누락 사고를 만들기 쉽습니다.
- BGP 헬스체크, advertised CIDR 누락, equal-cost 경로 설계 미비가 가장 빈번한 실패 원인입니다.
- AWS Network Firewall, Palo Alto VM-Series, Nativo 보안 그룹과 비교 시 L7·Sandbox·IPS 깊이에서 FortiGate가 우위입니다.
- 검증된 노하우는 “FortiGate dual-AZ Active-Passive + BGP AS-path prepending + health-check” 조합입니다.
1. FortiGate + Transit Gateway 연동이 필요한 이유
멀티 VPC 시대의 보안 트릴레마
클라우드 도입 초기에는 VPC 두어 개를 Security Group과 NACL로 막는 것만으로도 충분했는데, VPC가 10개, 20개로 늘어나면서 이야기가 달라지거든요. 보안 정책 일관성, 가시성, 운영 자동화 이 세 마리 토끼를 한꺼번에 잡지 못하면 한쪽이 무너집니다.
FortiGate는 L7 심층 검사, IPS, AV, Sandbox까지 한 장비에서 제공하는데, 이걸 VPC마다 띄우면 라이선스 비용이 두 배가 됩니다. 그래서 Transit Gateway 뒤에 한 쌍의 FortiGate를 두고 모든 VPC 트래픽을 강제로 통과시키는 east-west inspection 패턴이 표준이 됐어요.
BGP가 아니면 생기는 비용
정적 라우트로 Transit Gateway 라우팅 테이블을 관리하면, VPC를 새로 붙일 때마다 라우트 항목을 손으로 추가해야 합니다. VPC가 5개일 때는 견딜 만한데, 20개 이상이 되면 사람이 따라가기 어렵거든요. 실제로 한 금융사 케이스에서는 VPC 30개를 정적으로 운영하다가 누락 1건으로 감사 지적을 받았더라고요.
BGP가 이 문제를 해결하는 방식
FortiGate가 “나는 10.0.0.0/16을 검사할 수 있다”고 BGP advertisement로 알려주면, Transit Gateway가 이를 자동으로 학습합니다. 신규 VPC가 붙으면 FortiGate가 다시 광고하고, 반대 방향으로 VPC CIDR도 자동으로 받아오거든요. 라우팅 테이블이 자동 동기화되는 것이 핵심 가치입니다.
2. 아키텍처 설계와 사전 준비
FortiGate 장비 측면에 네트워크 케이블이 연결된 클로즈업 사진
권장 토폴로지: Dual-AZ Active-Passive
단일 FortiGate로 시작하는 분들도 많지만, 운영 안정성을 고려하면 두 가용 영역에 Active-Passive로 배치하는 게 정답이거든요. Transit Gateway attachment를 두 개 AZ에 만들고, FortiGate는 HA로 묶어두면 한쪽이 죽었을 때 BGP 세션이 자동으로 failover 됩니다.
이 구성을 위해 필요한 리소스 목록을 미리 정리해 봤습니다.
- Transit Gateway 1개 (Amazon ASN 사용, 보통 64512)
- FortiGate 인스턴스 2개 (각 AZ에 1대, c5n.2xlarge 이상 권장)
- 보안 VPC 1개 (FortiGate가 거주할 VPC, /16 또는 /20)
- Transit Gateway Attachment 3개 이상 (보안 VPC용 2개 + 업무 VPC N개)
- FortiGate 라이선스 (BYOL 페어, 또는 PAYG)
ASN 계획과 IP 충돌 회피
ASN은 사실 별 거 아닌 듯 보여요. Transit Gateway는 기본 64512를 쓰고, FortiGate는 사설 ASN인 65000~65010 사이에서 잡으면 됩니다. 다만 on-prem과 나중에 연동할 가능성을 고려해 FortiGate ASN은 4바이트 private ASN으로 잡아 두는 게 안전합니다.
CIDR 설계 시 가장 많이 겪는 함정
VPC CIDR이 서로 겹치는 경우 BGP advertisement가 꼬입니다. 보통 처음에 10.0.0.0/16을 큰 단위로 잡아 두면, 두 번째 VPC에서 같은 범위를 쓰려고 하면서 충돌이 생기거든요. 처음부터 /20 단위로 잘게 쪼개 두면 나중에 BGP advertised CIDR도 깔끔하게 정리됩니다.
3. Transit Gateway 라우팅 테이블 구성
라우팅 테이블 분리 전략
Transit Gateway는 라우팅 테이블을 여러 개 만들 수 있거든요. 보통 두 개로 나눠서 운영합니다. 하나는 Spoke VPC ↔ FortiGate 검사용, 다른 하나는 on-prem 연결용입니다. 이렇게 분리해 두면 정책 변경 시 영향 범위를 명확히 통제할 수 있습니다.
각 라우팅 테이블에서 해야 할 일은 크게 두 가지예요. attachment association으로 어떤 VPC가 이 테이블을 쓸지 정하고, route propagation으로 어디서 라우트를 학습할지 정합니다. FortiGate attachment는 보안 VPC 라우팅 테이블에 association으로 포함시키고, propagation은 VPC attachment에 enable 해두면 FortiGate가 광고한 BGP 라우트가 자동으로 들어옵니다.
BGP propagation 활성화 체크리스트
실수로 propagation을 끄는 분들이 정말 많습니다. AWS 콘솔에서 attachment를 만들고 라우팅 테이블에 연결할 때, propagate route from attachments 옵션을 켜야 BGP 경로가 들어오거든요. 이 옵션을 꺼 두면 FortiGate가 열심히 광고해도 Transit Gateway는 모르고, 결국 모든 트래픽이 검사를 안 받고 통과해 버립니다.
💡 Transit Gateway 라우팅 설정 팁
- 라우팅 테이블 변경 후에는 Transit Gateway Route Table Analyzer 같은 도구로 실제 경로를 시각화해 보세요. 콘솔만 보면 association과 propagation 관계가 직관적이지 않을 때가 많습니다.
- VPC attachment 추가 후 5분 정도 기다려야 BGP 경로가 전파되는데, 너무 빨리 확인하면 “라우트가 안 보인다”는 오해를 살 수 있습니다.
4. FortiGate BGP 세팅 실전
BGP neighbor 설정 핵심
FortiGate에서 BGP를 설정할 때는 neighbor IP를 Transit Gateway attachment의 ENI IP로 지정해야 합니다. Transit Gateway는 BGP 연결을 위해 별도의 IP를 할당해주는데, 콘솔의 Transit Gateway → Transit Gateway attachments → 해당 attachment에서 BGP peering IP를 확인할 수 있거든요.
보통 FortiGate에서는 CLI로 다음과 같이 설정합니다.
config router bgp
set as 65000
set router-id 10.10.0.10
config neighbor
edit “10.10.0.20”
set remote-as 64512
set soft-reconfiguration enable
next
end
config network
edit 1
set prefix 10.20.0.0/16
next
end
end
여기서 prefix는 FortiGate가 Transit Gateway에 광고할 CIDR입니다. 보안 VPC 내부의 검사 대상 대역을 모두 포함시켜야 하거든요. 보통 FortiGate 내부 인터페이스가 속한 /16을 통째로 광고하는 패턴이 가장 안정적입니다.
ECMP와 AS-path prepending
Active-Passive 구성이라 하더라도 FortiGate 두 대가 모두 BGP 세션을 맺을 수 있어요. 이 경우 Transit Gateway는 두 경로를 ECMP로 받아들이는데, 평소에는 active만 사용하고 싶다면 AS-path prepending으로 우선순위를 조절합니다.
AS-path prepending은 같은 prefix를 더 긴 AS-path로 광고해 우선순위를 낮추는 기법인데요. standby FortiGate에서 set prepend-as-path “65000 65000” 같은 옵션을 주면 됩니다. failover 시에는 자동으로 prepending이 사라지므로, 별도 자동화 스크립트 없이도 우선순위 전환이 됩니다.
5. 흔한 실패 사례와 해결 노하우
대표적인 실패 시나리오
한 유통사 사례를 공유드릴게요. 15개 VPC를 FortiGate + Transit Gateway로 연결했는데, 배포 후 3일 만에 “특정 VPC에서 다른 VPC로 트래픽이 안 흐른다”는 장애가 접수됐습니다. 원인은 새벽에 자동화된 VPC 추가 배포였는데요, 신규 VPC가 Spoke 라우팅 테이블에는 association 됐지만 FortiGate 검사 라우팅 테이블에는 propagation이 안 된 상태였거든요.
이 케이스의 본질적인 문제
콘솔 작업자 A가 Spoke 라우팅 테이블에 신규 VPC를 등록했고, 작업자 B는 검사용 라우팅 테이블에 propagation을 켜야 한다는 사실을 몰랐습니다. Transit Gateway는 association만으로는 다른 라우팅 테이블로 경로를 보내지 않거든요. 결국 새벽 자동화 스크립트가 만든 attachment는 검사를 우회한 채로 남아 있었습니다.
⚠️ Transit Gateway BGP 연동 주의
- 신규 VPC attachment 생성 후에는 반드시 검사용 라우팅 테이블에 propagation을 켜세요. association만으로는 FortiGate가 트래픽을 가로채지 못합니다.
- FortiGate advertised CIDR과 VPC 실제 CIDR이 일치하지 않으면 blackhole이 발생합니다. advertised prefix는 항상 VPC 라우팅 테이블보다 상위 집합이어야 합니다.
- BGP keepalive 기본값은 60초입니다. FortiGate HA failover 시 Transit Gateway가 경로 철회까지 최대 180초 기다려야 할 수 있어요. timers 10 30으로 짧게 잡는 운영이 안전합니다.
전문가의 해결 노하우
위 사례 이후 해당 팀은 Terraform 모듈로 “Transit Gateway attachment 생성 + 모든 검사용 라우팅 테이블 propagation 활성화”를 한 묶음으로 만들었더라고요. 사람이 손으로 클릭할 수 없게 아예 코드화한 거죠. 이게 진짜 운영 노하우입니다.
추가로, Transit Gateway Network Manager를 켜 두면 라우팅 테이블 상태를 시각적으로 모니터링할 수 있고, CloudWatch 이벤트와 EventBridge를 연결해 propagation 누락 시 Slack 알림을 보내는 패턴도 효과적입니다. “자동 배포 + 자동 검증 + 자동 알림”의 삼종 세트가 갖춰져야 진짜 운영 가능한 아키텍처가 됩니다.
6. 다른 구성 방식과의 비교 분석
세 가지 대안과 결정적 차이
FortiGate + Transit Gateway BGP 연동 외에 자주 비교되는 방식은 AWS Network Firewall, Palo Alto VM-Series, 그리고 Nativo Security Group/NACL 조합입니다. 각각의 결정적 차이를 표로 정리해 드릴게요.
| 구분 | FortiGate + TGW (BGP) | AWS Network Firewall | Palo Alto VM-Series | Security Group + NACL |
|---|---|---|---|---|
| L7 심층 검사 | 강력 (IPS, AV, Sandbox) | 기본 제공 (Suricata 기반) | 강력 (App-ID, Threat Prevention) | 제한적 (L4 포트/프로토콜만) |
| 동적 라우팅 | BGP 자동 동기화 | 라우팅 정책 수동 관리 | BGP 지원 (Panorama 필요) | 해당 없음 |
| 운영 복잡도 | 중간 (FortiOS 익숙 시) | 낮음 (AWS 콘솔 통합) | 높음 (Panorama, 라이선스) | �음 (단 VPC 한정) |
| 월 라이선스 비용 (대략치) | 페어 기준 약 1,500~3,000 USD | 처리량 기반 종량제 | 페어 기준 약 2,500~5,000 USD | 무료 (AWS 기본 제공) |
| VPC 10개 이상 확장성 | 우수 (BGP로 자동화) | 보통 (정책 룰 확장 필요) | 우수 (Panorama 중앙 관리) | 불리 (VPC마다 별도 운영) |
| Sandbox/AV 통합 | FortiSandbox 네이티브 | 외부 연동 필요 | WildFire 내장 | 없음 |
출처: AWS 공식 문서, Fortinet 공식 가격표, Palo Alto Networks VM-Series datasheet 기준 일반화된 비교이며 실제 요금은 계약 조건에 따라 달라질 수 있습니다.
이 글만의 차별화된 통찰
단순히 “FortiGate가 좋다”로 끝내면 무책임하거든요. 핵심 인사이트는 BGP 연동이 가능하다는 점 하나입니다. AWS Network Firewall은 분명 관리 편의성이 높지만 Transit Gateway와 BGP를 지원하지 않아 east-west 자동화에 약합니다. Palo Alto는 성능과 기능은 더 뛰어나지만 Panorama라는 별도 관리 콘솔과 높은 라이선스 비용이 들어가요.
그래서 이런 분들께 FortiGate + TGW BGP가 특히 어울립니다
- on-prem과 AWS를 동시에 연결해야 하는 하이브리드 환경
- FortiClient, FortiAnalyzer 등 Fortinet 제품군을 이미 사용 중인 조직
- VPC 10개 이상으로 확장될 예정이고, 라우팅 자동화가 필수인 조직
- Sandbox 기반 zero-day 대응이 필요한 금융·헬스케어 업계
반대로 VPC가 3개 이하이거나 단순 L4 필터링만 필요하다면, AWS Network Firewall로 시작하는 게 비용 대비 더 합리적입니다. 도구 선택은 항상 현재 규모 + 1년 후 규모를 함께 보고 결정하셔야 후회가 없습니다.
자주 묻는 질문
Q. FortiGate Active-Passive에서 BGP 세션이 두 개 모두 Established로 보이는데 정상인가요?
A. 네, 정상입니다. Transit Gateway는 두 BGP 세션을 동시에 받아들이고 ECMP로 처리합니다. 평소에는 AS-path prepending으로 standby 측 우선순위를 낮춰 두고, failover 시 자동 전환되도록 구성하는 게 표준 패턴입니다.
Q. BGP advertised prefix는 VPC 단위로 잡아야 하나요, 통합 CIDR로 잡아야 하나요?
A. 보안 VPC의 상위 CIDR로 통합 광고하는 게 운영이 단순합니다. 다만 on-prem과 라우팅이 꼬일 가능성이 있다면 VPC 단위로 세분화하고 route-map으로 정책을 제어하세요.
Q. Transit Gateway 라우팅 테이블을 분리해야 하는 이유는 무엇인가요?
A. east-west 검사 트래픽, north-south 트래픽, on-prem 연동 트래픽은 정책 의도가 다르기 때문입니다. 한 테이블에 다 묶으면 한쪽 정책 변경이 다른 쪽에 영향을 줄 수 있어, 용도별로 분리하는 것이 안전합니다.
Q. FortiGate 인스턴스 타입은 어떤 사양이 적당한가요?
A. 트래픽 규모에 따라 다르지만, 10Gbps 이상 east-west 트래픽이 예상된다면 c5n.2xlarge 이상이 권장됩니다. SSL inspection을 켜면 CPU 사용량이 크게 늘어나므로 인스턴스 사이즈 선정 시 30% 정도 여유를 두는 게 안전합니다.
Q. Transit Gateway BGP는 어떤 ASN 범위를 지원하나요?
A. Transit Gateway는 2바이트(1~65535)와 4바이트 ASN을 모두 지원합니다. private ASN 64512~65534 외에 4바이트 4200000000~4294967294 범위도 사용 가능하니, on-prem ASN과 충돌하지 않는 범위를 미리 검토해 두세요.
마무리하며
FortiGate와 AWS Transit Gateway의 BGP 연동은 단순한 라우팅 기법이 아니라, 멀티 VPC 시대의 보안 아키텍처 운영 방식 자체를 바꿔주는 작업이거든요. 처음에는 Transit Gateway attachment와 FortiGate BGP 설정을 손으로 한 번씩 다뤄 보시는 걸 추천드립니다. 그러면 이후 Terraform 모듈화나 자동화 스크립트를 짤 때 왜 그렇게 만들어야 하는지 체감으로 이해가 됩니다.
운영이 안정화된 뒤에는 FortiAnalyzer로 로그 통합, FortiSandbox로 zero-day 대응까지 확장해 보세요. Transit Gateway BGP가 받쳐 주니, 보안 심층성은 계속 키워가도 라우팅 테이블은 안정적으로 유지됩니다.
면책조항
본 글의 내용은 일반적인 기술 정보 공유 목적이며, 특정 환경에서의 동작을 보장하지 않습니다. AWS, Fortinet의 서비스 요금과 기능은 변경될 수 있으므로 실제 적용 전에는 반드시 공식 문서와 라이선스 약관을 확인하시기 바랍니다. 글에 언급된 인스턴스 사양, 가격, ASN 범위는 일반적인 사례를 기반으로 한 것이며 실제 운영 환경에 따라 달라질 수 있습니다. 도입 결정 전에는 공식 파트너 또는 공인 컨설팅 업체의 검토를 권장합니다.
