Microsoft AZ-700: Azure Virtual Network 설계 — 학습 가이드

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

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

주소 공간 및 서브넷 계획

체계적인 IP 주소 지정 계획은 향후 재작업을 방지하고 온프레미스 네트워크나 다른 VNet과의 충돌을 피할 수 있습니다. 계층적 CIDR 블록(예: 주요 사업부당 /16, VNet당 /24, 역할에 따라 서브넷당 /26–/22)을 사용하고, 확장, 피어링, VPN/S2S 사이트 매핑을 위해 연속적인 범위를 예약하십시오. Azure는 여러 플랫폼 서비스에 대해 이름 및 서브넷 요구 사항을 강제합니다: GatewaySubnet이 반드시 존재해야 하며(VPN 게이트웨이와 그 스케일 유닛을 포함하도록 크기 지정), AzureFirewallSubnet은 전용이어야 하고 이름이 AzureFirewallSubnet이어야 하며, AzureBastionSubnet은 전용 /27 또는 그 이상이어야 합니다. Application Gateway와 많은 네트워크 가상 어플라이언스(NVA)도 전용 서브넷(다른 리소스 없음)이 필요합니다. 피어링된 VNet과 온프레미스 범위 간에 주소가 겹치지 않도록 계획하십시오. 주소 공간이 겹치면 피어링, VPN, 라우팅이 중단됩니다. 플랫폼 서비스(AKS, Azure Database 관리형 인스턴스)를 배포할 때는 서브넷 위임을 고려하고, 해당 서비스에 필요한 플랫폼 경로와 충돌하는 NSG나 UDR을 배치하지 마십시오. 일반적인 함정은 GatewaySubnet이나 AzureFirewallSubnet의 크기를 너무 작게 잡는 것입니다. 이러한 서비스는 시간이 지남에 따라 확장될 수 있으며 추가 IP가 필요합니다. 장단점: 작은 CIDR은 주소 공간을 절약하지만 향후 재구성 위험을 증가시킵니다. 큰 CIDR은 비용이 들지 않지만 관리 범위를 넓힙니다. 모든 할당을 문서화하고 PaaS 프라이빗 엔드포인트, 점프 호스트, 모니터링 에이전트, 송신(egress) NAT 용량을 위해 블록을 예약하십시오.

VNet 피어링, 게이트웨이 전송, 경로 우선순위

VNet 피어링은 지연 시간이 짧고 대역폭이 높은 연결을 제공하지만 전이적(transitive)이지 않습니다: 피어링된 스포크에서 오는 트래픽이 온프레미스에 도달하기 위해 두 번째 피어링된 VNet을 통해 자동으로 라우팅되지 않습니다. 온프레미스 연결을 중앙 집중화하려면 VPN Gateway 또는 ExpressRoute 게이트웨이가 있는 허브 VNet을 배포해야 합니다. 허브 피어링은 allowGatewayTransit을 활성화하여 구성하고 스포크 피어링은 useRemoteGateways를 활성화하여 구성하십시오. VPN Gateway는 허브에만 존재해야 합니다. 피어링은 겹치지 않는 주소 공간이 필요하며, 지역 및 글로벌 피어링을 모두 지원한다는 점을 기억하십시오(글로벌 피어링은 데이터 전송 비용과 약간 더 높은 지연 시간이 발생합니다). 경로 우선순위가 중요합니다: 사용자 정의 경로(UDR)는 BGP 학습 경로 및 시스템 경로보다 우선합니다. BGP 경로는 시스템 경로보다 우선합니다. 송신(egress) 트래픽 검사를 위해 강제 터널링이 필요한 경우, VirtualAppliance(NVA) 또는 Azure Firewall을 가리키는 UDR을 생성한 다음, 필요한 경우 BGP를 통해 온프레미스로 적절한 경로를 다시 알리십시오. 일반적인 함정으로는 허브에서 allowGatewayTransit 또는 스포크에서 useRemoteGateways 설정을 잊는 것, 스포크 추가 후 P2S 클라이언트 구성을 다시 다운로드하지 않는 것(P2S 클라이언트는 업데이트된 경로가 필요함), 피어링이 전이적이라고 가정하는 것 등이 있습니다. 처리량과 P2S 기능에 따라 VPN Gateway SKU를 선택하십시오. 프로덕션 P2S 및 BGP 환경에는 VpnGw1/2/3을 고려하십시오. Basic SKU는 많은 기능이 부족합니다.

