Azure Firewall Basic·Standard·Premium 비교: 트래픽·검사·운영 요구로 선택하기

Azure Firewall에는 세 가지 SKU(기능·성능 등급)가 있다. 그래서 처음 비교할 때 흔히 Basic은 저렴하고, Standard는 보통이며, Premium이 가장 좋다는 가격 사다리로 이해한다. 솔깃하지만 잘못된 지름길이다. SKU는 가격만 바꾸지 않는다. 어떤 이름을 필터링할 수 있는지, 알려진 악성 목적지를 차단할 수 있는지, 암호화된 트래픽을 검사할 수 있는지, 문서화된 조건에서 서비스가 처리할 수 있는 트래픽 양은 얼마인지, 팀이 맡아야 할 운영 책임은 어느 정도인지가 달라진다.

도움이 되는 질문은 다음과 같은 질문이 아니다.

어떤 Azure Firewall SKU에 체크 표시가 가장 많은가?

다음 질문을 해야 한다.

어떤 트래픽이 중앙 정책 지점을 반드시 지나야 하는가?
그 트래픽을 얼마나 정밀하게 식별해야 하는가?
암호화·비암호화 트래픽을 어느 깊이까지 검사해야 하는가?
어느 정도의 최대 처리량과 단일 흐름 용량을 유지해야 하는가?
정책, 인증서, 경고, 예외와 롤백은 누가 운영할 것인가?

이 글은 Coursera Azure Cybersecurity Solutions and Microsoft Defender 강좌 Module 1을 12개 주제로 나눈 학습 계획의 여섯 번째 상세 노트다. Module 1 복습 글은 더 넓은 보안 지도를 제공한다. 바로 앞의 VNet·Subnet·NSG 기초 글에서는 주소 경계와 분산된 L3/L4 필터링을 설명했다. 이번에는 중앙 검사 지점으로 이동해 어떤 Azure Firewall 기능과 성능 경계가 워크로드에 맞는지 판단한다.

이 글은 강의 녹취록, 평가 답안, 운영 환경 배포 기록 또는 공급업체의 용량 보장을 대신하지 않는 독립 학습 노트다. 제품 동작, 성능 표와 문서 간 충돌은 2026년 8월 11일 Microsoft 공식 자료를 기준으로 검토했다.

이 글에서 명시적으로 다루지 않는 범위

이 글에서는 SKU를 선택하며 Portal, CLI, PowerShell, Bicep 또는 Terraform 배포 절차는 제공하지 않는다. 상세한 UDR과 DNS 아키텍처는 다음 글에서 다룬다. 규칙 구현, 구조화된 로그 쿼리와 검증 명령은 그다음 글의 주제다. 이후 비교 글에서는 DDoS Protection, NSG, Azure Firewall과 WAF를 함께 살펴볼 예정이다. 정확한 지역별 가격, Virtual WAN 보안 허브 설계, 타사 NVA 기능 표와 워크로드별 규정 준수 해석도 이 글의 범위에서 제외한다.

1. 이 글이 도와줄 의사결정

결정해야 할 질문은 다음과 같다.

이 워크로드에 Azure Firewall이 필요한가? 필요하다면 안전하지 않은 향후 마이그레이션 가정에 의존하지 않으면서 트래픽, 검사, 성능, 신뢰성, 비용과 운영 요구를 충족하는 최소 SKU는 무엇인가?

이 글을 읽은 뒤에는 다음 작업을 할 수 있어야 한다.

Firewall을 배포하는 것만으로 트래픽이 자동으로 그곳을 지나지 않는 이유를 설명한다.
Azure Firewall과 NSG, NAT Gateway, WAF, Network Virtual Appliance(NVA)를 구분한다.
세 SKU가 공통으로 제공하는 보안·관리 기능을 식별한다.
Basic을 장난감이나 느린 Standard가 아닌 명확한 경계가 있는 실제 SKU로 설명한다.
설계를 Basic에서 Standard로 올려야 하는 요구를 식별한다.
TLS 검사, IDPS, URL 수준 통제 또는 성능 증적으로 Premium을 정당화한다.
위협 인텔리전스 기반 평판 필터링과 서명 기반 IDPS를 구분한다.
HTTPS 전체 경로 검사가 인증서·개인정보 보호 프로그램을 만드는 이유를 설명한다.
전체 처리량과 하나의 대용량 흐름을 따로 해석한다.
Firewall 시간당 가격을 넘어선 총비용을 모델링한다.
정책 호환성과 롤백 증적을 포함해 SKU 마이그레이션을 계획한다.
선택한 통제가 의도한 트래픽을 실제로 처리함을 증명한다.

결과물은 SKU 드롭다운 화면 캡처가 아니라 다음과 같은 의사결정 기록이어야 한다.

필수 트래픽과 금지 트래픽
+ 경로와 우회 경로 목록
+ 검사 깊이 요구사항
+ 전체·단일 흐름 측정값
+ 선택한 SKU와 제외한 대안
+ 정책, DNS, PKI, 로그와 경고 담당자
+ 비용 모델과 성장 전환 조건
+ 성공, 실패, 성능과 복구 테스트
+ 마이그레이션과 롤백 계획

2. SKU가 아니라 통제 요구사항부터 시작하기

“Premium을 감당할 수 있는가?”라는 질문부터 시작하지 않는다. 연결과 위험부터 살펴본다.

요구사항 항목	질문	유용한 증적
방향	흐름이 아웃바운드, 인바운드 또는 워크로드 간 내부 트래픽(east-west)인가?	아키텍처와 흐름 목록
출발지	어느 Subnet, 워크로드 역할, Private 범위 또는 외부 Client가 연결을 시작하는가?	주소와 소유권 기록
목적지	대상이 IP, FQDN, URL 경로, Azure Service 또는 Category인가?	의존성 목록
Protocol과 Port	L3/L4 필터링이면 충분한가, 아니면 애플리케이션 맥락이 필요한가?	애플리케이션 통신 계약
암호화	HTTPS를 End-to-end로 유지해야 하는가, 아니면 승인된 TLS 검사가 필요한가?	위협, 개인정보 보호와 규정 준수 결정
위협 대응	경고면 충분한가, 아니면 알려진 지표와 서명을 차단해야 하는가?	탐지·대응 요구사항
전체 부하	평상시, p95, 최대, 이벤트 발생 시 트래픽 양은 얼마인가?	흐름과 성능 Metric
단일 흐름	하나의 Backup, Replication 또는 전송 Session이 매우 클 수 있는가?	연결별 테스트
가용성	Zone 복원력이면 충분한가, 지역 장애 복구는 어떻게 설계하는가?	신뢰성 목표와 Runbook
운영	규칙, DNS, 인증서, 오탐, 로그와 사고는 누가 담당하는가?	RACI와 On-call 계획
경제성	어느 정도의 고정·변동·Telemetry·인건비를 허용할 수 있는가?	비용 모델과 예산

