🔥 언제 EC2가 아닌 다른 걸 써야 하는가

오늘이 2026년 4월 29일인데, 내일 4월 30일부로 AWS App Runner가 새 고객을 받지 않는 maintenance mode로 들어간다. 2021년 5월 18일에 "AWS의 Heroku"라며 GA를 선언한 그 서비스가, 거의 5년 만에 신규 등록만 닫는다(기존 고객은 그대로 쓸 수 있다). 마이그레이션 대상으로 안내된 후속 서비스는 2025년 11월 21일 출시된 Amazon ECS Express Mode다. 한 컴퓨트 옵션이 사라지고 다른 옵션이 그 빈 위치를 채우는 것 자체가 본 글의 본주제(EC2 말고 어디로 갈 수 있는가, 그리고 그 길이 닫혔을 때 어디로 다시 이동하는가)가 살아 있는 채로 굴러가는 한 장면이다.

지금까지 일곱 단원은 EC2 안에서 손잡이를 어떻게 잡을지에 대한 이야기다. 인스턴스 타입을 어떻게 고르는지, AMI 라이프사이클이 어떻게 진행하는지, EBS와 Instance Store가 어떻게 다른지, 가격 모델 네 갈래에서 무엇을 선택해야 하는지, ASG로 늘리고 줄이는 법, ALB·NLB·GWLB로 트래픽을 받는 법까지. 그런데 이 한 묶음은 "EC2가 답이라고 가정한 다음의 손잡이"를 다룬 것이다. 이 글은 그 가정 자체를 다시 본다.

EC2가 떠안고 있는 일은 정확히 무엇인가

EC2를 한 줄로 띄우는 순간 사용자에게 안기는 책임 목록은 짧지 않다. OS 패치(보통 매주 한 번 보안 업데이트), AMI 관리(작년에 본 것처럼 imageState/DeprecationTime을 따라가야 함), IAM Instance Profile 부착, Security Group과 NACL의 두 계층 방화벽, EBS 볼륨의 IOPS·throughput 산정, ASG와 Launch Template으로 묶는 스케일링, Health Check 신호의 다중 입력, 그리고 청구서의 절반쯤이 EC2 시간당 단가가 아니라 옆 서비스(EBS·NAT GW·CloudWatch·data transfer)에서 자라는 사실까지. 한 묶음이 다 사용자 책임이다.

EC2의 다섯 계층(물리·하이퍼바이저·인스턴스·OS·앱)에서 깔아 둔 그림으로 보면, AWS는 하이퍼바이저 아래만 책임지고 게스트 OS 위는 전부 사용자 몫이다. 그래서 EC2의 "관리형이 아니다"는 말은 추상이 아니라, 매주 누군가 apt-get upgrade 또는 SSM Patch Manager 콘솔을 들여다봐야 한다는 구체적인 작업 시간을 뜻한다. 한 사람이 한 시간씩 매주 EC2 fleet을 손보면 일 년이면 50시간이고, 50시간을 시급 5만 원으로 환산하면 250만 원이 같은 EC2 청구서 옆에 눈에 안 보이는 줄로 같이 따라온다.

이 한 묶음을 누군가가 대신 가져가 주면 그게 관리형 컴퓨트다. 이동한다고 모든 게 공짜가 되지는 않는다. 부담이 다른 곳으로 이동할 뿐이다.

관리형 컴퓨트 여섯 갈래: 누가 어디까지 가져가나

EC2 옆에 떠 있는 관리형 옵션은 여섯 가지다. 한 줄 정의로 묶으면 아래와 같다.

• AWS Lambda: 요청·이벤트 한 번에 함수 한 번 실행. 서버 자체가 보이지 않는 가장 끝까지 간 추상. 최대 실행 시간 15분(900초), 메모리 최대 10,240MB.
• AWS Fargate: 컨테이너 한 task를 띄우는 데 EC2가 필요 없게 한 추상. ECS 또는 EKS 위에서 task로 등장한다. 한 task 최대 16 vCPU·120 GiB RAM이고, 이 한도는 2022년 8월 31일부터 풀려 있다.
• Amazon ECS-on-EC2: ECS는 컨테이너 오케스트레이터이고, 그 워커가 EC2 인스턴스인 경우. 컨테이너 추상은 받지만 EC2의 OS·패치 책임은 그대로 남는다.
• Amazon EKS: Kubernetes API를 그대로 받는 관리형 컨트롤 플레인. 워커는 EC2 또는 Fargate. 시간당 컨트롤 플레인 비용 $0.10이 청구서 첫 줄에 따로 올라간다.
• AWS Elastic Beanstalk: EC2 + ASG + ALB를 묶어 한 wizard로 띄워 주는 오케스트레이션 wrapper. 안에서 도는 건 결국 EC2라 청구서 구성도 EC2와 같다.
• Amazon ECS Express Mode: 2025년 11월 21일 출시된 새 모드. 컨테이너 이미지 하나만 가지고 web service에 가까운 경험을 단순한 wizard로 받게 해 준다. 코드 push 자동 배포는 GitHub Actions 같은 CI/CD로 묶어 만들어야 하는 점이 App Runner와 다르다. App Runner 마이그레이션 대상으로 공식 안내되는 곳이다.

