AWS에서 Hetzner로 마이그레이션해서 클라우드 비용 76% 절감
(digitalsociety.coop)- AWS와 DigitalOcean에서 Hetzner로 마이그레이션함으로써 클라우드 비용을 76% 절감하고 리소스 용량은 3배로 증가함
- 과거에는 AWS의 안정성과 DigitalOcean의 간편함을 바탕으로 두 클라우드 서비스를 병행 사용함
- 무료 크레딧 소진 후 월 449달러 이상의 운영비 부담이 발생하여 Hetzner 같은 대안을 모색하게 됨
- 비용 절감을 위해 Talos Linux 기반 Kubernetes, CloudNativePG, Ingress NGINX, ExternalDNS, cert-manager 등을 조합한 자체 관리형 클라우드 스택을 구축
- Hetzner의 ARM 공유 vCPU 서버와 S3 호환 스토리지를 이용해 성능과 안정성을 유지하면서도 대규모 리소스 확장 달성
- 관리 편의성은 다소 떨어지지만 유럽 내 대안 클라우드로서 비용·성능 효율이 탁월
배경
- DigitalSociety에서 개발하는 모든 소프트웨어는 클라우드 기반에서 구동됨
- 마이그레이션 전에는 주요 인프라를 AWS(주요 서비스와 인증·메일 등 관리) 와 DigitalOcean(경량 서비스와 모니터링, Kubernetes) 양쪽에서 운영함
- AWS는 15년 넘게 활용해 온 익숙함과 높은 API 안정성으로 선택함
- DigitalOcean은 간단한 Kubernetes 환경과 무료 컨트롤 플레인, 그리고 비용 효율성 덕분에 선택함
- 초기에는 DigitalOcean만 사용했으나, 데이터 집약형 SaaS인 tap처럼 많은 리소스와 추가 크레딧이 필요해 AWS의 스타트업 크레딧($1,000)을 활용함
크레딧 종료와 비용 부담
- AWS의 Fargate(서버리스 컨테이너 러닝) 덕분에 초기에 저렴하게 구축이 가능했으나, tap 서비스의 데이터 집약적 특성상 성능 유지를 위해 최소 2x CPU, 4 GiB RAM이 필요함
- Fargate 기준 해당 스펙의 컨테이너는 월 $70 이상 비용이 들며, 두 개의 워커 인스턴스 및 기타 인프라를 합산하면 월 $449.50까지 증가함
- 제공된 무료 크레딧은 6개월이 채 안 되어 소진되고, 자가 자본 스타트업 입장에서는 심각한 고정비 부담으로 작용함
대안 탐색 과정
- 높은 운영비 절감과 기술 독립성 확보를 위해 UK/EU 기반 클라우드 제공업체를 모색함
- Hetzner의 가격 경쟁력에 매료되어 자가 관리형 VPS 환경과 운영 복잡성에도 불구하고 AWS와 DigitalOcean 모두에서 마이그레이션을 결정함
- 이미 Kubernetes 기반으로 서비스 대부분을 운영 중이었기에, Talos Linux의 간편한 클러스터 구축 기능 덕분에 Hetzner 환경에서도 자체 Kubernetes 클러스터를 구축함
- 기존 AWS나 DigitalOcean의 Managed DB 서비스는 없으나, CloudNativePG로 PostgreSQL 클러스터를 Kubernetes 환경에서 안전하게 통합 관리(모니터링, 백업, 장애 대응 등)함
새로운 인프라 스택
- Hetzner: ARM 서버, 블록 스토리지, 부하분산기, 네트워크, 방화벽, S3 호환 객체 스토리지 활용
- Talos Linux: 선언형 설정을 통한 Kubernetes 노드 관리로 운영 자동화 실현
- CloudNativePG: Kubernetes 매니페스트에 DB 클러스터 선언 및 자동백업, 장애대응 등 통합 지원
- Ingress NGINX Controller: 클러스터 내 HTTP 라우팅 통합 관리
- ExternalDNS: 인그레스 리소스에 DNS 자동 연동
- cert-manager: HTTPS용 TLS 인증서 자동 발급
- 모든 인프라는 Terraform과 Helm으로 코드화, GitHub Actions를 통한 자동 배포로 DevOps 실현
비용 비교
- 이전 전 월비용: AWS + DigitalOcean = $559.36
- 이전 후 월비용: Hetzner = $132.96 (−76%)
- 리소스 증대:
- CPU: 12 vCPU → 44 vCPU (+367%)
- RAM: 24 GiB → 88 GiB (+367%)
- 리소스가 증가함에도 월 총비용은 훨씬 저렴
마이그레이션 과정의 도전과 시행착오
- Hetzner의 네트워크 존은 AWS의 가용영역(Availability Zone) 과 완전히 동일하지 않음
- AWS는 한 리전에 여러 가용영역, 프라이빗 네트워킹이 리전 단위로 광범위하게 연결됨
- Hetzner는 한 network zone(eu-central) 아래 여러 지역(location)이 있으며, 이들 간 네트워크 지연(latency)이 큼
- 실제로는 여러 지역에 분산할 경우 성능 저하 등 문제 발생함을 모니터링을 통해 경험함
- 대안으로 단일 지역(뉘른베르크) 내 Placement Group을 활용해 물리적 서버 분산을 통한 장애 복원력 확보
-
컨테이너 기반 서비스라도 이식이 간단하지는 않음
- AWS ECS에서 Kubernetes로 환경을 옮길 때, 전체 설정의 자동화 스크립트(특히 config 파일 배포 등) 수정 작업이 예상외로 오래 걸림
- 결국 Kustomize로 민감한 설정 연동 및 config 파일 관리 체계를 개선해 추적성과 검토 편의성을 높임
결론
- Hetzner는 손쉬운 관리형 서비스는 아니지만, 자가 관리가 가능한 팀에게 매우 효율적인 선택
- 자체 운영으로 세부 구성 제어권을 확보하면서도 비용 대비 성능을 극대화
- 이 방식으로 데이터 집약형 SaaS인 tap을 합리적인 비용과 안정적인 성능 하에 계속 개발 및 운영할 수 있는 기반을 마련함
Hacker News 의견
-
나는 베어메탈에 직접 배포했을 때 체감되는 성능 향상이 정말 엄청남을 강조하고 싶음. 우리 서비스 기준으로 성능이 2배로 뛰고, 예측 가능한 안정적인 퍼포먼스를 보여줌. 그 이유는 여러 가지가 있음:
-
낮은 레이턴시: 직접 네트워크를 관리하면 대규모 데이터센터의 복잡한 네트워크를 공유하지 않아 지연 시간이 10배 이상 줄어듦
-
캐쉬 최적화: 하드웨어에 최적화된 배포로 최신 CPU의 진짜 성능을 충분히 활용할 수 있음
-
전용 NVMe 사용: 디스크 IO 속도가 엄청남
-
또 다른 장점은 오토스케일러가 별로 필요 없어진다는 점임. 같은 가격에 하드웨어 성능이 10배 높고, 속도도 2배라서 풀 사이즈로 운영하는 게 더 합리적임. 시스템 전체가 안정적이고 관리가 쉬움
-
S3 요금 걱정도 안 해도 됨. 각 서버에 15TB NVMe 드라이브 넣고 MinIO/garage 클러스터 돌리면 됨. 우리는 10노드 클러스터에서 초당 20GiB, API콜 5만 건씩 처리 중임. S3였다면 API 콜만으로 초당 $20~$250 요금이라는 놀라운 차이가 있음
-
한 달 고정 요금만 나옴
-
그리고 저렴한 고속 스토리지, 대형 PostgreSQL 인스턴스 저비용 운영, 클라우드에서 느끼는 제약과 삽질이 확 줄어듦
-
만약 이런 구조에 투자해도 AWS 대비 10분의 1 비용임
-
만약 직접 관리가 부담된다면, 우리(https://lithus.eu)가 AWS 반값에 대신 관리해주고 DevOps까지 지원함. 연락은 adam@ 도메인 참조
-
기술적 배경: 베어메탈은 '가상화(VM)'가 아닌 직접적인 실서버에서 돌리는 방식임
-
나는 정말로, '장비만 늘리면 빨라진다', '비용은 별 의미 없다'라는 옛 시대를 넘어가길 바람. 내 경력 중 .NET 시절에 단일 캐비닛 서버로 수백만 유저까지 버텼던 경험이 있음. 그 후 클라우드 기반, 컨테이너, Node 마이크로서비스 쓰던 회사로 옮겼을 때, 청구서와 성능 문제의 혼돈을 매일 겪어서 아직도 가끔 오싹함을 느낌
-
변화란 늘 반복되는 것 같음. 우리 회사를 보면, 새 기술 없이 움직이지 않는 게 오히려 로컬 클라우드/엣지/사내 IDC 흐름의 최전선인 듯한 느낌이 듦
-
S3 API를 쓰면 양파 깎는 기분임. 계속 쓰다 보면 점점 더 눈물이 남
-
베어메탈로 하면 네트워크 관리, 보안 · 모니터링, 패치, 최신화 등을 위한 전담 인력을 둬야 함. 이런 전문 인건비는 일정 규모 이상에서만 효율적임. 그래서 중소기업이라면 여전히 클라우드가 보안과 운영비용 측면에서 이득임
-
AWS에서도 Lambda의 1 vCPU 할당 기준, 실제로는 50% 정도만 주고 있다는 점을 AWS가 스스로 문서로 밝히고 있음. 메모리·CPU 할당을 올릴수록 비율이 좋아지긴 해도, 100% 성능을 항상 주는 건 아님
-
-
예전부터 독립 서버를 쓰면 효율을 극대화할 수 있다고 생각했음. Hetzner에서 몇 노드 운영 중이고, 3년 된 구형 서버라도 경매로 빌려 쓰면 VM과는 차원이 다른 성능을 만날 수 있음. 서버 하드웨어들은 코어 수, IO 위주로 최적화되어있고, 대부분 클라우드가 하드웨어를 과할당해서 제공함. 심지어 디스크 IO도, NAS에 띄워놓고 로컬 디스크로 에뮬레이션하는 별별 꼼수를 씀. 대부분의 스타트업은 이런 과도한 가상화, NAS 기반의 디스크가 필요하지 않음. 오히려 Hetzner 같은 곳에서 서버 임대하면 훨씬 더 멀리, 더 저렴하게 나아갈 수 있음. 북미(특히 캐나다)에서 Hetzner급 가격·품질을 내는 업체가 궁금함. OVH는 알고 있으니, 혹시 유사한 다른 곳도 알려주면 좋겠음
-
많은 사람들이 Google·Facebook이 하는 기술 구조를 곧장 따라 해야 한다고 생각하는 것 같음. 우리는 유럽 VPS를 쓰며 소박하게 운영 중임. 그런데 신규 입사자(비즈니스, 개발 전부)는 매번 클라우드 이전 프로젝트를 시작해야 한다고 말함. 매번 "이미 우리도 클라우드 쓰고 있음, 네 이력서용 클라우드 이전 프로젝트는 하지 못하게 할 거임" 식으로 설득하게 됨
-
내가 실제로 클라우드와 베어메탈 서버 CPU 성능을 벤치마크한 기록이 있으니 참고해주면 좋겠음 https://jan.rychter.com/enblog/…
-
최근에 찾은 사이트가 도움이 될 수도 있음: https://vpspricetracker.com 컨셉이 매우 인상적임. 여기에 등록된 대부분의 업체가 독립 서버도 제공함
-
만약 '미국 내 Hetzner 품질이지만 현지 브랜드가 아니어도 된다'면, Hetzner 자체가 미국에도 2곳 데이터센터를 보유하고 있음
-
캐나다 기준 참고할 만한 업체로는 https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/ 등이 있음
-
-
우리도 같은 트렌드를 겪고 있음. 많은 팀들이 Hetzner로 이전하면서 저렴한 가격 대비 성능에 감탄하지만, Postgres 운영(백업, 장애조치, 모니터링 등)을 다시 다 구축해야 함을 깨달음. 그래서 직접 Hetzner 위에서 동작하는 관리형 Postgres를 만들었음. 동일한 하드웨어 최적화 구조에 고가용성(HA), 백업, 시점 복구(PITR)까지 챙김. 오픈소스이자 하드웨어 근처에서 뛰고, AWS에서 흔히 겪는 I/O 요금, 데이터 아웃바운드의 숨은 함정도 없음. 궁금하면 블로그 참고 바람 1, 2
-
이런 이유로 나는 Big Cloud, 특히 PaaS랑 관리형 SQL의 매력을 크게 느낌(내가 조언하는 개발팀도 마찬가지임). 운영 경험이 많지 않아도 데이터베이스 백업/복구, 패치, 접속 제한, 포트 관리, 이상 징후 탐지, DoS 공격 대응 등이 자동으로 처리되어 채택하는 게 마음이 편함. 정치적으로나 기술적으로나 인기 클라우드 기업을 쓰는 게 심적 안전망이 됨
-
자기 설정 버전, 자기 관리 Postgres로 이슈가 있다면 https://www.elephant-shed.io/ 참고할 만함
-
-
이런 종류 글이나 댓글들이 조언의 맥락을 거의 안 달고 이야기하는 게 재밌음. Spare time에 교회 소식지 하나 돌리는 건지, 전 세계 고객을 거느린 고도 트래픽 엔터프라이즈 SaaS인지에 따라 필요 조건 자체가 너무 다름. 본인 환경에 대한 설명 없이 가격, 성능, 가용성 조언은 사실상 무의미함. 웹 인프라가 과하게 복잡해진 이유도, 각기 다른 요구 사항을 가진 사람들의 조언을 서로 따라 하기 때문임
-
'요구가 다른데도 조언을 무비판적으로 따르는 건 현실을 더 복잡하게 만들 뿐'이라는 내 생각에 덧붙임. 어떤 기업은 클라우드 계정 매니저가 C레벨 임원의 점심에 끼어들면서 AWS 사용을 지시하게 만듦. 그 과정에서 AWS의 아키텍트가 우리 팀에 직접 파견되고, 자연스럽게 가장 비싼 서버리스 옵션들만 추천함. 그렇지만 실상은 결국 매번 도커 OS 이미지를 새로 배포하고, 일반 베어메탈 서버의 패치와 동일하게 끊임없이 관리해야 됨
-
내 개인 Pastebin조차 베어메탈이 아니면 버티지 못하는 상황임(농담)
-
이게 IT 업계 모습의 전형적인 사례임
-
요구 조건·기술 수준·비용 구조·문제 영역이 완전히 다름. Hetzner랑 AWS는 표면적으로 클라우드 비슷하지만 실제론 완전히 다른 서비스임. 둘 다 써본 경험자로서 하는 말임
-
격하게 동의함. 내 의견을 블로그로도 남겼으니 참고 바람 https://news.ycombinator.com/item?id=45616366 요약하면 "호스팅 업체를 DIY~엔터프라이즈까지 가격표로 이해하고, 안 쓰는 게 이득(YAGNI)이면 굳이 선택 말 것"임
-
-
나는 10년 넘게 SaaS를 Hetzner 위에 올려 운영 중임. 완전 독립 하드웨어, 독일·핀란드 데이터센터에 클러스터 구성, ansible로 관리함. 서버 간 VPN 연결에는 vpncloud를 씀(이 소프트웨어 정말 훌륭함). 월간 호스팅 요금은 AWS 등 대비 극히 적고, 서버 속도는 훨씬 빠름. 단순한 구조와 소수 서버로 충분히 버팀. 필요 시 서버만 추가하면 되는데, 베어메탈이라 수분 내 확장되는 방식은 아님. 몇 시간/며칠 정도 미리 계획하면 됨. 데이터베이스는 RethinkDB(이제 FoundationDB로 전환 예정) 분산 구조로 장애에 대비함
-
나도 rethinkdb 조합으로 비슷하게 운영 중임. 그런데 굳이 FoundationDB를 선택한 이유가 궁금함. RethinkDB는 아직도 유지보수 중이고, 가끔씩 신기능도 추가됨. 생각보다 Slack 커뮤니티에 유저들이 살아있음
-
RethinkDB를 아직 쓰는 사람이 있다는 게 반갑게 느껴짐
-
Hetzner DE/ FI 센터간 vpncloud로 직접 연결함? Hetzner도 자체적으로 저렴하게 그런 기능을 제공하는 줄 알았음
-
-
최근 AWS에서 Hetzner(및 Netcup)로 넘어가는 팀들을 많이 지원했는데, 사람들에게 가장 큰 놀라움은 비용이나 성능 그 자체가 아니라, 15겹의 관리 추상화(서비스) 계층을 걷어냈을 때 구조가 확 단순해지는 것임. S3/EFS/FSx 고민, Lambda 콜드스타트, EBS 버스트 크레딧 등 걱정이 사라짐. 그냥 빠른 NVMe에 Docker를 배포하면 바로 동작함. 단, DevOps 역량(모니터링, 백업, 패치 등)이 조금 더 필요해짐. 그렇지만 이런 운용 작업들은 자동화하면 매주 바뀌는 일이 아님. Elestio에서는 이 단순화에 집중해서, 400여 개 오픈소스 소프트웨어의 완전 관리형 스택을 어떤 클라우드에서도 제공함(CI/CD도 포함). Hetzner 등 어디에서든 production까지 커버함 https://elest.io (참고: 나는 Elestio에서 일하며 Multi-Cloud 오픈소스 서비스를 제공함)
- 네 Postgres 관리형 서비스가 궁금함. 스트리밍 리플리카와 스트리밍 백업을 지원하는지, 아니면 s3에 dump만 저장하는지 알고 싶음
-
경력 초창기에 엄청 좋은 회사를 다녔는데, 그때 RDS에서 지원 안 하던 Postgres 버전이 필요해서 EC2에 직접 Postgres 여러 번 셋업해야 했음. Docker도 없던 시절이라 세팅하는 데 갈수록 시간 낭비만 쌓였음. RDS가 해당 버전을 지원하자마자 모든 게 확 쉬워졌음. 새벽 3시까지 Postgres 설치 반복하던 기억이 아직도 생생함. 이 글이 좋긴 한데, 결국 한 달에 몇백 달러 아끼는 정도임. 엔지니어 한 명이 월 1시간만 관리해도 절감액이 상쇄될 수 있음. 갑자기 장애라도 생기면 1년치 절감액이 하루만에 날아갈 수도 있음. 시간 가치가 중요하지 않은 개인 프로젝트(대용량 서버가 필요한 경우)라면 베어메탈 운영이 나을 수 있음. 하지만 결국엔 내 시간의 가치가 더 높아지게 됨. 예컨대 Ghost 블로그를 공식 호스팅 쓰면 월 $10면 되는데, Hetzner 인스턴스에 여러 개 띄울 수도 있음. 하지만 결국 뭔가 고장이 나면 2~3시간을 고치느니 $20 더 내는 게 나을까 생각하게 됨
-
Hetzner의 (일부) 독립 서버 최고 장점은 무제한 대역폭임. 나는 이미지 위주 사이트를 호스팅 중인데, Hetzner로 이전한 후부터 3년째 고정 요금만 내고 밤에 안심하고 잠드는 경험을 하고 있음
-
Hetzner는 규모 확장에는 한계가 분명히 있음. 우리도 초기에 Hetzner 기반으로 수백 개의 VM을 돌렸고, 피크 때는 천 개 이상으로 확장해야 했음. 그런데 이때 문제들이 발생함: 블랙리스트에 오른 IP가 종종 할당되어 AWS, Google(특히 S3) 연결에 곤란을 겪음. 심지어 어느 순간에는 우리 지역에 VM이 더 이상 남지 않아 신규 할당 자체가 중단됨. 결국, 대규모 확장이 필요하지 않다면 Hetzner는 훌륭하지만, 정말 확장이 요구될 때는 타 서비스를 혼합 써야 했음
-
지역에서 VM이 완전히 할당 소진된 것은 특정 클라우드만의 문제는 아닌 것 같음. GCP도 몇 년 전만 해도 비슷했음. 피크 시간에 수백 대 VM을 단번에 요청하면 어떤 클라우드도 버거워하는 것 같음
-
Microsoft가 Hetzner·Scaleway 서비스를 막은 일은 잘 알려져 있음 https://linkedin.com/posts/…. AWS, GCP도 그랬다는 건 몰랐지만 크게 놀랍지도 않음. 빅클라우드는 '스팸 유입' 핑계로 이런 반경쟁 행위를 정당화하는데, 실제로는 그렇지 않음
-
여기서 말하는 게 Hetzner 실제 하드웨어(Server Auction 등) 사용자와 가상서버(VM) 사용자 간 이야기 차이일 수 있음. 실제 물리 서버는 가성비나 속도가 훨씬 뛰어나고, VM이 혁신적이지는 않아도 여전히 경쟁사보다 저렴함
-
이 논란은 Hetzner Cloud 상품(VM)에 대한 이야기임. Cloud 상품은 독립 서버에 비해 비교적 최근 출시됨. 많은 유저는 독립 서버의 가치 때문에 Hetzner를 찾는 경우가 더 많음
-
정말 궁금한데, 어떤 서비스면 수백~수천 VM이 필요하길래 그렇게 썼는지, 그리고 독립 서버 대신 VM을 쓴 이유가 뭔지 알고 싶음. Hetzner의 최대 사양 VM이 (48코어, 192GB RAM, 960GB SSD)라는데, 그 정도 스펙이 필요하다니 궁금함
-
-
Hetzner를 쓰는 이유가 있지만, 몇 가지 유의점이 있음. AWS보다 가용성이 다소 떨어지며, 리전 다양성도 부족함. 그래서 꼭 Cloudflare와 함께 쓰길 권장함. Hetzner에서는 코어 시스템(K8s) 운영, 데이터는 R2/D1/KV, Edge Durable Objects로 분산 처리함. 고객 데이터를 각 DO별로 Shard해서 핵심 데이터베이스의 부하 분산 및 보안 효과를 동시에 얻음
-
AWS도 의외로 대규모 장애가 꽤 있었음. 결국 멀티 리전 설계가 아니면 가용성 문제는 구조적으로 피하기 어려움이 있음
-
나도 Hetzner에 독립 서버로 코어, 스토리지 이중화하고 OVH에 전 세계 엣지 노드 추가해서 나만의 CDN처럼 쓰는 방식으로 설계했음
-
고객 데이터가 엣지이면, 그럼 '핵심'은 구체적으로 무엇에 해당하는지 궁금함
-