컴퓨트

App Service (웹 앱과 API 호스팅)

App Service 플랜과 가격 계층(Basic, Standard, Premium v3, Premium v4, Isolated v2), 배포 슬롯과 무중단 배포, VNet 통합과 Private Endpoint, 관리 ID 와 Key Vault 참조, 크기 조정, 흔한 장애 원인을 정리합니다.

App Service배포 슬롯VNet 통합Premium v4웹 앱2026-10 기준, 약 6분상태 표시 설명

구조: 플랜과 앱

App Service 는 웹 앱, REST API, 모바일 백엔드를 OS 관리 없이 올리는 PaaS 입니다. 핵심은 두 리소스입니다.

App Service 플랜: 실제 VM 묶음입니다. 가격 계층, 인스턴스 크기, 인스턴스 수, OS(Windows 또는 Linux), 리전을 정합니다. 요금은 플랜에 붙습니다.
앱(Web App): 플랜 위에서 도는 사이트입니다. 한 플랜에 여러 앱을 올리면 같은 인스턴스를 나눠 씁니다.

그래서 앱을 지워도 플랜이 남아 있으면 요금이 계속 나옵니다. 반대로 작은 앱 여러 개는 한 플랜에 모으면 싸지만, 하나가 CPU 를 다 쓰면 나머지도 느려집니다.

가격 계층 고르기

계층	주 용도	배포 슬롯	자동 크기 조정	비고
Free, Shared	시험용	없음	없음	공유 인프라, 운영 불가
Basic (B)	개발, 트래픽 적은 앱	없음	수동만	전용 인스턴스
Standard (S)	작은 운영	5개	있음
Premium v3 (P0v3~P5mv3)	일반 운영	20개	있음, 자동 확장(elastic)	메모리 최적화 크기
Premium v4	일반 운영 (새 세대)	20개	있음	2025년 GA, 새 하드웨어
Isolated v2 (I)	전용 환경, 규제	20개	있음	App Service Environment v3 안에서

새 운영 앱은 Premium v3 나 Premium v4 를 기준으로 봅니다. Premium v4 가 쓰려는 리전(예: Korea Central)과 OS 에서 제공되는지는 가격표와 포털에서 확인합니다. 슬롯 수와 크기 이름은 바뀔 수 있으니 가격표가 기준입니다.

배포와 슬롯

# Linux Python 앱 만들고 zip 배포
az appservice plan create -g rg-shop-prod -n asp-shop-prod --is-linux --sku P1v3 --zone-redundant
az webapp create -g rg-shop-prod -p asp-shop-prod -n app-shop-prod --runtime "PYTHON:3.12"
az webapp deploy -g rg-shop-prod -n app-shop-prod --src-path app.zip --type zip

배포 슬롯은 같은 플랜 위의 별도 앱(예: staging)입니다. 슬롯에 먼저 배포하고 워밍업을 확인한 뒤 스왑하면 무중단으로 바뀝니다. 문제가 생기면 다시 스왑해서 되돌립니다.

슬롯에 고정할 설정(연결 문자열, 기능 플래그)은 "배포 슬롯 설정" 으로 표시해야 스왑 때 따라가지 않습니다.
스왑 전에 applicationInitialization 경로나 상태 검사(Health check) 경로를 설정하면 차가운 인스턴스로 트래픽이 가는 일을 줄입니다.

네트워크

방향	기능	설명
들어오는 트래픽	액세스 제한	IP, 서비스 태그, VNet 서브넷 기준 허용 목록
들어오는 트래픽	Private Endpoint	앱을 사설 IP 로만 노출. 공용 접근 끄기 가능
나가는 트래픽	VNet 통합	앱이 VNet 안의 DB, Private Endpoint 에 접근. 위임된 전용 서브넷 필요

VNet 통합 서브넷은 Microsoft.Web/serverFarms 에 위임되고, 플랜 하나가 서브넷 하나를 씁니다. 인스턴스가 늘면 IP 를 더 쓰므로 /26 이상을 권장합니다. 앱에서 Private Endpoint 이름이 공인 IP 로 풀리면 VNet 의 DNS 설정을 봅니다 (Private Endpoint DNS 실패).

설정과 비밀

앱 설정은 환경 변수로 들어갑니다. 비밀은 앱 설정에 직접 두지 말고 Key Vault 참조를 씁니다.

DB_PASSWORD=@Microsoft.KeyVault(SecretUri=https://kv-shop-prod.vault.azure.net/secrets/db-password/)

Key Vault 참조가 동작하려면 앱의 관리 ID 에 Key Vault Secrets User 역할이 있어야 하고, Key Vault 가 방화벽 뒤라면 VNet 통합 경로로 닿아야 합니다.
DB 연결은 가능하면 비밀번호 대신 관리 ID 로 Entra 인증을 씁니다 (Azure SQL, PostgreSQL flexible server 지원).

크기 조정과 가용성

스케일 업: 더 큰 인스턴스로. 잠깐 재시작이 생깁니다.
스케일 아웃: 인스턴스 수 늘리기. 자동 크기 조정 규칙이나 Premium 계층의 자동 확장을 씁니다.
영역 중복: Premium v3 이상 플랜에서 영역 중복을 켜면 인스턴스가 영역에 나뉩니다. 인스턴스 최소 수 조건이 있으니 문서를 확인합니다.
ARR 선호도(세션 고정)는 기본으로 켜져 있습니다. 상태 없는 앱이면 꺼야 부하가 고르게 나뉩니다.

자주 만나는 문제

증상	흔한 원인	확인
배포 뒤 첫 요청이 매우 느림	콜드 스타트, Always On 꺼짐	Always On 켜기 (Basic 이상)
502, 503 간헐 발생	인스턴스 재시작, 메모리 부족, SNAT 포트 고갈	진단 및 문제 해결 블레이드, 아웃바운드 연결 재사용
컨테이너 앱이 안 뜸	포트 불일치	`WEBSITES_PORT` 설정, 컨테이너 로그
Key Vault 참조가 빨간색	관리 ID 권한, 네트워크	앱 설정 화면의 참조 상태 표시

SNAT 포트 고갈은 외부 API 를 매 요청마다 새 연결로 부를 때 흔합니다. HTTP 클라이언트를 재사용하고, 대량 아웃바운드라면 VNet 통합과 NAT Gateway 를 붙입니다.

Functions, Container Apps 와 비교

HTTP 앱을 "항상 켜진 웹 서버" 로 돌리면 App Service, 이벤트에 따라 0 까지 줄이고 싶으면 Azure Functions, 컨테이너와 마이크로서비스, 백그라운드 작업이 섞이면 Container Apps가 맞습니다.