배포 선택지의 자리 — 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 같은 큰 추상은 그 운영 부담을 감당할 인력이 있을 때만.

Next

• flyio
• iam

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