Migrasi dari AWS ke Hetzner memangkas biaya cloud 76%

 (digitalsociety.coop)
9 poin oleh GN⁺ 2025-10-18 | 1 komentar | Bagikan ke WhatsApp
  • Dengan bermigrasi dari AWS dan DigitalOcean ke Hetzner, biaya cloud berhasil dipangkas 76% dan kapasitas resource meningkat 3 kali lipat
  • Sebelumnya, dua layanan cloud digunakan secara paralel dengan mengandalkan stabilitas AWS dan kemudahan DigitalOcean
  • Setelah kredit gratis habis, beban biaya operasional lebih dari $449 per bulan muncul, sehingga mulai dicari alternatif seperti Hetzner
  • Untuk menekan biaya, dibangun stack cloud self-managed yang menggabungkan Kubernetes berbasis Talos Linux, CloudNativePG, Ingress NGINX, ExternalDNS, cert-manager, dan lainnya
  • Dengan memanfaatkan server ARM shared vCPU dan storage kompatibel S3 dari Hetzner, ekspansi resource skala besar tercapai sambil tetap menjaga performa dan stabilitas
  • Kemudahan pengelolaan memang sedikit menurun, tetapi sebagai cloud alternatif di Eropa, efisiensi biaya-performa yang ditawarkan sangat unggul

Latar belakang

  • Semua software yang dikembangkan di DigitalSociety berjalan di atas infrastruktur berbasis cloud
  • Sebelum migrasi, infrastruktur utama dijalankan di dua sisi: AWS (mengelola layanan utama, autentikasi, email, dan lainnya) serta DigitalOcean (layanan ringan, monitoring, dan Kubernetes)
  • AWS dipilih karena sudah familier digunakan selama lebih dari 15 tahun dan memiliki stabilitas API yang tinggi
  • DigitalOcean dipilih berkat lingkungan Kubernetes yang sederhana, control plane gratis, dan efisiensi biaya
  • Awalnya hanya menggunakan DigitalOcean, tetapi untuk SaaS padat data seperti tap dibutuhkan resource yang lebih besar dan kredit tambahan, sehingga memanfaatkan kredit startup AWS ($1,000)

Kredit habis dan beban biaya

  • Berkat Fargate dari AWS (serverless container runtime), infrastruktur awal bisa dibangun dengan murah, tetapi karena karakter layanan tap yang padat data, dibutuhkan minimal 2x CPU dan 4 GiB RAM untuk menjaga performa
  • Dengan acuan Fargate, container dengan spesifikasi tersebut menelan biaya lebih dari $70 per bulan, dan jika ditotal bersama dua instance worker serta infrastruktur lainnya, biayanya naik hingga $449.50 per bulan
  • Kredit gratis yang diberikan habis bahkan sebelum 6 bulan, dan bagi startup bootstrap hal ini menjadi beban biaya tetap yang serius

Proses mencari alternatif

  • Untuk menurunkan biaya operasional yang tinggi sekaligus memperoleh kemandirian teknologi, dicari penyedia cloud berbasis UK/EU
  • Tertarik pada daya saing harga Hetzner, diputuskan untuk bermigrasi dari AWS dan DigitalOcean meskipun harus menghadapi lingkungan VPS self-managed dan kompleksitas operasional yang lebih tinggi
  • Karena sebagian besar layanan sudah dijalankan di atas Kubernetes, berkat kemudahan pembentukan cluster dari Talos Linux, cluster Kubernetes mandiri juga dibangun di lingkungan Hetzner
  • Meski tidak ada layanan managed DB seperti di AWS atau DigitalOcean, CloudNativePG memungkinkan cluster PostgreSQL dikelola dan diintegrasikan dengan aman di lingkungan Kubernetes, termasuk monitoring, backup, dan penanganan gangguan

