Azure 에서 "몇 개까지 만들 수 있나" 는 두 종류로 갈린다. 하나는 플랫폼이 정한 고정 한도로 상향이 불가능하고, 다른 하나는 구독에 걸린 할당량(quota) 으로 지원 요청을 넣어 올릴 수 있다. 설계 단계에서 이 둘을 구분하지 않으면 나중에 늘릴 수 없는 벽에 부딪힌다.
한도 값은 수시로 바뀌므로 아래 표는 설계 감각을 잡는 용도로만 보고, 실제 값은 반드시 공식 한도 문서와 구독의 사용량 조회로 확인한다.[1]
| 항목 | 기본값 | 상향 |
|---|---|---|
| 구독 · 리전당 가상 네트워크 | 1,000 | 가능 |
| VNet 당 서브넷 | 3,000 | 불가 |
| VNet 당 피어링 | 500 | 가능 |
| 구독 · 리전당 네트워크 보안 그룹 | 5,000 | 가능 |
| NSG 당 보안 규칙 | 1,000 | 가능 |
| 경로 테이블당 사용자 정의 경로 | 400 | 가능 |
| VNet 당 ExpressRoute 연결 | 회선 SKU 에 따라 다름 | 가능 |
확인 필요 — 위 숫자는 시점에 따라 달라진다. Microsoft 는 한도를 상향 조정하는 일이 잦으므로, 용량 설계에 쓸 값은 공식 한도 문서에서 다시 읽는다.
VNet 자체에는 CPU · 메모리 같은 컴퓨트 한도가 없다. VNet 에 붙일 수 있는 VM 수를 제한하는 것은 서브넷의 주소 공간과 구독의 vCPU 할당량 두 가지다.
CIDR 접두사가 /n 이면 주소 개수는 2^(32-n) 이다.
| CIDR | 주소 수 | 범위 | 실제 배정 가능 |
|---|---|---|---|
10.0.0.0/20 |
4,096 | 10.0.0.0 ~ 10.0.15.255 | 10.0.0.4 ~ 10.0.15.254 |
10.0.0.0/24 |
256 | 10.0.0.0 ~ 10.0.0.255 | 10.0.0.4 ~ 10.0.0.254 |
Azure 는 모든 서브넷에서 앞의 네 개와 마지막 한 개, 모두 다섯 개를 예약한다. 첫 주소는 네트워크 주소, 그다음 셋은 기본 게이트웨이와 DNS 매핑용, 마지막은 브로드캐스트다. 그래서 /29 가 실제로 쓸 수 있는 최소 크기이고 주소는 세 개만 남는다. 관리형 서비스를 위임(delegation) 하는 서브넷은 더 큰 크기를 요구하는 경우가 많다.
vCPU 할당량은 구독 · 리전 · VM 계열(D 시리즈, E 시리즈 …) 단위로 따로 걸린다. 전체 여유가 있어도 특정 계열에서 막히는 일이 흔하다.
az vm list-usage --location koreacentral --output table
az network list-usages --location koreacentral --output table
az quota list --scope "/subscriptions/<SUBSCRIPTION_ID>/providers/Microsoft.Compute/locations/koreacentral" --output table
포털에서는 구독 → 사용량 + 할당량 에서 같은 값을 보고 그 자리에서 상향 요청을 넣는다. 신규 구독은 리전당 vCPU 가 매우 낮게 잡혀 있어 클러스터 노드를 조금만 늘려도 배포가 실패한다. 규모가 있는 배포는 작업 전에 미리 올려 둔다.
VM 의 네트워크 성능(대역폭, NIC 수, 가속 네트워킹 지원 여부) 은 VM 크기에 묶여 있다. 큰 크기일수록 대역폭이 커지므로, 네트워크 처리량이 필요한 워크로드는 vCPU 수보다 크기 선택을 먼저 본다.