이 과정을 거치면 Azure Firewall이 필요 없다는 정당한 결론이 나올 수도 있다. 작은 워크로드에 Subnet 수준 L3/L4 분리만 필요하다면 NSG로 충분할 수 있다. 예측 가능한 아웃바운드 SNAT와 높은 연결 확장성만 필요하다면 NAT Gateway가 맞을 수 있다. 인바운드 HTTP 공격 보호가 필요하다면 WAF가 관련 통제다. 필요한 통제를 다른 곳에서 제공하고 잔여 위험을 명시적으로 수용했다면 Firewall을 선택하지 않는 것도 책임 있는 결정이다.

3. Azure Firewall의 네 가지 용어와 한 가지 선행 조건 익히기

서로 다른 역할을 하는 여러 객체를 일상적으로 모두 “Firewall”이라고 부르곤 한다.

개념	의미	입문자가 하기 쉬운 실수
Azure Firewall Resource	Private 주소와 선택적 Public Data Path 주소를 가진 관리형 Enforcement Service	존재하는 것만으로 Route가 바뀐다고 생각함
Firewall Policy	보안·운영 설정을 담는 별도의 정책 Resource	정책을 Firewall 하나 안에 저장된 화면 캡처처럼 취급함
SKU	Basic, Standard 또는 Premium의 기능·성능 경계	과금 등급으로만 생각함
규칙 계층	Rule Collection Group, Collection과 개별 NAT·Network·Application Rule	모든 Priority가 하나의 평면 목록에서 순서대로 평가된다고 생각함
Routing 선행 조건	트래픽이 Firewall을 지나게 만드는 UDR, Routing Intent 또는 Topology	트래픽이 우회하는데도 정책을 테스트함

사용하는 기능에 맞게 Policy Tier와 Firewall Tier가 호환되어야 한다. Premium Firewall은 이름에 Premium이 들어간다는 이유만으로 TLS 검사 기능을 얻지 않는다. 호환되는 Premium Policy와 명시적인 기능 설정이 필요하다. 반대로 Premium 전용 기능이 담긴 Policy를 하위 Tier Firewall에 단순히 연결할 수 없다.

다음 핵심 모델을 기억한다.

Route는 트래픽이 Azure Firewall에 도달하는지를 결정한다.
Policy는 Azure Firewall이 그 트래픽을 어떻게 처리할지 결정한다.
SKU는 사용할 수 있는 Policy 기능과 성능 한계를 정의한다.
증적은 실제 결과를 입증한다.

4. Azure Firewall과 인접 통제 구분하기

다음은 제품 전체를 비교하는 표가 아니라 경계를 요약한 표다.

통제	가장 적합한 질문	증명하거나 대체하지 못하는 것
NSG	이 출발지·목적지·Protocol·Port 흐름이 Subnet 또는 NIC 경계를 통과해도 되는가?	중앙 FQDN 정책, SNAT, TLS 검사, IDPS 또는 WAF
NAT Gateway	Private 아웃바운드 트래픽이 어떤 명시적 Public IP와 SNAT 용량을 사용해야 하는가?	목적지 정책, 콘텐츠 검사, 요청하지 않은 인바운드 게시 또는 SIEM에 바로 쓸 Firewall 판정
Azure Firewall	중앙으로 Routing된 Network 또는 Application 트래픽을 허용·차단·변환·기록·검사해야 하는가?	Route 생성, 사용자 신원, Secure Coding, Endpoint Protection 또는 지역 DR
WAF	인바운드 HTTP/S Request가 SQL Injection이나 XSS 같은 웹 공격 형태인가?	일반 TCP/UDP Egress, 비웹 Protocol 또는 Subnet 분리
NVA	특정 공급업체의 가상 어플라이언스가 전문 검사, SD-WAN, VPN 또는 정책 요구를 충족하는가?	제품이 명시적으로 제공하지 않는 한 Azure 관리형 Lifecycle

Azure Firewall과 NSG는 흔히 함께 사용한다. NSG는 최소 권한 경계를 워크로드 가까이에 두고, Azure Firewall은 여러 Network에서 선택한 트래픽을 중앙 통제한다. 지원되는 설계에서는 NAT Gateway를 AzureFirewallSubnet에 연결해 Azure Firewall이 검사를 계속 수행하면서 아웃바운드 SNAT 용량을 늘릴 수도 있다. 제품이 많다고 자동으로 더 안전해지는 것은 아니다. Data Path, 담당자, 장애 동작과 비용을 계속 이해할 수 있어야 한다.

Azure Firewall Premium도 인바운드 Web Application Firewall은 아니다. Premium TLS 검사는 아웃바운드와 east-west Forward Proxy 시나리오를 위해 설계되었다. Public HTTP/S 애플리케이션은 일반적으로 인바운드 경계에서 Azure Application Gateway WAF 또는 Azure Front Door WAF를 사용하며, 필요하면 경로의 다른 지점에서 Azure Firewall과 결합한다.

5. 공통 Data Path 따라가기

세 SKU에는 같은 기본 요구사항이 있다. 트래픽을 서비스 쪽으로 보내야 한다.

아웃바운드
워크로드 Subnet
  → UDR 또는 Routing Intent
  → Azure Firewall Private IP
  → Policy와 선택적 검사
  → SNAT 경로
  → 인터넷 목적지

east-west
출발지 워크로드
  → Azure Firewall을 지나는 대칭 Route
  → Network/Application 판정
  → 목적지 워크로드
  → 유효한 반환 경로

인바운드 비 HTTP/S 게시
인터넷 Client
  → Azure Firewall Public IP
  → DNAT Rule
  → Private Backend

Resource를 배포해도 트래픽이 스스로 끌려오지 않는다. Azure Firewall을 우회하는 인터넷 Route를 가진 워크로드의 트래픽은 검사되지 않는다. 아웃바운드 Packet은 Firewall로 보내지만 반환 트래픽이 다른 경로를 지나면 비대칭 흐름 장애가 생길 수 있다. 올바른 Policy가 잘못된 경로에 놓이면 그 흐름에는 운영상 Policy가 없는 것과 같다.

다음 Module 1 글에서는 UDR과 DNS 설계를 자세히 구현한다. 이번 비교에서는 SKU를 논의하기 전에 다음 관문 하나를 기억한다.

아키텍처가 필수 트래픽을 이 지역 Firewall로 보낼 수 있고, 의도하지 않은 우회 경로가 남지 않았음을 증명할 수 있는가?

6. SKU를 비교하기 전에 처리 기준선 이해하기

위협 인텔리전스 필터링을 활성화하면 알려진 악성 지표를 NAT, Network 또는 Application Rule보다 먼저 평가한다. 그 뒤 Azure Firewall은 대략 다음 순서로 Rule Type을 처리한다.

위협 인텔리전스
→ DNAT Rule
→ Network Rule
→ Application Rule
→ 허용한 Rule이 없으면 기본 차단

