배포 선택지의 자리 — VM 부터 함수까지

"AWS 에 배포한다" 는 한 문장 안에는 매우 다른 추상 수준의 선택지가 있습니다. EC2 한 대 직접 관리부터 Lambda 같은 함수 단위 호스팅까지. 다른 클라우드와 PaaS 까지 포함하면 그림이 더 넓어집니다.

1. AWS 의 컴퓨팅 추상 사다리

서비스	추상 수준	메모
EC2	VM	OS 까지 직접. 가장 자유롭고 가장 많은 책임.
Lightsail	VM 정액제	단순한 작은 VPS 묶음.
Elastic Beanstalk (2011)	플랫폼	코드 zip → 자동 EC2 + ELB + ASG. 오래된 PaaS.
ECS (2014)	컨테이너 오케스트레이터	EC2 또는 Fargate 위에서.
Fargate (2017)	서버리스 컨테이너	EC2 관리 없이 컨테이너 단위 청구.
EKS (2018)	매니지드 Kubernetes	컨트롤 플레인 매니지드. 워커는 EC2/Fargate.
App Runner (2021)	PaaS	컨테이너/소스 → 자동 빌드·배포·스케일.
Lambda (2014)	함수	이벤트 단위 실행. 짧은 작업.

같은 코드를 어디에 올릴지의 결정은 운영 통제와 인지 부하 사이의 트레이드오프입니다.

2. EC2 — 가장 자유, 가장 많은 책임

OS 패치 · 런타임 설치 · 로그 회전 · 보안 업데이트가 모두 사용자 책임. 자유도는 최대. 운영 인력이 충분치 않으면 부담이 큽니다.

3. Beanstalk — 매니지드 EC2 묶음

소스/도커 이미지를 올리면 EC2 + ELB + ASG 를 자동 구성합니다. 2010 년대 초반의 유산 같은 위치이지만 여전히 운영됩니다. App Runner · ECS 가 등장하면서 사용 비중은 다소 줄었습니다.

4. ECS · Fargate

컨테이너를 띄우는 매니지드 서비스. 두 가지 시작 모드.

EC2 모드 — 직접 관리하는 EC2 클러스터 위에 컨테이너 배치. 인스턴스 비용 + ECS 무료.
Fargate 모드 — 인프라 보이지 않음. 컨테이너의 vCPU·메모리 단위 청구.

Fargate 가 인프라 관리를 줄이는 대신 단가는 EC2 보다 비싸다는 비교가 흔합니다. 트래픽이 스파이크형이거나 운영 인력이 한정적이면 Fargate, 안정적인 큰 워크로드면 EC2 모드가 비용에 유리할 수 있습니다.

5. EKS — 매니지드 Kubernetes

컨트롤 플레인은 AWS 가, 워커 노드는 EC2 또는 Fargate. k8s 자체의 학습·운영 부담은 그대로 사용자에게 남습니다. 다중 클라우드 이식성·생태계가 강점.

6. App Runner — 컨테이너 PaaS

컨테이너 이미지 (또는 소스 저장소) 를 가리키면 자동으로 빌드·배포·스케일·HTTPS 종단까지 합니다. ECS/Fargate + ALB 의 조합을 한 추상으로 묶은 느낌. 작은 웹 앱·API 에 어울리는 자리.

7. Lambda — 함수 단위

요청·이벤트 단위로 실행. 호출이 없으면 비용이 0. 콜드 스타트 (첫 호출 지연) · 실행 시간 한도 (최대 15 분) · 응답 크기 제한 같은 제약이 있습니다. API Gateway · ALB · EventBridge · SQS 등과 결합합니다.

8. 다른 클라우드의 PaaS

서비스	메모
Heroku (2007, Salesforce 인수 2010)	클래식 PaaS. `git push heroku main`. 무료 티어 종료 (2022).
Vercel (2015)	프런트엔드·풀스택 (특히 Next.js). 글로벌 엣지 + 함수.
Railway (2020)	모던 PaaS. Heroku 의 정신적 후속.
Render (2018)	정적·웹서비스·DB 매니지드.
Fly.io (2017)	다중 리전 컨테이너 배포. 엣지 가까운 워크로드.
Cloudflare Workers (2017)	엣지 함수. V8 isolate 런타임.
Google Cloud Run (2019)	GCP 의 컨테이너 서버리스.
Azure Container Apps (2022)	KEDA 기반.

PaaS 의 공통 매력은 운영 결정의 상당 부분을 위임할 수 있다는 점입니다. 한계는 비용·이동성·세부 통제 — 어느 시점에 vendor lock-in 이 부담이 될 수 있습니다.

9. 단일 VPS 와의 트레이드오프

사업자	메모
Hetzner Cloud	유럽 기반 저가 VPS. 가격 대비 성능.
DigitalOcean	단순 UI · 매니지드 DB · App Platform.
Linode (Akamai)	전통적 VPS.
OVHcloud	유럽 기반 큰 VPS 사업자.
Vultr	다양한 리전 VPS.

작은 트래픽 · 고정 비용 선호 · 운영 인지 부하 최소화를 원하면 단일 VPS + docker compose 가 종종 합리적입니다. AWS 의 강점은 기능 폭과 확장 천장이지, 단순성·가격은 아닙니다.

10. 워크로드 → 추상 매핑 (예시)

워크로드	자연스러운 자리
정적 사이트	S3 + CloudFront · Vercel · Cloudflare Pages · Netlify
작은 API	App Runner · Lambda + API Gateway · Fly.io
컨테이너 한 두 개	App Runner · ECS Fargate · 단일 VPS + Compose
복잡한 마이크로서비스	ECS Fargate · EKS · Nomad
이벤트·배치 잡	Lambda · ECS scheduled tasks · Step Functions
큰 인프라·다중 팀	EKS · 자체 Kubernetes

대체로 추상 수준이 높을수록 운영 부하는 낮고 단가는 높습니다. EC2 < ECS EC2 < Fargate < App Runner < Lambda 의 단가 순서가 일반적이지만 호출 패턴·항상 켜져 있는지 여부에 따라 역전됩니다.

11. 자주 걸리는 자리

Lambda 의 콜드 스타트 — 자바·Node 큰 의존을 가진 함수에서 두드러집니다. Provisioned Concurrency · ARM (Graviton) 함수 · 의존 다이어트가 대안.

데이터 송신 비용의 누적 — 어느 자리든 외부 트래픽 GB 가 쌓입니다. CDN · 캐싱 · 압축이 큰 차이를 만듭니다.

EKS 의 운영 부하 — 매니지드라 해도 노드 · 네트워크 · 애드온 관리가 따릅니다. 작은 팀의 첫 선택으로는 거의 권장되지 않습니다.

PaaS lock-in — 손쉬운 시작이 이전 시점의 큰 비용으로 돌아옵니다. 빌드·런타임·환경변수·시크릿이 표준 컨테이너 모델에 머물러 있는지 점검.

여러 추상의 혼재 — 한 시스템 안에 EC2 + ECS + Lambda + App Runner 가 다 있으면 운영 모델이 분열됩니다. 비용 추적·관측성도 흩어집니다.

하고픈 말

배포 선택지는 코드의 모양보다 팀의 운영 모델에 더 큰 영향을 받습니다. 작은 팀은 단순한 자리에서 시작해 필요할 때 한 단계씩 올라가는 흐름이 안전합니다. EKS 같은 큰 추상은 그 운영 부담을 감당할 인력이 있을 때만.

flyio
iam

AWS Compute 서비스 · App Runner · Lambda · Cloud Run · Fly.io · Heroku · Hetzner Cloud 를 참고합니다.