AZ-305 시험에서 네트워킹은 가장 까다로운 도메인 중 하나입니다. Front Door와 Traffic Manager의 차이, Application Gateway의 한계, ExpressRoute에서 BGP가 필수인 이유처럼 서비스 간의 경계를 정확히 이해해야 합니다. 이 글에서는 실제 시험 문제 42개를 분석해 추출한 핵심 패턴을 중심으로 정리합니다.
---
VNet와 서브넷 설계
VNet은 단일 Azure 리전에 귀속됩니다. 3개 리전에 인프라를 배포한다면 최소 VNet 수는 3개이며, 계층(프론트엔드/백엔드/DB) 분리는 서브넷으로 처리합니다. 시험에서 "최소 VNet 수"를 묻는 문제에서 리전 수 × 계층 수를 계산하는 함정에 빠지기 쉽습니다.
하이브리드 환경에서 IP 주소 공간 충돌은 치명적입니다. 주소가 겹치면 라우팅이 불가능해지고 우회 방법이 없습니다. Azure는 각 서브넷마다 5개 IP를 예약합니다(네트워크 주소, 게이트웨이, DNS 2개, 브로드캐스트). /24 서브넷은 251개가 실제 사용 가능하므로 VM 150개를 수용하기에 충분합니다.
GatewaySubnet 설계 원칙
VPN Gateway나 ExpressRoute Gateway용 서브넷은 반드시 이라는 이름이어야 합니다. 세 가지 원칙이 적용됩니다.
전용 서브넷 필수: VM 등 워크로드를 함께 배치할 수 없습니다. NSG 미적용 필수: 적용하면 컨트롤 플레인 트래픽이 차단되어 터널 장애가 발생합니다. 권장 크기: /27 이상. ExpressRoute 전환이나 두 게이트웨이 공존을 고려하면 /27이 안전합니다.
VNet Peering의 핵심 전제 조건은 두 VNet의 주소 공간이 겹치지 않아야 한다는 것입니다. 중복이 있으면 반드시 IP 공간을 재설계해야 하며, NAT Gateway나 VPN Gateway로 우회할 수 없습니다.
---
하이브리드 연결: VPN Gateway와 ExpressRoute
ExpressRoute는 BGP(Border Gateway Protocol)를 유일한 라우팅 프로토콜로 사용합니다. 정적 라우팅 보기가 나오면 즉시 오답입니다. 사이트 A에 장애가 발생하면 BGP 세션이 종료되고, 수십 초 내 사이트 B로 자동 전환됩니다. 이중화에서 기본/백업 경로를 구분하려면 AS Path Prepending을 사용합니다. 기본 경로(사이트 A)는 AS Path를 짧게, 백업(사이트 B)은 길게 설정합니다.
"자동 장애조치 + 동적 라우팅" 키워드가 나오면 BGP, "수동으로 경로를 고정"하는 요건이라면 UDR을 선택합니다.
Azure Virtual WAN SKU 선택
여러 사이트를 통합 관리할 때 Virtual WAN이 등장합니다.
Basic SKU: Site-to-Site VPN만 지원합니다. ExpressRoute, 리전 간 전이 라우팅 불가합니다. Standard SKU: ExpressRoute, S2S VPN, P2S VPN, 리전 간 전이 라우팅을 모두 지원합니다.
시험에서 ExpressRoute 또는 리전 간 전이 라우팅 키워드가 나오면 반드시 Standard SKU입니다. 허브 배치는 "N개 대륙 최근접 라우팅"이 요건이면 최소 N개 허브가 필요합니다. Secured Virtual Hub는 Azure Firewall을 통합한 구성으로, P2S + 전이 라우팅 + FQDN 필터링 세 키워드가 동시에 나오면 Virtual WAN Standard + Secured Virtual Hub를 선택합니다.
---
전역 트래픽 라우팅: Front Door, Traffic Manager, CDN
Front Door는 Microsoft 글로벌 엣지 네트워크에서 Anycast 방식으로 동작하는 L7 프록시입니다. 사용자와 가장 가까운 PoP에서 트래픽을 수신하고 WAF 정책을 엣지에서 적용합니다. 리전 간 자동 장애조치(수 초 내), 내장 WAF(SQL Injection, XSS, 봇, rate limiting), SSL 오프로딩, URL 경로 기반 라우팅, 쿠키 기반 세션 선호도를 단일 서비스로 제공합니다.
Front Door Premium은 Private Link 오리진을 지원합니다. 백엔드 VM을 인터넷에 노출하지 않고 Front Door에서 프라이빗 경로로 연결합니다. NSG에서 Front Door 트래픽만 허용하려면 서비스 태그를 사용합니다. Microsoft가 자동으로 최신 상태를 유지하므로 IP 목록을 관리할 필요가 없습니다.
Traffic Manager는 DNS 기반 전달 서비스입니다. 클라이언트에게 최적의 엔드포인트 IP를 DNS 응답으로 반환할 뿐 트래픽 패킷이 통과하지 않습니다. 이 비개입 구조 때문에 HTTP 헤더 조작, rate limiting, SSL 오프로딩이 불가능합니다. 리전별 Application Gateway WAF와 계층화하면 강력합니다. Traffic Manager가 DNS 레벨에서 리전을 선택하고, Application Gateway가 HTTP 헤더 라우팅과 WAF를 처리합니다.
---
부하 분산: Application Gateway와 Load Balancer
Application Gateway는 단일 리전 내 L7 부하 분산 서비스입니다. 리전 간 라우팅이나 자동 장애조치 기능이 없습니다. 여러 리전에 배포하려면 각각 별도 인스턴스를 배포하고 상위에 Traffic Manager나 Front Door를 추가합니다. WAF SKU는 OWASP CRS 기반 SQL Injection·XSS 차단, 쿠키 기반 세션 선호도, URL 경로 기반 라우팅, 자동 스케일링을 제공합니다. "WAF + 세션 선호도 + 로드 밸런싱 단일 서비스"라는 요건이 나오면 Application Gateway WAF가 정답입니다.
APIM과 Application Gateway를 함께 쓰는 패턴도 출제됩니다. 외부 트래픽이 Application Gateway(WAF)를 거친 뒤 VNet 내부 APIM으로 전달됩니다. APIM Internal 모드는 프라이빗 IP만 할당받아 인터넷 직접 접근이 불가하며 내부 팀 전용 시나리오에 적합합니다.
Load Balancer는 OSI 4계층(TCP/UDP) 단일 리전 서비스입니다. HTTP 헤더 라우팅, WAF, 리전 간 전환이 모두 없습니다. Gateway Load Balancer는 타사 NVA를 VXLAN 터널링으로 기존 로드밸런서에 투명하게 삽입합니다. "타사 NVA + L4 투명 삽입 + 기존 구성 변경 최소화" 키워드 조합이 나오면 선택합니다.
!Application Gateway vs Azure Load Balancer
서비스 비교표
| 항목 | Front Door | Traffic Manager | Application Gateway | Load Balancer | |------|-----------|----------------|---------------------|---------------| | 동작 계층 | L7 (HTTP/HTTPS) | DNS 기반 | L7 (HTTP/HTTPS) | L4 (TCP/UDP) | | 범위 | 글로벌 | 글로벌 | 단일 리전 | 단일 리전 | | WAF 내장 | 있음 | 없음 | 있음 (SKU 선택) | 없음 | | 세션 선호도 | 있음 | 없음 | 있음 (쿠키) | 없음 | | 리전 장애조치 | 자동 (수 초) | DNS TTL 기반 | 없음 | 없음 | | 주요 사용 사례 | 글로벌 L7 앱 | DNS 지역 라우팅 | 리전 내 L7+WAF | 리전 내 L4 분산 |
---
시험에서 자주 헷갈리는 선택 기준
글로벌 HTTP/HTTPS + SSL 종료 + 자동 장애조치가 단일 서비스로 필요하면 Front Door를 선택합니다. Traffic Manager는 SSL 종료를 할 수 없고, Application Gateway는 단일 리전에 한정됩니다.
지리적 최근접 라우팅 + 리전별 HTTP 헤더 라우팅 + WAF가 필요하면 Traffic Manager + Application Gateway WAF 계층화를 선택합니다. Load Balancer는 HTTP 헤더와 WAF를 지원하지 않아 Front Door + Load Balancer 조합은 부적합합니다.
온프레미스 앱 외부 노출 + 서버 직접 노출 금지 + Entra ID 인증이 동시에 요구되면 Microsoft Entra Application Proxy를 선택합니다. 온프레미스에 커넥터 에이전트만 설치하면 방화벽 인바운드 규칙 변경 없이 외부 접근을 허용하며 Conditional Access와 MFA가 기본 지원됩니다.
ExpressRoute + 온프레미스 DNS에서 Private Endpoint FQDN 해석이 필요하면 Azure Private DNS Zone + DNS Private Resolver 인바운드 엔드포인트를 조합합니다. 온프레미스 DNS에서 도메인을 인바운드 엔드포인트 IP로 조건부 포워딩하면 프라이빗 IP로 응답받습니다.
NSG 트래픽 차단 여부를 즉시 확인해야 하면 Network Watcher IP Flow Verify를 선택합니다. 5-tuple을 입력하면 NSG 허용/차단 결과와 규칙 이름을 수 초 내에 반환합니다. NSG Flow Logs는 사후 집계 분석 도구로 즉각 진단이 불가합니다.
---
실무 적용 팁
Private Endpoint를 사용하는 모든 시나리오에서 DNS 설계를 함께 고민해야 합니다. Azure Private DNS Zone을 생성하고 VNet에 연결하면 FQDN이 프라이빗 IP로 자동 해석됩니다. App Service와 SQL Database를 프라이빗으로 연결할 때는 서브넷이 최소 2개 필요합니다. App Service VNet Integration 전용 서브넷(/28 이상)과 Private Endpoint 전용 서브넷으로 역할이 다르므로 공유할 수 없습니다.
API Management에서 JWT 토큰을 중앙 검증하려면 정책을 게이트웨이 레벨에서 구성합니다. 백엔드 API 코드를 수정하지 않고 모든 API에 토큰 검증을 일괄 적용할 수 있습니다. Synapse Analytics에서 PaaS 서비스와 프라이빗 연결을 구성하려면 workspace 생성 시 Managed Virtual Network를 활성화해야 합니다. 이 설정은 이후 변경이 불가능하므로 설계 단계에서 반드시 결정해야 합니다.
---
정리
AZ-305 네트워킹에서 반복적으로 등장하는 판단 기준입니다.
글로벌 L7 + WAF + 자동 장애조치 단일 서비스 → Front Door DNS 지역 라우팅 + 리전별 L7 WAF → Traffic Manager + Application Gateway 계층화 단일 리전 VM 간 L4 분산 → Load Balancer ExpressRoute 자동 장애조치 → BGP + AS Path Prepending Virtual WAN + ExpressRoute 또는 리전 간 전이 라우팅 → Standard SKU 필수 GatewaySubnet: NSG 미적용, /27 이상, 전용 서브넷 VNet Peering: IP 주소 공간 중복 시 우회 불가, 반드시 재설계 NSG 즉시 진단 → Network Watcher IP Flow Verify
각 서비스의 동작 계층(L4 vs L7), 범위(단일 리전 vs 글로벌), 패킷 개입 여부(프록시 vs DNS)를 기준으로 구분하면 대부분의 선택 문제를 자신 있게 풀 수 있습니다.