VPN Gateway SKU: VpnGw1 — 중간 수준 처리량, OpenVPN/IKEv2/P2S 지원; VpnGw2 — 더 높은 처리량 및 TLS 확장성; VpnGw3 — 가장 높은 처리량 및 최대 규모. Basic — 기능이 제한적이며 허브 시나리오에는 권장되지 않음.

서비스 엔드포인트 vs 프라이빗 엔드포인트 및 DNS 영향

서비스 엔드포인트는 VNet ID를 Azure PaaS 서비스(Storage, SQL, Cosmos DB)로 확장하여 트래픽이 Microsoft 백본을 사용하도록 하면서, 서비스의 공용 엔드포인트는 선택된 서브넷에 대해서만 보안을 유지합니다. 프라이빗 엔드포인트는 서브넷에 네트워크 인터페이스를 배치하여 PaaS 리소스의 사설 IP에 매핑함으로써 진정한 사설 연결을 제공합니다. DNS 변경 없이 간단한 서브넷 수준의 액세스 제어를 원할 때는 서비스 엔드포인트를 선택하고, 리소스별 액세스, VNet 수준의 격리 또는 공용 네트워크 액세스를 완전히 비활성화해야 할 때는 프라이빗 엔드포인트를 선택하십시오. 프라이빗 엔드포인트는 ENI를 생성하며, 사설 DNS 영역(privatelink.<service>.azure.com)과 연결되거나 수동 DNS A 레코드가 필요합니다. 흔한 함정은 DNS를 소홀히 하여 클라이언트가 프라이빗 엔드포인트 대신 공용 IP를 확인하게 되는 것입니다. 또한 프라이빗 엔드포인트는 대상 서브넷에서 IP를 소비하므로 IP 용량을 계획해야 합니다. 서비스 엔드포인트는 공용 엔드포인트를 제거하지 않습니다. 스토리지 계정을 완전히 잠그려면 프라이빗 엔드포인트를 활성화한 후 공용 네트워크 액세스를 비활성화해야 합니다. 비용 및 운영상의 장단점: 프라이빗 엔드포인트는 관리(리소스별 DNS 및 승인)와 약간의 운영 복잡성을 증가시키지만 더 강력한 격리를 제공합니다. 서비스 엔드포인트는 더 간단하고 비용이 저렴하지만 세분화된 제어는 어렵습니다.

NAT 게이트웨이, Azure Firewall 및 경로 설계의 장단점