Rule은 일치하면 평가가 끝나는 Terminating 방식이다. 일치한 판정이 해당 흐름에 대한 뒤의 평가를 중단한다. DNAT는 인바운드 트래픽을 변환하며 변환된 연결을 암묵적으로 허용하므로, 출발지 조건에 설명되지 않은 Wildcard를 사용해서는 안 된다. Network Rule은 L3/L4 속성으로 판정하며 인바운드, 아웃바운드 또는 east-west 트래픽을 처리할 수 있다. Application Rule은 아웃바운드와 east-west에 애플리케이션 수준 통제를 제공하지만 인바운드 WAF Rule처럼 작동하지 않는다.

계층에는 각각의 Priority를 가진 Rule Collection Group과 Collection도 포함되며, 상위 Policy가 지역 Policy 평가에 영향을 줄 수 있다. 따라서 “내 Allow Rule의 Priority는 100이다”라는 설명만으로는 증적이 불완전하다. 완전한 증적에는 적용되는 Policy 상속, Collection Type, Route, DNS 결과와 일치 로그가 포함되어야 한다.

7. Basic·Standard·Premium 공통 기능

Basic이 Firewall의 기본 정의를 잃은 제품은 아니다. 세 SKU 모두 상당한 공통 기준선을 제공한다.

공통 기능	실무적 의미
상태 저장 Firewall	연결 속성으로 새 흐름을 평가하고, 허용된 응답 트래픽을 추적함
Network Rule	중앙에서 IP, Port, Protocol, 출발지와 목적지를 필터링함
Application FQDN Rule	지원되는 HTTP/S와 SQL 시나리오에서 애플리케이션 수준 목적지 이름을 통제함
SNAT와 DNAT	아웃바운드 출발지 변환과 인바운드 목적지 변환
기본 제공 고가용성	고객이 Load Balancer를 관리하지 않아도 Microsoft가 여러 Service Instance를 운영함
Availability Zone 지원	지원 지역에서 여러 Zone에 걸쳐 배포할 수 있음
Firewall Policy와 Manager	중앙 정책과 다중 Firewall 관리 기능
Tag	지원되는 Rule에서 Service Tag와 FQDN Tag로 하드코딩된 주소 유지보수를 줄임
Azure Monitor 연동	진단을 구성하면 로그와 Metric을 운영 목적지로 보낼 수 있음
자동화	REST, CLI, PowerShell, Template과 Terraform으로 서비스를 관리할 수 있음

세 가지 단서를 반드시 기억해야 한다.

첫째, 로그 연동이 곧 로그 보존은 아니다. 팀이 여전히 Diagnostic Setting, 목적지, 보존 기간, 접근 권한, 경고와 비용 통제를 구성해야 한다. 둘째, 기본 제공 고가용성이 곧 지역 재해 복구는 아니다. Azure Firewall은 지역 서비스이므로 다중 지역 연속성을 위해서는 별도의 지역 설계가 필요하다. 셋째, Application FQDN 필터링은 전체 URL 검사가 아니다. downloads.example.com 같은 Domain 판정과 downloads.example.com/approved/package 같은 경로 판정은 다르다.

8. Basic: 확실한 경계 안의 필수 통제

Azure Firewall Basic은 단지 실습에서 가장 저렴한 선택 상자가 필요해서가 아니라, 요구사항이 작고 안정적이며 명확할 때 후보가 된다.

Basic이 제공하는 기능

상태 저장 Network Rule과 Application 수준 FQDN Rule
SNAT와 DNAT
기본 제공 고가용성과 Availability Zone 지원
중앙 Firewall Policy, 로그, Tag와 자동화
알려진 악성 지표에 대한 위협 인텔리전스 경고 전용(alert-only) 신호
문서화된 250Mbps 처리량 상한

Basic이 제공하지 않는 기능

Firewall의 DNS Proxy 또는 Custom DNS 설정
임의 TCP/UDP Protocol을 위한 Network Rule의 FQDN 목적지
위협 인텔리전스 Alert and Deny 강제 적용
현재 주요 기능 표 기준 Web Category 필터링
TLS 검사, 관리형 IDPS 또는 전체 경로 URL 필터링
Standard 또는 Premium의 확장 한계

따라서 Basic은 Application FQDN Allowlist, L3/L4 Policy, NAT와 중앙 로그로 충분하고, 측정한 최대 트래픽이 250Mbps보다 넉넉히 낮으며, 경고 전용 위협 인텔리전스를 실제로 모니터링할 담당자가 있는 통제된 워크로드에 적합하다. 팀에 비 HTTP FQDN Rule, Custom DNS 정합성, 알려진 악성 목적지 자동 차단, Web Category 또는 쉬운 용량 확장이 필요하다면 평균 대역폭이 낮더라도 Basic은 잘못된 기능 경계다.

Basic에도 인프라 운영 부담이 있다

Basic은 항상 관리 NIC를 사용한다. VNet 배포에는 전용 AzureFirewallSubnet과 AzureFirewallManagementSubnet이 필요하며, 현재 배포 지침은 각각 최소 /26을 사용한다. 관리 NIC에는 업데이트, 상태와 서비스 운영을 위해 Azure Platform이 사용하는 별도의 관리 Public IP가 있다. 고객의 인바운드 주소로 사용하는 IP가 아니다.

이 점은 전체 설계에 영향을 준다. 작은 애플리케이션의 트래픽이 적더라도 Firewall에는 예약된 Subnet 두 개, Public IP Resource, Policy, 로그, Routing, 담당자와 월별 고정 배포 비용이 필요하다. “Basic이 더 저렴하다”는 말이 “Basic에는 운영 비용이 없다”는 뜻은 아니다.

Basic을 선택하기 전에 전환 조건 작성하기

다음 조건이면 Basic에서 벗어난다.
- 측정한 최대 트래픽이 250Mbps 경계에 가까워진다.
- 비 HTTP Network Rule에 FQDN이 필요해진다.
- Custom DNS 또는 DNS Proxy가 필요해진다.
- 위협 인텔리전스가 경고만 하지 않고 차단해야 한다.
- Category, TLS, IDPS 또는 URL 수준 검사가 필수가 된다.
- 성장 계획상 제약이 있는 Basic 마이그레이션을 받아들일 수 없다.

9. Standard: 엔터프라이즈 정책의 기준선

Standard는 공유 지역 Hub에서 실용적인 중간 Tier인 경우가 많다. 공통 Firewall 기능을 유지하면서 중앙 엔터프라이즈 Egress Policy를 더 쉽게 운영하게 해주는 기능을 추가한다.

Standard가 추가하는 기능

공개된 조건에서 최대 30Gbps의 문서화된 전체 처리량으로 Autoscaling
지원되는 TCP/UDP 트래픽을 위한 Network Rule의 FQDN 목적지
DNS Proxy와 Custom DNS 구성
Alert and Deny 모드의 위협 인텔리전스
최신 SKU 선택 표 기준 FQDN 기반 Web Category
엔터프라이즈 Routing을 위해 문서화된 Forced Tunneling과 관리 NIC Pattern
더 큰 SNAT·DNAT 설계를 위한 확장된 Public IP 지원

