가상 네트워크 및 서브넷 Azure

Azure VNet(가상 네트워크) 및 서브넷은 모든 Azure 네트워크의 기본 구성 요소입니다. 이 문서에서는 VNet이 격리를 제공하는 방법, 서브넷이 리소스를 구성하는 방법 및 프로덕션 워크로드를 위해 네트워크의 크기를 조정하고 구성하는 방법을 설명합니다.

이 문서에서 다루는 내용

이 문서에서는 VNet 격리 경계, 서브넷 크기 조정 및 예약된 주소, Azure Firewall 및 Application Gateway와 같은 서비스에 대한 전용 플랫폼 서브넷, VNet 피어링 및 일반적인 네트워크 레이아웃 패턴에 대해 설명합니다.

이 문서가 필요한 사람

다음과 같은 경우 이 문서를 읽어보세요.

Azure 첫 번째 워크로드를 배포하고 있으며 리소스를 만들기 전에 네트워킹의 작동 방식을 이해해야 합니다.
다중 워크로드 환경을 계획하고 있으며 만들 VNet 및 서브넷 수를 결정해야 합니다.
온-프레미스 워크로드를 Azure 마이그레이션하고 있으며 Azure 네트워킹이 실제 네트워킹과 어떻게 다른지 이해해야 합니다.
Azure Firewall, VPN Gateway 또는 AKS(Azure Kubernetes Service) 같은 Azure 플랫폼 서비스에 대해 서브넷 크기를 올바르게 조정해야 합니다.
워크로드를 다른 VNet으로 분리하는 경우와 동일한 VNet에 유지하는 경우를 이해하려고 합니다.

리프트 앤 시프트 포커스: Azure 온-프레미스 서브넷 세분화를 미러링합니다. 기존 VLAN 및 보안 영역을 서브넷에 매핑하고, 팀이 이미 운영하고 있는 범위에 맞춰 주소 공간을 유지하고, 마이그레이션 중에 주소를 다시 처리할 필요가 없도록 서브넷 크기를 넉넉하게 조정합니다.

포커스 현대화: 플랫폼 서비스 및 자동화를 중심으로 서브넷을 디자인합니다. AKS, 프라이빗 엔드포인트 및 전용 플랫폼 서비스에 맞게 서브넷 크기를 적절히 산정하고, Azure Virtual Network Manager가 여러 VNet에 일관된 구성을 적용할 수 있도록 계획합니다.

클라우드 간 포커스: VNet을 만들기 전에 Azure, AWS 및 Google Cloud에서 겹치지 않는 주소 공간을 계획합니다. NAT 없이 클라우드를 피어링하거나 VPN에 연결할 수 있도록 기존 VPC와 충돌하지 않는 CIDR 범위를 예약합니다.

Azure 서비스 및 기능

다음 서비스와 기능은 Azure 가상 네트워킹 기반을 구성합니다.

서비스 또는 기능	제공하는 내용	사용 시기
Azure Virtual Network(VNet)	Azure의 격리된 전용 네트워크. 모든 Azure 네트워킹은 여기에서 시작됩니다. 동일한 VNet의 리소스는 기본적으로 통신할 수 있습니다. 다른 VNet의 리소스는 명시적으로 연결하지 않으면 통신할 수 없습니다.	항상: 네트워크 연결이 필요한 모든 워크로드에는 VNet이 필요합니다.
Subnet	VNet 주소 공간의 파티션입니다. 서브넷은 NSG(네트워크 보안 그룹) 및 경로 테이블 연결의 범위입니다.	항상: 함수 또는 보안 경계를 통해 워크로드 구성 요소를 서브넷으로 구성합니다.
VNet 피어링	대기 시간이 짧고 동일한 지역 또는 지역 간 두 VNet 간의 프라이빗 연결입니다. 트래픽은 Microsoft 백본 네트워크를 통해 전송됩니다. 피어링은 전이성이 없습니다. 각 피어링은 개별적인 직접 연결입니다.	별도의 VNet의 리소스가 통신해야 하는 경우 지역 간 피어링에 대해서는 지역 간 연결을 참조하세요.
서브넷 피어링(미리 보기)	전체 VNet이 아닌 특정 서브넷 간의 피어링. 피어링 관계에 참여하는 서브넷에 대한 세부적인 제어를 제공합니다.	서로 다른 VNet의 특정 서브넷 간에 세분화된 피어링 제어가 필요한 경우 제약 조건 섹션을 참조하세요.
경로 테이블/UDR(사용자 정의 경로)	트래픽이 전송되는 위치를 제어하기 위해 Azure 기본 시스템 경로를 재정의합니다. 서브넷 수준에서 적용됩니다.	트래픽이 방화벽 또는 네트워크 가상 어플라이언스(NVA)를 통과하도록 강제해야 하는 경우 허브 앤 스포크 아웃바운드 제어에 필요합니다. Azure Firewall 설계 및 허브-스포크 토폴로지를 참조하세요.
AZURE VIRTUAL NETWORK MANAGER(AVNM)	구독에서 VNet에 네트워크 구성을 중앙에서 만들고, 관리하고, 적용합니다.	여러 구독에서 많은 VNet을 관리하는 경우 중앙 집중식 네트워크 관리를 참조하세요.

