배포 선택지의 자리
배포 선택지의 자리 — 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 를 참고합니다.