Network Rule의 FQDN 필터링은 Hostname을 입력하는 것만으로 끝나지 않는다. Firewall과 Client가 이름을 일관되게 해석해야 한다. 안정적인 운영 Pattern은 다음과 같다.

Client DNS Query
→ Azure Firewall DNS Proxy
→ 승인된 상위 Azure 또는 Custom DNS
→ Firewall과 Client가 일치하는 응답을 관찰
→ Network FQDN Rule이 해석된 목적지를 추적

DNS Proxy는 기본적으로 비활성화되어 있다. Azure Firewall에서만 활성화한 채 Client가 계속 다른 Resolver를 사용하면 응답 시점과 IP가 달라질 수 있다. 상세 DNS 설계는 다음 글에서 다루지만, SKU를 선택하는 시점에 이미 그 담당자를 지정해야 한다.

Standard의 보안 경계

Standard는 TLS 검사, 관리형 IDPS 또는 전체 URL 경로 필터링을 제공하지 않는다. updates.example.com을 허용하고 Domain 기준으로 Site를 분류할 수 있지만, TLS를 종료하지 않고는 /approved/releases/agent.msi 같은 암호화된 Request Path를 검사할 수 없다. Microsoft의 알려진 악성 지표 Feed와 일치하는 목적지는 차단할 수 있지만, 이 평판 판정은 임의 Packet Payload의 서명 검사가 아니다.

중앙 FQDN, DNS, 위협 차단, Category, NAT와 더 높은 확장성 요구가 실제로 존재하지만 암호화된 콘텐츠 검사와 IDPS가 승인된 요구사항은 아닐 때 Standard를 선택한다.

10. Premium: 더 깊은 검사와 달라지는 책임

Premium은 Standard 기능을 모두 포함하고 고급 검사와 더 높은 공개 성능 경계를 추가한다.

Premium이 추가하는 기능

아웃바운드와 east-west TLS 검사
Microsoft 관리형 서명 기반 침입 탐지 및 방지 시스템(IDPS)
Application Rule에서 TLS 검사를 활성화했을 때 HTTPS를 포함한 전체 URL 경로 필터링
더 세밀한 URL 수준 Web Category 분류
특정 구성에서 문서화된 최대 100Gbps의 전체 성능
기본 구성에서 훨씬 높은 단일 흐름 성능 경계

이 기능은 Exploit, Command-and-control 트래픽, Malware 관련 서명과 금지된 암호화 목적지를 탐지해야 하는 민감한 워크로드를 지원한다. 성능은 기본 SKU의 대표 수치가 아니라, 사용하려는 Premium 기능 조합이 테스트에서 전체·단일 흐름 요구를 충족할 때에만 Premium을 선택할 근거가 된다.

Premium은 “모든 Switch를 켠다”는 뜻이 아니다. 각 검사 기능은 시스템을 바꾼다.

기능	새로 생기는 책임
TLS 검사	CA 설계, Key Vault 접근, Client 신뢰, 인증서 교체, 예외와 개인정보 보호 검토
IDPS	모드 선택, 서명 튜닝, 오탐 처리, 사고 담당자와 용량 테스트
URL 필터링	승인 경로 목록, Redirect·Embedded Resource 테스트와 예외 Lifecycle
고급 Category	Category 검증, 업무 예외, 변경 요청과 개인정보 보호 경계
더 높은 용량	운영 트래픽 형태의 부하 테스트, Prescaling 결정, 비용과 지역 용량 검토

이 기능을 비활성화한 Premium Resource는 튜닝된 Premium 검사 서비스와 다르게 동작한다. 어느 기능을 활성화했고 어디에 적용하며 정상 트래픽을 차단했을 때 팀이 어떻게 대응하는지를 증적으로 보여야 한다.

11. TLS 검사는 PKI·개인정보 보호 프로그램이다

일반적인 End-to-end HTTPS에서는 중간 Firewall이 Request Payload와 전체 URL 경로를 볼 수 없다. Azure Firewall Premium TLS 검사는 보호된 Session 두 개를 만든다.

Client
  ⇄ 조직의 검사 CA가 서명한 TLS Session
Azure Firewall Premium
  ⇄ 실제 Server와 맺는 별도 TLS Session
목적지

Firewall은 두 Session 사이에서 트래픽을 복호화하고 구성한 검사를 적용한 뒤 다시 암호화한다. 이 방식은 더 깊은 가시성을 제공하지만, 조직이 암호화 통신 중간에 신뢰받는 중개자를 의도적으로 삽입했다는 의미이기도 하다.

운영 요구사항에는 다음이 포함된다.

지원되는 Key Vault Secret 형태로 저장한 유효한 Intermediate CA 인증서
Secret을 가져올 수 있는 Managed Identity
검사 대상 모든 Client 또는 워크로드에 Trusted Root CA 배포
인증서 만료, 교체, 폐기와 긴급 교체 절차
Certificate Pinning, Mutual TLS, Custom Trust Store와 비 Browser Client에 대한 애플리케이션 테스트
복호화해서는 안 되거나 복호화할 수 없는 트래픽의 명시적 제외
개인정보 보호, 법무, 직원, 의료, 금융과 규제 검토
민감한 목적지 URL과 Metadata를 노출할 수 있는 Firewall 판정 로그·사고 증적에 대한 보호된 접근
TLS와 계획한 IDPS 모드를 활성화한 상태의 용량 테스트

HTTPS 전체 URL 필터링을 하려면 Application Rule 수준에서 TLS 검사를 활성화해야 한다. 그렇지 않으면 Firewall은 일반적으로 지원되는 Metadata를 통해 목적지 이름은 볼 수 있어도 암호화된 경로는 읽을 수 없다. Tunnel을 불투명하게 둔 상태에서 /approved/path 통제를 약속해서는 안 된다.

TLS 검사도 Azure Firewall을 인바운드 WAF로 만들지 않는다. Microsoft는 Azure Firewall Premium의 아웃바운드와 east-west 검사를 문서화하고 있다. 인바운드 웹 보호에는 해당 아키텍처에서 Application Gateway WAF 같은 Reverse Proxy 서비스를 사용한다.

12. 위협 인텔리전스와 IDPS는 서로 다른 질문에 답한다

두 기능을 모두 “위협 차단”이라고 뭉뚱그리기 쉽지만 증적과 한계가 다르다.

기능	답하는 질문	Basic	Standard	Premium
위협 인텔리전스	IP, FQDN 또는 URL이 Microsoft Feed의 알려진 악성 지표인가?	경고 전용	경고 또는 경고 및 차단	경고 또는 경고 및 차단
IDPS	트래픽이 관리형 공격·Exploit·Malware·Command-and-control 서명과 일치하는가?	없음	없음	있음

위협 인텔리전스를 활성화하면 NAT, Network와 Application Rule보다 먼저 평가하며 Allowlist 예외를 둘 수 있다. 평판을 바탕으로 판단하기 때문에 목록에 없는 목적지가 안전하다고 증명하지 않으며, IDPS처럼 모든 Payload를 검사하지도 않는다.