예측 가능한 아웃바운드 SNAT와 간소화된 이그레스(egress) 관리를 위해, 서브넷이나 NIC에 Azure Virtual Network NAT(Standard NAT Gateway)를 배포하고 Standard 공용 IP 또는 접두사(standard SKU만 해당)를 연결하십시오. NAT Gateway는 임시 포트 관리를 오프로드합니다. 많은 아웃바운드 연결이 예상되는 경우, 여러 공용 IP 접두사를 연결하여 사용 가능한 SNAT 포트를 늘리고 포트 고갈을 방지하십시오. 이는 다수의 VM이나 컨테이너 호스트 환경에서 흔히 발생합니다. Azure Firewall은 중앙 집중식 완전 관리형 상태 저장 검사, 위협 인텔리전스, 애플리케이션/FQDN 필터링을 제공합니다. 기본적인 필터링이 필요하면 Azure Firewall Standard를, TLS 검사, IDPS, 향상된 위협 기능이 필요하면 Premium SKU를 선택하십시오. 네트워크 가상 어플라이언스(타사 NVA)는 풍부한 기능이나 비용 대안을 제공하지만, 관리, HA 구성 및 확장 계획이 필요합니다. VirtualAppliance 또는 Internet/NAT를 가리키는 UDR은 Azure의 시스템 경로와 비교하여 평가해야 합니다. 잘못된 UDR은 플랫폼 서비스 트래픽(예: 서비스 엔드포인트 트래픽 또는 플랫폼 관리 상태 프로브 차단)을 중단시킬 수 있기 때문입니다. 고가용성 및 성능을 위해, 고정 비용 어플라이언스 대신 영역 중복 SKU(Application Gateway v2, 가용성 영역의 Firewall)와 자동 확장 기능을 고려하십시오. 일반적인 함정: 서브넷과 NIC 모두에 NAT를 연결하면 예기치 않은 우선순위가 적용될 수 있습니다. NAT에는 Standard 공용 IP가 필요하다는 사실을 잊는 경우, AzureFirewallSubnet의 이름 지정 및 크기 조정을 잘못하는 경우, 그리고 UDR이 무시될 것이라고 가정하는 경우(UDR은 시스템 경로를 재정의합니다)가 있습니다.

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

시나리오: Contoso Enterprises는 허브-스포크(hub-and-spoke) Azure 네트워크를 운영합니다. West US 지역의 허브는 ExpressRoute 게이트웨이와 VpnGw2(GatewaySubnet 내)를 호스팅합니다. 여러 스포크에는 애플리케이션 서브넷과 PaaS 서비스를 위한 프라이빗 엔드포인트가 포함되어 있습니다. 원격 근무자는 지점-사이트(P2S) VPN을 통해 허브에 연결합니다.

과제: 원격 사용자는 허브의 리소스에는 액세스할 수 있지만, 최근 스포크가 추가된 후 스포크의 VNet 리소스에는 연결할 수 없으며 일부 P2S 클라이언트에는 오래된 경로 집합이 표시됩니다.

권장 접근 방식:

허브 VNet에서 VPN 게이트웨이가 적절한 크기의 GatewaySubnet(최소 /27)에 배포된 VpnGw2인지 확인합니다. 피어링된 토폴로지에서 유일한 게이트웨이인지, 그리고 ExpressRoute가 경로 교환을 통해 공존하는지 검증합니다.
허브-스포크 피어링에서 허브 측 피어링에는 allowGatewayTransit = true를 설정합니다. 각 스포크 피어링에서는 useRemoteGateways = true를 설정하고 주소 공간이 겹치지 않도록 합니다.
허브 VPN 게이트웨이에서 업데이트된 P2S VPN 클라이언트 구성(IKEv2/OpenVPN 포함)을 다시 생성하여 배포하고, 원격 사용자가 클라이언트를 재설치하여 라우팅 테이블에 새로운 스포크 접두사가 포함되도록 요구합니다.
스포크가 검사를 위해 허브를 통해 아웃바운드 라우팅해야 하는 경우, 스포크 라우팅 테이블에 0.0.0.0/0 트래픽을 허브 가상 어플라이언스 또는 Azure Firewall(AzureFirewallSubnet에 배포됨)로 보내는 UDR을 추가하고, ExpressRoute/VPN에서 BGP를 통해 필요한 경로를 다시 광고합니다.

근거: useRemoteGateways와 함께 게이트웨이 전송을 활성화하면 추가 게이트웨이를 생성하지 않고도 허브 게이트웨이를 통해 온프레미스 및 P2S 라우팅을 중앙 집중화할 수 있습니다. P2S 클라이언트 구성을 재발급하면 클라이언트 라우팅 테이블이 업데이트되어 새로운 스포크 접두사에 연결할 수 있게 됩니다. UDR과 BGP는 제어된 이그레스(egress)와 검사를 위한 가시성을 보장합니다.

← ExpressRoute 및 WAN 연결 · 모든 도메인 · 하이브리드 네트워킹 →

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