Azure Container Apps와 AKS는 무엇이 다른가요?

Container Apps는 AKS 위에 KEDA·Dapr·Envoy를 얹어 서버리스로 감싼 관리형 서비스로, 쿠버네티스 API를 직접 다루지 않고 컨테이너만 배포합니다. AKS는 쿠버네티스 클러스터 자체를 제어하므로 자유도가 크지만 노드·네트워크·업그레이드를 직접 운영해야 합니다.

App Service에서도 컨테이너를 실행할 수 있나요?

가능합니다. App Service는 코드 배포뿐 아니라 단일 도커 컨테이너 배포를 지원합니다. 다만 여러 컨테이너로 구성된 마이크로서비스나 이벤트 기반 자동 확장이 필요하면 Container Apps나 AKS가 더 적합합니다.

세 서비스 중 유휴 비용이 가장 적은 것은 무엇인가요?

Container Apps는 요청이 없을 때 인스턴스를 0으로 줄이는 스케일 투 제로를 지원해 유휴 비용을 크게 낮출 수 있습니다. App Service 전용 플랜과 AKS는 최소 1개 이상의 인스턴스·노드를 유지하므로 트래픽이 없어도 기본 비용이 발생합니다.

Azure App Service vs Container Apps vs AKS: 컨테이너 앱, 어디에 배포할까

같은 컨테이너라도 어디에 올리느냐에 따라 운영 부담과 비용이 완전히 달라집니다. Azure의 세 가지 대표 배포 옵션을 관리 부담·확장·비용 기준으로 비교하고, 상황별로 무엇을 골라야 하는지 정리했습니다.

Azure 컨테이너 배포 선택 - App Service, Container Apps, AKS 비교 다이어그램

한눈에 보기

App Service : 웹앱·API 하나를 빠르게 올리고 싶을 때. 가장 쉬운 PaaS.
Container Apps : 마이크로서비스·이벤트 기반·백그라운드 작업. 스케일 투 제로 지원하는 서버리스 컨테이너.
AKS : 쿠버네티스 전체 제어가 필요한 복잡한 시스템. 자유도 최대, 운영 부담도 최대.

“컨테이너로 만들었으니 이제 배포만 하면 되는데, App Service에 올릴지 AKS를 세울지 모르겠다”는 고민은 Azure로 넘어오는 팀이 거의 예외 없이 마주칩니다. 결론부터 말하면 세 서비스는 경쟁 관계가 아니라 관리 부담과 자유도의 스펙트럼입니다. 왼쪽 끝(App Service)은 쉽지만 제약이 있고, 오른쪽 끝(AKS)은 뭐든 되지만 직접 다 운영해야 합니다. Container Apps는 그 사이의 균형점입니다.

세 서비스 한눈에 비교

기준	App Service	Container Apps	AKS
추상화 수준	PaaS(앱 중심)	서버리스 컨테이너	관리형 쿠버네티스
관리 부담	가장 낮음	낮음	높음(노드·업그레이드 직접)
스케일 투 제로	미지원(전용 플랜)	지원(KEDA 기반)	기본 미지원(추가 구성 필요)
쿠버네티스 API	없음	직접 접근 불가	완전 제어
적합 워크로드	단일 웹앱·API	마이크로서비스·이벤트·잡	복잡한 대규모 시스템
러닝 커브	낮음	중간	높음
대표 부가기능	배포 슬롯·인증·SSL	Dapr·KEDA·Envoy	오퍼레이터·헬름·CRD

Container Apps가 내부적으로 AKS·KEDA·Dapr·Envoy 위에서 동작한다는 점이 핵심입니다. 즉 쿠버네티스의 확장성은 그대로 누리되, 클러스터 운영은 Azure가 대신 해주는 구조입니다.

각 서비스가 빛나는 시나리오

App Service — 프런트엔드+백엔드가 붙은 전통적인 웹 애플리케이션, 사내 관리자 도구, 단일 REST API처럼 “덩어리 하나”를 빠르게 배포할 때 가장 효율적입니다. 배포 슬롯으로 무중단 배포와 A/B 전환이 쉽고, 사용자 인증·커스텀 도메인·SSL이 기본 제공됩니다.

Container Apps — 여러 서비스가 큐·이벤트로 통신하는 마이크로서비스, HTTP 트래픽에 따라 0에서 N으로 급격히 오르내리는 API, 큐 길이에 반응하는 백그라운드 워커에 적합합니다. KEDA가 이벤트 소스(서비스 버스, 큐, HTTP 등) 기준으로 자동 확장하고, 요청이 없으면 0으로 줄여 비용을 아낍니다.

