Microsoft AZ-700: 하이브리드 네트워킹 — 학습 가이드

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

다음의 일부입니다: Microsoft Azure Network Engineer AZ-700 — 학습 가이드. 검증된 답안으로 연습하기: Microsoft 시험 허브, 또는 다음에서 시간 제한 모의고사 풀기: ExamRoll.io.

하이브리드 연결 기본 사항 및 주소 지정 제약 조건

하이브리드 연결은 온프레미스와 Azure 가상 네트워크 간의 신뢰성 있고, 라우팅 가능하며, 안전한 IP 연결성을 확보하는 것입니다. 가상 네트워크 주소 지정을 계획할 때, 서브넷 내의 일부 Azure 관리 리소스는 연속적이고 충돌하지 않는 주소 할당과 때로는 특정 예약된 주소를 필요로 한다는 점을 기억해야 합니다. Azure 부하 분산 장치와 게이트웨이 서브넷은 의도적으로 분할해야 하며(GatewaySubnet은 이름이 정확해야 하고 게이트웨이 SKU 확장을 수용할 수 있도록 크기가 조정되어야 함), 프라이빗 엔드포인트와 Azure 관리 서비스 엔드포인트는 호스팅 VNet에서 가져온 주소가 필요합니다. 온프레미스와 Azure 접두사가 겹치는 것이 가장 흔한 함정입니다. 주소 범위가 겹치면 라우팅 및 BGP 경로 선택이 중단되고, 비대칭 라우팅이 발생하며, 방화벽 정책이 복잡해집니다. 상태 저장 방화벽, 부하 분산 장치 또는 다수의 프라이빗 엔드포인트를 호스팅하는 서브넷에는 최소 /27–/24 세그먼트를 사용하고, 전용 GatewaySubnet(/27 또는 SKU에 따라 더 크게)을 예약하십시오. DNS도 마찬가지로 중요합니다. 프라이빗 엔드포인트는 플랫폼 프라이빗 DNS 영역(예: privatelink.database.windows.net)을 사용하므로, 온프레미스에서 Azure 프라이빗 이름을 확인하려면 조건부 전달자나 Azure DNS Private Resolver가 필요합니다. 설계 시 절충점은 IP 활용률과 복원력 사이에서 결정됩니다. 더 조밀한 IPv4 구성은 주소 공간을 절약하지만 충돌 및 마이그레이션 위험을 증가시키는 반면, 더 크고 덜 효율적인 접두사는 향후 확장 및 BGP 광고 전략을 단순화합니다.

VPN Gateway SKU, BGP 기본 사항 및 로컬 네트워크 게이트웨이

올바른 VPN 게이트웨이 SKU(VpnGw1–VpnGw5, 레거시의 경우 Basic)를 선택하는 것은 처리량, 동시 S2S/P2S 세션 수, 그리고 액티브-액티브 또는 경로 제한과 같은 사용 가능한 기능에 직접적인 영향을 미칩니다. 최신 하이브리드 설계에는 경로 기반 게이트웨이를 사용하십시오. 정책 기반은 레거시이며 BGP를 제한합니다. BGP는 접두사의 동적 교환을 제공하고 경로 복원력, 자동 장애 조치, 접두사 우선순위 지정을 지원합니다. Azure VPN Gateway ASN(기본값 65515)을 구성하고 Local Network Gateway 개체에서 온프레미스 ASN과 일치시키거나 피어링하십시오. Local Network Gateway는 온프레미스 공용 IP, 주소 공간, 그리고 선택적으로 BGP 피어 IP 및 ASN을 저장합니다. BGP 피어 IP를 채우는 것을 잊거나 ASN이 일치하지 않으면 경로 전파가 방지되고 정적 경로를 이용한 해결 방법으로 이어집니다. 다중 사이트 확장 및 내장된 전송 라우팅을 위해 Azure Virtual WAN 허브를 고려하십시오. VWAN 허브는 대규모 S2S 및 P2S를 지원하며 Azure Firewall 및 ExpressRoute와 통합됩니다. 경로 테이블 전파에 주의하십시오. 기본적으로 일부 허브-스포크 또는 가상 어플라이언스 토폴로지는 자동 전파를 억제하므로, 명시적인 UDR 또는 BGP 경로 광고가 필요할 수 있습니다. 절충점: 더 높은 SKU와 VWAN은 비용을 증가시키지만 관리 오버헤드를 줄이고 처리량과 라우팅 규모를 개선합니다.