선택 방법

가상 네트워크가란?

VNet(가상 네트워크)은 Azure 소프트웨어 정의 격리된 네트워크입니다. Azure 프라이빗 네트워크로 생각하세요. 케이블, 스위치 및 라우터를 사용하는 실제 네트워크와 달리 VNet은 전적으로 소프트웨어로 정의됩니다. 이를 만들고, 주소 공간을 할당하고, 리소스를 배포합니다.

주요 특징:

지역 범위: VNet은 하나의 Azure 지역 내에만 존재합니다. 해당 VNet의 모든 리소스는 동일한 지역에 있어야 합니다. VNet은 해당 지역 내의 가용성 영역에 걸쳐 있습니다.
기본적으로 격리: 연결(피어링 또는 VPN)을 명시적으로 만들지 않는 한 한 VNet의 리소스는 다른 VNet의 리소스와 통신할 수 없습니다.
기본 내부 연결: 동일한 VNet 내의 리소스는 기본적으로 Azure 제공하는 시스템 경로를 통해 서로 통신할 수 있습니다.

서브넷이란?

서브넷은 VNet 내의 IP 주소 범위입니다. 서브넷을 사용하면 다음을 수행할 수 있습니다.

워크로드 구성 요소(예: 웹 계층, 애플리케이션 계층, 데이터 계층)로 네트워크를 분할합니다.
보안 규칙 적용: NSG는 서브넷 수준에서 연결하여 트래픽을 필터링합니다.
제어 라우팅: 경로 테이블은 트래픽을 직접 보내기 위해 서브넷 수준에서 연결됩니다.

Azure 모든 서브넷에 처음 4개의 주소와 마지막 주소 등 5개의 IP 주소를 예약합니다. 예를 들어 /24 서브넷(256개 주소)에서는 251개만 사용할 수 있습니다. 이 예약을 크기 조정 계산에 고려합니다.

예: 3계층 애플리케이션

일반적인 3계층 웹 애플리케이션은 세 개의 서브넷을 사용하여 문제를 구분하고 고유한 보안 규칙을 적용합니다.

Subnet	CIDR 범위	Purpose	예제 리소스
`web-subnet`	10.0.1.0/24	인터넷 또는 Application Gateway에서 인바운드 HTTP/HTTPS 트래픽을 허용하는 프런트 엔드 웹 서버	Azure App Service Environment, NGINX를 실행하는 가상 머신 확장 집합
`app-subnet`	10.0.2.0/24	중간 계층 애플리케이션 논리입니다. 웹 서브넷에서만 트래픽을 허용합니다.	Azure Functions(VNet 통합), 비즈니스 논리를 실행하는 VM
`data-subnet`	10.0.3.0/24	데이터 저장소. 앱 서브넷의 트래픽만 허용합니다. 직접 인터넷에 액세스할 수 없습니다.	Azure SQL Managed Instance, Azure SQL Database 또는 Cosmos DB에 대한 프라이빗 엔드포인트

이 레이아웃을 사용하면 트래픽을 해당 계층에 필요한 항목으로만 제한하는 각 서브넷에 NSG를 적용할 수 있습니다. 웹 서브넷은 인바운드 HTTPS(포트 443)를 허용합니다. 앱 서브넷은 웹 서브넷의 IP 범위에서만 인바운드 트래픽을 허용합니다. 데이터 서브넷은 앱 서브넷의 IP 범위에서만 인바운드 트래픽을 허용합니다.

