# AWS에서 베어메탈로 이전한 지 2년: AWS 탈출에 대한 질문에 답하다 > Clean Markdown view of GeekNews topic #24011. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24011](https://news.hada.io/topic?id=24011) - GeekNews Markdown: [https://news.hada.io/topic/24011.md](https://news.hada.io/topic/24011.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-10-30T09:49:40+09:00 - Updated: 2025-10-30T09:49:40+09:00 - Original source: [oneuptime.com](https://oneuptime.com/blog/post/2025-10-29-aws-to-bare-metal-two-years-later/view) - Points: 16 - Comments: 3 ## Summary OneUptime 팀은 **AWS에서 베어메탈로 전환 후 연간 120만 달러 절감**이라는 인상적인 결과를 2년간의 실전 데이터와 함께 공개했습니다. **MicroK8s + Ceph 스택** 기반으로 **99.993% 가용성**을 유지하면서도, 절감된 비용을 **AI 서버 확충과 LLM 기능 고도화**에 재투자해 기술 경쟁력을 높였다고 합니다. 특히 **DWDM 이중 연결, 자동화된 IaC·Talos 운영, Ceph 미러링** 등으로 안정성과 효율을 모두 확보한 점이 돋보입니다. 클라우드의 탄력성은 여전히 유효하지만, 상시 부하형 서비스라면 이제 “** 비용 최적화 회의 대신 운영 자동화에 집중하라**”는 메시지가 더 설득력 있게 들립니다. ## Topic Body - 2년전 [**AWS에서 베어메탈로 이전해 연간 23만 달러를 절감**했던 경험](https://news.hada.io/topic?id=11954) 공유 후, 커뮤니티의 다양한 질문에 대한 **후속 답변**을 정리한 보고서 2년간의 실전 운영 데이터를 공개하며 **$120만 이상의 연간 절감 효과**를 달성했다고 밝힘 - 실전 운영을 통해 절감액은 연간 **120만 달러 이상**으로 증가했으며, 이를 **AI 기반 사고 요약 및 자동 코드 수정용 서버 투자**에 재투자해 서비스 품질 향상으로 이어짐 - **MicroK8s + Ceph 스택**을 기반으로 **99.993% 가용성**을 유지하고, **이중 데이터센터 구성**으로 단일 장애 지점을 제거함 - **실제 운영 비용, 장애 대응, 하드웨어 수명, 보안 인증, 클라우드 대체 서비스** 등 주요 쟁점을 구체적 수치와 함께 설명 - 결과적으로 **안정성과 비용 효율 모두 향상**되었으며, 일정 규모 이상의 상시 부하 시스템에서는 **Bare Metal이 더 합리적**이라는 결론을 제시 --- ### 2년간의 운영 결과 요약 - 24개월 동안 **MicroK8s + Ceph 스택**을 프로덕션 환경에서 운영하며 99.993%의 가용성 달성 - 단일 랙 문제를 해소하기 위해 프랑크푸르트에 **두 번째 랙**을 추가하고, 파리 메인 랙과 **DWDM 이중 연결** 구성 - **로컬 NVMe**와 소음 간섭 제거로 고객 지연시간을 19% 단축 - 절감된 비용을 **베어메탈 AI 서버** 구매에 재투자해, OneUptime의 **LLM 기반 알림 요약 및 자동 코드 수정 기능** 확장 ### 절감 효과 및 비용 비교 - 초기 예상 절감액은 연간 **$230,000**이었으나 현재는 **$1.2M 이상**으로 증가함 - 이는 AWS 대비 **약 76% 절감 효과**에 해당함 - 글로벌 인건비 기준으로는 엔지니어 2~5명의 연봉에 해당하는 규모임 - **Savings Plans / Reserved Instances**를 적용하더라도 여전히 Bare Metal이 유리함 - Savings Plans는 **S3·Egress·Direct Connect 비용**에는 적용되지 않음 - EKS 제어 플레인 비용 $1,260/월, NAT 게이트웨이 $600/월 등도 절감 불가 - **24/7 상시 운영형(steady) 워크로드**로 **리저브 인스턴스 효율이 제한적**이었음 ### 마이그레이션 및 운영 비용 - 초기 마이그레이션은 약 **1주일의 엔지니어링 작업**으로 완료됨 - IaC 정비, 백업 정책 강화 등 기존에 필요했던 작업이 대부분이었음 - 현재 운영비는 다음과 같음: - **직접 관리:** 분기당 약 24시간 (패치·펌웨어 업데이트 포함) - **Remote Hands:** 24개월 동안 2회만 개입 필요(주로 디스크 문제), 평균 대응 시간 27분 - **자동화:** PXE 부팅(Tinkerbell), Talos 이미지 관리, Flux/Terraform 구성 자동화 - 운영 인력은 기존 AWS 시절보다 오히려 **릴리스 속도 증가**, “비용 최적화 회의” 부담 제거 효과도 확인됨 ### 장애 대비 및 가용성 확보 - 프랑크푸르트에 **두 번째 랙** 추가, **DWDM 이중 경로 연결**로 단일 장애 지점 제거 - 비동기 복제 기반 **Ceph 미러링**과 **이중 제어 플레인** 구성 - **4G/위성 기반 관리 경로** 추가로 네트워크 장애 시 원격 접근 가능 - MicroK8s → Talos로 전환 중 - AWS Failover 백업 클러스터는 여전히 유지하며, **분기별 장애 복구 리허설** 수행 - Anycast+BGP 기반 Ingress로 DNS 전환 지연도 1분 미만으로 개선 - 2년간 **99.993% 가용성 유지**, 최근 AWS 리전 장애의 영향도 받지 않음 ### 하드웨어 및 CapEx 관리 - 서버는 **5년 감가상각** 기준(2×EPYC 9654, 1TB RAM, NVMe 구성)으로 운용 - 성능 포화 시 **분석 클러스터로 이관** 후 신규 서버로 교체 - 절감분 덕분에 **2년마다 40% 리프레시 가능**해 졌으며, 여전히 AWS 대비 연간 비용 절감 - Supermicro 보증 연장 + 예비 서버 3대 보유 - 실제 수명은 7~8년이지만 보수적으로 5년으로 산정함 ### 관리형 서비스 대체 논리 - **OneUptime의 제품 철학**은 자체 호스팅 가능성이므로 동일한 스택 유지가 필요함 - Kubernetes·Postgres·Redis·ClickHouse 등 **오픈스택 일관성** 유지 - **Terraform + EKS + RDS → MicroK8s + Argo Rollouts + Ceph**로 진화 - 자체 포크 없이 순정 오픈소스 활용 - 여전히 **클라우드도 병행 사용 중**: AWS Glacier(백업), CloudFront(엣지 캐싱), 부하 테스트용 임시 인스턴스 - 클라우드는 **탄력성 중심**, 베어메탈은 **기본 부하 중심**에 적합 ### 네트워크 및 보안 - **5Gbps(95th percentile)** 회선 2개 확보, AWS egress 대비 **8배 저렴** - DDoS 방어는 **Cloudflare 전면 배치**로 해결 - 독립된 4G/위성 기반 관리망 확보로 장애 시 원격 접근 가능 ### 컴플라이언스 및 감사 대응 - **SOC 2 Type II, ISO 27001** 인증 유지 - 코로케이션센터의 **Tier III 인증·출입 로그·CCTV** 자료 활용 - **Terraform/Talos 설정 로그**를 변경 이력 증빙으로 활용 - 감사인은 AWS 콘솔 스크린샷보다 이를 더 신뢰했다고 평가 ### 클라우드 대안 비교 - **Hetzner, OVH, Leaseweb, Equinix Metal, AWS Outposts** 비교 - Hyperscaler는 egress 비용이 여전히 높음 - 유럽 호스트는 대규모 Ceph 클러스터와 SLA 요건 충족 어려움 - Equinix Metal은 CapEx 대비 25~30% 프리미엄 존재 - 자가 하드웨어 운용이 **전력밀도·업그레이드 자유도** 면에서 우위 - 결과적으로 **15kW 랙 구성**과 부품 재사용 가능성 덕분에 **콜로케이션이 비용·성능 양면에서 우세** ### 운영 부담(TOIL) 측정 - 주간: 커널/펌웨어 패치 및 Ceph 점검 (1시간) - 월간: Kubernetes 제어 플레인 카나리 업그레이드 (2시간) - 분기: DR 훈련, 용량 계획, 통신사 계약 점검 (12시간) - 총합 **월 14시간 수준**, AWS 시절과 유사하나 “비용 추적”에서 “운영 자동화”로 초점이 이동함 ### 클라우드의 여전히 유효한 경우 - 워크로드가 **스파이크형 또는 계절적 패턴**인 경우 - **Aurora Serverless, Kinesis, Step Functions** 등 관리형 서비스 의존도가 높은 경우 - **Kubernetes·Ceph·모니터링·사고 대응**을 직접 운영할 여력이 없는 경우 - 즉, 초기 단계나 가변 부하가 큰 비즈니스에는 여전히 **클라우드 우위**가 존재함 ### 향후 계획 - **Colo 예산 예측용 Terraform 모듈 및 Runbook** 공개 예정 - Talos 기반 운영 경험을 다룬 심층 기술 포스트도 준비 중 - 지속적으로 HN·Reddit 피드백에 응답하며 **실제 수치 중심의 사례 공유**를 이어갈 계획 ## Comments ### Comment 45630 - Author: xguru - Created: 2025-10-30T10:14:51+09:00 - Points: 1 [AWS에서 베어-메탈로 이전하여 연간 23만 달러(3억원) 절약](https://news.hada.io/topic?id=11954) ### Comment 45659 - Author: okxrr - Created: 2025-10-30T16:47:30+09:00 - Points: 3 aws 에서만 제공하는 서비스를 전혀 쓰지않는데 aws를 열정적으로 쓰는 회사를 다니고 있습니다. 이 결정에 몇몇 리더분들의 커리어 개발이라는 지극히 개인적인 욕심이 크게 작용하는걸 본 웃픈 이야기.. ### Comment 45627 - Author: neo - Created: 2025-10-30T09:49:41+09:00 - Points: 3 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45745281) - AWS는 **너무 비쌈**. 완전히 AWS 위에 시스템을 올릴 이유가 생각보다 드묾. 예전엔 다들 **베어메탈 서버** 직접 돌릴 줄 알았는데, 이제는 그걸 잊은 듯함. 우리 팀은 730일 넘게 99.993% 가용성을 유지했고, 최근 AWS 리전 장애도 피해갔음. Cloudflare로 DDoS 방어를 하긴 하지만, DNS나 인그레스 관리가 풀타임 일이 되는 건 이해함. 하지만 마이크로서비스 몇 개와 DB 정도는 직접 돌려도 충분함. AWS는 대부분의 회사에 과금이 과함 - AWS의 진짜 문제는 **직원들의 AWS 종속화**임. AWS 인증 따고, AWS Well Architected Framework에 맞춰야 한다는 분위기 속에서 스스로 생각하지 않게 됨. AWS의 락인 서비스는 일부러 싸게 보이게 가격을 책정하지만, 결국 더 깊이 묶이게 됨. 예를 들어 PostgreSQL을 DynamoDB로 옮기면 단기적으로는 절약 같지만, 장기적으로는 AWS 의존이 커짐 - 온프레미스는 싸지만 **전문 인력 확보**가 어려움. 단순한 제품엔 잘 맞지만, 복잡한 시스템은 오히려 인건비와 운영 리스크가 커짐. AWS/Azure/GCP가 완벽하진 않지만, 요즘은 온프레미스 전문가가 너무 희귀함 - AWS를 비판하면 **이상하게 반발하는 사람들**이 많음. Reddit에서도 비슷한 현상이 있음. 마치 누군가 돈 받고 AWS를 옹호하는 것처럼 느껴짐 - 셀프호스팅 성공담엔 **확증편향**이 있음. 서버 직접 운영은 초기엔 좋아 보이지만, 1년쯤 지나면 문서와 실제 설정이 달라지고, 담당자가 퇴사하면 혼란이 커짐. 결국 많은 스타트업이 다시 AWS로 돌아감. 이런 실패담은 잘 공유되지 않음 - 베어메탈을 잘 돌리려면 **숙련된 엔지니어**가 필요함. 신입이나 컨설팅 회사 출신 “클라우드 전문가”로는 어려움 - 초창기 클라우드는 단순하고 **가성비 좋은 서비스**로 시작했지만, 지금은 200개 넘는 복잡한 서비스로 뒤엉켜 있음. 관리 안 하면 요금이 폭증함 - 사실 AWS는 처음부터 “싸다”가 아니라 “**빠르게 확장할 수 있다**”가 핵심이었음. 2010년대 초엔 비쌌지만 유연성이 장점이었음. 지금도 성능 대비 가격은 여전히 비쌈. 서버 관리 기본기만 있으면 전용 서버가 훨씬 나음 - AWS는 이제 **200개 넘는 서비스**로 과잉 확장됨. 기본 기능에 집중해야 함 - AWS 콘솔에 들어갈 때마다 **복잡함과 피로감**이 밀려옴. 너무 비대함 - AWS 서비스마다 **가성비 편차**가 큼. 특히 오래된 핵심 서비스들은 여전히 가치가 있음 - AWS의 진짜 기능은 (1) **조직 확장과 권력 구조**를 가능하게 함, (2) CapEx 대신 OpEx로 회계 처리 가능함, (3) 무능한 인사 구조를 감춤. 예전엔 5~10명으로 데이터센터를 돌릴 수 있었지만, 이제는 3000명짜리 DevOps 조직이 생김 - OpEx vs CapEx 차이가 왜 중요한지 모르겠음. 결국 돈은 돈 아닌가? - 클라우드는 **초기 스타트업**엔 유용함. 용량 계획 걱정 없이 빠르게 성장 가능함. 하지만 성장률이 낮은 회사가 계속 클라우드에 머무르면 비효율적임 - 온프레미스는 커스텀화가 심해 **인력 교체가 어려움**. 반면 AWS 인력은 어디서나 구할 수 있음 - 숙련된 시스템 관리자는 실제로 **구하기 어렵고 비쌈**. 싸게 하려다 백업이 2년째 안 된 경우도 봄 - 이 성공의 핵심은 **24/7 일정한 부하**임. 대부분의 회사도 사실상 비슷한 패턴임 - 사실 초기에 **단일 랙, 단일 데이터센터**로 시작한 게 운이 좋았음. 신뢰성 비용을 미리 안 냈기 때문임 - 관련 글: [One Big Server](https://www.specbranch.com/posts/one-big-server/) - AWS는 종종 “재고 없음”이라며 예약 인스턴스를 강요함. 결국 상시 운영 비용과 비슷해짐 - Hetzner 같은 곳은 AWS보다 **10배 싸게** 같은 성능을 제공함. 클라우드의 “탄력성”은 과장된 신화임 - **탄력성 vs 기저 부하**가 핵심임. 데이터 수집처럼 트래픽이 폭발적으로 몰릴 때만 클라우드가 유리함. 대부분의 경우엔 베어메탈이 낫음 - 2010년대엔 하드웨어와 네트워크가 느렸지만, 지금은 **CPU 성능과 효율이 수백 배 향상**됨. 예전 64대 서버가 지금은 1대면 충분함. 앞으로는 100:1 비율까지 갈 것임. 이런 상황에서 클라우드의 장점은 점점 줄어듦 - 아마존 직원으로서 보기에, **Kubernetes 자체 관리**는 너무 위험함. etcd 같은 구성요소는 불안정하고, 직접 패치까지 해야 했음. 글에서 말하는 셀프호스팅은 리스크가 과소평가됨 - 다른 하이퍼스케일러에서도 **Kubernetes 관리 실패**로 큰 장애를 겪음. Microk8s처럼 단일 랙용 간단한 대안이 나음. 관련 글: [Microk8s 6 Months Later](https://benbrougher.tech/posts/microk8s-6-months-later/) - 복잡한 환경은 어디서든 어렵고, 결국 **전문가가 필요함**. AWS도 마찬가지로 쉽지 않음. 클라우드 장애가 나도 세상은 계속 돌아감 - k3 같은 경량 버전은 훨씬 단순함 - **Kubernetes는 필요할 때만** 써야 함. 기본값으로 쓰면 시간과 돈 낭비임 - 많은 스타트업은 AWS 요금이 너무 비싸서 존재조차 못 했을 것임. 예를 들어 GeoIP 무료 다운로드([링크](https://downloads.pingoo.io)) 같은 건 불가능했을 것임. 클라우드는 느리고, **디스크 지연과 CPU 과밀**이 심함. 월 1만 달러 이하에서는 괜찮지만, 그 이상이면 베어메탈이 훨씬 효율적임 - 클라우드의 느린 성능에 익숙해져 **이상한 적응 현상**이 생김. 항상 베어메탈 기준으로 비교해야 함 - 내가 일하던 회사도 트래픽이 적었는데 AWS로 옮기려 했음. 이유는 단순했음 — **이력서에 AWS를 넣고 싶어서**였음. 개발자뿐 아니라 경영진도 마찬가지였음. “AWS 마이그레이션 리드”가 경력에 좋아 보였기 때문임. 결국 회사는 매각되고 사무실은 비었음. 이제는 “AWS에서 벗어났다”가 새로운 경력 포인트가 될지도 모름 - 개발자들이 AWS를 원하면, 다음 세대는 AWS밖에 모르게 됨. 논의가 편향됨 - 결국 결정은 **리더십의 의지**에 달림 - 결국 중요한 건 **무엇을 하려는가**임 - 내부용 데이터 중심 웹사이트라면 서버랙 하나면 충분함 - 불규칙하고 캐시 불가능한 대규모 트래픽이라면 클라우드가 유리함 - DNS나 인그레스가 복잡하면 하이브리드 접근이 좋음 - 데이터 규모가 커질수록 클라우드의 장기 감가상각 구조가 유리해짐