지점 및 사이트 간 설계 선택, 클라이언트 지원 및 DNS 통합

지점 및 사이트 간(P2S) 선택은 클라이언트 호환성, 인증 및 규모를 결정합니다. OpenVPN(SSL)은 가장 크로스플랫폼을 잘 지원하며 macOS, Linux 및 모바일 클라이언트에 권장됩니다. IKEv2는 가볍고 macOS 네이티브 클라이언트와 잘 작동하며, SSTP는 구형 Windows 전용 시나리오를 위한 옵션으로 남아 있습니다. 인증 모드에는 Azure Active Directory(ID 통합 및 조건부 액세스에 권장), 인증서 기반, 그리고 온프레미스 MFA 또는 RADIUS 기반 솔루션을 위한 RADIUS가 포함됩니다. VPN Gateway SKU는 P2S 터널 수와 처리량을 결정합니다. 중간에서 큰 규모의 사용자 풀에는 VpnGw2/3를, 대규모 또는 처리량에 민감한 사용 사례에는 VpnGw4/5를 선택하십시오. 프라이빗 엔드포인트와 P2S는 DNS를 통해 상호 작용합니다. P2S 클라이언트가 프라이빗 엔드포인트 이름(privatelink 영역)을 확인할 수 있도록 하려면, 프라이빗 DNS 영역을 VNet에 연결하거나 온프레미스 또는 클라이언트 DNS에서 Azure DNS Private Resolver 및 조건부 전달자를 사용해야 합니다. 흔한 함정은 P2S 클라이언트가 일반적으로 클라이언트가 경로 및 DNS 설정을 푸시할 때만 게이트웨이에서 제공하는 Azure DNS를 사용한다는 사실을 잊는 것입니다. 명시적인 DNS 접미사 및 전달자 구성은 “프라이빗 엔드포인트를 확인할 수 없음” 문제를 방지합니다. 확장성과 비용의 균형을 맞추십시오. 인증서 인증은 비용이 저렴하지만 해지하기가 더 어렵고, Azure AD는 최신 보안 제어를 제공하지만 라이선스/복잡성이 추가됩니다.

트랜짓 라우팅, 강제 터널링, 검사 및 보안 어플라이언스 배치

여러 VNet, 온프레미스, 검사 어플라이언스 간의 트랜짓을 설계하려면 라우팅 및 NAT 경계를 명확하게 적용해야 합니다. Azure Firewall 또는 가상 어플라이언스를 통해 트래픽을 강제로 보내려면 방화벽 프라이빗 IP를 가리키는 사용자 정의 경로(UDR)를 사용하거나 Virtual WAN 허브 라우팅을 사용하여 검사를 중앙 집중화해야 합니다. 완전한 투명 프록시 또는 TLS 검사가 필요한 경우, 어플라이언스를 전용 검사 서브넷에 배치하고 게이트웨이 서브넷과 방화벽 SKU가 예상 처리량에 대한 트랜짓을 지원하는지 확인해야 합니다. SNAT 동작 및 공용 IP SKU 선택에 주의를 기울여야 합니다. 예측 가능한 아웃바운드 SNAT 및 보안 규칙을 위해서는 Standard Public IP와 NAT Gateway를 권장합니다. NAT Gateway를 Standard 공용 IP 세트와 함께 사용하면 SNAT 부하를 줄이고 VM별 공용 IP가 무분별하게 늘어나는 것을 방지할 수 있습니다. 한 가지 함정은 온프레미스 경로와 Azure UDR로 인해 반환 트래픽이 의도한 어플라이언스를 우회하는 비대칭 라우팅입니다. 모든 스포크가 BGP를 통해 필요한 접두사를 광고하거나 검사 지점으로 트래픽을 모으는 UDR을 가지고 있는지 확인해야 합니다. 성능 대 비용: Azure Firewall Premium 또는 타사 고성능 어플라이언스를 사용하는 허브 앤 스포크 구성은 보호 및 중앙 관리를 강화하지만, 활성-활성 이중화 허브를 배포하고 지역 간에 게이트웨이를 페어링하지 않으면 비용과 단일 허브 장애 위험이 증가합니다.

