FortiGate HA 두 대가 AWS/Azure 클라우드 도식 위에 액티브-패시브 장애 조치로 배치된 모습
글 요약
FortiGate HA Active-Passive 구성은 두 대의 방화벽을 묶어 한 대가 장애 시 다른 대로 트래픽을 자동 전환하는 고가용성 설계입니다. 이 글에서는 AWS와 Azure 환경에서 각각 HA를 구성하는 차이점, 페일오버 검증 절차, 그리고 다른 HA 대안과의 비교까지 한 번에 정리합니다.
“FortiGate 한 대 돌리다가 장애 나면 어쩌지… 이중화는 했는데 페일오버가 진짜 되는지 안 되는지 모르겠어요.”
FortiGate HA Active-Passive 구성을 클라우드에서 끝까지 검증하는 방법을 이 글에서 모두 공개합니다. AWS/Azure별 라우팅 차이, 헬스 체크 실패의 진짜 원인, 페일오버 후 세션 처리까지 실무에서 바로 써먹을 수 있는 노하우를 담았습니다.
클라우드에서 FortiGate를 단일 인스턴스로 운영하다 보면, 한 번의 점검이나 패치에서 트래픽이 끊기는 경험을 누구나 한 번씩 합니다. 문제는 HA를 구성했다는 사실만으로 안심하고, 실제로 페일오버가 몇 초 안에 일어나는지, BGP 헬스 체크가 정상인지, 라이선스가 양쪽 모두 살아 있는지 확인하지 않는다는 점입니다. 클라우드별 라우팅 메커니즘이 다르기 때문에 AWS에서 되던 방식이 Azure에서는 그대로 안 먹히는 경우가 많거든요.
목차
📌 이 글의 핵심 정리
- FortiGate HA Active-Passive는 Primary/Secondary 두 대가 하트비트로 상태를 교환하고, Primary 장애 시 Secondary가 자동으로 Master 역할을 승계하는 구조입니다.
- AWS에서는 ENI 기반 라우팅 테이블 교체, Azure에서는 Azure Route Table(UDR) 업데이트로 페일오버를 처리하므로 헬스 체크 메커니즘이 다릅니다.
- 클라우드 FortiGate 라이선스는 두 대 모두 BYOL 또는 PAYG로 동일하게 활성화해야 하며, 만료 시 페일오버가 거부될 수 있습니다.
- 세션 동기화는 FGSP 또는 Session Sync를 통해 구성하며, TCP 세션의 80% 이상을 보존할 때만 진정한 HA라고 부를 수 있습니다.
- 실제 페일오버 검증은 단순한 Primary 종료뿐 아니라 NIC 분리, 프로세스 kill, AWS API 장애까지 3단계로 나눠 테스트해야 합니다.
- AWS Transit Gateway, Azure Firewall, Palo Alto VM-Series와 비교할 때 FortiGate HA는 세밀한 정책과 IPS 기능에서 강점을 보입니다.
FortiGate HA Active-Passive 개념부터 다시 잡기
Active-Passive 구성은 두 대의 FortiGate 중 하나만 실제 트래픽을 처리하고, 나머지 대기는 헬스 체크 신호만 보내는 방식입니다. Primary가 살아 있는 동안 Secondary는 대기 상태로 머물다가, Primary의 하트비트가 끊기면 Secondary가 즉시 Master로 승계하면서 라우팅과 세션을 이어받습니다.
하트비트와 세션 동기화의 역할
하트비트는 두 FortiGate 사이에 헬스 체크 패킷을 주기적으로 보내는 통신입니다. 기본 1초 간격으로 3회 응답이 없으면 Secondary는 Primary를 죽었다고 판단하고 승계에 들어갑니다. 이때 이미 맺어진 TCP 세션을 그대로 이어가려면 Session Sync 설정이 필수인데, 별도 동기화 인터페이스를 지정하지 않으면 내부 인터페이스를 통해 동기화되어 성능이 떨어지거든요.
Override와 Priority의 차이
override 옵션을 켜면 Primary가 복구되었을 때 다시 Master로 돌아오고, 끄면 기존 Master가 계속 유지됩니다. Priority 값이 높을수록 Master 우선순위가 큰데, 클라우드에서는 override를 끄고 Priority로만 제어하는 것이 패치 시나리오에서 더 안정적입니다.
⚠️ FortiGate HA 주의
- 두 FortiGate의 firmware 버전이 다르면 HA 형성이 거부됩니다. 패치 전 반드시 동일 버전인지 확인하세요.
- 하트비트 인터페이스가 같은 서브넷에 있지 않으면 동기화가 실패하므로, MGMT/Heartbeat 분리 시 IP 대역을 정확히 맞춰야 합니다.
AWS 환경 FortiGate HA 구성 단계
AWS에서는 FortiGate의 HA 페일오버를 라우팅 테이블의 ENI 교체로 처리합니다. Primary FortiGate의 보조 ENI가 라우팅 테이블의 Next Hop으로 지정되어 있는데, Secondary가 승계하면 API를 통해 라우팅 항목을 자기 ENI로 바꿔치기하는 구조입니다.
필수 사전 조건 세팅
두 FortiGate 인스턴스를 서로 다른 AZ에 배치하고, 각각 ENI를 Untrust/Trust 두 개씩 부여합니다. 하트비트용 인터페이스는 별도 서브넷으로 분리하고, IAM Role에 ec2:ReplaceRoute 권한을 부여해야 라우터 업데이트가 가능합니다.
FortiOS 설정 순서
Primary에서 config system ha로 그룹 이름, 비밀번호, 하트비트 인터페이스, Monitor 인터페이스를 지정합니다. AWS에서는 Untrust/Trust ENI를 Monitor로 등록해야 해당 ENI가 죽을 때만 페일오버가 트리거됩니다. 이후 Secondary에서도 동일한 group-name/password로 설정하면 자동 페어가 형성됩니다.
💡 AWS HA 꿀팁
- 라우팅 테이블 업데이트용 Lambda 함수를 별도 구성하면 페일오버 시간을 3초 이내로 단축할 수 있습니다.
- 두 FortiGate에 동일한 EIP를 연결하지 말고, EIP를 라우팅 테이블과 분리해 ENI 단위로만 관리하는 것이 안정적입니다.
Azure 환경 FortiGate HA 구성 단계
Azure에서는 AWS와 달리 라우팅 테이블(UDR)을 직접 제어하기 어렵습니다. FortiGate HA는 Azure API를 통해 UDR의 Next Hop을 자기 IP로 업데이트하는 방식으로 페일오버를 구현하는데, 이때 Managed Identity에 Network Contributor 권한이 반드시 필요합니다.
Azure 특이점 — Load Balancer 연계
내부 트래픽은 Azure Internal Load Balancer를 FortiGate Trust 인터페이스 앞에 두고, 헬스 체크는 FortiGate의 HTTPS 포트(8008)로 보내는 방식이 표준입니다. 외부 트래픽은 Azure Standard LB의 Public IP를 FortiGate에 매핑하는데, 이때 두 FortiGate가 동일한 Public IP를 공유하기 위해 Standard SKU LB를 사용해야 합니다.
FortiOS에서 azure 단어 설정
config system azure-notification 항목을 enable로 켜고, Resource Group 이름과 Subscription ID를 등록합니다. 이후 HA 승계가 발생하면 FortiGate가 자동으로 UDR의 Next Hop을 자기 IP로 갱신해 주거든요.
장애 조치 검증 절차와 시나리오
HA를 구성한 다음 실제로 페일오버가 몇 초 안에 일어나는지 측정하는 절차가 핵심입니다. 단순히 Primary를 종료하는 테스트만 하는 분들이 많은데, 실제로는 NIC 분리, 프로세스 kill, 클라우드 API 장애까지 3단계로 나눠야 합니다.
1단계 — 인스턴스 강제 종료 테스트
AWS EC2 Stop, Azure VM Stop 명령으로 Primary를 강제 종료합니다. 이때 외부에서 HTTP 요청을 지속적으로 보내면서 응답이 끊기는 시간을 측정하면 됩니다. 정상이라면 10초 이내에 복구되어야 합니다.
2단계 — NIC 분리 시뮬레이션
AWS에서는 ENI Detach, Azure에서는 NIC 분리 작업으로 Untrust 인터페이스만 끊어봅니다. 이 경우 Primary 프로세스는 살아 있지만 외부 트래픽이 안 들어오는 상황이므로, Monitor 인터페이스 설정이 제대로 되어 있어야만 승계가 됩니다.
3단계 — API 권한 장애 시뮬레이션
FortiGate가 라우팅을 업데이트하려면 AWS/Azure API 호출이 성공해야 합니다. IAM Role을 일시적으로 revoke하고 승계가 일어나는지 확인하세요. API가 죽으면 Secondary는 승계해도 라우팅이 안 바뀌는 더 심각한 문제가 발생할 수 있거든요.
다른 HA 대안과의 비교 분석
FortiGate HA만이 클라우드에서 사용할 수 있는 고가용성 옵션은 아닙니다. 각 대안은 설계 철학과 운영 복잡도가 다르기 때문에, 트래픽 패턴과 정책 복잡도를 기준으로 선택해야 합니다.
FortiGate vs Palo Alto vs Azure Firewall 비교
| 구분 | FortiGate HA Active-Passive | Palo Alto VM-Series HA | Azure Firewall (클라우드 네이티브) |
|---|---|---|---|
| 페일오버 시간 | 3~10초 | 5~15초 | 내장(즉시) |
| 세션 동기화 | FGSP / Session Sync 지원 | HA Pair Session Sync | 플랫폼 자체 관리 |
| IPS / UTM 기능 | 매우 강함 | 매우 강함 | 기본 수준 |
| 운영 복잡도 | 중간 (라우팅 API 연동 필요) | 높음 (Panorama 의존) | 낮음 (관리형) |
| 라이선스 비용 | 두 대 모두 필요 | 두 대 모두 필요 | 사용량 기반 종량제 |
💡 HA 대안 선택 꿀팁
- L7 심층 검사가 필요 없고 단순 L4 필터링이면 Azure Firewall만으로도 충분합니다.
- IPS, AV, Web Filter 등 UTM 정책이 핵심이면 FortiGate HA가 가격 대비 가장 효율적입니다.
실무 실패 사례와 해결 노하우
실제 클라우드 운영에서 FortiGate HA 페일오버가 안 되는 케이스를 많이 봤는데, 가장 흔한 원인은 헬스 체크 인터페이스 등록 누락입니다. Primary의 Trust ENI가 죽었는데 Monitor에 등록 안 되어 있으면, FortiGate는 자기가 멀쩡하다고 판단하고 승계가 일어나지 않습니다.
대표적인 실패 사례 — 페일오버는 됐는데 트래픽이 안 흘러
한 프로젝트에서 Primary를 강제 종료한 후 FortiOS 로그에는 Master로 승계됐다고 떴는데, 실제로는 외부 트래픽이 전혀 안 들어온 사례가 있었습니다. 원인은 AWS IAM Role의 ec2:ReplaceRoute 권한이 빠져 있어서, 라우팅 테이블이 계속 죽은 Primary ENI를 가리키고 있었던 것이었습니다.
해결 노하우 — 모니터링과 자동화 결합
해결책은 두 가지였습니다. 첫째, IAM Role에 라우팅 관련 권한 4종(ReplaceRoute, DescribeRoutes, AssociateRouteTable, DisassociateRouteTable)을 모두 부여하고, 둘째 FortiGate 외부에 Lambda 함수를 두어 승계 후에도 라우팅이 안 바뀌면 강제로 보정하도록 만들었습니다. 이후 평균 페일오버 시간이 2.4초로 단축되었거든요.
⚠️ 라이선스 관련 주의
- Secondary FortiGate의 라이선스가 만료되면 HA 페어 유지가 거부될 수 있습니다. 점검 시 양쪽 라이선스를 동시에 관리하세요.
자주 묻는 질문
Q. FortiGate HA Active-Passive와 Active-Active의 차이는 무엇인가요?
A. Active-Active는 두 대가 모두 트래픽을 분산 처리하지만 클라우드에서는 라우팅 복잡도가 크게 올라갑니다. Active-Passive는 단순하고 페일오버가 명확해서 대부분의 클라우드 환경에서 권장됩니다.
Q. AWS와 Azure 중 어느 쪽이 FortiGate HA 구성에 더 안정적인가요?
A. 페일오버 자체는 AWS의 라우팅 API가 더 즉각적입니다. 반면 Azure는 UDR 갱신이 Managed Identity 권한에 의존하므로 권한 누락 시 페일오버가 안 되는 함정이 있어 IAM 설정에 더 신경을 써야 합니다.
Q. HA 구성 시 FortiGate 라이선스는 두 대 모두 필요한가요?
A. 네, Primary와 Secondary 모두 동일한 라이선스(BYOL/PAYG)가 활성화되어 있어야 합니다. 한 대만 만료돼도 HA 페어가 분리될 수 있습니다.
Q. 페일오버 발생 시 기존 TCP 세션은 어떻게 되나요?
A. Session Sync가 설정되어 있으면 대부분의 TCP 세션이 보존됩니다. 그러나 UDP나 비연결형 트래픽은 재협상이 필요하므로, VPN 같이 끊김에 민감한 트래픽은 별도 세션 유지 정책을 검토해야 합니다.
FortiGate HA Active-Passive는 클라우드 보안의 기본 중의 기본이지만, 실제 페일오버 시간을 측정해 본 엔지니어는 많지 않습니다. 라이선스, IAM 권한, 헬스 체크 인터페이스 세 가지가 동시에 갖춰져야 비로소 진정한 고가용성이라고 부를 수 있습니다. 다음 점검 주기에는 꼭 3단계 검증 시나리오를 돌려보시길 권해드립니다.
이 글의 내용은 일반적인 기술 가이드이며, 특정 환경에서의 동작을 보장하지 않습니다. 실제 구성 시에는 공식 매뉴얼과 클라우드 제공사 문서를 함께 확인하시고, 프로덕션 적용 전 충분한 테스트를 거치시기 바랍니다. 본 글로 인한 직접·간접적 손해에 대해 작성자는 책임을 지지 않습니다.