Stack infrastruktur baru

  • Hetzner: memanfaatkan server ARM, block storage, load balancer, network, firewall, dan object storage kompatibel S3
  • Talos Linux: mewujudkan otomatisasi operasional melalui pengelolaan node Kubernetes dengan konfigurasi deklaratif
  • CloudNativePG: mendeklarasikan cluster DB dalam manifest Kubernetes serta mendukung backup otomatis dan penanganan gangguan secara terintegrasi
  • Ingress NGINX Controller: mengelola routing HTTP di dalam cluster secara terpusat
  • ExternalDNS: menghubungkan resource ingress dengan DNS secara otomatis
  • cert-manager: menerbitkan sertifikat TLS untuk HTTPS secara otomatis
  • Seluruh infrastruktur dikodekan dengan Terraform dan Helm, lalu diwujudkan DevOps melalui deployment otomatis menggunakan GitHub Actions

Perbandingan biaya

  • Biaya bulanan sebelum migrasi: AWS + DigitalOcean = $559.36
  • Biaya bulanan setelah migrasi: Hetzner = $132.96 (−76%)
  • Peningkatan resource:
    • CPU: 12 vCPU → 44 vCPU (+367%)
    • RAM: 24 GiB → 88 GiB (+367%)
    • Meski resource meningkat, total biaya bulanan tetap jauh lebih murah

Tantangan dan trial-and-error dalam proses migrasi

  • Network zone Hetzner tidak sepenuhnya sama dengan Availability Zone di AWS
    • AWS memiliki beberapa Availability Zone dalam satu region, dan private networking terhubung luas pada tingkat region
    • Hetzner memiliki beberapa location di bawah satu network zone (eu-central), dan latency jaringan antar location cukup besar
    • Dalam praktiknya, saat beban disebar ke beberapa location, monitoring menunjukkan munculnya masalah seperti penurunan performa
    • Sebagai alternatif, ketahanan terhadap gangguan diamankan dengan memanfaatkan Placement Group dalam satu location saja (Nuremberg) untuk menyebarkan server fisik
  • Meski layanan berbasis container, portabilitasnya tidak selalu sederhana
    • Saat memindahkan lingkungan dari AWS ECS ke Kubernetes, pekerjaan revisi skrip otomatisasi untuk keseluruhan konfigurasi, terutama distribusi file config, memakan waktu lebih lama dari perkiraan
    • Pada akhirnya, integrasi konfigurasi sensitif dan sistem pengelolaan file config diperbaiki menggunakan Kustomize, sehingga keterlacakan dan kemudahan review meningkat

Kesimpulan

  • Hetzner memang bukan layanan managed yang mudah, tetapi sangat efisien bagi tim yang mampu melakukan self-management
  • Dengan operasi mandiri, kontrol atas detail konfigurasi dapat diamankan sekaligus memaksimalkan performa per biaya
  • Pendekatan ini menjadi fondasi untuk terus mengembangkan dan mengoperasikan SaaS padat data seperti tap dengan biaya yang masuk akal dan performa yang stabil

Bacaan terkait

