티스토리 뷰
어떤 플랜을 선택해야 할까 — Consumption / Flex / Premium / Dedicated
Azure Functions 101 시리즈 (5/7)
4화에서는 함수를 classic Consumption 플랜에 올렸습니다. 그 경로는 데모와 학습에는 여전히 가장 단순합니다. 다만 현재 Microsoft Learn 기준으로 classic Consumption은 레거시 플랜이고, 새 서버리스 앱의 기본 선택지는 Flex Consumption입니다.
그래도 Consumption을 빼고 설명하면 실제 선택을 이해하기 어렵습니다. 이번 글에서는 Consumption / Flex Consumption / Premium / Dedicated(App Service Plan) 네 가지를 모두 다루되, 각 플랜의 현재 위치와 제약을 그대로 적겠습니다.
목표는 단순합니다. 각 플랜이 무엇을 주고 무엇을 포기하게 만드는지, 그리고 내 워크로드에 어떤 플랜이 맞는지를 한 번에 판단할 수 있게 만드는 것입니다.
한 줄 정의 — 네 가지 플랜
| 플랜 | 한 줄 정의 |
|---|---|
| Consumption | 가장 단순한 종량제 서버리스. 현재는 레거시 플랜이고, Windows 중심으로 생각하는 편이 맞습니다. |
| Flex Consumption | Microsoft가 새 서버리스 앱의 기본 선택지로 권장하는 Linux 기반 종량제 플랜. VNet, 메모리 선택, per-function scaling을 제공합니다. |
| Premium | Always Ready / Pre-warmed 인스턴스로 콜드 스타트를 줄이거나 피하는 고급 플랜. VNet과 더 큰 SKU를 쓸 수 있습니다. |
| Dedicated (App Service Plan) | Functions를 일반 App Service 인프라 위에서 돌리는 모델. 이벤트 기반 자동 스케일 대신 App Service 규칙을 직접 관리합니다. |
Azure Functions를 “자동으로 늘어나는 서버리스”라고만 기억하고 있었다면, 여기서 한 번 수정해야 합니다. 자동 스케일의 방식과 운영 모델이 플랜마다 꽤 다릅니다.
큰 그림 — 무엇이 다른가

