2 tahun setelah pindah dari AWS ke bare metal: menjawab pertanyaan tentang keluar dari AWS

 (oneuptime.com)
16 poin oleh GN⁺ 2025-10-30 | 3 komentar | Bagikan ke WhatsApp
  • Setelah membagikan pengalaman bermigrasi dari AWS ke bare metal dan menghemat $230.000 per tahun 2 tahun lalu, ini adalah laporan yang merangkum jawaban lanjutan atas berbagai pertanyaan dari komunitas. Mereka mempublikasikan data operasional nyata selama 2 tahun dan menyatakan telah mencapai penghematan tahunan lebih dari $1,2 juta
  • Melalui operasi produksi nyata, nilai penghematan meningkat menjadi lebih dari $1,2 juta per tahun, dan dana tersebut diinvestasikan kembali ke server untuk ringkasan insiden berbasis AI dan perbaikan kode otomatis, yang berujung pada peningkatan kualitas layanan
  • Berdasarkan stack MicroK8s + Ceph, mereka mempertahankan ketersediaan 99,993% dan menghilangkan single point of failure dengan konfigurasi dua data center
  • Berbagai isu utama seperti biaya operasional nyata, respons insiden, umur hardware, sertifikasi keamanan, dan layanan pengganti cloud dijelaskan dengan angka yang konkret
  • Hasilnya, stabilitas dan efisiensi biaya sama-sama meningkat, dan mereka menyimpulkan bahwa untuk sistem dengan beban tetap pada skala tertentu, bare metal lebih rasional

Ringkasan hasil operasional selama 2 tahun

  • Selama 24 bulan, mereka menjalankan stack MicroK8s + Ceph di lingkungan production dan mencapai ketersediaan 99,993%
    • Untuk mengatasi masalah satu rak tunggal, mereka menambahkan rak kedua di Frankfurt dan membangun koneksi ganda DWDM dengan rak utama di Paris
    • Dengan NVMe lokal dan penghilangan interferensi noisy neighbor, latensi pelanggan berkurang 19%
  • Biaya yang dihemat diinvestasikan kembali untuk membeli server AI bare metal, memperluas fitur ringkasan alert berbasis LLM dan perbaikan kode otomatis milik OneUptime

Efek penghematan dan perbandingan biaya

  • Estimasi penghematan awal adalah $230.000 per tahun, tetapi kini meningkat menjadi lebih dari $1,2 juta
    • Ini setara dengan sekitar 76% penghematan dibanding AWS
    • Berdasarkan biaya tenaga kerja global, nilainya setara dengan gaji tahunan 2 hingga 5 engineer
  • Bahkan jika menerapkan Savings Plans / Reserved Instances, Bare Metal tetap lebih unggul
    • Savings Plans tidak berlaku untuk biaya S3, egress, dan Direct Connect
    • Biaya control plane EKS $1.260/bulan dan NAT gateway $600/bulan juga tidak bisa dihemat
    • Untuk workload steady yang berjalan 24/7, efektivitas reserved instance terbatas
Iklan

Migrasi dan biaya operasional

  • Migrasi awal selesai dengan sekitar 1 minggu kerja engineering
    • Sebagian besar adalah pekerjaan yang memang sudah diperlukan sebelumnya, seperti perapihan IaC dan penguatan kebijakan backup
  • Biaya operasional saat ini adalah sebagai berikut:
    • Dikelola langsung: sekitar 24 jam per kuartal (termasuk patch dan update firmware)
    • Remote Hands: hanya perlu intervensi 2 kali selama 24 bulan (terutama masalah disk), dengan waktu respons rata-rata 27 menit
    • Otomatisasi: boot PXE (Tinkerbell), manajemen image Talos, otomatisasi konfigurasi Flux/Terraform
  • Dibanding masa masih menggunakan AWS, tim operasional justru mengalami peningkatan kecepatan rilis, dan beban “rapat optimasi biaya” juga hilang

Kesiapan menghadapi gangguan dan menjaga ketersediaan

  • Dengan menambahkan rak kedua di Frankfurt dan koneksi dual-path DWDM, mereka menghilangkan single point of failure
    • Mereka membangun mirroring Ceph berbasis replikasi asinkron dan dual control plane
    • Dengan tambahan jalur manajemen berbasis 4G/satelit, akses jarak jauh tetap tersedia saat terjadi gangguan jaringan
  • Sedang dalam proses transisi dari MicroK8s ke Talos
  • Cluster backup failover di AWS masih dipertahankan, dan simulasi pemulihan bencana per kuartal tetap dilakukan
  • Dengan ingress berbasis Anycast+BGP, keterlambatan perpindahan DNS juga membaik menjadi kurang dari 1 menit
  • Selama 2 tahun, mereka mempertahankan ketersediaan 99,993% dan juga tidak terdampak gangguan region AWS terbaru

