Azure VM 크기 선택 화면을 열면 수백 개가 나옵니다. 대부분은 D 시리즈 중에서 대충 골라 시작하고, 나중에 비용이나 성능 문제가 생기면 그때 고민합니다. 문제는 그 시점에는 이미 데이터와 설정이 얹혀 있어 바꾸기가 번거롭다는 것입니다.
이 글은 시리즈별 스펙 나열이 아니라, 같은 vCPU 수에서 시리즈를 바꿨을 때 월 비용이 얼마나 달라지는지를 계산하고, 워크로드 특성에서 시리즈를 역산하는 방법을 정리합니다.
시리즈 이름 읽는 법부터
Standard_D4as_v5 같은 이름은 규칙이 있습니다. 이걸 알면 목록에서 원하는 것만 걸러낼 수 있습니다.
Standard_D 4 a s _v5
│ │ │ │ └─ 세대 (v5, v6 - 높을수록 신형·가성비 좋음)
│ │ │ └───── s = Premium SSD 지원 (거의 필수)
│ │ └─────── a = AMD CPU / 없으면 Intel
│ └───────── vCPU 수
└─────────── 시리즈 (B/D/E/F/L/N)실무에서 바로 쓸 수 있는 판단 두 가지가 여기서 나옵니다.
s가 없는 크기는 피하세요. Premium SSD를 못 붙입니다. 나중에 디스크 성능이 필요해지면 VM을 다시 만들어야 합니다.a(AMD)는 대체로 저렴합니다. 같은 vCPU에서 Intel 대비 단가가 낮은 편이라, 특정 명령어 집합에 의존하지 않는 일반 워크로드라면 먼저 검토할 가치가 있습니다.
시리즈별 성격과 vCPU당 메모리
시리즈를 가르는 핵심 축은 vCPU당 메모리 비율입니다. 이 비율만 알면 선택이 단순해집니다.
| 시리즈 | vCPU당 메모리 | 성격 | 대표 용도 |
|---|---|---|---|
| B (Burstable) | 2~4 GB | CPU 크레딧 누적 방식 | 개발·테스트, 저부하 웹 |
| F (Compute) | 2 GB | CPU 집약 | 배치 처리, 게임 서버, 인코딩 |
| D (General) | 4 GB | 균형 | 웹 서버, API, 소규모 DB |
| E (Memory) | 8 GB | 메모리 집약 | DB, 캐시, 인메모리 분석 |
| L (Storage) | 8 GB + NVMe | 로컬 디스크 성능 | NoSQL, 데이터 웨어하우스 |
| N (GPU) | 다양 | GPU 탑재 | ML 학습·추론, 렌더링 |
선택 방법은 이렇습니다. 필요한 메모리를 먼저 정하고, 필요한 vCPU로 나눠서 나오는 비율에 맞는 시리즈를 고릅니다. “16GB가 필요하고 CPU는 4개면 충분하다” → 비율 4 → D 시리즈. “64GB가 필요한데 CPU는 8개” → 비율 8 → E 시리즈.
이 계산을 안 하면 메모리를 맞추려고 CPU를 과하게 사는 일이 벌어집니다. D 시리즈로 64GB를 맞추려면 D16s(16 vCPU)가 필요한데, E8s(8 vCPU)로도 64GB가 나옵니다. CPU 8개 값을 그냥 버리는 셈입니다.
숫자로 확인: 64GB가 필요할 때 시리즈별 비용
앞의 이야기를 실제 금액으로 확인해보겠습니다. 메모리 64GB가 필요한 워크로드를 가정하고, 시리즈별로 그 메모리를 맞췄을 때 얼마인지 계산합니다.
가정: Linux, 종량제, 월 730시간, 환율 1,400원. 단가는 미국 동부 기준 근사치입니다.
| 선택 | vCPU | 메모리 | 시간당 | 월 비용 | 낭비 |
|---|---|---|---|---|---|
| D16s_v5 | 16 | 64GB | $0.768 | 약 785,000원 | vCPU 8개 과잉 |
| E8s_v5 | 8 | 64GB | $0.504 | 약 515,000원 | — |
| E8as_v5 (AMD) | 8 | 64GB | $0.454 | 약 464,000원 | — |
같은 64GB를 확보하는데 월 785,000원과 464,000원의 차이가 납니다. 연간으로는 약 385만원입니다. 시리즈를 잘못 고른 것만으로 발생하는 금액입니다.
반대 방향의 실수도 있습니다. CPU가 필요한데 D를 쓰는 경우입니다.
| 선택 | vCPU | 메모리 | 월 비용 | 비고 |
|---|---|---|---|---|
| D16s_v5 | 16 | 64GB | 약 785,000원 | 메모리 48GB가 놀고 있음 |
| F16s_v2 | 16 | 32GB | 약 690,000원 | 배치 처리엔 이걸로 충분 |
배치 처리처럼 CPU만 쓰는 작업이라면 F 시리즈가 맞습니다. 다만 차액이 위 사례만큼 크지는 않아서, 메모리 과잉(D 대신 E를 써야 할 상황)이 CPU 과잉보다 손해가 큽니다.
B 시리즈의 크레딧 함정
B 시리즈는 가장 싸서 개발 환경에 많이 씁니다. 그런데 동작 방식이 다른 시리즈와 근본적으로 다릅니다.
B 시리즈는 기준 성능(baseline)이 정해져 있고, 그보다 적게 쓰면 크레딧이 쌓입니다. 순간적으로 CPU를 많이 써야 할 때 쌓인 크레딧을 소모해서 최대 100%까지 올라갑니다. 문제는 크레딧이 바닥나면 기준 성능으로 강제로 떨어진다는 점입니다.
예를 들어 B2s의 기준 성능은 vCPU당 20% 수준입니다. 크레딧이 소진되면 2 vCPU짜리 VM이 사실상 0.4 vCPU처럼 동작합니다. “어제까지 잘 되던 서버가 갑자기 느려졌다”는 상황의 흔한 원인입니다.
# B 시리즈 크레딧 잔량 확인 (소진되고 있는지)
az monitor metrics list \
--resource "/subscriptions/<SUB>/resourceGroups/<RG>/providers/Microsoft.Compute/virtualMachines/<VM>" \
--metric "CPU Credits Remaining" "CPU Credits Consumed" \
--interval PT1H \
--start-time 2026-07-24T00:00:00Z \
-o tableCPU Credits Remaining이 0에 가까운 상태로 유지된다면 그 워크로드에 B 시리즈는 맞지 않습니다. D 시리즈로 옮기세요. 반대로 크레딧이 항상 최대치라면 오히려 더 작은 B 크기로 낮출 여지가 있습니다.
정리하면 B 시리즈는 평소에 놀다가 가끔 바쁜 워크로드용입니다. 꾸준히 부하가 있는 운영 서버에 쓰면 반드시 문제가 됩니다.
이미 돌고 있는 VM의 적정 크기 찾기
신규 선택보다 흔한 상황이 이미 만들어진 VM이 적절한지 판단하는 것입니다. 추측하지 말고 실제 사용률을 봅니다.
// Log Analytics - 지난 30일 CPU·메모리 사용률
Perf
| where TimeGenerated > ago(30d)
| where CounterName in ("% Processor Time", "% Committed Bytes In Use")
| summarize
p50 = percentile(CounterValue, 50),
p95 = percentile(CounterValue, 95),
p99 = percentile(CounterValue, 99)
by Computer, CounterName
| sort by Computer asc판단 기준은 이렇습니다.
| CPU p95 | 메모리 p95 | 조치 |
|---|---|---|
| < 20% | < 40% | 한 단계 축소 (D4s → D2s) |
| < 20% | > 70% | E 시리즈로 변경 (CPU 줄이고 메모리 유지) |
| > 70% | < 40% | F 시리즈로 변경 또는 확장 |
| > 80% | > 80% | 한 단계 확대 또는 수평 확장 |
| 20~70% | 40~70% | 적정. 유지 |
p95를 쓰는 이유는 순간 피크에 과잉 반응하지 않기 위해서입니다. p99로 보면 대부분의 VM이 “확대 필요”로 나옵니다.
Windows VM의 메모리 지표 주의
Linux와 달리 Windows는 기본 메트릭에 메모리 사용률이 없습니다. Azure Monitor Agent를 설치하고 성능 카운터를 명시적으로 수집해야 위 쿼리가 동작합니다. 이걸 모르고 “메모리 데이터가 없다”며 CPU만 보고 판단하는 경우가 있습니다.
크기 변경 시 알아둘 것
# 현재 VM이 변경 가능한 크기 목록 (같은 하드웨어 클러스터 내)
az vm list-vm-resize-options \
--name <VM> -g <RG> \
--query "[].{size:name, vcpu:numberOfCores, memoryMB:memoryInMb}" -o table
# 크기 변경 (재시작 발생)
az vm resize --name <VM> -g <RG> --size Standard_E8s_v5- 재시작이 필요합니다. 무중단이 아닙니다. 가용성 집합이나 영역이 구성돼 있어야 서비스 중단 없이 순차 변경이 가능합니다.
list-vm-resize-options에 원하는 크기가 없으면, 현재 VM이 올라간 하드웨어 클러스터가 그 크기를 지원하지 않는 것입니다. VM을 할당 해제(deallocate)한 뒤 변경하면 다른 클러스터로 배치되어 가능해지는 경우가 많습니다.- 임시 디스크(
/mnt,D:) 데이터는 사라집니다. 크기를 바꾸면 초기화됩니다. 임시 디스크에 중요한 걸 두지 않았는지 확인하세요. - 세대를 올릴 때(v4 → v5) 성능이 오르면서 단가는 비슷하거나 낮은 경우가 있습니다. 같은 크기라도 세대만 올리는 것이 이득일 수 있습니다.
VM 크기가 결정하는 것은 CPU·메모리만이 아니다
간과하기 쉬운 부분입니다. VM 크기는 디스크 성능과 네트워크 대역폭의 상한도 함께 정합니다. 이것 때문에 “비싼 디스크를 붙였는데 성능이 안 나오는” 상황이 생깁니다.
구체적으로 VM 크기마다 아래 네 가지 상한이 걸려 있습니다.
- 최대 데이터 디스크 개수 — 작은 크기는 2~4개까지만 붙습니다
- 최대 디스크 IOPS·처리량 — VM 레벨의 상한. 디스크가 아무리 빨라도 여기서 잘립니다
- 네트워크 대역폭 — vCPU 수에 비례해 커집니다
- 가속 네트워킹 지원 여부 — 지연 시간에 큰 영향
두 번째가 실무에서 자주 사고를 냅니다. P30 Premium SSD(약 5,000 IOPS)를 붙였는데 VM 상한이 3,200 IOPS라면, 비싼 디스크 값을 내면서 성능은 3,200에서 막힙니다. 디스크를 업그레이드해도 아무 변화가 없어서 원인을 못 찾고 헤매게 됩니다.
# VM 크기별 상한 확인 (디스크 개수·IOPS·처리량)
az vm list-sizes --location koreacentral \
--query "[?contains(name,'Standard_D') && numberOfCores==\`8\`].\
{size:name, cores:numberOfCores, memMB:memoryInMb, maxDisks:maxDataDiskCount}" \
-o table더 정확한 IOPS 상한은 Microsoft 문서의 시리즈별 표를 봐야 합니다. 디스크 성능이 중요한 워크로드라면 VM 크기를 CPU·메모리가 아니라 IOPS 상한 기준으로 골라야 하는 경우도 있습니다. DB 서버가 대표적입니다.
구독 할당량도 미리 확인하세요
크기를 정해도 구독의 vCPU 할당량에 걸리면 배포가 실패합니다. 신규 구독은 시리즈별 기본 할당량이 낮게 잡혀 있어, 조금만 키워도 막힙니다. 배포 직전이 아니라 미리 확인하고 필요하면 증설을 신청하세요.
# 시리즈별 vCPU 할당량과 현재 사용량
az vm list-usage --location koreacentral \
--query "[?currentValue > \`0\`].{name:localName, used:currentValue, limit:limit}" \
-o table할당량 증설은 포털의 지원 + 문제 해결 → 새 지원 요청 → 서비스 및 구독 제한(할당량)에서 신청합니다. 대개 빠르게 처리되지만, 배포 당일에 발견하면 일정이 밀립니다.
선택 순서 정리
- 필요 메모리 ÷ 필요 vCPU로 비율을 구한다 → 2면 F, 4면 D, 8이면 E
- 이름에
s가 있는지 확인한다 (Premium SSD 지원) - AMD(
a) 버전이 있으면 단가를 비교한다 - 가장 최신 세대를 고른다
- 개발·테스트는 B 시리즈, 단 크레딧 소진 여부를 모니터링한다
- 운영 시작 후 30일 뒤 p95 사용률로 재조정한다
크기를 정한 뒤에는 약정 할인을 검토할 차례입니다. 다만 순서가 중요합니다 — 크기를 줄인 다음에 약정해야 낭비를 3년간 확정하지 않습니다. 자세한 내용은 Reserved·Savings Plan·Spot 선택 기준에 정리했습니다. 비용이 이미 늘어난 상태라면 Cost Analysis로 원인 찾기를 먼저 보시는 편이 낫습니다.
※ 본문 단가는 미국 동부·Linux·종량제 기준 근사치입니다. Korea Central 실제 가격은 Azure 요금 계산기에서 확인하세요.