이제 비교표로 세부 차이를 정리합니다.
비교표 — 한 화면에 정리
| 항목 | Consumption | Flex Consumption | Premium | Dedicated |
|---|---|---|---|---|
| 현재 위치 | 레거시 | 새 서버리스 기본 선택지 | 고급 서버리스 | 일반 App Service 계열 |
| 과금 모델 | 실행 기준 종량제 | 실행 기준 종량제 + Always Ready가 있으면 그 용량도 과금 | 인스턴스 시간 + 실행 용량 | App Service Plan SKU 기준 |
| 트래픽 0일 때 비용 | 0 | Always Ready가 0이면 0 | 최소 인스턴스 비용 발생 | 항상 발생 |
| 콜드 스타트 | 있음 | 줄일 수 있음 (Always Ready 선택) | 대체로 회피 가능 | 상시 실행이면 사실상 없음 |
| OS | Windows 중심 레거시, Linux Consumption은 retired/retiring | Linux only | Windows / Linux | Windows / Linux |
| VNet 통합 | 없음 | 있음 | 있음 | 있음 |
| 최대 인스턴스 수 | 대략 200, OS와 제한 조건에 따라 더 낮을 수 있음 | 최대 1000, 지역별 250코어 기본 쿼터 영향 | 대략 20~100+, OS·지역·제한 조건에 따라 달라짐 | App Service Plan SKU와 autoscale 설정에 따름 |
| 이벤트 기반 자동 스케일 | 지원 (이벤트별 리스너 기반) | 지원 (per-function, target-based) | 지원 (target-based 옵션) | 직접 메트릭 룰 구성 |
| Per-function scaling | 없음 | 있음 | 없음 | 없음 |
| 인스턴스 메모리 | 1.5 GB 고정 | 512 / 2048 / 4096 MB 선택 | SKU별로 다름 | App Service Plan SKU에 따름 |
| 배포 슬롯 | 제한적 | 없음, rolling update 경로 사용 | 있음 | 있음 |
| Warmup 트리거 | 없음 | 있음 | 있음 | 있음 |
출처: Microsoft Learn의 Function scale and hosting options, Flex Consumption plan, Event-driven scaling, Target-based scaling. 인스턴스 상한은 플랜, OS, 지역, 네트워크 제한 조건에 따라 달라질 수 있습니다.
이 표를 볼 때 가장 먼저 확인할 값은 세 가지입니다. OS, VNet, 스케일 방식입니다. 비용보다 먼저 이 세 조건에서 후보가 갈리는 경우가 많습니다.
Consumption — 가장 단순하지만 이제는 레거시
Consumption은 여전히 설명하기 쉬운 플랜입니다. 호출이 없으면 비용이 0이고, 준비 과정도 단순합니다. 다만 새 프로젝트의 기본 선택지로 보기는 어렵습니다.
선택 기준
- 가장 단순한 데모, 실험, PoC가 필요함
- Windows 기반 제약이 있음
- VNet 통합이 필요 없음
- 첫 호출 지연을 어느 정도 감수할 수 있음
약점
- 콜드 스타트
- VNet 통합 없음
- 1.5 GB 고정 메모리
- 레거시 플랜이라는 점 자체가 장기 운영 리스크
- Linux Consumption은 이미 retired 또는 retiring 단계라 새 기준점으로 잡기 어려움
그래서 4화에서는 Consumption으로 배포했지만, 그건 가장 짧은 시연 경로였기 때문입니다. 새 서버리스 서비스를 처음 설계한다면 Consumption을 출발점으로 둘 이유는 예전보다 많이 줄었습니다.
Flex Consumption — 새 서버리스 앱의 기본 후보
Flex Consumption은 Microsoft가 공식적으로 권장하는 새 서버리스 호스팅 플랜입니다. Consumption의 장점을 유지하면서도, 실무에서 자주 걸리던 제약을 여러 개 풀어 줍니다.
핵심 차별점
- VNet 통합 — private endpoint 뒤 리소스 접근이 가능합니다.
- 인스턴스 메모리 선택 — 512 MB, 2048 MB, 4096 MB 중에서 고를 수 있습니다.
- Always Ready — 특정 함수 그룹에 미리 떠 있는 인스턴스를 둘 수 있습니다. 기본값은 0입니다.
- Per-function scaling — 함수별 또는 함수 그룹별로 스케일이 갈립니다.
- 큰 스케일 범위 — 앱 기준 최대 1000 인스턴스까지 확장할 수 있지만, 지역별 코어 쿼터가 실제 상한을 먼저 만들 수 있습니다.
중요한 제약
- Linux 전용입니다.
- Blob trigger는 Event Grid 소스만 지원합니다. 예전 Consumption에서 익숙하던 polling 기반 blob trigger와 같은 전제로 보면 안 됩니다.
- 일부 바인딩과 기능이 Flex 전용 제약을 가집니다. 배포 슬롯 미지원, 플랜 간 in-place 마이그레이션 불가 같은 차이도 있습니다.
- Per-function scale group으로 동작합니다. 즉, 모든 함수가 완전히 독립 인스턴스로 스케일하는 것은 아닙니다. HTTP끼리, Blob(Event Grid)끼리, Durable끼리 묶이는 그룹이 있습니다.
선택 기준
- 새 서버리스 프로젝트를 시작함
- VNet 안의 리소스를 호출해야 함
- Consumption보다 나은 스케일 유연성과 메모리 선택권이 필요함
- Linux 채택이 가능함
새 프로젝트라면 가장 먼저 검토할 후보가 맞습니다. 다만 “Consumption의 약점을 거의 다 고쳤다” 정도로 이해하는 선이 안전하지, 모든 제약이 사라졌다고 보면 설계 단계에서 다시 막힐 수 있습니다.
Premium — 콜드 스타트와 Windows 요구사항까지 같이 풀 때
Premium은 항상 준비된 용량을 두는 방식으로 접근합니다. 호출이 없어도 비용은 들지만, 그만큼 콜드 스타트를 더 강하게 제어할 수 있습니다.
선택 기준
- 첫 호출 지연이 비즈니스적으로 허용되지 않음
- Windows를 유지해야 하는데 VNet도 필요함
- 더 큰 CPU/메모리 SKU가 필요함
- 여러 Function App을 같은 Premium 플랜에 묶어 운영하고 싶음
약점
- 최소 인스턴스 비용이 항상 발생
- Linux 새 프로젝트에서는 Flex Consumption과 비교 검토가 거의 필수
- 상한 인스턴스 수가 지역, OS, 네트워크 조건에 따라 달라져서 “무조건 100”처럼 외우면 틀리기 쉬움
Premium은 “서버리스 과금”보다 “서버리스 운영 모델 + 더 강한 성능 보장” 쪽에 가깝습니다.
Dedicated — Functions를 App Service 방식으로 운영할 때
Dedicated(App Service Plan)는 이름보다 본질을 보는 편이 쉽습니다. Functions를 일반 App Service Plan 위에서 돌리는 모델입니다. 다른 웹 앱과 같은 플랜에 올릴 수 있고, 비용도 App Service 기준으로 계산됩니다.
선택 기준
- 이미 App Service Plan이 있고 여유 용량이 있음
- Functions를 다른 웹 앱과 같은 인프라에서 운영하고 싶음
- 비용을 완전히 고정적으로 보고 싶음
- 이벤트 기반 자동 스케일이 꼭 필요하지 않음
가장 중요한 특징
- Consumption/Flex/Premium 같은 이벤트 기반 자동 스케일은 없습니다. App Service autoscale 규칙을 메트릭 기반으로 직접 설계해야 합니다.
이 점을 모르고 Dedicated를 고르면 “Functions인데 왜 큐 길이에 따라 자동으로 안 늘지?” 같은 상황을 맞기 쉽습니다. Dedicated는 Functions의 프로그래밍 모델을 쓰되, 운영 모델은 App Service에 더 가깝습니다.
의사결정 트리