Premium IDPS는 지원되는 인바운드, 아웃바운드, east-west와 Hybrid 트래픽에서 서명 Pattern을 검사한다. 암호화되지 않은 트래픽은 Port와 Protocol 전반에서 검사할 수 있다. 암호화된 HTTPS Payload를 보려면 TLS 검사가 필요하다. 모드는 Off, Alert, Alert and Deny이며 서명 수준 튜닝 기능을 제공한다.

합리적인 도입 순서는 다음과 같다.

대상 흐름을 조사하고 Firewall로 Routing
→ IDPS를 Alert 모드로 활성화
→ 신뢰도가 높거나 반복되는 일치 조사
→ 문서화된 오탐과 불가피한 예외 튜닝
→ 실제 기능 조합으로 용량 테스트
→ 승인된 서명 또는 Policy를 차단으로 전환
→ 롤백 방법과 경고 담당자 유지

전역 Alert and Deny가 모든 서명에서 트래픽을 차단한다고 가정해서는 안 된다. Microsoft는 일부 서명에 대해 시스템 정의 경고 전용 동작과 Override 제약을 문서화한다. IDPS Bypass 목록은 성능 가속기가 아니다. 검사 범위를 바꾸므로 보안상 근거가 있어야 한다.

13. FQDN·Category·전체 URL 판정 구분하기

SKU와 기능에 따라 목적지 식별의 정밀도가 높아진다.

IP 주소
→ FQDN: downloads.example.com
→ Category: software downloads
→ 전체 URL: https://downloads.example.com/approved/agent.msi

통제	Basic	Standard	Premium
Application Rule FQDN	가능	가능	가능
더 넓은 TCP/UDP 용도의 Network Rule FQDN	불가	가능	가능
DNS Proxy와 Custom DNS	불가	가능	가능
Web Category	현재 주요 기능 표에서는 불가	FQDN 수준	필요한 곳에서 검사할 때 전체 URL 수준의 정밀도
전체 URL 경로	불가	불가	가능, HTTPS에는 TLS 검사 필요

주소가 바뀌는 이름 기반 서비스에는 FQDN 필터링이 유용하다. 그러나 신원을 보장하지는 않는다. Domain을 허용해도 워크로드가 인증되거나 애플리케이션 작업이 인가되는 것은 아니다. Web Category는 목록 유지보수를 줄이지만 Category가 바뀔 수 있고 업무상 예외가 필요할 수 있다. 전체 URL 통제는 정밀하지만 현대 웹페이지는 Redirect, API, Content Delivery Network와 Embedded Resource를 호출한다. 따라서 화면에 보이는 한 경로를 허용하는 것만으로 애플리케이션이 동작한다는 보장은 없다.

Premium에는 Category별 개인정보 보호 동작도 있다. Microsoft 문서에 따르면 Education, Finance, Government, Health and medicine Web Category는 Category Rule을 통한 TLS 종료를 지원하지 않으며, 승인한 특정 URL을 Application Rule에 명시적으로 추가해야 한다. 이를 광범위한 예외를 추가할 이유가 아니라 기술적 가시성도 개인정보 보호와 규정 준수의 제약을 받는다는 알림으로 받아들인다.

14. 성능 수치는 약속이 아닌 조건으로 읽기

간략한 SKU 선택 자료는 기능과 성능을 기억하기 쉬운 대표 수치로 요약한다. 2026년 8월 4일에 업데이트된 Azure Firewall 상세 성능 문서는 더 구체적인 최대 테스트 결과를 공개한다. 다음 표는 의사결정 보조 자료이지 SLA가 아니다.

SKU 또는 테스트한 Premium 모드	공개된 전체 최대치	공개된 단일 TCP 최대치	중요한 조건
Basic	최대 0.25Gbps	최대 0.25Gbps	고정 용량, Basic은 Autoscaling하지 않음
Standard	30Gbps	1.5Gbps	초기 전체 용량은 최대치보다 훨씬 낮음
Premium 기본 테스트 구성	100Gbps	9Gbps	기능 조합과 트래픽 형태가 중요함
TLS 검사와 IDPS `Alert and Deny`를 함께 사용한 Premium	최대 22Gbps	최대 0.6Gbps	두 기능을 결합한 공개 테스트 결과이며 계획한 트래픽 형태를 검증해야 함

일반 SKU 요약은 현재 단일 대용량 흐름(fat flow)을 Standard 1Gbps, Premium 10Gbps로 표시하지만, 더 최신의 상세 성능 Benchmark는 단일 TCP 최대치를 1.5Gbps와 9Gbps로 보고한다. 엔지니어링 의사결정에서는 어느 숫자 쌍도 보장된 용량으로 취급하지 말고 출처 날짜를 기록한 뒤 현재 상세 성능 문서에 맞춰 테스트한다.

전체 처리량은 여러 흐름의 합이다. 단일 대용량 흐름은 Backup이나 Replication Stream 같은 연결 하나다. 서비스의 전체 트래픽이 크지 않아도 단일 흐름 요구를 충족하지 못할 수 있다. 반대로 작은 연결이 많으면 대역폭 대표 수치에 도달하기 전에 연결 자원과 SNAT 자원을 소진할 수 있다.

Standard와 Premium은 점진적으로 Scale-out한다. Microsoft는 사용률 임계값을 넘은 후 약 5~~7분의 Scale-out 시간을 문서화하고, 새 연결을 만들면서 최소 10~~15분간 성능 테스트하기를 권장한다. 갑작스러운 이벤트가 발생한다고 공개된 최대치가 즉시 제공되는 것은 아니다. 예측 가능한 Peak에는 Prescaling을 고려할 수 있다. Standard와 Premium에서 Capacity Unit 범위를 지정할 수 있고 Capacity Unit 과금이 추가되며, 지역 용량이 무한하다고 보장하지는 않는다.

테스트 계획은 다음 조건을 재현해야 한다.

Protocol과 Packet 크기
전체·단일 흐름의 양
초당 새 연결 수와 동시 연결 수
TLS 검사와 계획한 IDPS 모드
Rule 개수와 형태
SNAT 목적지 집중도
Zone, Hub, Spoke, Peering과 Hybrid 경로
적어도 한 번의 Scale-out과 복구 구간

15. 관문형 SKU 의사결정 트리 사용하기

중앙 Routing, Policy, NAT, Logging 또는 검사가 필요한가?
├─ 아니요
│  └─ NSG, NAT Gateway, WAF 또는 다른 설계 중 필요한 통제만 선택
└─ 예
   │
   ├─ 최대 트래픽과 성장이 250Mbps보다 충분히 낮고,
   │  Network Rule FQDN, DNS Proxy/Custom DNS,
   │  위협 인텔리전스 차단, Category, TLS, IDPS와 URL 경로가 불필요한가?
   │  └─ 예 → Basic 후보
   │
   ├─ TLS 검사, 관리형 IDPS, 전체 URL 필터링,
   │  URL 수준 Category, 30Gbps 초과 전체 처리량
   │  또는 대용량 단일 흐름이 필요한가?
   │  └─ 예 → 계획한 검사 모드에서 실제 성능 요구를
   │           검증할 수 있을 때에만 Premium 후보
   │
   └─ 그 외 → 중앙 엔터프라이즈 정책을 위한 Standard 후보