Hardware dan pengelolaan CapEx

  • Server dioperasikan dengan acuan depresiasi 5 tahun (2×EPYC 9654, RAM 1TB, konfigurasi NVMe)
    • Saat performa mulai jenuh, server dipindahkan ke cluster analitik lalu diganti dengan server baru
    • Berkat penghematan yang didapat, kini mereka bisa melakukan refresh 40% setiap 2 tahun, namun tetap menghemat biaya tahunan dibanding AWS
  • Mereka juga memiliki perpanjangan garansi Supermicro + 3 server cadangan
    • Umur pakai sebenarnya 7–8 tahun, tetapi dihitung konservatif sebagai 5 tahun
    Iklan

Logika pengganti managed service

  • Filosofi produk OneUptime adalah harus bisa self-hosted, sehingga stack yang sama perlu dipertahankan
    • Mereka menjaga konsistensi open stack seperti Kubernetes, Postgres, Redis, dan ClickHouse
  • Evolusi dari Terraform + EKS + RDS → MicroK8s + Argo Rollouts + Ceph
    • Menggunakan open source murni tanpa fork internal
  • Mereka juga masih tetap menggunakan cloud secara paralel: AWS Glacier (backup), CloudFront (edge caching), dan instance sementara untuk load test
  • Cloud cocok untuk elastisitas, sedangkan bare metal cocok untuk beban dasar

Jaringan dan keamanan

  • Mereka mengamankan 2 jalur 5Gbps (95th percentile), dengan biaya 8 kali lebih murah dibanding egress AWS
  • Pertahanan DDoS ditangani dengan Cloudflare di depan seluruh trafik
  • Mereka juga memiliki jaringan manajemen independen berbasis 4G/satelit sehingga akses jarak jauh tetap memungkinkan saat terjadi gangguan

Kepatuhan dan respons audit

  • Mereka mempertahankan sertifikasi SOC 2 Type II dan ISO 27001
    • Memanfaatkan data sertifikasi Tier III, log akses, dan CCTV dari colocation center
    • Log konfigurasi Terraform/Talos digunakan sebagai bukti riwayat perubahan
    Iklan
  • Auditor menilai bukti tersebut lebih dapat dipercaya daripada screenshot konsol AWS

Perbandingan alternatif cloud

  • Mereka membandingkan Hetzner, OVH, Leaseweb, Equinix Metal, dan AWS Outposts
    • Hyperscaler masih memiliki biaya egress yang tinggi
    • Host Eropa sulit memenuhi kebutuhan cluster Ceph skala besar dan persyaratan SLA
    • Equinix Metal memiliki premi 25–30% dibanding CapEx
    • Operasi hardware sendiri lebih unggul dalam hal densitas daya dan kebebasan upgrade
  • Hasilnya, berkat konfigurasi rak 15kW dan kemungkinan penggunaan ulang komponen, colocation unggul baik dari sisi biaya maupun performa

Pengukuran beban operasional (TOIL)

  • Mingguan: patch kernel/firmware dan pemeriksaan Ceph (1 jam)
  • Bulanan: canary upgrade control plane Kubernetes (2 jam)
  • Triwulanan: latihan DR, perencanaan kapasitas, pemeriksaan kontrak operator (12 jam)
  • Totalnya sekitar 14 jam per bulan, mirip dengan masa AWS, tetapi fokusnya berpindah dari “pelacakan biaya” ke “otomatisasi operasional”

Kasus ketika cloud tetap relevan

  • Jika workload memiliki pola spike atau musiman
  • Jika sangat bergantung pada managed service seperti Aurora Serverless, Kinesis, dan Step Functions
  • Jika tidak memiliki kapasitas untuk mengoperasikan sendiri Kubernetes, Ceph, monitoring, dan respons insiden
  • Artinya, untuk bisnis tahap awal atau dengan beban yang sangat fluktuatif, cloud masih unggul

Rencana ke depan

  • Mereka berencana merilis modul Terraform dan runbook untuk memprediksi anggaran colo
  • Post teknis mendalam tentang pengalaman operasional berbasis Talos juga sedang disiapkan
  • Mereka akan terus menanggapi masukan dari HN·Reddit dan melanjutkan berbagi studi kasus berbasis angka nyata

Bacaan terkait