AKS — 이미 쿠버네티스 자산(헬름 차트, 오퍼레이터, CRD)이 있거나, GPU 노드 풀·특수 네트워킹·서비스 메시처럼 클러스터 레벨의 세밀한 제어가 필요할 때 선택합니다. 자유도가 가장 크지만 노드 업그레이드, 패치, 용량 계획을 팀이 책임져야 합니다.

선택 기준 체크리스트

쿠버네티스 API를 직접 써야 하나? → 그렇다면 AKS. 아니라면 App Service나 Container Apps로 충분합니다.
여러 컨테이너가 서로 통신하나? → 예면 Container Apps(또는 AKS), 아니면 App Service.
트래픽이 없을 때 0으로 줄여 비용을 아껴야 하나? → 그렇다면 스케일 투 제로가 되는 Container Apps.
팀에 쿠버네티스 운영 인력이 있나? → 없다면 AKS는 신중히. 관리형 옵션이 총소유비용에서 유리할 수 있습니다.
배포 슬롯·통합 인증 같은 PaaS 편의가 중요한가? → 그렇다면 App Service.

빠른 결론
단일 앱이면 App Service, 이벤트 기반 마이크로서비스면 Container Apps, 쿠버네티스 전체 제어가 필요하면 AKS. 애매하면 Container Apps에서 시작해 필요할 때 AKS로 넓히는 편이 위험이 적습니다.

배포는 얼마나 다른가 (CLI 비교)

세 서비스 모두 Azure CLI 한 줄에 가까운 명령으로 시작할 수 있지만, 요구하는 사전 리소스가 다릅니다.

# App Service (단일 컨테이너)
az webapp create \
  --resource-group rg-demo --plan plan-demo \
  --name my-webapp --deployment-container-image-name myacr.azurecr.io/app:1.0

# Container Apps (서버리스, 스케일 투 제로)
az containerapp create \
  --resource-group rg-demo --name my-capp \
  --environment cae-demo \
  --image myacr.azurecr.io/app:1.0 \
  --min-replicas 0 --max-replicas 10 --ingress external --target-port 8080

# AKS (클러스터부터 생성)
az aks create --resource-group rg-demo --name aks-demo --node-count 2 --generate-ssh-keys
az aks get-credentials --resource-group rg-demo --name aks-demo
kubectl apply -f deployment.yaml   # 이후 매니페스트로 직접 운영

줄 수만 봐도 운영 부담의 차이가 드러납니다. AKS는 클러스터 생성 이후에도 매니페스트·노드·업그레이드를 계속 다뤄야 합니다.

흔한 실수

웹앱 하나에 AKS를 세운다 — 가장 흔한 오버엔지니어링입니다. 단일 앱은 App Service로 충분하고, 클러스터 운영비만 늘어납니다.
Container Apps에서 쿠버네티스 명령을 기대한다 — kubectl로 직접 제어할 수 없습니다. 그 수준의 제어가 필요하면 처음부터 AKS를 골라야 합니다.
스케일 투 제로의 콜드 스타트를 무시한다 — 0에서 깨어날 때 첫 요청은 지연이 생깁니다. 지연에 민감한 서비스는 --min-replicas 1로 최소 1개를 유지하세요.
App Service 전용 플랜을 0으로 줄이려 한다 — 전용 플랜은 스케일 투 제로가 안 됩니다. 유휴 비용 절감이 목적이면 Container Apps가 맞습니다.
이미지 레지스트리 인증을 빠뜨린다 — 프라이빗 ACR을 쓸 때 관리 ID나 자격 증명을 연결하지 않으면 세 서비스 모두 이미지 풀에 실패합니다.

나중에 옮길 수 있을까

컨테이너 이미지로 표준화해 두면 이전은 생각보다 수월합니다. App Service의 단일 컨테이너를 Container Apps로 옮기거나, Container Apps 워크로드를 AKS 매니페스트로 승격하는 경로가 일반적입니다. 반대로 AKS의 복잡한 구성을 App Service로 되돌리기는 어렵습니다. 그래서 확신이 없을 때는 더 단순한 쪽에서 시작하는 편이 안전합니다. 필요해지면 오른쪽으로 넓히면 됩니다.

