본문으로 건너뛰기
azure검색
컴퓨트

Azure Functions (Flex Consumption 과 호스팅 플랜)

2026-10 기준 Azure Functions 의 기본 서버리스 플랜인 Flex Consumption 의 인스턴스 크기, 확장 한도, Always ready, VNet 통합, 과금 방식과 제약을 정리하고, 2028-09-30 퇴역이 정해진 Linux Consumption 에서 옮기는 방법, 트리거 설계 요령을 다룹니다.

Azure FunctionsFlex Consumption서버리스Durable Functions콜드 스타트2026-10 기준, 약 6분상태 표시 설명

호스팅 플랜 한눈에

플랜상태 (2026-10)0 까지 축소VNet 통합OS
Flex ConsumptionGA (2024-11), 새 서버리스 앱 권장OOLinux
Consumption (기존)레거시. Linux 는 2028-09-30 RetiringOXWindows, Linux
Premium (Elastic Premium)GA최소 1대 상시OWindows, Linux
Dedicated (App Service 플랜)GAXOWindows, Linux
Container AppsGAOOLinux 컨테이너

Microsoft 문서는 Consumption 플랜 페이지에 "legacy" 를 붙였고, 새 서버리스 함수 앱은 Flex Consumption 을 권장합니다. Linux Consumption 은 2028-09-30 에 퇴역하며, 그때까지 새 기능과 새 언어 버전이 들어가지 않습니다. Windows Consumption 은 2026-10 기준 퇴역 대상이 아니지만, Flex Consumption 이 Linux 전용이라 옮기려면 Linux 로 바꿔야 합니다.

경고 Linux Consumption 에서 수명이 끝난 v3 런타임으로 도는 앱은 2026-09-30 이후 실행이 멈춥니다. 아직 남아 있다면 v4 로 올리는 것이 먼저입니다.

Flex Consumption 의 핵심

항목값
인스턴스 메모리512 MB(0.25 코어), 2,048 MB(1 코어, 기본 권장), 4,096 MB(2 코어)
최대 인스턴스앱당 1,000 (기존 Consumption 은 200)
리전 할당량구독, 리전당 기본 250 코어(512,000 MB), 모든 Flex 앱이 나눠 씀
Always ready미리 켜 둔 인스턴스. 기본 0, 콜드 스타트 감소
확장 단위함수별 확장. HTTP, Blob(Event Grid), Durable 은 그룹으로 묶여 확장
배포앱 패키지(zip)를 Blob 컨테이너에 올림
플랜당 앱1개
az functionapp create -g rg-shop-prod -n func-shop-orders \
  --storage-account stfuncshopprod --flexconsumption-location koreacentral \
  --runtime python --runtime-version 3.12 --instance-memory 2048

# 콜드 스타트가 문제면 HTTP 그룹에 상시 인스턴스 1대
az functionapp scale config always-ready set -g rg-shop-prod -n func-shop-orders --settings http=1

Flex Consumption 이 쓰려는 리전에 있는지는 az functionapp list-flexconsumption-locations 로 확인합니다. 모든 리전에 있지는 않습니다.

과금

  • On demand: 실행 중 메모리 GB-초와 실행 횟수에 과금하고, 매달 무료 제공량이 있습니다.
  • Always ready: 상시 인스턴스의 기본 메모리 요금 + 실행 GB-초 + 실행 횟수. 무료 제공량이 없습니다.
  • 한 번 실행의 최소 과금은 1,000 ms 이고, 그 뒤로 100 ms 단위로 올림합니다. 아주 짧은 함수를 아주 많이 부르면 이 최소 과금이 비용을 좌우합니다.

단가와 무료 제공량은 Functions 가격표에서 확인합니다.

제약

  • 배포 슬롯이 없습니다. 무중단 배포는 롤링 업데이트(2026-10 기준 Preview)를 씁니다.
  • 기존 플랜에서 Flex 로 제자리 변경이 안 됩니다. 새 앱을 만들고 다시 배포합니다.
  • Blob 트리거는 Event Grid 방식만 됩니다. 예전 폴링 방식 Blob 트리거는 바꿔야 합니다.
  • C# 은 격리 작업자(isolated worker) 모델만 됩니다. in-process 모델 앱은 먼저 옮겨야 합니다.
  • WEBSITE_TIME_ZONE 이 지원되지 않아 타이머 트리거의 CRON 은 UTC 기준으로 씁니다. 한국 시간 오전 9시는 0 0 0 * * * 입니다.
  • 앱 시작 제한 시간은 30초입니다. 무거운 초기화는 지연 로딩으로 바꿉니다.

Consumption 에서 옮기기

  1. 런타임을 v4 로, C# 은 격리 작업자 모델로 먼저 올립니다.
  2. 앱 설정을 내보내고, Flex 에서 지원하지 않는 설정(WEBSITE_TIME_ZONE, 일부 스케일 설정)을 정리합니다.
  3. Flex 앱을 새로 만들고 관리 ID, 역할, 네트워크를 다시 설정합니다. 관리 ID 의 principal ID 가 바뀌므로 역할 할당도 새로 해야 합니다.
  4. 트래픽을 옮기고(커스텀 도메인, Front Door 원본 변경) 기존 앱을 정리합니다.

Microsoft Learn 의 "Migrate Consumption plan apps to the Flex Consumption plan" 가이드와 Azure CLI 의 마이그레이션 보조 명령을 같이 봅니다.

트리거와 바인딩 설계

트리거확장 기준주의
HTTP동시 요청 수230초 응답 제한이 있는 앞단(부하 분산기)을 고려해 긴 작업은 큐로 넘김
Queue, Service Bus메시지 수독성 메시지 큐 확인, 멱등 처리
Event Hubs파티션 수와 지연인스턴스 수는 파티션 수를 넘어 늘어도 효과 없음
Timer단일 실행여러 인스턴스에서 중복 실행되지 않음. UTC 기준
Blob (Event Grid)이벤트 수스토리지 계정에 이벤트 구독 필요

연결 문자열 대신 ID 기반 연결(AzureWebJobsStorage__accountName 처럼 __ 로 끝나는 설정)을 쓰면 비밀 없이 관리 ID 로 스토리지, Service Bus, Event Hubs 에 붙습니다.

Durable Functions

여러 단계의 워크플로, 팬아웃 팬인, 사람 승인 대기 같은 상태 있는 흐름은 Durable Functions 로 만듭니다. Flex Consumption 에서는 저장소 공급자로 Azure Storage 와 Durable Task Scheduler 만 지원합니다. 처리량이 많으면 Durable Task Scheduler 가 관리 부담이 적습니다.

공식 문서

이 문서에서