모든 후보의 최종 관문:
지역, Topology, Routing, DNS, PKI, 예산, 운영,
성능 테스트, 마이그레이션과 롤백 요구사항을 충족할 수 있는가?

선호도의 평균이 아니라 가장 높은 필수 요구사항을 사용한다. 대부분의 흐름에 Network Rule만 필요하더라도 승인된 Premium 전용 요구사항이 하나 있으면 Premium이 최소 SKU다. 반대로 “규제를 받는 워크로드”라는 말만으로는 기술 요구사항이 되지 않는다. 규정이나 위험 평가에서 요구하는 통제, 트래픽 범위, 증적과 담당자를 구체적으로 적는다.

Must, Should, Not required로 의사결정 표를 만든다. Should 행에 Premium 체크 표시가 있다고 해서 예산이나 운영 제약을 자동으로 무시할 수는 없다. 의사결정 담당자가 Trade-off를 해결하고 잔여 위험을 기록한다.

16. 시나리오 A: 작고 통제된 워크로드가 Basic을 선택한다

한 지역의 내부 서비스가 작은 Subnet 세 개를 사용하고, 측정한 최대 트래픽이 60Mbps라고 가정하자. 필요한 중앙 통제 흐름은 다음과 같다.

짧은 공급업체 FQDN 목록으로 향하는 아웃바운드 HTTPS
고정 IP와 Port를 사용하는 아웃바운드 NTP·DNS
출발지를 좁게 제한한 비웹 Protocol용 DNAT 경로 하나
중앙 Allow·Deny 로그
알려진 악성 지표에 대한 경고

Firewall의 Custom DNS, Network Rule FQDN, 위협 인텔리전스 자동 차단, Category, TLS 검사 또는 IDPS는 필요하지 않다. 성장 계획상 p95와 테스트된 Peak는 250Mbps보다 훨씬 낮다. 운영 팀은 경고 전용 위협 인텔리전스 이벤트를 조사할 수 있다.

이 경우 Basic은 방어 가능한 선택이다. 그래도 증적 묶음에는 다음 항목이 들어가야 한다.

측정한 최대치와 12개월 성장 추정치
+ Application FQDN·Network Flow 목록
+ /26 Firewall Subnet 두 개 예약
+ 관리 Public IP의 용도
+ 성공·실패 연결 테스트
+ 경고 목적지와 대응 담당자
+ Standard 마이그레이션·재구축 전환 조건
+ 월별 고정·변동 비용

“다음 분기에 Custom DNS가 필요할 수 있다”거나 “보안 팀이 알려진 악성 목적지를 차단할 것으로 기대한다”는 요구가 이미 현실적이라면 Basic은 부적절해진다. 불확실한 마이그레이션을 만들면서 첫 달의 SKU 가격 차이를 아끼는 것은 경제적인 선택이 아니다.

17. 시나리오 B: 여러 Spoke를 운영하는 서비스가 Standard를 선택한다

여러 애플리케이션 Spoke가 공유 지역 Hub를 사용한다고 가정하자. 워크로드 요구는 다음과 같다.

중앙에서 관리하는 인터넷 Egress
Custom DNS와 정합성이 유지되는 DNS Proxy 동작
비 HTTP TCP/UDP 의존성을 위한 FQDN Network Rule
Alert and Deny 모드의 위협 인텔리전스
FQDN 기반 Web Category
수 Gbps의 Peak
여러 Subscription에 걸친 공통 Policy, Logging과 예외 담당 체계

HTTPS를 복호화하거나 관리형 IDPS를 실행하거나 전체 경로를 필터링하라는 승인된 요구는 없다. Public Web Application은 승인된 Edge에서 WAF를 사용하고, NSG는 워크로드 가까이에서 Tier 경계를 유지한다.

Standard가 기능적으로 맞는 최소 선택이다.

NSG          → 지역 Tier 분리
WAF          → 인바운드 HTTP/S Exploit 보호
Standard     → 중앙 Egress/east-west Policy, FQDN, DNS, 위협 차단, NAT, 로그
NAT Gateway  → 측정한 설계에 필요할 때 선택적으로 SNAT 확장

모든 Spoke의 의도한 Route가 Firewall에 도달하고, DNS 응답의 정합성이 유지되며, 직접 인터넷 우회가 닫혔고, 충분한 시간 동안 진행한 Scale 테스트에서 실제 용량이 테스트된 경계 아래임을 증명해야 선택이 완성된다.

18. 시나리오 C: 민감한 워크로드가 Premium을 정당화한다

결제 처리 환경에 위험 검토를 거쳐 승인된 다음 요구가 있다고 가정하자.

아웃바운드와 선택한 east-west HTTPS 검사
관리형 Exploit·Command-and-control 서명 탐지와 차단
민감한 Software Supply 경로에서 승인된 URL Path만 허용
Domain보다 세밀한 수준에서 Category 구분
계획한 TLS·IDPS 모드에서 대용량 Replication Flow를 검증하고, 공개된 IDPS 차단 단일 흐름 최대치가 Standard 기본 구성보다 낮다는 점을 인지

“결제”라는 단어 때문이 아니라 이름을 붙일 수 있는 통제 때문에 Premium이 정당화된다. 구현 프로그램에는 다음 항목이 포함된다.

Inspection CA와 Key Vault 운영 모델
워크로드에 Root Trust 배포
Certificate Pinning과 Mutual TLS 조사
개인정보 보호 승인을 받은 비검사 Category와 예외
차단 전에 IDPS Alert 모드 관찰
TLS와 IDPS를 활성화한 전체 규모 테스트
Public 인바운드 HTTP/S용 WAF
지역 분리를 위한 NSG
사고 담당자가 정해진 구조화된 Firewall·IDPS 로그
어떤 통제가 사라지는지 설명하는 Downgrade 계획

Premium이 PCI DSS에 적합하다는 Microsoft 문서가 고객 환경 전체를 인증하는 것은 아니다. Identity, Application, Key Management, 취약점 조치, Logging, Segmentation, 증적과 운영 절차가 여전히 규정 준수 여부를 결정한다.

19. SKU 가격이 아닌 총비용 모델링하기

Azure Firewall 가격은 지역, 통화, 계약과 날짜에 따라 달라진다. 월별 가격을 고정해서 적으면 빠르게 낡는다. 대신 비용 동인을 사용한다.

예상 월간 비용
= 배포 시간 × SKU 고정 시간당 요금
+ 처리한 GB × SKU 데이터 처리 요금
+ 선택적 Standard/Premium Prescaling Capacity Unit 시간
+ 사용한 Public IP·NAT Gateway Resource
+ 해당되는 VNet Peering, Zone 간, 지역 간, 인터넷 전송 비용
+ Log Analytics 수집, Query, 보존, Archive와 Export
+ TLS 검사용 Key Vault·인증서 운영
+ Engineering, 검토, 오탐 튜닝, 사고 대응과 복구 인건비