AKS 기반 현대화 패턴의 경우, Azure CNI Overlay를 배포할 때 클러스터 노드 풀에 10.0.4.0/24와 같은 aks-nodes 서브넷을 사용할 수 있습니다. 이 모델에서는 노드만 서브넷에서 VNet IP 주소를 할당받아 사용합니다. Pod는 별도의 오버레이 CIDR을 사용하여 노드 서브넷을 플랫 네트워크 AKS 디자인보다 작게 유지할 수 있습니다.

일반적인 패턴

다음 서브넷 레이아웃은 가장 일반적인 Azure 배포 시나리오를 다룹니다.

패턴	Subnets	사용 시기
간단한 웹앱	`web` + `data`	프런트 엔드 및 데이터베이스가 있는 2계층 애플리케이션. 최소한의 복잡성.
3계층 엔터프라이즈	`web` + `app` + `data` + `management`	명확히 구분된 계층과 관리용 점프 박스 또는 Bastion 서브넷이 있는 기존 엔터프라이즈 워크로드.
공유 서비스를 사용하는 AKS	`aks-nodes` + `aks-ingress` + `appgw` + `shared`	전용 인그레스 컨트롤러 서브넷 및 WAF용 Application Gateway가 포함된 Kubernetes 워크로드.
허브 및 스포크 간 송신	`AzureFirewallSubnet` + `GatewaySubnet` + `AzureBastionSubnet` + `management`	허브-스포크 토폴로지의 허브 VNet입니다. 공유 서비스의 트래픽은 스포크 VNet을 통해 라우팅됩니다. 허브 및 스포크 토폴로지 참조
데이터 워크로드	`compute` + `data` + `private-endpoints` + `management`	스토리지 및 데이터베이스에 대한 프라이빗 엔드포인트가 IP 계획 명확성을 위해 자체 서브넷이 필요한 분석 및 데이터 플랫폼 워크로드.

VNet 및 서브넷은 몇 개입니까?

안내 원칙은 간단합니다. 애플리케이션당 하나의 가상 네트워크 와 구성 요소당 하나의 서브넷 (계층)을 사용합니다. 이 기본값은 각 워크로드를 격리하고, 계층 간 트래픽을 네트워크 보안 그룹으로 쉽게 제어할 수 있게 하며, 증가의 여지를 남깁니다. 공유 서비스, 격리 요구 사항 및 규모에 따라 여기에서 조정합니다.

이 의사 결정 테이블을 사용하여 VNet 및 서브넷 전략을 결정합니다.

사용자 상황	권장되는 접근 방식
단일 워크로드, 단일 팀, 공유 서비스가 필요하지 않음	애플리케이션 구성 요소당 서브넷이 있는 하나의 VNet(웹, 애플리케이션 논리, 데이터). 단일 워크로드 토폴로지 참조
게이트웨이 또는 방화벽을 공유하는 여러 독립 워크로드	공유 서비스를 위한 허브 VNet + 워크로드별 스포크 VNet 1개. 허브 및 스포크 토폴로지 참조
워크로드 간의 엄격한 격리(폭발 반경, 규정 준수 요구 사항)	각 워크로드마다 VNet을 하나씩 두고, 이들 간에는 피어링이 없습니다.
구독 및 지역이 많은 매우 큰 환경	자동화된 허브 관리 기능이 있는 Azure Virtual WAN Virtual WAN 토폴로지를 참조하세요.

전용 서브넷 크기 조정 참조

많은 Azure 플랫폼 서비스에는 특정 이름과 최소 크기의 전용 서브넷이 필요합니다. 다음 다이어그램에서는 전용 플랫폼 서브넷에 대한 명명 요구 사항 및 최소 크기를 보여 줍니다.

주소 공간을 계획할 때 다음 표를 사용합니다.