여섯 카드 중 진짜로 EC2의 OS 책임을 가져가는 옵션은 Lambda · Fargate · ECS Express Mode 셋이다. ECS-on-EC2와 EKS-on-EC2와 Beanstalk은 EC2를 보이지 않게 하지만 치우지는 못한다. 패치 cycle은 그대로 사용자 몫으로 남는다는 뜻이다.

책임이 어떤 형태로 이동하는지 한 줄로 표현하면, 왼쪽 끝 EC2(전부 사용자)에서 오른쪽 끝 Lambda(코드만 사용자)까지의 스펙트럼이다. 그 사이에 ECS-on-EC2 / EKS-on-EC2 / Beanstalk이 EC2 쪽에 가깝게, Fargate / ECS Express Mode가 Lambda 쪽에 가깝게 위치한다. 이 그림이 결정의 첫 화면이다.

비용은 사라지지 않는다: 이동할 뿐이다

관리형으로 옮겼을 때 청구서가 줄어드느냐. 워크로드 형태에 따라 줄거나 늘거나다. 한 가벼운 HTTP API를 예로 쥐고 셋을 옆에 놓아 본다.

조건: 평균 100ms 응답, 1일 10만 요청(월 약 300만 요청), 평균 메모리 256MB, 24시간 살아 있어야 함, 서울 리전(ap-northeast-2).

• EC2 t3.small 24/7: 서울 리전 기준 On-Demand 시간당 약 $0.0265 × 730시간 = 약 $19.3/월. 단, EBS 8GB(gp3) ≈ $0.8, CloudWatch 기본 메트릭, 그리고 ALB를 붙이면 시간당 약 $0.0225 × 730 ≈ $16 + LCU. 합 약 $40/월.
• AWS Fargate (ECS) 0.25 vCPU·512 MiB 1 task 24/7: 공식 pricing 페이지의 US East 단가는 vCPU-시간당 약 $0.0405, GB-시간당 약 $0.00444이고, 서울(ap-northeast-2)은 보통 약 26% 높아 vCPU-시간당 약 $0.0506, GB-시간당 약 $0.00553 부근으로 본다. 0.25 vCPU × 730 × $0.0506 + 0.5GB × 730 × $0.00553 ≈ 약 $11.3/월(ALB 별도). ALB를 붙이면 합 약 $27/월.
• AWS Lambda 300만 요청·평균 100ms·512MB: 요청 수 300만 호출이지만, 공식 무료 한도에 매월 영구적으로 100만 호출 + 40만 GB-초가 들어 있다. 그래서 청구 대상 호출은 200만이고, 호출당 $0.0000002 → $0.40. 컴퓨트 시간은 300만 × 0.1초 × 0.5GB = 150,000 GB-초인데 무료 한도 40만 GB-초 안에 다 들어가므로 컴퓨트 비용은 $0. 합 약 $0.40/월(API Gateway 별도). API Gateway $1/100만 요청 가정 시 약 $3.4/월.

같은 워크로드인데 청구서가 EC2 약 $40 → Fargate 약 $27 → Lambda 약 $3.4로 줄어든다. 그래서 가벼운 HTTP API는 Lambda + API Gateway가 한 자릿수 달러 답이고, EC2를 24/7 켜 두는 것은 청구서에 정직하지 않다. 다만 무료 한도가 없는 두 번째 함수부터는 호출당 단가가 살아나기 시작하므로, 트래픽이 한 함수에 집중되지 않을수록 Lambda 청구서의 변동성이 커진다.

다만 정반대 경우도 있다. 한 워크로드가 GPU를 8장 꽂고 24시간 도는 ML inference라면, Lambda는 GPU를 받지 못하고 Fargate도 못 받는다. EC2 g5.12xlarge 한 대에 t-engine을 띄우는 것이 답이고, 그 상황에서 Lambda를 강요하면 워크로드 자체가 안 돌아간다. 그리고 한 워크로드가 4 vCPU · 8GB로 95% busy인 상태로 24/7 돌아간다면, Lambda 청구서는 GB-초가 EC2 시간당 단가의 3~5배 위로 자란다. 가벼운 burst엔 Lambda가 답이지만, 무거운 sustained 워크로드는 EC2가 다시 답이다.

여기서 "관리형이 감추는 비용"의 다른 얼굴이 드러난다. NAT GW가 한 시간당 + GB당 양쪽으로 비용을 매기는 NAT GW의 이중 비용 구조에서 본 패턴과 같다. Lambda는 시간당이 아닌 요청당 + GB-초당이라는 다른 축으로 비용을 부과하지만, 그 축이 내 워크로드 형태와 어긋나면 EC2 청구서보다 더 빨리 자란다.

결정 트리: 어떤 워크로드가 어디로 가나