이 트리에서 Dedicated가 기본 경로 바깥에 있는 이유가 중요합니다. Dedicated는 나쁜 플랜이 아니라, Functions 고유의 이벤트 기반 스케일을 일부 포기해도 되는 경우에만 맞는 플랜입니다.
새 프로젝트 시작 시 추천
세 줄로 요약하면 이렇습니다.
- 새 서버리스 프로젝트라면 Flex Consumption을 먼저 봅니다. 현재 공식 권장 경로입니다.
- Windows 제약이나 강한 콜드 스타트 제어가 필요하면 Premium을 봅니다.
- Consumption은 가장 단순한 데모 경로이거나 기존 자산을 유지할 때만 제한적으로 선택합니다.
여기에 단서가 하나 더 있습니다. Flex Consumption은 분명 강력하지만, Blob trigger는 Event Grid 기반만 지원하고, 일부 바인딩과 기능에 Flex 전용 제약이 있으며, 스케일도 per-function scale group 단위로 이해해야 합니다. 그래서 “무조건 Flex”가 아니라 “기본 후보는 Flex, 설계 제약은 반드시 확인”이 더 정확한 표현입니다.
다음 화에서
플랜을 골랐다면 다음 질문은 자연스럽게 이어집니다. 실제로 어떤 기준으로 인스턴스가 늘고 줄어드는가, 그리고 첫 호출은 왜 느린가입니다. 6화에서는 이벤트 기반 스케일, target-based scaling, 콜드 스타트를 한 장으로 묶어 설명합니다.
시리즈 맥락
이 글은 Azure Functions 101의 5화입니다. 4화에서 실제 배포를 한 번 끝까지 해 봤다면, 이번 글은 그 배포 대상을 어떤 호스팅 플랜에 둘지 결정하는 기준을 정리하는 자리입니다. 다음 글에서는 여기서 고른 플랜이 실제로 어떻게 스케일하고 왜 콜드 스타트 차이를 만드는지 이어서 다룹니다.
시리즈 목차
- Azure Functions란? — 이벤트가 함수를 호출하는 세상
- 트리거와 바인딩 — 함수 입출력의 모든 것
- Host와 Worker — 함수는 누가 실행하는가
- 함수 하나 배포하기 — 로컬에서 Azure까지
- 어떤 플랜을 선택해야 할까 — Consumption / Flex / Premium / Dedicated (현재 글)
- 스케일링과 콜드 스타트 — 서버리스가 빨라지는 순간과 느려지는 순간 (예정)
- 모니터링과 운영 기초 (예정)
참고 자료
공식 문서
'Azure' 카테고리의 다른 글
| 모니터링과 운영 기초 (0) | 2026.04.27 |
|---|---|
| 스케일링과 콜드 스타트 — 서버리스가 빨라지는 순간과 느려지는 순간 (0) | 2026.04.27 |
| 함수 하나 배포하기 — 로컬에서 Azure까지 (0) | 2026.04.27 |
| Host와 Worker — 함수는 누가 실행하는가 (0) | 2026.04.27 |
| 트리거와 바인딩 — 함수 입출력의 모든 것 (0) | 2026.04.27 |
- Total
- Today
- Yesterday
- ALTAIR
- scaling
- aks
- rag
- embeddings
- vector search
- appserviceplan
- CloudArchitecture
- 공공데이터
- app service
- Kubernetes
- Tutorial
- pandas
- DevOps
- Azure Functions
- faiss
- cloudcomputing
- openAI
- Document Processing
- serverless
- 데이터시각화
- Cloud
- AZURE
- langchain
- Prompt engineering
- AppService
- LLM
- Python
- streaming
- Ai
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| 31 |