Azure 서비스	최소 서브넷 크기	필수 서브넷 이름	Notes
Azure Firewall	/26(59개 사용 가능한 IP)	`AzureFirewallSubnet`	모든 방화벽 SKU에 필요합니다. Azure Firewall 디자인을 참조하세요.
VPN 게이트웨이	/27(사용 가능한 IP 27개)	`GatewaySubnet`	Microsoft는 확장 여유를 위해 /27 이상을 권장합니다.
Azure Bastion	/26(59개 사용 가능한 IP)	`AzureBastionSubnet`	2021년 11월 이후 생성된 모든 배포의 최소값은 /26입니다.
Application Gateway v2	/24 권장(사용 가능한 IP 251개)	필수 이름 없음	자동 크기 조정을 수용하기 위해 매우 권장되는 /24입니다. 최소값은 공식에 따라 결정됩니다(인스턴스 + 예약 5개 + 프라이빗 프런트엔드 IP 1개).
앱 서비스 환경	/24(프로덕션), /23(최대 규모)	필수 이름 없음	스케일링은 서브넷에서 IP 주소를 소모합니다. 200 인스턴스 최대값에 가깝게 크기를 조정하려는 경우 /23을 사용합니다.
애저 라우트 서버 (Azure Route Server)	/26(59개 사용 가능한 IP)	`RouteServerSubnet`	NVA와의 BGP 경로 교환에 필요합니다.
Azure DNS Private Resolver (Azure DNS 프라이빗 리졸버)	엔드포인트 서브넷당 최소 /28	전용 인바운드 및 아웃바운드 서브넷	인바운드 및 아웃바운드 엔드포인트에 대해 별도의 서브넷이 필요합니다. 다른 리소스와 공유할 수 없습니다.
AKS(Azure Kubernetes Service)	수식 기반(CNI 종속)	필수 이름 없음	AKS 크기 조정 지침을 참조하세요.

메모

프라이빗 엔드포인트는 기존 서브넷의 IP 주소를 사용합니다. 전용 서브넷이 필요하지 않습니다. 이 IP 사용량을 서브넷 크기 조정에 고려합니다. 자세한 IP 계획은 IP 주소 계획을 참조하세요.

AKS 서브넷 크기 조정

AKS 서브넷 크기 조정은 CNI(Container Networking Interface) 플러그 인 선택에 따라 달라집니다. 최소 크기는 하나도 없습니다.

Azure CNI 오버레이: 서브넷은 Pod가 별도의 프라이빗 CIDR(클래스리스 Inter-Domain 라우팅) 블록을 사용하기 때문에 노드만 수용하면 됩니다. 플랫 네트워킹에 비해 훨씬 더 작은 서브넷을 사용할 수 있습니다.
Azure CNI(플랫 네트워크): 서브넷은 노드 AND Pod를 모두 수용해야 합니다. 수식: (nodes + surge) × (max_pods + 1). 노드가 50개 이상인 클러스터에는 /21 이상이 일반적입니다.
Kubenet: 노드만 VNet 서브넷 IP를 사용합니다. Pod는 클러스터 내부 IP 주소를 가져옵니다.

CNI당 수식 크기 조정 옵션은 AKS 클러스터에 대한 IP 주소 지정 계획을 참조하세요.

서브넷 피어링 제약 조건

서브넷 피어링에서는 전체 주소 공간 대신 VNet 간에 특정 서브넷을 연결합니다. 이 방법은 피어링 관계에 참여하는 서브넷을 세부적으로 제어합니다.

Important

서브넷 피어링이 현재 미리 보기로 제공되며 다음과 같은 제약 조건이 있습니다.

구독을 승인된 목록에 추가해야 합니다(셀프 서비스 등록 아님).
CLI, ARM 템플릿, Terraform 또는 PowerShell만(포털 지원 없음)
인텔 기반 V5 SKU(또는 AMD Genoa/Cobalt 100 기반 SKU)는 이전 세대 SKU에서 알려진 버그를 방지하기 위해 프로덕션 사용에 필요합니다. 현재 하드웨어 요구 사항에 대한 서브넷 피어링 구성 을 참조하세요.
피어링 링크의 각 측당 최대 200개의 서브넷
VNet당 모든 피어링 링크에서 총 서브넷 최대 1,000개
서브넷은 겹치지 않는 고유한 주소 공간에 속해야 합니다.

현재 제한 사항 및 등록은 서브넷 피어링 구성을 참조하세요.

메모

AVNM(Azure Virtual Network Manager)은 VNet 피어링과 서브넷 피어링을 구분할 수 없습니다. AVNM을 사용하여 피어링 구성을 관리하는 경우 서브넷 수준 피어링 관계가 AVNM에서 표준 VNet 피어링으로 표시됩니다.

디자인 고려 사항

리프트 앤 시프트 VNet 및 서브넷 디자인 포커스