3 komentar

 
okxrr 2025-10-30

Saya bekerja di perusahaan yang sangat antusias menggunakan AWS, padahal sama sekali tidak memakai layanan yang hanya disediakan AWS.

Agak tragis tapi lucu melihat keputusan ini sangat dipengaruhi oleh ambisi yang sangat pribadi dari beberapa pemimpin untuk mengembangkan karier mereka..
 
GN⁺ 2025-10-30
Opini Hacker News

  • AWS terlalu mahal. Alasan untuk menaruh seluruh sistem sepenuhnya di atas AWS ternyata lebih jarang daripada yang dibayangkan. Dulu semua orang tahu cara menjalankan server bare metal sendiri, tetapi sekarang sepertinya itu sudah dilupakan. Tim kami mempertahankan ketersediaan 99,993% selama lebih dari 730 hari, dan juga terhindar dari gangguan region AWS baru-baru ini. Kami memang memakai Cloudflare untuk perlindungan DDoS, tetapi saya paham bahwa mengelola DNS atau ingress bisa menjadi pekerjaan penuh waktu. Meski begitu, untuk beberapa microservice dan database, menjalankannya sendiri sudah lebih dari cukup. Untuk kebanyakan perusahaan, biaya AWS berlebihan

    • Masalah sebenarnya dengan AWS adalah ketergantungan karyawan pada AWS. Setelah mengambil sertifikasi AWS dan hidup dalam suasana yang menuntut kepatuhan pada AWS Well Architected Framework, orang berhenti berpikir sendiri. Layanan lock-in AWS sengaja diberi harga agar tampak murah, tetapi pada akhirnya membuat ketergantungan semakin dalam. Misalnya, memindahkan PostgreSQL ke DynamoDB mungkin terlihat seperti penghematan jangka pendek, tetapi dalam jangka panjang ketergantungan pada AWS justru membesar
    • On-premise memang murah, tetapi sulit mendapatkan tenaga ahli. Untuk produk sederhana ini cocok, tetapi untuk sistem yang kompleks justru biaya SDM dan risiko operasional bisa lebih besar. AWS/Azure/GCP memang tidak sempurna, tetapi sekarang ahli on-premise sudah terlalu langka
    • Saat mengkritik AWS, ada banyak orang yang bereaksi aneh. Fenomena serupa juga ada di Reddit. Rasanya seperti ada orang yang dibayar untuk membela AWS
    • Kisah sukses self-hosting mengandung bias konfirmasi. Mengelola server sendiri memang terlihat bagus di awal, tetapi setelah sekitar setahun, dokumentasi dan konfigurasi aktual mulai berbeda, dan ketika penanggung jawab keluar, kekacauan membesar. Pada akhirnya banyak startup kembali ke AWS. Kisah kegagalan seperti ini jarang dibagikan
    • Untuk menjalankan bare metal dengan baik, dibutuhkan insinyur yang berpengalaman. Sulit dilakukan hanya dengan lulusan baru atau “ahli cloud” dari perusahaan konsultan

  • Cloud generasi awal dimulai sebagai layanan yang sederhana dan punya rasio harga-kinerja bagus, tetapi sekarang sudah kusut dengan lebih dari 200 layanan yang kompleks. Kalau tidak dikelola, tagihannya bisa meledak

    • Sebenarnya sejak awal inti AWS bukan “murah”, melainkan “bisa diskalakan dengan cepat”. Di awal 2010-an pun AWS mahal, tetapi keunggulannya adalah fleksibilitas. Sampai sekarang pun harga dibanding performanya masih mahal. Kalau punya dasar administrasi server yang baik, dedicated server jauh lebih baik
    • AWS sekarang sudah melebar berlebihan menjadi lebih dari 200 layanan. Harusnya fokus ke fungsi dasarnya
    • Setiap kali masuk ke konsol AWS, langsung terasa rumit dan melelahkan. Terlalu besar
    • Tiap layanan AWS punya perbedaan value for money yang besar. Khususnya layanan inti yang lebih lama masih tetap bernilai

  • Fungsi sebenarnya AWS adalah: (1) memungkinkan skalasi organisasi dan struktur kekuasaan, (2) memungkinkan pencatatan akuntansi sebagai OpEx alih-alih CapEx, (3) menyembunyikan struktur kepegawaian yang tidak kompeten. Dulu pusat data bisa dijalankan dengan 5~10 orang, sekarang muncul organisasi DevOps berisi 3000 orang

    • Saya tidak mengerti kenapa perbedaan OpEx vs CapEx itu penting. Bukankah pada akhirnya uang tetap uang?
    • Cloud memang berguna untuk startup tahap awal. Bisa tumbuh cepat tanpa khawatir soal capacity planning. Tetapi kalau perusahaan dengan laju pertumbuhan rendah terus bertahan di cloud, itu jadi tidak efisien
    • On-premise sering sangat dikustomisasi sehingga sulit mengganti personel. Sebaliknya, tenaga AWS bisa dicari di mana saja
    • Administrator sistem yang benar-benar terampil memang sulit dicari dan mahal. Saya bahkan pernah melihat kasus backup tidak berjalan selama dua tahun karena ingin berhemat

  • Kunci keberhasilan ini adalah beban yang stabil 24/7. Sebenarnya kebanyakan perusahaan juga memiliki pola yang mirip

    • Sebenarnya beruntung karena sejak awal dimulai dengan satu rak, satu pusat data. Artinya biaya reliabilitas tidak dibayar di muka
    • Artikel terkait: One Big Server
    • AWS sering memaksa reserved instance dengan alasan “stok habis”. Pada akhirnya biayanya jadi mirip dengan biaya operasi terus-menerus
    • Tempat seperti Hetzner bisa memberi performa yang sama dengan harga 10 kali lebih murah daripada AWS. “Elastisitas” cloud adalah mitos yang dibesar-besarkan

  • Intinya adalah elastisitas vs beban dasar. Cloud hanya unggul ketika ada ledakan trafik besar seperti pada pengumpulan data. Dalam kebanyakan kasus, bare metal lebih baik

  • Pada 2010-an hardware dan jaringan masih lambat, tetapi sekarang performa dan efisiensi CPU meningkat ratusan kali lipat. Dulu butuh 64 server, sekarang 1 server saja cukup. Ke depan bahkan bisa mencapai rasio 100:1. Dalam kondisi seperti ini, keunggulan cloud makin berkurang

  • Dari sudut pandang saya sebagai karyawan Amazon, mengelola Kubernetes sendiri terlalu berisiko. Komponen seperti etcd tidak stabil, dan kami bahkan harus melakukan patch sendiri. Self-hosting yang dibicarakan dalam tulisan ini meremehkan risikonya

    • Hyperscaler lain juga pernah mengalami gangguan besar karena gagal mengelola Kubernetes. Alternatif sederhana untuk satu rak seperti Microk8s lebih baik. Artikel terkait: Microk8s 6 Months Later
    • Lingkungan yang kompleks itu sulit di mana pun, dan pada akhirnya tetap membutuhkan ahli. AWS pun sama-sama tidak mudah. Meski cloud down, dunia tetap berjalan
    • Versi ringan seperti k3 jauh lebih sederhana
    • Kubernetes sebaiknya dipakai hanya saat memang perlu. Jika dijadikan default, itu hanya membuang waktu dan uang

  • Banyak startup mungkin bahkan tidak akan bisa eksis jika biaya AWS terlalu mahal. Misalnya hal seperti unduhan gratis GeoIP (tautan) mungkin tidak akan mungkin dilakukan. Cloud lambat, dan latensi disk serta kepadatan CPU sangat parah. Di bawah 10 ribu dolar per bulan masih oke, tetapi di atas itu bare metal jauh lebih efisien

    • Karena terbiasa dengan performa cloud yang lambat, muncul fenomena adaptasi yang aneh. Perbandingan seharusnya selalu memakai bare metal sebagai patokan

  • Perusahaan tempat saya bekerja juga trafiknya kecil, tetapi tetap ingin pindah ke AWS. Alasannya sederhana — karena ingin menaruh AWS di resume. Bukan hanya developer, eksekutif pun sama. “Memimpin migrasi AWS” terlihat bagus untuk karier. Pada akhirnya perusahaan itu dijual dan kantornya kosong. Mungkin sekarang “berhasil keluar dari AWS” akan menjadi poin karier baru

    • Jika developer menginginkan AWS, generasi berikutnya hanya akan mengenal AWS. Diskusinya jadi bias
    • Pada akhirnya keputusan bergantung pada kemauan kepemimpinan

  • Pada akhirnya yang penting adalah apa yang ingin dilakukan

    • Jika itu situs web internal yang berpusat pada data, satu rak server saja sudah cukup
    • Jika trafiknya besar, tidak teratur, dan tidak bisa di-cache, cloud lebih menguntungkan
    • Jika DNS atau ingress rumit, pendekatan hybrid lebih baik
    • Semakin besar skala data, semakin menguntungkan struktur depresiasi jangka panjang cloud