1 komentar

 
GN⁺ 2025-10-18
Opini Hacker News

  • Saya benar-benar ingin menekankan betapa besar peningkatan performa yang terasa saat deploy langsung ke bare metal. Untuk layanan kami, performanya naik 2x dan menunjukkan kinerja yang stabil serta dapat diprediksi. Alasannya ada beberapa:

    • Latensi rendah: jika jaringan dikelola langsung, kita tidak perlu berbagi jaringan kompleks di data center skala besar, sehingga latensi bisa turun lebih dari 10x

    • Optimasi cache: deployment yang dioptimalkan untuk hardware memungkinkan kita benar-benar memanfaatkan performa CPU modern

    • Penggunaan NVMe dedicated: kecepatan disk IO sangat tinggi

    • Keuntungan lain adalah autoscaler nyaris tidak lagi diperlukan. Dengan harga yang sama, performa hardware 10x lebih tinggi dan kecepatannya 2x, jadi lebih masuk akal menjalankan sistem dalam ukuran penuh. Seluruh sistem jadi stabil dan lebih mudah dikelola

    • Tidak perlu khawatir soal biaya S3 juga. Cukup pasang drive NVMe 15TB di tiap server dan jalankan cluster MinIO/garage. Kami menjalankan cluster 10 node dengan throughput 20GiB per detik dan 50 ribu API call per detik. Jika pakai S3, hanya untuk API call saja biayanya bisa $20~$250 per detik, perbedaan yang mencengangkan

    • Biayanya hanya tagihan tetap bulanan

    • Ditambah lagi storage cepat yang murah, menjalankan instance PostgreSQL besar dengan biaya rendah, dan jauh lebih sedikit batasan serta kerepotan yang biasa terasa di cloud

    • Bahkan kalau berinvestasi pada arsitektur seperti ini pun, biayanya tetap hanya sepersepuluh dibanding AWS

    • Kalau mengelola sendiri terasa membebani, kami (https://lithus.eu) bisa mengelolanya dengan biaya setengah AWS sekaligus mendukung DevOps. Kontak lihat domain adam@

    • Latar belakang teknis: bare metal adalah cara menjalankan langsung di server fisik, bukan lewat 'virtualisasi (VM)'

    • Saya sungguh berharap kita bisa melampaui era lama pemikiran seperti 'tinggal tambah mesin maka akan lebih cepat' dan 'biaya tidak terlalu penting'. Dalam karier saya, pada era .NET saya pernah menopang jutaan pengguna dengan server satu kabinet saja. Setelah itu saya pindah ke perusahaan yang memakai cloud, container, dan microservice Node, dan setiap hari saya menghadapi kekacauan tagihan serta masalah performa yang kadang masih membuat saya merinding sampai sekarang

    • Rasanya perubahan memang selalu berulang. Melihat perusahaan kami, justru tidak bergerak tanpa teknologi baru terasa seperti berada di garis depan arus local cloud/edge/IDC internal

    • Menggunakan API S3 itu rasanya seperti mengupas bawang. Semakin lama dipakai, semakin banyak air mata yang keluar

    • Dengan bare metal, perlu orang khusus untuk mengelola jaringan, keamanan · monitoring, patch, pembaruan, dan sebagainya. Biaya tenaga ahli seperti ini baru efisien di skala tertentu. Jadi untuk UKM, cloud tetap lebih menguntungkan dari sisi keamanan dan biaya operasional

    • Bahkan di AWS, untuk alokasi 1 vCPU pada Lambda, AWS sendiri menyatakan dalam dokumentasinya bahwa yang diberikan secara nyata hanya sekitar 50%. Meskipun rasio itu membaik saat alokasi memori·CPU ditingkatkan, tetap tidak selalu memberikan 100% performa

  • Sejak lama saya berpikir bahwa memakai server dedicated bisa memaksimalkan efisiensi. Saya menjalankan beberapa node di Hetzner, dan bahkan server lama berusia 3 tahun pun, jika disewa lewat lelang, bisa memberikan performa yang sama sekali berbeda dibanding VM. Hardware server dioptimalkan untuk jumlah core dan IO, sementara kebanyakan cloud memberi layanan dengan overcommit hardware. Bahkan untuk disk IO pun, mereka memakai berbagai trik aneh seperti menjalankannya di NAS lalu mengemulasikannya sebagai disk lokal. Sebagian besar startup tidak membutuhkan virtualisasi berlebihan seperti ini maupun disk berbasis NAS. Justru dengan menyewa server di tempat seperti Hetzner, kita bisa melangkah jauh lebih jauh dengan biaya lebih rendah. Saya penasaran penyedia di Amerika Utara, khususnya Kanada, yang bisa memberi harga·kualitas setara Hetzner. Saya tahu OVH, jadi kalau ada alternatif serupa lain, saya ingin mengetahuinya

    • Banyak orang tampaknya berpikir mereka harus langsung meniru struktur teknis yang dipakai Google·Facebook. Kami menjalankan layanan kecil dengan VPS Eropa. Namun setiap karyawan baru (baik bisnis maupun developer) selalu bilang kita harus memulai proyek migrasi ke cloud. Setiap kali saya harus meyakinkan mereka dengan gaya, "kita juga sudah memakai cloud, dan saya tidak akan membiarkan ada proyek migrasi cloud hanya untuk mempercantik CV-mu"

    • Saya punya catatan benchmark nyata tentang performa CPU server cloud dan bare metal, mungkin bisa jadi referensi https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12

    • Situs yang saya temukan baru-baru ini mungkin juga membantu: https://vpspricetracker.com konsepnya sangat mengesankan. Sebagian besar penyedia yang terdaftar di sana juga menawarkan server dedicated

    • Jika yang dimaksud adalah 'kualitas Hetzner di AS meski bukan brand lokal', Hetzner sendiri juga memiliki 2 data center di Amerika Serikat

    • Untuk referensi di Kanada, ada penyedia seperti https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/

  • Kami juga mengalami tren yang sama. Banyak tim pindah ke Hetzner dan kagum pada price/performance-nya, tetapi kemudian sadar bahwa mereka harus membangun ulang sendiri operasional Postgres seperti backup, failover, monitoring, dan sebagainya. Karena itu kami membuat managed Postgres yang berjalan langsung di atas Hetzner. Tetap memakai struktur optimasi hardware yang sama, tetapi juga mencakup high availability (HA), backup, dan point-in-time recovery (PITR). Open source, berjalan dekat dengan hardware, dan tidak memiliki jebakan biaya tersembunyi seperti ongkos I/O atau data outbound yang umum di AWS. Jika penasaran, lihat blog 1, 2

    • Karena alasan seperti inilah saya sangat merasakan daya tarik Big Cloud, terutama PaaS dan managed SQL (demikian juga tim developer yang saya beri nasihat). Meski pengalaman operasional tidak banyak, backup/recovery database, patch, pembatasan akses, pengelolaan port, deteksi anomali, dan penanganan serangan DoS bisa ditangani otomatis, sehingga rasanya lebih tenang untuk diadopsi. Secara politis maupun teknis, memakai perusahaan cloud besar yang populer juga menjadi semacam jaring pengaman psikologis

    • Jika ada masalah dengan versi yang Anda konfigurasi dan kelola sendiri untuk Postgres, https://www.elephant-shed.io/ layak dilihat

  • Menarik melihat bagaimana tulisan atau komentar seperti ini hampir tidak pernah memberi konteks pada nasihatnya. Menjalankan satu buletin gereja di waktu luang jelas sangat berbeda dengan enterprise SaaS bertrafik tinggi yang melayani pelanggan di seluruh dunia. Tanpa penjelasan tentang lingkungan masing-masing, nasihat soal harga, performa, dan availability pada dasarnya tidak banyak artinya. Salah satu alasan infrastruktur web menjadi terlalu kompleks adalah karena orang dengan kebutuhan yang sangat berbeda saling meniru nasihat satu sama lain

    • Saya ingin menambahkan pada pendapat saya bahwa 'mengikuti nasihat secara tidak kritis meski kebutuhannya berbeda hanya akan membuat kenyataan semakin kompleks'. Ada perusahaan di mana account manager cloud sampai ikut makan siang dengan eksekutif C-level lalu mendorong penggunaan AWS. Dalam proses itu, arsitek dari AWS dikirim langsung ke tim kami, dan secara alami yang direkomendasikan hanya opsi serverless paling mahal. Namun kenyataannya, pada akhirnya kami tetap harus terus-menerus me-deploy ulang image OS Docker, sama seperti patching server bare metal biasa

    • Bahkan Pastebin pribadi saya pun tidak akan bertahan jika bukan di bare metal (bercanda)

    • Ini contoh yang sangat khas dari wajah industri TI

    • Syarat kebutuhan, tingkat teknis, struktur biaya, dan domain masalahnya benar-benar berbeda. Hetzner dan AWS sekilas sama-sama tampak seperti cloud, tetapi pada praktiknya adalah layanan yang sama sekali berbeda. Saya mengatakan ini sebagai orang yang pernah memakai keduanya

    • Sangat setuju. Saya juga menuliskan pendapat saya di blog, silakan lihat https://news.ycombinator.com/item?id=45616366 ringkasnya: "pahami penyedia hosting sebagai spektrum harga dari DIY sampai enterprise, dan jika tidak memakainya justru lebih baik (YAGNI), jangan dipilih"

  • Saya sudah lebih dari 10 tahun menjalankan SaaS di atas Hetzner. Hardware sepenuhnya dedicated, cluster dibangun di data center Jerman·Finlandia, dan dikelola dengan ansible. Untuk koneksi VPN antarserver saya memakai vpncloud (software ini benar-benar luar biasa). Biaya hosting bulanan sangat kecil dibanding AWS dan sejenisnya, sementara kecepatan server jauh lebih tinggi. Struktur yang sederhana dan jumlah server yang sedikit sudah cukup menopang semuanya. Jika perlu, tinggal tambah server, meski karena ini bare metal, skalanya bukan model bertambah dalam hitungan menit. Biasanya cukup direncanakan beberapa jam/hari sebelumnya. Untuk database, saya memakai struktur terdistribusi RethinkDB (dan berencana berpindah ke FoundationDB) agar tahan terhadap gangguan

    • Saya juga menjalankan setup yang mirip dengan kombinasi rethinkdb. Tapi saya penasaran kenapa Anda memilih FoundationDB. RethinkDB masih dipelihara dan sesekali bahkan mendapat fitur baru. Komunitas penggunanya ternyata masih cukup hidup di Slack

    • Senang rasanya mengetahui masih ada yang memakai RethinkDB

    • Apakah Anda menghubungkan langsung pusat Hetzner DE/FI dengan vpncloud? Saya kira Hetzner sendiri juga menyediakan fungsi seperti itu dengan harga murah

  • Belakangan ini saya banyak membantu tim yang pindah dari AWS ke Hetzner (dan Netcup), dan kejutan terbesar bagi mereka bukan biaya atau performa itu sendiri, melainkan betapa sederhananya arsitektur ketika 15 lapis abstraksi manajemen (layanan) disingkirkan. Tidak perlu lagi memikirkan S3/EFS/FSx, Lambda cold start, atau burst credit EBS. Tinggal deploy Docker ke NVMe yang cepat dan langsung berjalan. Memang dibutuhkan sedikit lebih banyak kemampuan DevOps seperti monitoring, backup, patch, dan sebagainya. Namun pekerjaan operasional seperti ini, jika sudah diotomatisasi, bukan hal yang berubah setiap minggu. Di Elestio kami fokus pada penyederhanaan ini dan menyediakan stack managed penuh untuk sekitar 400 software open source di cloud mana pun (termasuk CI/CD). Bisa dipakai sampai production di mana pun, termasuk Hetzner https://elest.io (catatan: saya bekerja di Elestio dan menyediakan layanan open source multi-cloud)

    • Saya penasaran dengan layanan managed Postgres Anda. Apakah mendukung streaming replica dan streaming backup, atau hanya menyimpan dump ke s3?

  • Di awal karier saya, saya pernah bekerja di perusahaan yang sangat bagus, tetapi saat itu kami membutuhkan versi Postgres yang belum didukung RDS, jadi saya harus berkali-kali menyiapkan Postgres langsung di EC2. Itu zaman sebelum Docker, jadi semakin lama semuanya terasa seperti penumpukan pemborosan waktu. Begitu RDS mendukung versi tersebut, semuanya langsung jadi jauh lebih mudah. Saya masih ingat jelas masa-masa memasang Postgres berulang kali sampai jam 3 pagi. Tulisan ini bagus, tetapi pada akhirnya penghematannya cuma beberapa ratus dolar per bulan. Kalau satu engineer saja harus mengelolanya 1 jam per bulan, penghematan itu bisa habis. Kalau tiba-tiba terjadi gangguan, penghematan setahun pun bisa lenyap dalam satu hari. Untuk proyek pribadi yang nilai waktunya tidak terlalu penting (apalagi jika memang butuh server besar), mengoperasikan bare metal bisa lebih baik. Tapi pada akhirnya nilai waktu saya sendiri menjadi lebih tinggi. Misalnya, hosting resmi Ghost hanya $10 per bulan, dan memang kita bisa menjalankan beberapa instance di Hetzner. Tetapi saat sesuatu rusak, saya jadi berpikir apakah lebih baik membayar $20 ekstra daripada menghabiskan 2~3 jam untuk memperbaikinya

  • Keunggulan terbesar server dedicated Hetzner (untuk sebagian penawarannya) adalah bandwidth tak terbatas. Saya meng-host situs yang didominasi gambar, dan setelah pindah ke Hetzner saya sudah 3 tahun membayar tarif tetap dan bisa tidur nyenyak di malam hari

  • Hetzner jelas punya batas dalam hal scale-out. Kami juga sempat menjalankan ratusan VM di atas Hetzner pada tahap awal, dan saat puncaknya kami perlu scale sampai lebih dari seribu. Di situ masalah mulai muncul: kadang kami diberi IP yang masuk blacklist, sehingga koneksi ke AWS dan Google (terutama S3) jadi bermasalah. Bahkan ada titik ketika di region kami sudah tidak ada VM tersisa, jadi provisioning baru benar-benar berhenti. Pada akhirnya, Hetzner sangat bagus kalau tidak butuh ekspansi besar-besaran, tetapi ketika scale sungguh dibutuhkan, kami harus mencampurnya dengan layanan lain

    • VM di suatu region bisa habis total rasanya bukan masalah yang unik pada satu cloud tertentu. GCP beberapa tahun lalu juga mirip. Kalau meminta ratusan VM sekaligus pada jam sibuk, sepertinya cloud mana pun akan kesulitan

    • Sudah cukup dikenal bahwa Microsoft pernah memblokir layanan Hetzner·Scaleway https://www.linkedin.com/posts/jeroen-jacobs-8209391_something-interesting-happened-today-it-activity-7382774062164516864-GSKT/. Saya tidak tahu bahwa AWS dan GCP juga begitu, tetapi juga tidak terlalu mengejutkan. Big cloud membenarkan perilaku anti-persaingan seperti ini dengan alasan 'arus spam masuk', padahal kenyataannya tidak sesederhana itu

    • Yang dibicarakan di sini mungkin perbedaan pengalaman antara pengguna hardware Hetzner yang sebenarnya (seperti Server Auction) dan pengguna server virtual (VM). Server fisik nyata jauh lebih unggul dari sisi price/performance maupun kecepatan, sementara VM mereka meski tidak revolusioner tetap lebih murah daripada banyak pesaing

    • Kontroversi ini terkait produk Hetzner Cloud (VM). Produk cloud itu hadir relatif belakangan dibanding server dedicated mereka. Banyak pengguna datang ke Hetzner justru karena nilai server dedicated-nya

    • Saya benar-benar penasaran, layanan seperti apa yang sampai membutuhkan ratusan hingga ribuan VM, dan kenapa memilih VM alih-alih server dedicated. Katanya VM spesifikasi tertinggi Hetzner itu (48 core, 192GB RAM, 960GB SSD), jadi menarik juga kalau sampai butuh skala seperti itu

  • Ada alasan untuk memakai Hetzner, tetapi ada beberapa hal yang perlu diperhatikan. Availability-nya sedikit di bawah AWS, dan keragaman region juga kurang. Karena itu saya sangat menyarankan dipadukan dengan Cloudflare. Di Hetzner saya menjalankan sistem inti (K8s), lalu data saya taruh di R2/D1/KV dan didistribusikan lewat Edge Durable Objects. Data pelanggan saya-shard per DO, sehingga beban pada database inti tersebar sekaligus memberi efek keamanan tambahan

    • AWS juga ternyata beberapa kali mengalami outage besar. Pada akhirnya, tanpa desain multi-region, masalah availability memang secara struktural sulit dihindari

    • Saya juga mendesain sistem dengan core dan redundansi storage di server dedicated Hetzner, lalu menambahkan edge node global di OVH untuk dipakai seperti CDN pribadi

    • Kalau data pelanggan ada di edge, lalu yang dimaksud 'inti' itu tepatnya apa?