온-프레미스 구분을 다시 만듭니다. 각 VLAN 또는 보안 영역을 서브넷에 매핑하여 기존 방화벽 경계 및 운영 소유권이 최소한의 재설계로 이월되도록 합니다.
헤드룸을 사용하여 서브넷 크기를 조정합니다. 마이그레이션 후 주소를 다시 할당하면 운영에 지장을 줄 수 있으므로, 향후 증가분과 서브넷마다 Azure가 예약하는 5개의 주소를 감안해 현재 호스트 수에 필요한 것보다 더 큰 CIDR 범위를 할당하세요.
라우팅을 간소화하고 VPN Gateway 또는 ExpressRoute를 통해 연결할 때 겹치지 않도록 가능한 경우 Azure 주소 공간을 온-프레미스 범위에 맞춰 유지합니다.
기본값은 계층당 서브넷이 있는 마이그레이션된 애플리케이션당 하나의 VNet입니다. 이 디자인은 일반적인 3계층 온-프레미스 레이아웃을 반영하고 이동을 예측 가능하게 유지합니다.

VNet 및 서브넷 디자인 포커스 현대화

플랫폼 서비스를 중심으로 서브넷을 먼저 디자인합니다. Azure Firewall, Application Gateway 및 Bastion용 전용 서브넷과 CNI 선택에 따라 AKS용으로 올바르게 크기가 조정된 서브넷.
Pod는 VNet 주소 공간이 아니라 별도의 오버레이 CIDR에서 할당받으므로, AKS에 Azure CNI Overlay를 사용하여 노드 서브넷 규모를 작게 유지합니다.
프라이빗 엔드포인트용 전용 서브넷을 예약하여 더 많은 Azure PaaS 서비스를 채택할 때 IP 소비가 예측 가능한 상태를 유지합니다.
VNet 수가 구독에서 증가함에 따라 네트워크 그룹, 연결 및 보안 구성을 일관되게 적용하려면 Azure Virtual Network Manager 일찍 채택합니다.

클라우드 간 VNet 및 서브넷 디자인 포커스

VNet을 만들기 전에 전역 주소 계획을 설정합니다. 기존 AWS VPC 및 Google Cloud VPC 네트워크와 충돌하지 않는, Azure용 비중첩 CIDR 블록을 예약하세요. 이 예약은 라우트된 VPN 또는 상호 연결에 필수입니다.
각 클라우드의 네트워크 기본 형식을 Azure 매핑합니다. AWS VPC 또는 Google Cloud VPC 네트워크는 Azure VNet에 해당하고 보안 그룹은 NSG에 해당합니다.
Azure Virtual WAN 사용하는 VPN Gateway 또는 허브와 같은 GatewaySubnet 클라우드 간 연결 구성 요소에 대한 서브넷 공간을 예약하므로 전송 인프라는 확장할 여지가 있습니다.
클라우드에서 서브넷 명명 및 태그 지정을 표준화하여 운영 팀이 다중 클라우드 트래픽 문제를 해결할 때 동등한 계층의 상관 관계를 지정할 수 있습니다.

사전 요구 사항

가상 네트워크 및 서브넷 레이아웃을 디자인하기 전에 다음이 있는지 확인합니다.

Azure 구독: 네트워킹 리소스를 만들 수 있는 권한이 있는 활성 Azure 구독입니다(네트워크 기여자 역할 이상).
리소스 그룹: VNet 리소스를 포함할 대상 지역의 리소스 그룹입니다.
지역 결정: 사용자 근접성, 규정 준수 요구 사항 및 서비스 가용성에 따라 기본 Azure 지역을 선택합니다.
주소 공간 계획: 온-프레미스 네트워크 또는 피어하려는 다른 VNet과 겹치지 않는 IP 주소 범위(CIDR 블록)를 결정합니다. 지침은 IP 주소 계획을 참조하세요.

보안 고려 사항

가상 네트워크 및 서브넷은 네트워크 분할의 첫 번째 계층입니다. 다음 보안 사례를 적용합니다.

NSG(네트워크 보안 그룹) : NSG를 모든 서브넷과 연결하여 인바운드 및 아웃바운드 트래픽을 필터링합니다. 각 서브넷의 역할에 특정한 허용 규칙을 정의하고 기본적으로 다른 모든 것을 거부합니다. 자세한 지침은 네트워크 보안 그룹 및 애플리케이션 보안 그룹을 참조하세요.
UDR을 사용한 강제 터널링: 규정 준수 요구 사항에서 모든 인터넷 바인딩 트래픽이 온-프레미스 검사 디바이스 또는 클라우드 방화벽을 통과하도록 요구하는 경우 사용자 정의 경로가 있는 경로 테이블을 사용하여 기본 인터넷 라우팅을 재정의합니다. 아웃바운드 및 이그레스 연결을 참조하세요.
서브넷 격리: 서로 다른 신뢰 수준을 가진 리소스를 별도의 서브넷에 배치합니다. 예를 들어 애플리케이션 계층 서브넷의 인바운드 트래픽만 허용하는 서브넷에 데이터베이스를 유지합니다. 이 분리는 공격자가 하나의 구성 요소를 손상시키는 경우 횡적 이동을 제한합니다.
플랫폼 서비스를 위한 전용 서브넷: 많은 Azure 플랫폼 서비스(Azure Firewall, Application Gateway, Bastion)가 전용 서브넷에 배포됩니다. 이렇게 격리하면 플랫폼 서비스 라우팅 및 보안 규칙이 워크로드 서브넷을 방해하지 않습니다.

