AWS EC2 인프라 철수기: 현황 분석부터 의사결정까지
운영 중인 시스템에서 AWS EC2 인프라 철수를 결정하기까지의 과정을 기록한다. 현재 AWS 사용 현황을 분석하고, 왜 철수를 고민하게 되었는지 문제를 제기한다. 그리고 구체적인 대안을 검토하고 최종 결정을 내리기까지의 과정, 전체 의사결정을 돌아보며 배운 점도 함께 정리한다.
TL;DR
- AWS EC2를 1년간 운영하며 월 약 80만 원 비용 발생
- 클라우드 핵심 가치(탄력성, 글로벌 확장성)를 활용하지 못하고 있었음
- 현재 워크로드 특성상 온프레미스가 더 적합하다고 판단
- Right-sizing, 타 클라우드 전환, 온프레미스 이전 세 가지 대안을 검토
- 최종적으로 EC2 철수 + Frontend 온프레미스 이전 + Model Repository는 S3로 결정
배경
원대한 시작
2024년 12월, 내부 프로젝트를 시작할 때 AWS 인프라 도입을 검토했다. 당시에는 일반 사용자를 대상으로 하는 클라우드 서비스로 기획되었다. 클라우드에서 구동되는 플랫폼을 목표로 했고, 초기 비즈니스 모델을 탐색하는 단계에서 클라우드 환경을 미리 경험해 보자는 의도도 있었다.
1년이 지나고
약 1년이 지났다. 서비스 형상이 여러 차례 바뀌었고, 현재는 내부 AI 엔지니어들이 주로 사용하는 서비스 형태로 정착했다. 일반 사용자 대상 클라우드 서비스라는 초기 기획과는 많이 달라진 상황이다.
그런데 매달 청구되는 AWS 비용을 보면서 의문이 들기 시작했다. 12월 기준으로 월 약 80만 원 정도가 과금되고 있었다. 환율이 높아진 요즘, 우리는 이 비용만큼의 가치를 누리고 있는 것일까?
현황
리소스 구성
현재 AWS에서 사용 중인 주요 리소스는 다음과 같다.
| 리소스 | 상세 | 용도 |
|---|---|---|
| EC2 | c5.4xlarge (16 vCPU, 32GB) | Frontend 서빙, 공인 IP 접근 |
| EBS | gp2, 512GB | EC2 인스턴스 스토리지 |
| Elastic IP | 1개 | 고정 공인 IP |
| Site-to-Site VPN | IPSec 기반 | 내부망-AWS 연결 |
EC2 인스턴스는 온프레미스 쿠버네티스 클러스터에 노드로 조인되어 있다. 내부망과 AWS VPC는 IPSec VPN으로 연결되어 있어, 마치 하나의 네트워크처럼 운영된다.
$ kubectl get nodes
NAME STATUS ROLES AGE
aws-node-01 Ready,SchedulingDisabled <none> 347d
onprem-master-01 Ready control-plane,etcd,master 33d
onprem-gpu-01 Ready <none> 317d
# ... 기타 온프레미스 노드들
현재 AWS 노드는 SchedulingDisabled 상태로 cordon해 놓은 상태다. 철수를 고려하면서 새로운 파드가 스케줄링되지 않도록 조치한 것이다.
실제 사용 현황
AWS 노드에서 실행 중인 파드를 확인해 보면, 핵심 워크로드는 Frontend뿐이다.
$ kubectl get pods -A -o wide --field-selector spec.nodeName=aws-node-01
NAMESPACE NAME READY STATUS RESTARTS AGE
app app-front-9675544cc-4dl87 1/1 Running 0 17d
app app-front-9675544cc-n88k4 1/1 Running 0 17d
app app-front-9675544cc-prtrd 1/1 Running 0 17d
# 나머지는 모니터링, 시스템 관련 DaemonSet
Backend는 이미 온프레미스 클러스터로 이전한 상태다. AWS 노드에는 Frontend 3개 레플리카만 남아 있다.
그 외에 AWS 리소스를 활용하는 것이 하나 더 있다. 내부망에 있는 MinIO의 공인 IP 접근이다. 외부 Edge 장비에서 Triton Model Repository에 접근해야 하는데, 이를 위해 AWS Elastic IP를 사용하고 있다.
비용 분석
비용 분석에 앞서 한 가지 언급할 것이 있다. 리셀러를 통해 AWS를 사용하고 있어서, AWS 대시보드에서 Cost Management나 Billing 관련 메뉴에 접근할 수 없었다. 따라서 세부적인 사용량 분석에는 한계가 있었고, 청구서를 기반으로 대략적인 비용 구조만 파악할 수 있었다.
월별 비용 추세
2025년 1월부터 10월까지의 비용 추세를 살펴보면 다음과 같다.
| 기간 | 대략적 비용 | 비고 |
|---|---|---|
| 2025년 1월 | 약 20만 원 | 초기 저사양 운영 추정 |
| 2025년 3월~ | 월 약 80만 원 이상 | 본격 운영 시작 |
| 연간 총액 | 약 1,000만 원 수준 | 환율 변동에 따라 증감 |
1월과 3월 사이에 비용이 급증한 것을 볼 수 있다. 초기에 저사양 인스턴스로 시작했다가 서비스 안정성을 위해 c5.4xlarge로 업그레이드한 것으로 보인다. 당시에는 빠른 실행과 안정성이 우선이었다.
비용 구성 요소
청구서를 분석해 보면, 주요 비용 구성은 다음과 같다.
- EC2 인스턴스: 가장 큰 비용 요소.
c5.4xlargeOn-Demand 24시간 운영 - EBS 볼륨: 512GB gp2 스토리지
- Site-to-Site VPN: 시간당 과금으로 월 고정 비용 발생
- 기타: Data Transfer, Cost Explorer 등
EC2 인스턴스가 전체 비용의 대부분을 차지한다. On-Demand 방식으로 24시간 운영하고 있어, Reserved Instance나 Savings Plan을 적용했다면 비용을 상당히 절감할 수 있었을 것이다.
문제 제기
클라우드 이점 활용 여부
클라우드 서비스의 핵심 가치는 무엇일까?
- 탄력성(Elasticity): 트래픽에 따라 리소스를 자동으로 확장/축소
- 글로벌 확장성: 전 세계 리전에 손쉽게 배포
- 매니지드 서비스: 인프라 관리 부담 경감
- 종량제 비용 모델: 사용한 만큼만 지불
현재 우리가 AWS를 어떻게 사용하고 있는지 돌아보았다.
- EC2를 24시간 풀가동하고 있다. Auto Scaling이나 탄력적 리소스 활용이 없다.
- 내부 엔지니어들이 주로 사용하는 서비스다. 지금 단계에서 글로벌 확장까지 고려할 필요는 없다.
- 트래픽이 예측 가능하다. 수 시일 내에 급격한 확장 가능성도 낮다.
- 매니지드 서비스를 거의 활용하지 않는다. EC2에 직접 배포하고 있다.
결론적으로, 클라우드가 제공하는 핵심 가치를 거의 활용하지 못하고 있다.
비용 대비 효용
현재 AWS로부터 얻는 핵심 가치는 두 가지다.
- Frontend 서빙을 위한 컴퓨팅 리소스
- 공인 IP를 통한 외부 접근
이 두 가지 가치가 월 약 80만 원의 가치가 있는가?
온프레미스에는 이미 충분한 컴퓨팅 리소스가 있다. 공인 IP도 자체 인프라에서 확보 가능하다. 굳이 클라우드를 사용해야 할 명확한 이유가 없어 보인다.
현재 워크로드에 적합한 인프라인가?
현재 상황을 정리해 보면, 어떻게 봐도 현재 단계에서는 온프레미스 운영이 더 유리해 보인다.
| 항목 | 현재 상태 | 클라우드 적합성 |
|---|---|---|
| 사용자 | 내부 연구자 | 온프레미스 적합 |
| 트래픽 패턴 | 예측 가능, 안정적 | 온프레미스 적합 |
| 확장 필요성 | 낮음 | 온프레미스 적합 |
| 인프라 역량 | 자체 보유 (K8s 클러스터 운영 중) | 온프레미스 적합 |
클라우드를 사용해야 하는 경우 vs 온프레미스가 유리한 경우
일반적으로 정리해 보면 다음과 같다.
- 클라우드가 적합한 경우:
- 예측 불가능한 트래픽 급증 가능성
- 글로벌 서비스 필요
- 빠른 실험과 반복 (스타트업 MVP 단계)
- 인프라 관리 인력 부족
- 피크 타임과 일반 시간의 차이가 큰 경우
- 온프레미스가 유리한 경우:
- 예측 가능한 안정적인 워크로드
- 보안/규제 요구사항으로 데이터 외부 반출 제한
- 일정 규모 이상에서 자체 운영이 더 저렴
- 인프라 관리 가능한 기술 역량 보유
- 내부 연구/개발 목적
현재 우리 케이스는 온프레미스가 유리한 조건을 대부분 만족한다.
대안 검토
문제를 인식한 후, 세 가지 방향의 대안을 검토했다.
- 클라우드 유지 + 최적화: EC2 Right-sizing, 과금 방식 변경
- 클라우드 프로바이더 변경: 타 클라우드로 이전
- 온프레미스 이전: 클라우드 탈출
대안 1: 클라우드 유지 + 최적화
Right-sizing
현재 c5.4xlarge(16 vCPU, 32GB)가 과도하게 큰 인스턴스인지 검토했다. 문제는 CPU/메모리 사용률 데이터를 확인해 본 적이 없다는 것이다. CloudWatch로 볼 수 있었지만 확인하지 않았다.
그럼에도 워크로드 특성상 추정해 보면, Frontend 서빙만 하는 상황에서 16 vCPU는 과도해 보인다. 절반 수준인 c5.2xlarge(8 vCPU, 16GB)로도 충분할 가능성이 높다.
| 인스턴스 타입 | vCPU | 메모리 | 시간당 비용 | 월 비용 (730h 기준) | 절감률 |
|---|---|---|---|---|---|
| c5.4xlarge (현재) | 16 | 32GB | $0.768 | 약 $560 | - |
| c5.2xlarge | 8 | 16GB | $0.384 | 약 $280 | 50% |
| t3.xlarge | 4 | 16GB | $0.166 | 약 $121 | 78% |
비용은 AWS 서울 리전(ap-northeast-2) On-Demand 기준이며, 월 730시간(24시간 × 약 30일) 운영을 가정했다. 실제 비용은 EBS, 네트워크 등 추가 요소에 따라 달라질 수 있다.
Right-sizing만으로도 상당한 비용 절감이 가능하다.
과금 방식 변경
현재 On-Demand 방식을 사용하고 있다. 24시간 풀가동하는 워크로드라면 Reserved Instance(RI)나 Savings Plan이 더 적합했을 것이다.
- Reserved Instance: 1-3년 약정, 30-70% 할인
- Savings Plan: 시간당 금액 약정, RI보다 유연하지만 할인율 낮음
- Spot Instance: 최대 90% 할인, 하지만 언제든 회수 가능하여 Frontend 서빙에는 부적합
다만, 지금 시점에서 RI를 구매하는 것은 오히려 손해다. 클라우드 탈출을 고려하고 있기 때문이다.
대안 2: 클라우드 프로바이더 변경
타 클라우드로 이전하면 비용이 나아질까?
| 프로바이더 | 리전 | 동급 인스턴스 | 예상 비용 | 비고 |
|---|---|---|---|---|
| AWS | 서울 | c5.4xlarge |
기준 | 현재 |
| Azure | Korea Central | F16s v2 |
비슷 | 유의미한 차이 없음 |
| GCP | asia-northeast3 | n2-standard-16 |
약간 비쌈 | 스토리지 비용 높음 |
| 국내 클라우드 | 한국 | 동급 | 약 30% 저렴 | 마이그레이션 비용 고려 필요 |
글로벌 클라우드 간에는 유의미한 가격 차이가 없다. 국내 클라우드가 다소 저렴하지만, 마이그레이션 비용과 학습 곡선을 고려하면 매력적이지 않다.
대안 3: 온프레미스 이전
가장 근본적인 대안은 클라우드를 떠나는 것이다.
비용을 비교해 보았다.
- 현재 AWS: 월 약 80만 원, 연간 약 1,000만 원
- 온프레미스 이전 시: 초기 서버 구매 비용 외에는 전력/관리비 정도
동급 사양 서버를 새로 구매한다면 비용은 일회성이다. 1년이면 본전, 2년차부터는 연간 1,000만 원 가까이 절감 가능하다.
다만, 이미 사내에 유휴 리소스가 있다면 이야기가 달라진다. 서버를 새로 구매할 필요가 없으니, 이전하는 즉시 월 80만 원이 절감된다.
결정
근본적인 문제
인스턴스 타입을 낮추거나, 저렴한 타 클라우드로 이동하는 방향도 있다. 하지만 근본적인 문제는 해결되지 않는다.
“이 워크로드는 클라우드에 부적합하다.”
클라우드의 핵심 가치는 탄력성과 글로벌 확장성이다. 우리는 이 가치를 활용하지 못하고 있다. 비용만 낮춘다고 해서 이 본질적인 미스매치가 해결되지는 않는다.
온프레미스 이전 결정
최종적으로 온프레미스 이전을 결정했다. 근거는 다음과 같다.
- 워크로드 특성: 사내 연구자 중심, 예측 가능한 트래픽, 확장 필요성 낮음
- 인프라 역량: 이미 사내에서 쿠버네티스 클러스터를 운영하고 있음
- 비용 효율: 장기적으로 상당한 비용 절감 가능
- 클라우드 이점 미활용: 현재 탄력성, 글로벌 확장성 등 핵심 가치를 활용하지 못함
예상 문제점 및 대안
EC2 철수 시 예상되는 문제점과 대안을 정리했다.
Frontend 서빙
문제: AWS EC2 노드에서 Frontend 파드가 서빙되고 있다.
대안: 사내망에서 외부 접근 가능한 서버로 이전하면 된다. 이미 Backend는 온프레미스 클러스터로 이전한 상태이므로, Frontend도 동일한 방식으로 처리 가능하다.
Model Repository 외부 접근
문제: 외부 Edge 장비에서 Triton Model Repository(MinIO)에 접근해야 한다. 현재는 AWS Elastic IP를 통해 접근하고 있다.
이 문제가 핵심이다. AWS를 떠나면 외부에서 사내망 MinIO에 어떻게 접근할 것인가?
검토한 대안:
- MinIO를 외부 접근 가능한 서버로 이전
- MinIO Reverse Proxy 구성
- AWS S3 사용
AWS를 떠나면서 왜 S3는 고려하는가? EC2를 떠나려는 이유는 “24시간 풀가동 컴퓨팅 리소스에 클라우드가 맞지 않다”는 것이었다. 반면 S3는 성격이 다르다. 사용한 만큼만 과금되고, 외부 접근 가능한 오브젝트 스토리지라는 클라우드 고유의 이점을 그대로 활용할 수 있다. 매니지드 서비스라 유지보수 부담도 없다.
S3 비용 예측
S3를 사용하면 비용이 얼마나 들까? 현재 사용량 기준으로 예측해 보았다.
S3 비용 구성 요소:
- 스토리지 비용: GB-월 단위
- 요청 비용: GET, PUT 등 요청당 과금
- 데이터 전송 비용: Outbound 트래픽
현재 MinIO 사용량 (2025년 12월 기준):
- 저장 용량: 약 32GB (모델 파일 + 이벤트 데이터)
- 요청 횟수: 월 약 800건 수준
사용량이 적은 이유: 현재 사내 엔지니어들이 주로 사용하는 시스템이라 트래픽이 많지 않다. 서비스 사용이 활발해지면 달라질 수 있지만, 현 시점 기준으로 예측한다.
S3 Standard 기준 예상 비용:
스토리지: 32GB × $0.025/GB = 약 $0.8/월
요청 비용: 거의 무시 가능한 수준
─────────────────────────────────
총 예상 비용: 월 $1 미만
예상보다 훨씬 저렴하다. S3는 EC2처럼 On-Demand로 시간당 과금되는 것이 아니라, 순수하게 사용한 만큼만 과금된다. 소규모 사용량에서는 극적으로 저렴해질 수 있다.
사용량 증가 시나리오:
현재 사용량이 대폭 증가해도 비용이 감당 가능한지 확인해 보았다.
$51 / $0.025/GB = 약 2,000GB 저장 가능
현재 사용량: 32GB
여유: 약 60배 증가해도 동일 비용
현재 사용량의 60배가 증가해도 월 $51 수준이다. 물론 요청 비용과 데이터 전송 비용이 추가되지만, 현재 규모에서는 무시 가능한 수준이다.
MinIO 유지보수 모드 전환 리스크
S3를 고려하게 된 또 다른 이유가 있다. MinIO 커뮤니티 에디션이 2025년 12월 유지보수 모드로 전환되었다.
2025년 MinIO 정책 변화:
- 2025년 2월: 웹 콘솔 관리 기능 제거
- 2025년 10월: Docker 이미지 배포 중단
- 2025년 12월: 유지보수 모드 전환 (새 기능 개발 중단, 보안 패치도 사안별 평가)
사실상 커뮤니티 버전의 개발이 중단된 것이다. 새로운 인프라에 MinIO를 선택하는 것은 기술 부채를 쌓는 결정이 될 수 있다.
참고: MinIO 유지보수 모드 공지
물론 기존에 운영 중인 MinIO를 당장 마이그레이션해야 하는 것은 아니다. 하지만 새로운 Model Repository를 구축한다면, MinIO보다는 S3나 다른 대안(Ceph, SeaweedFS 등)을 고려하는 것이 현명해 보인다.
최종 결정
팀 내 논의를 거쳐 다음과 같이 결정했다.
- EC2 철수: 온프레미스로 완전 이전
- Frontend: 사내망 외부 접근 가능 서버로 이전
- Model Repository: AWS S3 사용
S3는 월 $1 미만의 비용으로 외부 접근 가능한 Model Repository를 제공한다. MinIO 유지보수 부담도 사라지고, HTTPS 인증서 관리도 AWS가 해준다. 보안적으로도 사내망을 직접 열 필요가 없어 더 안전하다.
후속 조치
S3 사용 시 장점
- 보안: 사내망을 외부에 노출하지 않아도 됨
- HTTPS: AWS가 제공하는 인증서 사용 가능
- 유지보수 부담 감소: MinIO 구축/운영/메모리 누수 이슈 등 관리 포인트 없음
- 종량제: 사용한 만큼만 비용 발생
마이그레이션 계획
- Frontend 이전: 사내망 외부 접근 가능 노드로 이동
- S3 버킷 생성: Model Repository용 버킷 구성
- 데이터 마이그레이션: 기존 MinIO 데이터 중 필요한 것만 S3로 이전
- 애플리케이션 설정 변경: Triton 등 Model Repository 접근 주소 변경
- AWS 리소스 정리: EC2, EBS, VPN 등 삭제
AWS 리소스 정리
마이그레이션 완료 후:
- EC2 인스턴스 종료 및 삭제
- EBS 볼륨 삭제 (필요한 데이터 백업 후)
- Elastic IP 해제
- Site-to-Site VPN 연결 해제
- 리셀러 계약 검토
S3 도입 시 고려사항
비용 최적화:
- S3 Intelligent-Tiering: 접근 패턴에 따라 자동 최적화
- 태깅 전략: 리소스별 태그로 비용 추적
- 예산 알림 설정: 예상치 못한 비용 증가 방지
보안:
- IAM 정책 최소 권한 원칙
- 버킷 정책 설정
- 접근 로깅 활성화
현재 데이터 규모는 작지만, 향후 확장을 대비해 처음부터 좋은 관행을 적용해 두는 것이 좋다.
돌아보며
의사결정 과정
초기 검토 문서를 다시 찾아보았다. 당시 CPU/GPU 노드 구성을 검토한 흔적이 있었지만, 실제 결정 근거는 남아 있지 않았다. 인스턴스 타입 변경 이력도 마찬가지였다.
초기에는 빠른 실행이 우선이었다. 비즈니스 방향이 여러 번 바뀌는 과정에서 인프라 재점검 타이밍을 놓쳤고, 리셀러를 통해 사용하다 보니 비용 가시성도 낮았다. 결과적으로, 현재 단계에 맞지 않는 비용을 지속적으로 지불해 왔다.
인프라 구축 의사결정이 너무 중요하다
인프라 결정은 한번 내리면 쉽게 바꾸기 어렵다. 특히 클라우드는 시간이 지날수록 비용이 누적되기 때문에, 초기 결정이 더욱 중요하다.
앞으로 인프라 결정 시 반드시 해야 할 것을 정립하고자 한다.
- 워크로드 특성 분석: 클라우드가 정말 필요한가?
- 비용 예측: 월별/연별 비용을 구체적으로 산정
- 대안 비교: 온프레미스, 타 클라우드 등 대안과 비교
- 결정 근거 문서화: 왜 이 선택을 했는지 기록
모니터링과 관측 가능성의 중요성
이번 분석에서 가장 아쉬웠던 것은 CPU/메모리 사용량 데이터가 없다는 것이다.
실제 사용률 데이터가 있었다면:
- Right-sizing을 훨씬 정확하게 할 수 있었다
- 16 vCPU 중 실제로 몇 %를 사용했는지 알 수 있었다
- 의사결정에 명확한 근거를 제시할 수 있었다
CloudWatch로 CPU/메모리 사용률을 볼 수 있었는데, 확인하지 않았다. 도구가 없어서가 아니라 보는 습관이 없었던 것이 문제였다.
클라우드가 능사는 아니다
클라우드를 떠나는 것이 트렌드에서 후퇴하는 것 아닌가? 처음에는 그런 생각이 들기도 했다. 하지만 그렇지 않다.
Right-sizing infrastructure to business stage.
이번 경험을 통해 느낀 것은, 비즈니스 단계에 맞는 인프라를 선택하는 것이 중요하다는 점이다. 적어도 우리 케이스에서는, 클라우드의 핵심 가치(탄력성, 글로벌 확장성)를 활용하지 못하면서 비용만 지불하고 있었다. 그렇다면 굳이 클라우드에 남아 있을 이유가 없었다.
클라우드 네이티브 사고방식은 유지하자
클라우드를 떠나더라도, 클라우드 네이티브 사고방식은 여전히 유효하다.
- Infrastructure as Code: Terraform 등으로 인프라 코드화
- 컨테이너 기반 배포: 쿠버네티스 유지
- 자동화된 CI/CD: 배포 파이프라인 자동화
- 관측 가능성: 모니터링, 로깅, 트레이싱
이런 원칙들은 온프레미스에서도 동일하게 적용된다. 인프라가 어디에 있느냐보다, 어떻게 운영하느냐가 더 중요하다.
결론
이번 경험은 많은 것을 가르쳐 주었다. 비즈니스 탐색 단계에서는 빠른 실행이 중요하지만, 어느 시점에서는 인프라 비용도, 의사결정 근거도, 모니터링도 점검해야 한다는 것을 배웠다.
초기에 클라우드를 선택한 것 자체가 잘못은 아니었다. 당시 비즈니스 방향에는 맞는 선택이었다. 다만, 비즈니스 방향이 바뀌었을 때 인프라도 함께 재점검했어야 했다. 늦게라도 문제를 인식하고 개선한 것에 의미를 두고 싶다.
앞으로는 인프라 결정에 더 신중해지고, 모니터링을 게을리하지 않고, 비용과 효용의 균형을 지속적으로 점검할 것이다.
댓글남기기