애플리케이션 트래픽이 없어도 Firewall이 할당되어 있는 동안 배포 요금이 계속 부과된다. Pricing FAQ에 따르면 배포 시간 일부도 한 시간 전체로 청구된다. Firewall 할당을 해제하면 서비스 과금은 중지되지만 다른 Resource에는 각자의 Meter가 있으며, 다시 할당한 후 Firewall Private IP가 바뀌어 Route 의존성에 영향을 줄 수 있다. 따라서 운영 Firewall을 밤마다 가볍게 끄는 Desktop VM처럼 취급하지 않는다.

지역마다 하나의 Firewall로 중앙화하면 중복 Firewall Instance를 줄일 수 있지만 Spoke Peering과 트래픽 경로 비용이 절감액 일부를 상쇄할 수 있다. Basic은 Firewall Meter를 낮추는 대신 부족한 DNS나 차단 기능을 다른 서비스 또는 수동 대응으로 보완해야 해 운영 비용을 높일 수 있다. Premium은 직접 비용을 높이지만 특정 위험을 줄일 수 있다. 단, 팀이 실제로 그 기능을 활성화하고 운영할 때만 그렇다.

승인 전에는 Azure Pricing Calculator를, 배포 후에는 Cost Management를 사용한다. 도입 기간에는 적어도 매달 예측치와 실제 처리 데이터, Telemetry 수집량, 용량을 비교한다.

20. SKU와 함께 신뢰성·운영 설계하기

세 SKU 모두 기본 제공 고가용성과 Availability Zone을 지원한다. 검증일 현재 여러 Availability Zone이 있는 지역에서 새 Firewall은 기본적으로 Zone Redundant로 배포되며, Microsoft는 기존 Non-zonal 배포를 2026년 중 마이그레이션한다고 설명한다. Zone Redundant 배포는 Zone 장애에 대한 복원력을 높이지만 기존 TCP Session을 영구히 보존하거나, 모든 Zone의 용량을 보장하거나, 지역 전체 장애를 막아주지는 않는다.

계층별 책임은 다음과 같다.

계층	책임
Instance 장애	관리형 서비스가 비정상 Backend 용량을 교체
Zone 장애	Zone Redundant 지역 배포와 Client Retry 동작
지역 장애	별도 지역에 배포한 Firewall, Policy 가용성, Routing, DNS와 Failover 계획
Policy 오류	버전이 관리되는 Policy, 단계적 배포, 테스트, 승인과 롤백
DNS 장애	Resolver 상태, 정합성이 맞는 Client·Firewall 구성, 모니터링과 복구
인증서 장애	CA·Secret 교체, Trust 배포, 만료 경고와 Bypass 결정
용량 이벤트	Metric, Prescaling 또는 아키텍처 변경, SNAT 계획과 테스트한 임계값

Azure Firewall을 보안 서비스로 운영한다.

가능하면 Policy를 코드로 관리한다.
모든 Rule에 목적, 담당자, 검토일과 임시 Rule의 만료일을 지정한다.
전역 상위 Policy와 워크로드별 하위 결정을 신중하게 분리한다.
탐지, 감사 또는 문제 해결 목적이 있는 Diagnostic Category만 활성화한다.
상태, Telemetry 누락, 용량, 광범위한 Rule 변경과 Policy 실패에 경고를 설정한다.
Policy를 Backup하고 복원 또는 재배포를 테스트한다.
Any 접근을 남기지 않는 비상 롤백 방법을 유지한다.
지역, SKU, Limit, 가격과 문서 변경을 정기적으로 검토한다.

“완전 관리형”이란 Microsoft가 서비스 인프라와 확장 동작을 관리한다는 뜻이다. Microsoft가 조직의 필수 목적지를 알고, 고객의 Inspection CA를 교체하고, 오탐을 튜닝하고, Rule 예외를 결정하거나, 사고에 대응한다는 뜻은 아니다.

21. 경로·정책·검사·용량을 각각 증명하기

배포 화면의 초록색 표시는 Layer 0 증적일 뿐이다. 여러 계층을 사용한다.

Layer 1: 경로 증적

Effective Route를 내보내 Azure Firewall Private IP가 의도한 Next Hop인지 확인한다.
없어야 하는 직접 인터넷 우회와 Cross-spoke 우회 경로를 테스트한다.
반환 경로가 계속 대칭인지 확인한다.
Public IP 목록을 만들고 어느 구성요소가 SNAT 또는 DNAT를 수행하는지 증명한다.

Layer 2: 정책 증적

실제 적용 Firewall Policy, 상위 관계, SKU와 기능 설정을 보존한다.
필수 Allow 하나와 그와 인접한 금지 목적지, Port, FQDN 또는 경로 하나를 테스트한다.
예상한 NAT, Network 또는 Application Rule이 일치하는지 확인한다.
응답이 없다는 이유만으로 Firewall이 차단했다고 생각하지 말고 Default Deny를 검증한다.

Layer 3: 검사 증적

선택한 SKU의 위협 인텔리전스 모드와 경고 목적지를 확인한다. Basic은 경고 전용만 지원한다.
Premium에서는 Client Trust, 제시된 인증서, TLS 검사 범위와 승인된 제외 항목을 증명한다.
IDPS를 Alert 모드로 도입하고, 문서화된 오탐을 조정한 뒤 승인된 비운영 환경 차단 테스트를 수행한다.
HTTPS 전체 경로 판정을 테스트할 때 TLS 검사가 실제로 활성화되어 있는지 확인한다.

Layer 4: 용량·신뢰성 증적

평상시, p95, 최대 전체, 단일 흐름, 새 연결과 동시 연결 동작을 측정한다.
Standard와 Premium은 새 연결이 포함된 운영 트래픽 형태의 테스트를 최소 10~15분 실행해 Scale-out 동작이 보이게 한다. Basic은 고정된 250Mbps 경계를 기준으로 테스트한다.
상태, 처리량, 지연, 처리 데이터, SNAT 사용률과 Rule Hit Telemetry를 관찰한다.
유지보수 또는 통제된 의존성 장애 중 Retry 동작을 테스트한다.
실제 비용·로그와 예측치를 비교한다.

Allow 로그는 Firewall 판정을 증명할 뿐 애플리케이션 상태를 증명하지 않는다. 성공한 애플리케이션 Request는 연결을 증명하지만 의도한 Firewall이 실제로 처리했다는 보장은 없다. 경로 증적과 동일 Timestamp의 Firewall 일치 증적을 모두 보존한다.

22. 호환되는 Policy와 롤백 증적으로 마이그레이션하기

Firewall이 Firewall Policy를 사용하고 지역과 구성이 지원되며 Premium 전용 설정을 올바르게 처리했다면 Standard와 Premium 사이에는 문서화된 간편 SKU 변경 경로가 있다. Microsoft는 이 경로를 Zero Downtime으로 설명하지만, 운영 변경에는 여전히 Maintenance Window, 전체 규모 테스트, 모니터링과 롤백이 필요하다.