NSG 및 서브넷 상호 작용

NSG를 서브넷과 연결하면 NSG 규칙이 해당 서브넷의 모든 리소스에 적용됩니다. 다음 상호 작용 동작을 이해합니다.

누적 평가: VM의 NIC에도 NSG가 있는 경우 Azure 서브넷 수준 NSG와 NIC 수준 NSG를 모두 평가합니다. 인바운드 트래픽의 경우 Azure 먼저 서브넷 NSG를 평가한 다음, NIC NSG를 평가합니다. 아웃바운드 트래픽의 경우 Azure 먼저 NIC NSG를 평가한 다음 서브넷 NSG를 평가합니다.
기본 거부: Azure VNet 내 트래픽 및 아웃바운드 인터넷 액세스를 허용하는 기본 규칙을 포함합니다. 사용자 지정 거부 규칙을 추가한 후 합법적인 트래픽(예: IP 주소 168.63.129.16의 Azure Load Balancer 상태 프로브)이 실수로 차단되지 않았는지 확인합니다.
서비스 태그 및 ASG: 원시 IP 주소 대신 NSG 규칙에서 서비스 태그(예 AzureLoadBalancer: , Internet) VirtualNetwork및 ASG(애플리케이션 보안 그룹)를 사용합니다. 이 방법은 규칙 관리를 간소화하고 Azure IP 범위가 변경됨에 따라 자동으로 조정됩니다.
가시성을 위한 흐름 로그: 모든 서브넷 수준 NSG에서 NSG 흐름 로그를 사용하도록 설정하여 허용된 트래픽과 거부된 트래픽을 캡처합니다. 흐름 로그를 사용하면 보안 규칙이 의도한 대로 작동하는지 확인하고 규정 준수 감사에 대한 증거를 제공할 수 있습니다. 설정 지침 은 NSG 흐름 로그 를 참조하세요.

Azure 네트워킹 디자인 가이드의 다음 문서에서는 관련 항목을 다룹니다.

IP 주소 계획: 주소 공간을 디자인하고, 겹치지 않도록 하고, 성장을 계획합니다.
네트워크 보안 그룹 및 애플리케이션 보안 그룹: 서브넷 및 NIC 수준에서 트래픽 필터링 규칙을 정의합니다.
단일 워크로드 토폴로지: 공유 서비스가 없는 하나의 워크로드에 대한 간단한 네트워크를 디자인합니다.
허브 및 스포크 토폴로지: 공유 서비스 허브를 통해 여러 워크로드 VNet을 연결합니다.
Virtual WAN 토폴로지: 자동화된 허브 라우팅을 사용하여 대규모 연결을 관리합니다.
지역 간 연결: 전역 피어링 또는 Virtual WAN 사용하여 Azure 지역에 걸쳐 VNet을 연결합니다.
중앙 집중식 네트워크 관리: Azure Virtual Network Manager 사용하여 구독 전체에서 VNet 구성을 관리합니다.

자세히 알아보기

Azure 가상 네트워킹에 대한 자세한 내용은 다음 리소스를 참조하세요.

다음 단계

팁 (조언)

직접 탐색하시겠습니까? 개요 탐색기로 돌아가서 기능별로 다음 문서를 찾습니다.

리프트 앤 시프트 과정의 다음 단계:

IP 주소 공간 계획: 온-프레미스 주소 범위와 겹치지 않도록 /16 CIDR 풀을 할당합니다.

현대화 과정의 다음 단계:

IP 주소 공간 계획: 활성-활성 피어링을 위해 겹치지 않는 범위가 있는 이중 지역 IP 풀을 할당합니다.

멀티클라우드 여정의 다음 단계:

IP 주소 공간 계획: Azure, AWS(Amazon Web Services) 및 Google Cloud에서 겹치지 않는 주소 지정을 디자인합니다.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-07-01