여섯 카드를 한 결정 트리로 묶으면, 워크로드의 네 가지 질문이 첫 답을 결정한다.

1. GPU·high-IOPS·OS 통제·라이선스 BYOL이 필요한가? → EC2. 다른 옵션은 이 질문에 "받지 못함"으로 답한다.
2. 요청·이벤트 기반인가, 평균 실행 시간 15분 이하인가? → Lambda. API, 이미지 썸네일, S3 트리거, EventBridge 스케줄, 짧은 ETL이 여기.
3. 컨테이너 기반이고 stateful이 아닌가? 24/7 도는 web service인가? → Fargate 또는 ECS Express Mode. 둘의 차이는 운영 인터페이스다. Fargate는 ECS task definition을 직접 쓰는 컨테이너 사람들의 답이고, ECS Express Mode는 git push 한 번으로 끝내고 싶은 사람들의 답이다.
4. Kubernetes API가 필요한가, 멀티-클라우드 호환성이 정말 필요한가? → EKS. 그 외엔 EKS의 컨트롤 플레인 비용($0.10/시간 = 월 약 $73)을 정당화하기 어렵다.

이 트리에서 다루지 않은 두 카드가 있다. Beanstalk은 기존 EC2 워크로드를 wizard 한 번에 띄우고 싶을 때 답이다. 그러나 안에 EC2가 그대로 들어가므로 관리 부담을 덜어 주지는 않는다. 첫 setup만 빨라지고 운영의 책임은 EC2와 동등하다. App Runner는 내일부터 새 고객을 받지 않으므로 실질적으로 후보에 두지 않는다. 같은 빈 곳은 ECS Express Mode가 가져간다.

EC2로 다시 돌아와야 하는 경우

여기까지 읽으면 EC2는 옛날 도구이고 가능하면 떠나라는 결론으로 들릴 수도 있다. 그건 절반만 맞다. EC2가 유일한 답인 워크로드도 분명 있다.

GPU 워크로드(Lambda·Fargate가 받지 못한다), high-IOPS NVMe 스토리지가 필요한 데이터베이스, Windows Server 라이선스 BYOL, OS 커널 모듈 설치가 필요한 보안 도구(예: 호스트 IDS), HPC와 MPI 클러스터, 기존 vendor가 EC2 AMI로만 distribute하는 어플라이언스. 한 묶음이 모두 EC2가 default 답이다. 그리고 24/7 95% busy인 워크로드에서는 Reserved Instances나 Savings Plans 약정으로 EC2 시간당 단가가 Fargate vCPU 단가보다 더 작다(Spot, On-Demand, Reserved: 세 가지 가격 모델에서 본 약정의 침전 비용 그래프 반대편).

Auto Scaling Group: 수요에 따라 늘리고 줄이는 법에서 ASG가 과한 곳으로 컨테이너 오케스트레이터를 짚었던 것, 그리고 Load Balancer: ALB·NLB·GWLB의 역할에서 LB가 답이 아닌 곳을 짚었던 것. 같은 패턴이다. 도구가 답이 아닌 영역이 명확하면, 그 도구가 답인 영역도 명확하다. EC2도 같은 식으로 본다. 언제 이동할지를 아는 만큼 언제 돌아올지도 알 수 있다.

다음 단계로: Lambda를 한 번 직접 본 다음에

지금까지 본 결정 트리는 모든 옵션을 한 줄 정의로만 짚어 두었다. 결정의 첫 단계엔 한 줄 정의로 충분하지만, 실제로 이동할지 말지를 정하려면 이동 대상 도구를 한 번은 직접 들여다봐야 한다. 다음 섹션에서 가장 끝까지 추상화된 옵션인 Lambda를 일곱 편에 걸쳐 본다. handler 모델, 실행 역할, 콜드 스타트, 동시 실행 한도, 비용 모델, VPC 통합, 그리고 마지막 편에서 Lambda가 답이 아닌 영역. 그 갈래까지 한 번 정리한 다음에 EC2로 돌아오면, 이 글의 결정 트리가 다른 색깔로 보일 수 있다.

EC2가 답이 아닌 영역만큼이나 다른 컴퓨트가 답이 아닌 영역도 있고, 그 경계는 이동 대상 도구를 직접 본 다음에 다시 그어야 정직하다.

참고 자료

• AWS App Runner availability change (공식 docs): 2026-04-30 maintenance mode 전환 공식 안내
• AWS Service Availability Updates 2026-03: App Runner·WorkMail 일정 발표
• AWS Lambda 공식 pricing: 요청·GB-초 단가 (2026-04-29 기준)
• AWS Lambda 함수 timeout docs: 최대 900초(15분)
• AWS Fargate 공식 pricing: vCPU·GB-시간당 단가
• AWS Fargate compute/memory 4x 증액: 2022-09부터 task 당 16 vCPU·120 GiB
• AWS Fargate Spot 공식 페이지: up to 70% 할인
• Amazon EKS pricing: 컨트롤 플레인 시간당 $0.10