Standard에서 Premium으로 변경할 때는 다음 순서를 따른다.

Policy, Route, Public IP, 진단, DNS와 의존성을 조사한다.
호환되는 Premium Policy를 준비하거나 생성한다.
지원되는 경로로 SKU를 변경한다.
새 검사를 활성화하기 전에 일반 흐름을 검증한다.
TLS와 IDPS를 통제된 단계로 도입한다.
이전 Policy와 복구 기준을 유지한다.

Premium에서 Standard로 변경하려면 Premium 전용 요구를 먼저 제거하거나 다시 설계해야 한다. TLS 검사, IDPS 차단, 전체 URL Rule과 URL 수준 Category 동작을 Standard Policy에 그대로 남길 수 없다. Downgrade는 비용 변경일 뿐만 아니라 보안 통제 변경이다.

Basic에는 같은 방식의 단순하고 일반적인 Zero-downtime 변경 약속이 없다. 현재 Microsoft 문서는 간편 SKU 변경을 Standard와 Premium으로 제한하면서도 Basic 전환에 대해 상충하는 표현을 담고 있다. 실제 Subscription, 지역, API와 지원 경로를 검증하기 전까지는 다음과 같은 안전한 계획을 가정한다.

별도 VNet 또는 Hub에 병렬 Firewall과 Policy 배포
(Azure는 VNet 하나에 Firewall 하나만 허용)
→ 통제된 Route 전환
→ Public IP Allowlist 조율
→ 성공, 실패와 성능 검증
→ 이전 경로로 롤백

전환 설계에는 새 Hub 또는 VNet Peering, Public IP 의존성과 대칭 반환 경로도 포함되어야 한다. 향후 Standard 또는 Premium 요구가 현실적이라면 오늘의 Basic 총비용에 마이그레이션 복잡성도 넣는다.

23. 시간에 따라 바뀌는 문서 충돌을 기록하고 최종 체크리스트 사용하기

공식 문서는 일반적으로 가장 좋은 출처지만 페이지별 업데이트 시점이 다를 수 있다. 2026년 8월 11일 현재 여러 Microsoft 페이지가 완전히 일치하지 않는다.

주제	현재 충돌	안전한 설계 처리 방법
Basic Forced Tunneling	2025년 10월 기능 표는 미지원으로 표시하지만 2026년 6월 FAQ는 Basic이 지원한다고 설명함. 모든 Basic Firewall은 관리 NIC를 사용함	더 최신의 해당 기능 FAQ를 단서로 삼되 승인 전에 지역, API, Topology와 지원 여부 검증
Basic SKU 마이그레이션	SKU 변경 문서는 일부 Basic 경로를 제한하거나 거부하면서 뒤에서는 상충하는 표현을 사용함	Basic의 One-click 또는 Zero-downtime 마이그레이션을 약속하지 말고 테스트하거나 병렬 전환 계획 수립
Web Category	최신 SKU 선택 문서는 Standard와 Premium이 서로 다른 정밀도로 제공한다고 하지만 별도 기능 문서는 여전히 Premium 전용 범위를 설명함	최신 SKU 선택 문서를 사용하고 대상 지역의 Portal/API 검증
단일 흐름 성능	요약 표는 1Gbps·10Gbps를 표시하지만 2026년 8월 상세 성능 문서는 테스트 구성에서 1.5Gbps·9Gbps를 보고함	날짜가 명시된 상세 테스트를 기준으로 용량을 정하고 워크로드 재현
Forced Tunneling과 DNAT	일반 제약과 관리 NIC 예외가 Forced Tunnel 자료마다 다르게 설명됨	인바운드 게시를 독립 Topology로 검증하고 하나의 설정 항목만 보고 지원 여부를 추론하지 않음

추측해도 된다는 의미가 아니다. 문서 날짜를 기록하고 실제 환경에서 테스트하며, 운영 설계가 논쟁 중인 동작에 의존한다면 Microsoft Support Case를 열어야 한다는 뜻이다.

아키텍처·SKU 체크리스트

운영·증적 체크리스트

24. 스스로 점검할 질문과 1분 기억 카드

질문

Azure Firewall을 생성해도 워크로드 트래픽을 자동으로 검사하지 않는 이유는 무엇인가?
Azure Firewall 없이 NSG만으로 충분할 수 있는 때는 언제인가?
고정 아웃바운드 IP 요구사항을 NAT Gateway 검토부터 시작해야 하는 이유는 무엇인가?
세 Azure Firewall SKU에 모두 있는 핵심 기능은 무엇인가?
Basic이 단순히 속도가 느린 Standard가 아닌 이유는 무엇인가?
어떤 요구사항이 Standard를 최소 합리적 Tier로 만드는가?
위협 인텔리전스와 IDPS는 왜 다른가?
TLS 검사를 활성화하지 않으면 Premium도 HTTPS 전체 경로를 검사할 수 없는 이유는 무엇인가?
TLS 검사로 어떤 새로운 신뢰·개인정보 보호 책임이 생기는가?
Premium이 Public 인바운드 HTTP/S용 WAF를 대체하지 못하는 이유는 무엇인가?
전체 처리량과 하나의 대용량 흐름을 따로 측정해야 하는 이유는 무엇인가?
“Premium은 100Gbps를 지원한다”라는 문장이 성능 보장이 아닌 이유는 무엇인가?
트래픽이 다른 Route가 아니라 의도한 Firewall을 지났음을 어떤 증적으로 입증하는가?
Basic 마이그레이션을 One-click Zero-downtime 변경으로 약속하면 안 되는 이유는 무엇인가?
화면에 표시되는 SKU 시간당 가격 외에 어떤 비용이 있는가?

기억 카드

필요 → 경로 → 통제 → 확장 → 운영 → 증명

Route는 트래픽을 Firewall에 도달시킨다.
Policy는 트래픽의 통과 여부를 결정한다.
SKU는 사용할 수 있는 검사 깊이와 성능 한계를 정의한다.
로그와 테스트가 결과를 증명한다.

Basic
= 경계가 분명한 중앙 Firewall, 250Mbps, 위협 경고

Standard
= 엔터프라이즈 DNS/FQDN Policy, Category, 위협 차단, 확장

Premium
= TLS 검사, IDPS, 전체 URL 통제, 조건부 고성능

기능이 가장 많음 ≠ 가장 적합함
최대 처리량 ≠ 보장 처리량
관리형 인프라 ≠ 관리형 보안 운영

마지막으로 기억할 문장은 다음과 같다.

모든 필수 통제와 테스트된 용량 요구사항을 충족하는 가장 낮은 Azure Firewall SKU를 선택하고, 그 SKU를 현실에서 작동하게 할 Routing, DNS, PKI, Logging과 사고 대응 업무에 예산을 배정한다.

다음 Module 1 상세 노트에서는 Azure Firewall 배포, UDR과 DNS 동작을 설계한다. 완성된 영문·국문 글 한 쌍이 준비되기 전까지 계획 상태로 유지하며 빈 경로를 연결하지 않는다.