실용적인 문제: 사용 사례 시나리오

시나리오: Contoso Ltd는 두 개의 온프레미스 데이터센터(시애틀, 암스테르담)와 단일 허브 VNet(VNet-Hub)에 세 개의 VNet(VNet-Prod, VNet-Shared, VNet-Dev)이 있는 기존 Azure 환경을 보유하고 있습니다. 현재 시애틀 연결을 위해 VpnGw1 VPN Gateway를 사용하고 있으며, 암스테르담 연결을 위해 Azure Virtual WAN 허브에 사이트 간 연결을 사용하고 있습니다. VNet-Shared에서는 Azure SQL에 프라이빗 엔드포인트를 사용합니다.

과제: Contoso는 두 데이터센터와 Azure 간에 동적 라우팅(BGP)을 사용하는 복원력 있고 확장 가능한 하이브리드 연결, macOS 사용자를 위한 안정적인 P2S 지원, 온프레미스에서 프라이빗 엔드포인트의 DNS 확인, 그리고 스포크에서 나가는 아웃바운드 트래픽을 Azure Firewall을 통해 중앙에서 검사하는 기능이 필요합니다.

권장 접근 방식:

VNet-Hub에 BGP가 활성화된 활성-활성 구성의 새로운 경로 기반 VpnGw3 VPN Gateway를 배포하고(게이트웨이 ASN을 명시적으로 설정), 온프레미스 BGP 피어 IP 및 ASN으로 Local Network Gateway 개체를 업데이트합니다. 더 높은 처리량과 경로 제한을 지원하기 위해 시애틀 S2S 연결을 새 게이트웨이로 마이그레이션합니다.
ExpressRoute를 설정하거나 VWAN 허브를 VNet-Hub와 허브 피어링으로 마이그레이션하여 암스테르담 연결을 허브로 통합합니다. 정적 경로를 피하고 자동 장애 조치를 활성화하기 위해 두 데이터센터 간에 BGP 경로가 교환되도록 보장합니다.
VpnGw3에서 Azure AD 인증과 함께 OpenVPN 프로토콜을 사용하여 P2S를 구성하여 macOS 클라이언트를 지원하고(IKEv2를 대체 옵션으로 사용), VpnGw3 제한에 따라 클라이언트 풀 크기를 조정합니다. 온프레미스 DNS에 조건부 전달자를 게시하여 privatelink.* 영역에 대한 요청을 VNet-Shared에 배포된 Azure DNS Private Resolver로 전달하고, 이를 프라이빗 엔드포인트용 프라이빗 DNS 영역에 연결합니다.
VNet-Hub에 Azure Firewall(TLS 검사가 필요한 경우 Standard 또는 Premium)을 활성-활성 구성으로 배포하고, 스포크 서브넷에 0.0.0.0/0 트래픽을 방화벽 프라이빗 IP로 보내는 UDR을 생성합니다. 방화벽에 Standard 공용 IP를 사용하는 NAT Gateway를 연결하거나, 명시적 SNAT 및 중앙 Log Analytics 로깅을 위해 방화벽의 공용 IP를 사용합니다.

근거: BGP와 함께 VpnGw3를 사용하면 다중 사이트 복원력을 위한 동적 경로 전파와 처리량을 제공합니다. OpenVPN+Azure AD는 macOS 사용자를 안전하게 지원합니다. Azure DNS Private Resolver로 DNS를 전달하면 온프레미스에서 프라이빗 엔드포인트 이름 확인을 보장합니다. UDR을 사용하여 Azure Firewall 허브에서 검사를 중앙 집중화하면 비대칭 라우팅을 방지하고 정책 관리를 단순화하는 동시에, 비용을 투자하여 중앙 집중식 보안 및 가시성을 확보할 수 있습니다.

← Azure Virtual Network 설계 · 모든 도메인 · Azure DNS 및 이름 확인 →

이 문제 연습하기 → · ExamRoll.io에서 시간 제한 연습 →