비용 구조가 다르다는 점도 함께 보기

기능만 비교하면 AKS가 가장 강력해 보입니다. 하지만 세 서비스는 과금 방식 자체가 달라서, 트래픽 패턴에 따라 순위가 뒤집힙니다.

	App Service	Container Apps	AKS
과금 대상	플랜(인스턴스) 시간	vCPU·메모리 초 단위	노드 VM 시간
0으로 스케일	불가	가능	노드는 유지됨
유휴 시 비용	발생	0에 가까움	발생 (노드 상시)
제어 플레인	—	—	무료 티어 존재
운영 인력	거의 불필요	적음	전담 필요

여기서 실무 판단이 갈립니다.

트래픽이 산발적이거나 야간에 거의 없다 → Container Apps. 0으로 스케일되는 구간의 절감이 큽니다
트래픽이 24시간 꾸준하다 → App Service나 AKS. 상시 가동이면 초 단위 과금의 이점이 사라집니다
서비스가 10개 이상이고 서로 통신한다 → AKS. 노드를 공유하므로 서비스가 늘어날수록 단가가 유리해집니다

AKS에서 자주 간과되는 비용이 시스템 노드 풀입니다. 애플리케이션 파드가 하나도 없어도 CoreDNS, metrics-server 같은 시스템 구성 요소가 돌 노드가 필요합니다. 클러스터를 만드는 순간 최소 노드 비용이 고정으로 발생합니다. 서비스가 한두 개뿐이라면 이 고정비가 App Service보다 비쌉니다.

반대로 서비스가 많아지면 AKS가 유리해지는 지점이 옵니다. 대략 서비스 10개 안팎이 손익분기로 언급되지만, 워크로드 크기에 따라 다르므로 실제 리소스 요청량으로 계산해보시는 편이 정확합니다.

운영 인력 행도 비용입니다. AKS는 버전 업그레이드, 노드 패치, 네트워크 정책 관리가 계속 필요합니다. 이 시간을 비용으로 환산하면 인프라 요금보다 클 수 있습니다. 사람이 부족한 조직에서 AKS를 고르면, 결국 업그레이드를 미루다 지원 종료 버전에 갇히는 경우가 생깁니다.

비용을 줄이는 방법으로는 Spot 노드 풀을 배치성 워크로드에 쓰거나, 이미지 크기를 줄여 스케일 아웃 속도를 높이는 방법이 있습니다. AKS 운영 중 파드가 안 뜨는 문제는 CrashLoopBackOff 원인 추적을 참고하세요.

자주 묻는 질문

Q. Container Apps와 AKS는 무엇이 다른가요?
Container Apps는 AKS 위에 KEDA·Dapr·Envoy를 얹어 서버리스로 감싼 관리형 서비스로, 쿠버네티스 API를 직접 다루지 않고 컨테이너만 배포합니다. AKS는 클러스터 자체를 제어하므로 자유도가 크지만 노드·네트워크·업그레이드를 직접 운영해야 합니다.
Q. App Service에서도 컨테이너를 실행할 수 있나요?
가능합니다. App Service는 단일 도커 컨테이너 배포를 지원합니다. 다만 여러 컨테이너로 구성된 마이크로서비스나 이벤트 기반 자동 확장이 필요하면 Container Apps나 AKS가 더 적합합니다.
Q. 세 서비스 중 유휴 비용이 가장 적은 것은?
Container Apps는 요청이 없을 때 인스턴스를 0으로 줄이는 스케일 투 제로를 지원해 유휴 비용을 크게 낮춥니다. App Service 전용 플랜과 AKS는 최소 1개 이상을 유지하므로 트래픽이 없어도 기본 비용이 듭니다.
Q. 처음이라면 무엇부터 시작하는 게 좋나요?
단일 웹앱은 App Service, 여러 서비스로 나뉜 구조는 Container Apps에서 시작하길 권합니다. 쿠버네티스 경험과 운영 인력이 갖춰졌을 때 AKS로 넓히는 것이 총소유비용 측면에서 유리한 경우가 많습니다.

정리하면, 세 서비스는 “무엇이 더 좋다”가 아니라 지금 우리 워크로드에 필요한 제어 수준이 어디까지인가의 문제입니다. 관리 부담을 최소로 두고 시작해, 요구가 커질 때 한 단계씩 오른쪽으로 이동하는 전략이 대부분의 팀에 잘 맞습니다.