Tagihan Cloud Saya Turun dari $500 ke $50 Sebulan, Ini Ceritanya
Teman-teman pasti udah sering denger cerita kayak gini: developer kere buka tagihan AWS, lihat angkanya, jantungan, terus panik migrasi ke yang lebih murah sambil nangis. 😅
Nah ini bukan cerita itu.
Soalnya waktu pertama kali saya bangun sistem ini, tagihan $500 sebulan itu nggak masalah sama sekali. Aplikasinya udah tembus sejuta download di tiga wilayah. Ownernya punya duit, beneran punya duit, dan pesannya cuma satu: "Bikin yang anti-mati. Jangan sampai down. Soal biaya nggak usah dipikirin."
Ya udah, saya bangunin dia sistem yang serba mewah. Eh, beberapa tahun kemudian, dia malah minta saya rampingin lagi. Ini cerita gimana saya mangkas tagihan itu 90% tanpa kehilangan satu user pun.
Kalau Duit Bukan Masalah
Biar nyambung, saya kasih konteksnya dulu. Soalnya di cerita ini konteks itu penting banget.
Kalau kamu pegang sejuta user dan bos yang beneran nggak peduli sama tagihan, kamu nggak bakal milih yang murah. Kamu bakal milih yang aman. Pakai aja semua layanan siap-pakai yang AWS jual, karena tiap layanan yang diurusin AWS itu satu beban yang lepas dari pundak kamu pas jam 3 pagi.
Tapi sebelum ngomongin isinya, ada satu hal yang nggak bisa ditawar: tiga wilayah itu wajib. Aplikasinya melayani user di Eropa, Asia, sama Amerika. Dan yang nentuin itu bukan selera teknis saya, tapi hukum. Aturannya namanya data residency, alias data harus disimpan di negara asal usernya.
Aturan di Eropa (GDPR) yang paling galak, tapi intinya sama di mana-mana. Data user Eropa harus nyimpen di server Eropa, data user Amerika di Amerika, gitu seterusnya. Nggak bisa main corong semua user ke satu pusat data murah terus kelar. Data pribadi harus tetap di negaranya sendiri, titik. Makanya tiap bagian di bawah ini ada tiga kali lipat.
Jadi ini yang saya jalanin. Semua AWS, semua diurusin AWS, tersebar di Eropa (Stockholm), Asia (Singapura), sama Amerika (Oregon):
- EC2 + Auto Scaling buat menjalankan aplikasi, otomatis nambah server kalau ramai
- RDS PostgreSQL buat database, backup 7 hari, dengan cadangan otomatis kalau satu server mati
- ElastiCache Redis buat menyimpan data sementara biar aplikasi cepat
- Load Balancer buat ngebagi-bagi traffic, plus pengalihan otomatis ke HTTPS
- S3 buat penyimpanan file, terenkripsi
- Route53 buat DNS
- ACM buat sertifikat SSL yang perpanjang sendiri
- CloudWatch, sepuluh lebih alarm ngawasin CPU, memori, error, kecepatan, semuanya
- Secrets Manager + SSM buat nyimpen password dan pengaturan
- ECR buat nyimpen image aplikasi
Di atas kertas cakep banget. Tahan banting, bisa pulih sendiri, dan semua diurusin AWS. Backup, update, pemulihan kalau ada yang mati, semua mereka yang urus. Ada server mati, server baru udah nongol sebelum saya kelar baca notifikasinya.
Dan buat kondisi waktu itu, ngelayanin sejuta orang yang berharap aplikasinya tinggal jalan, ini keputusan yang bener. Dikasih situasi yang sama, saya bakal bangun persis kayak gini lagi.
Ini yang jarang dibahas orang. Sistem yang kelewat mewah itu bukan kesalahan. Itu jawaban yang bener buat pertanyaan yang sekarang udah nggak ada.
Soalnya pertanyaannya berubah.
Telepon Itu
Maju beberapa tahun.
Aplikasinya udah stabil. Pertumbuhannya landai, sehat, gampang ditebak. Energi panik di awal yang serba kejar-kejaran udah lama hilang. Terus suatu hari ownernya nelepon, kasih perintah baru yang kebalikan total dari yang dulu:
"Jalannya udah bagus. Sekarang bikin lebih murah."
Dan langsung deh, semua asumsi yang jadi pondasi sistem mahal saya kebalik.
Server cadangan otomatis? Udah bertahun-tahun nggak ada wilayah yang down. Penambahan server otomatis pas ramai? Traffic-nya stabil, jadi nyaris nggak pernah kepakai. Sepuluh alarm CloudWatch? Yang saya lirik paling cuma dua. Saya bayar mahal buat jaga-jaga dari bencana yang ya emang nggak pernah datang.
Selama ini saya bayar mahal biar semua diurusin AWS, dan buat waktu yang lama itu sepadan kok. Tapi begitu prioritasnya geser ke biaya, bukan lagi anti-mati mati-matian, bayaran itu langsung berubah dari "asuransi pinter" jadi "bakar duit".
Jadi saya buka tagihannya, baris per baris, terus mulai nanya pertanyaan nggak enak buat tiap layanan:
Saya beneran butuh AWS ngerjain ini, atau saya cuma bayar mereka biar nggak usah mikir?
NAT Gateway doang, benda yang bikin server di jaringan dalam bisa ngomong ke internet, itu biayanya lebih mahal dari server-nya sendiri. Load Balancer ada biaya per jam plus per permintaan. Database jalan sekitar $25 per wilayah per bulan cuma buat ukuran kecil yang sebenernya bisa saya jalanin di kentang. 🥔
Numpuk cepet banget. Dan hampir semuanya udah nggak ngasih manfaat apa-apa lagi.
Kenapa Pindah ke Hetzner
Udah lama saya lihat developer, kebanyakan di Eropa, ngomongin Hetzner Cloud. Provider Jerman, nggak setenar AWS atau Google Cloud, tapi punya penggemar fanatik gara-gara satu hal: harga sama performanya nggak masuk akal.
Bayangin, server 2 inti prosesor sama 4 GB RAM cuma sekitar €4 sebulan. Bandingin sama AWS yang setara, sekitar $17, dan itu belum ditambahin load balancer, NAT gateway, sama database di atasnya.
Jadi pertanyaannya sekarang: bisa nggak saya bangun ulang semua yang sistem mahal itu kasih, tapi di Hetzner, tanpa kehilangan hal yang sekarang penting?
Bisa. Tapi pola pikirnya harus beda total.
Di AWS, kamu bayar mahal biar semua diurusin dan kamu nggak usah mikir. Di Hetzner, kamu yang pegang mesinnya, jadi kamu harus mikir. Buat hari-hari awal, "nggak usah mikir" itu bener. Tapi sekarang, mikir itu justru yang dibutuhin biar hemat.
Ngaku: Kenapa Nggak Pakai Docker
Oke, sebelum saya tunjukin susunan barunya, saya mau ngedahuluin kolom komentar dulu. Soalnya begitu ada developer lihat ini, yang pertama mereka ketik pasti:
"Lah, nggak pakai Docker? Di tahun 2025? Lu waras?"
Jawaban jujurnya ada dua lapis.
Yang pertama, alasan praktis: kami butuh pindahan cepet. Ini bukan proyek baru dari nol yang santai, tapi aplikasi yang udah jalan dengan sejuta user dan disuruh hemat sekarang juga. Tiap lapisan tambahan itu satu hal lagi yang harus diatur, dicari masalahnya, dan jadi penghalang biar pindahannya mulus. Kalau lagi dikejar waktu, ya kirim yang paling sederhana dan jalan.
Tapi "lagi buru-buru" itu bukan alasan yang bagus. Jadi saya kasih alasan sebenarnya, yang saya beneran percaya:
Docker itu nyelesain masalah yang udah nggak saya punya.
Coba pikir, Docker itu sebenernya ngasih apa sih ke kamu? Misahin banyak aplikasi biar nggak saling ganggu di satu server. Bikin lingkungan yang sama persis di komputer mana pun. Ngatur banyak aplikasi sekaligus pas jumlahnya udah banyak. Itu semua berguna banget, kalau kamu emang punya masalahnya.
Tapi susunan baru saya cuma satu aplikasi, satu server, satu wilayah. Nggak ada yang perlu dipisah-pisah, lha wong cuma dia satu-satunya yang ada di server itu. Soal lingkungan yang sama persis, itu udah diurus skrip otomatis saya, nanti saya bahas. Skrip itu bikin server yang persis sama tiap dijalanin, dari mesin kosong sampai aplikasi jalan, tanpa langkah manual. Saya cuma nggak butuh Docker buat ngelakuinnya.
Dan di server 4 GB, Docker itu nggak gratis. Makan RAM, makan tenaga proses, dan nambah satu langkah ekstra tiap saya mau ngintip catatan error atau benerin masalah jam 2 pagi. Di server yang cuma diisi satu aplikasi, Docker itu cuma beban buat fitur yang nggak saya pakai.
Jadi ini bukan saya males atau motong jalan pintas. Ini pelajaran yang sama kayak pindah dari AWS tadi, cuma diterapin di hal yang lebih kecil: jangan bayar sesuatu yang kamu nggak butuh.
Nanti kalau ini tumbuh jadi banyak aplikasi per server, atau saya butuh ngatur banyak server sekaligus, ya saya bakal langsung pakai Docker tanpa mikir dua kali. Itu alat yang pas buat kerjaan itu. Cuma bukan buat yang ini.
Intinya: jangan pasang sesuatu cuma karena "siapa tau nanti butuh". Sederhanain dulu, pasang nanti pas emang udah perlu.
Susunan Baru: Apa yang Beneran Saya Bangun
Nah ini susunan barunya. Dan saya pengen kamu ngerasain betapa jauh lebih adem-nya.
Satu server per wilayah. Itu doang ceritanya. Tapi inget, satu per wilayah tetep wajib. Aturan data residency yang tadi nggak ilang cuma gara-gara providernya ganti. Data user tetep harus disimpen di negaranya. Jadi hal pertama yang saya cek di Hetzner bukan harga, tapi apakah mereka punya lokasi yang ngebolehin saya nyimpen data Eropa di Eropa, data Amerika di Amerika, dan data Asia di Asia. Ternyata ada. ✅
- Server Hetzner Cloud, ukuran kecil (2 inti, 4 GB) di Eropa, plus yang setara di Singapura sama Amerika
- Nginx buat ngatur dan nerusin traffic ke aplikasi, jalan di server yang sama
- PostgreSQL 16 buat database, datanya nempel di penyimpanan terpisah yang selamat walau servernya dibangun ulang total
- Redis buat data sementara, jalan langsung di server
- Node.js 22 + PM2 buat menjalankan aplikasi, tanpa Docker kayak yang tadi dibahas
- Cloudflare buat DNS sama SSL, sertifikat gratisnya yang ngurus HTTPS
- GitHub Container Registry (GHCR) gantiin ECR, gratis buat nyimpen aplikasi pakai token
- Loki + Promtail + Node Exporter, alat pemantau gratis yang ngirim catatan log ke layar pemantau saya sendiri (Grafana)
Dan ini bagian yang bikin orang ketar-ketir:
Semuanya dipasang otomatis sama satu skrip 351 baris. Skrip ini jalan pertama kali server nyala. Dia install semuanya, atur Nginx, setup database, nyalain aplikasi, sama benerin keamanan dasar. Seluruh sistem, satu skrip, satu server, nol klik.
Pasti ada yang nanya: "Terus kalau servernya mati gimana? Nggak ada cadangannya?"
Fair. Jujur aja, di AWS, server cadangan otomatis itu diurus sendiri buat saya. Dan waktu kami pegang sejuta user yang teriak-teriak, itu penting banget.
Di Hetzner, saya tuker cadangan otomatis sama tagihan yang bisa ditebak dan kontrol penuh. Penyimpanan database tetep aman walau servernya dibangun ulang, tapi kalau mati nggak langsung ada gantinya seketika. Itu emang ada plus-minusnya, bukan makan siang gratis.
Tapi gini, buat posisi aplikasi ini sekarang, pilihan itu justru pas. Ownernya minta lebih murah, bukan minta jaminan anti-mati 99,999% yang sebenernya nggak pernah kami pakai.
Perjuangan Versi Gratisan yang Nggak Pernah Ditulis di Tutorial
Ini bagian yang paling pengen saya tulis, soalnya nggak ada yang ngomonginnya.
Sakitnya bukan dari Hetzner, tapi dari versi gratisan Cloudflare.
Banyak fitur keamanan yang saya mau ternyata harus bayar. Yang paling ngeselin: saya nggak bisa pakai enkripsi penuh (Full SSL), yang butuh sertifikat khusus dari Cloudflare berbayar. Akhirnya saya pakai mode yang lebih sederhana (Flexible SSL), yang artinya jalur terakhir, dari Cloudflare ke server Hetzner saya, nggak terenkripsi di bagian itu.
Buat sebagian sistem, itu jelas nggak boleh. Tapi saya gali dulu apa artinya buat kasus spesifik saya, paham risikonya sampai mana, baru rancang solusi yang aman di dalam batasan itu.
Dan itu jadi pola yang berulang. Tiap kepentok fitur yang harus bayar, saya harus berhenti, riset, terus cari cara lain biar hasilnya tetep sama. Ada beneran momen, biasanya jam 2 pagi sambil mantengin pengaturan Nginx yang ngeyel nggak mau nerusin traffic, di mana saya mikir mendingan balik ke AWS aja kali ya. 😩
Tapi kepentok itu ada gunanya: maksa saya ngerti sistem saya sendiri. Di AWS, saya bayar biar nggak mikir. Di versi gratisan, nggak ada pintu darurat. Nggak bisa tinggal klik "aktifkan fitur". Saya harus belajar.
Dan begitu ngerti, ya udah nempel terus. Sistemnya stabil, dan saya tau persis tiap bagian kerjanya gimana, soalnya saya yang ngerakit semuanya sendiri.
Angkanya
Ini sebelum sama sesudahnya, nggak saya bulet-buletin biar keliatan bagus.
AWS (sebelum):
- NAT Gateway, biaya transfer datanya lumayan gede
- Load Balancer, per jam plus per permintaan
- Database, sekitar $25 per wilayah per bulan
- ElastiCache, biaya bulanan tambahan
- CloudWatch, nambah biaya lagi
- Total: $500+/bulan
Hetzner (sekarang):
- 3 server produksi + 1 server buat ngoprek, sekitar €25–30/bulan, udah semuanya
- Cloudflare DNS + SSL, gratis
- GHCR, gratis
- Grafana + Loki di server ngoprek, gratis
- Total: ~$50/bulan
Turun 90%. Dan jujur, layar pemantau saya sekarang malah lebih bagus dari CloudWatch yang dulu.
Intinya Apa Sih
Pelajarannya bukan "AWS itu jelek" ya. AWS itu luar biasa. Kalau kamu punya aturan ketat, lima puluh engineer, dan produk yang beneran nggak boleh mati lima detik pun, ya udah stay aja di AWS atau Google Cloud. Waktu saya pegang sejuta user dan duit nggak terbatas, AWS itu jawaban yang bener, dan saya bakal milih itu lagi.
Pelajaran sebenarnya lebih halus, dan ini benang merah seluruh cerita:
Cara kamu membangun sistem itu cuma cerminan dari kondisi kamu saat itu. Begitu kondisinya berubah, jawaban yang bener ikut berubah.
Sistem mahal itu nggak salah. Dia bener, waktu itu. Sistem mahal yang serba diurusin dan punya cadangan di mana-mana itu jawaban yang pas buat "duit bukan masalah, jangan pernah down". Sistem ramping satu server itu jawaban yang pas buat "bikin lebih murah, jaga tetep stabil". Orangnya sama, aplikasinya sama, tapi jawabannya kebalik, soalnya pertanyaannya kebalik.
Kesalahannya bukan bangun sistem mahal. Kesalahannya itu masih betah pakai sistem mahal bertahun-tahun setelah nggak ada lagi yang butuh dan mau bayar perawatannya.
Saya pindah dari "AWS yang urus semua" ke "saya yang urus semua", dan potongan biaya 90% itu cuma bonus dari kemauan belajar sistem saya sendiri dari nol. Perjuangan versi gratisan, fitur yang nggak bisa diklik gratis, benerin Nginx jam 2 pagi, itu semua yang ngubah sebuah tagihan jadi sebuah pelajaran.
Kalau kamu mau saya bahas lebih dalem soal apa pun, entah skrip otomatisnya, pengaturan Cloudflare, setup Nginx, atau cara nyimpen datanya, bilang aja. Saya lagi rencana bikin panduan lengkapnya buat lanjutan.
Sekarang, coba buka tagihan kamu sendiri. Tanyain pertanyaan nggak enak itu buat tiap baris. Bisa jadi kamu kaget, hal mana yang selama ini kamu bayarin mahal cuma biar nggak pernah kepakai. 🚀