1 poin oleh GN⁺ 2025-06-22 | 1 komentar | Bagikan ke WhatsApp
  • Karena masalah kedaulatan data dan kepatuhan GDPR yang muncul pada layanan cloud AS, timbul kebutuhan untuk bermigrasi ke cloud Eropa
  • Dengan melepaskan kemudahan dan layanan terintegrasi AWS sepenuhnya, mereka tetap memperoleh penghematan biaya langsung dan kejelasan data melalui hosting Eropa seperti Hetzner
  • Untuk efisiensi operasional infrastruktur, mereka membangun otomatisasi berbasis Ansible dan sistem pemantauan self-hosted
  • Melalui pembangunan langsung, mereka mendapatkan desain keamanan yang lebih ketat dan struktur yang memudahkan audit yang transparan
  • Mereka juga memperoleh keuntungan strategis dari sisi bisnis, termasuk penghematan biaya 90% dan penurunan risiko pengawasan AS

Proses perpindahan dari AWS ke cloud Eropa (Hetzner) dan strategi mempertahankan ISO 27001

Dilema CTO Eropa: masalah kepatuhan saat keluar dari AWS

  • Kekhawatiran utama yang dialami banyak pemimpin teknologi berasal dari keterbatasan penyedia cloud AS
  • Mereka puas dengan layanan bersertifikasi ISO 27001 yang kuat dari AWS, tetapi karena CLOUD Act dan FISA AS, data pelanggan di Eropa tetap terekspos pada yurisdiksi AS
  • Terlepas dari lokasi server yang sebenarnya, muncul situasi di mana sulit memenuhi komitmen GDPR
  • Biaya cloud tahunan sebesar $24.000 disadari terlalu berlebihan dibanding kebutuhan aktual
  • Mereka merasakan bahwa masa depan perusahaan yang bergantung pada satu penyedia berbasis AS adalah keputusan yang berisiko secara strategis

Pengenalan kasus nyata Datapult

  • Datapult adalah perusahaan perangkat lunak manajemen tenaga kerja asal Denmark, dan tugas seperti penjadwalan karyawan, penyesuaian upah lembur, serta pengelolaan data kehadiran menuntut keandalan setingkat finansial
  • Mereka telah menyesuaikan persyaratan hukum dengan workflow berbasis AWS, tetapi proses perpindahan ke layanan on-premise atau alternatif independen membutuhkan peninjauan hukum tambahan

Kekhawatiran saat meninggalkan AWS dan elemen yang benar-benar hilang

  • Melepaskan kemudahan terintegrasi AWS merupakan hambatan psikologis yang besar
  • Mereka kehilangan kemudahan dan otomatisasi seperti Lambda, RDS satu klik, dan berbagai alat kepatuhan bawaan
  • Ini berarti beralih dari layanan terkelola ke kontrol langsung dan tanggung jawab yang lebih besar

Dampak yang diharapkan dari cloud Eropa dan manfaat nyata

  • Migrasi ke penyedia layanan Eropa (Hetzner, OVHcloud) memberi manfaat langsung dalam hal kedaulatan data, GDPR, dan ISO 27001
    • Komunikasi pelanggan dan respons audit menjadi transparan melalui bukti data residency yang sesungguhnya
    • Tercapai penghematan biaya tak terduga (90%) dan transparansi anggaran
    • Meski meninggalkan kenyamanan AWS, secara teknis mereka justru mendapatkan prosedur otomatisasi yang lebih kuat (konfigurasi Ansible) dan peningkatan keamanan
  • Dibanding sebelumnya, mereka memperoleh otonomi, inovasi, dan infrastruktur yang dapat diverifikasi

Strategi transisi yang spesifik dan pelajaran utama

  • Otomatisasi kepatuhan dengan Ansible
    • Mereka mewujudkan pengelolaan infrastruktur yang terdokumentasi sendiri dengan menghubungkan semua konfigurasi server langsung ke kontrol ISO 27001 Annex A
  • Membangun sistem pemantauan pengganti AWS
    • Dengan kombinasi Prometheus, Grafana, Loki, mereka dapat mencapai pemantauan kelas enterprise setara AWS CloudWatch dan respons insiden yang cepat
  • Penerapan security-by-design untuk memperkuat desain keamanan
    • Dalam situasi tanpa alat keamanan terkelola, otomatisasi Ansible memperkuat ISMS (sistem manajemen keamanan informasi) dan memudahkan pengembang untuk tetap patuh

Dampak strategis yang melampaui teknologi

  • Meminimalkan risiko kepatuhan akibat undang-undang pengawasan AS
  • Memanfaatkan infrastruktur hosting Eropa sebagai poin diferensiasi penjualan untuk meningkatkan kepercayaan dan nilai merek
  • Membangun struktur agar biaya cloud yang dihemat (90%) dapat diinvestasikan kembali ke inti bisnis

Panduan penerapan strategi transisi

  • Berdasarkan pengalaman migrasi dari infrastruktur AWS ke cloud Eropa yang berdaulat sambil mempertahankan ISO 27001, mereka dapat menyediakan panduan yang dapat direplikasi
  • Bagi CTO dan pendiri yang mempertimbangkan perpindahan dari AWS ke cloud Eropa, mereka menawarkan konsultasi yang disesuaikan mengenai analisis biaya, risiko kepatuhan, dan jadwal implementasi
    • Dalam satu jam, perbedaan biaya, risiko hukum utama, dan tahap awal migrasi dapat dirangkum

1 komentar

 
GN⁺ 2025-06-22
Komentar Hacker News
  • Kami memang menghemat biaya dengan mereimplementasikan sendiri fungsi-fungsi inti AWS, tetapi banyak orang mengabaikan biaya nyata dari hosting gaya DIY, terutama hal-hal seperti dukungan 24 jam. Jika mencoba membangun dukungan seperti itu sendiri, justru biayanya bisa cukup besar. Biaya AWS sebesar $24.000 per tahun setara dengan 1–2 bulan freelancer DevOps yang sangat bagus atau sekitar 1/3 FTE developer bergaji rendah, dan dengan anggaran seperti itu sulit mengharapkan dukungan siaga 24 jam. Tentu pilihan seperti ini bisa masuk akal, tetapi saya menyayangkan mereka tidak jujur mengungkap seluruh biaya sebenarnya seperti waktu pengembangan atau biaya pengelolaan. Saya juga sedang mempertimbangkan pilihan serupa, tetapi bukan demi penghematan biaya melainkan karena kebutuhan bisnis seperti pelanggan di Jerman. Namun semuanya akan jadi lebih kompleks dan kami juga perlu menambah anggota tim. Sebagai CTO, waktu saya terbatas, jadi terjun langsung ke pekerjaan seperti ini adalah penggunaan waktu yang paling buruk. Saya rasa saya seharusnya lebih fokus pada perkembangan perusahaan dan produk. Secara pribadi, untuk skala sekecil ini saya merasa Terraform itu berlebihan, dan Ansible lebih cocok sebagai kasus YAGNI (You Ain’t Gonna Need It).

    • Orang sering salah paham bahwa penyedia cloud besar seperti AWS, Azure, dan GCP benar-benar memberikan dukungan aplikasi 24/7, padahal kenyataannya tidak begitu. Yang ada hanya infrastrukturnya yang “sebagian besar” berjalan baik, dan pada akhirnya tetap perlu ahli untuk memakainya dengan benar, mengecek sendiri ledakan biaya atau masalah integrasi. Gagasan bahwa tagihan cloud adalah TCO (total cost of ownership) itu mitos yang sepenuhnya keliru

    • Jika menyalin fungsi AWS 100%, biayanya bisa mahal, tetapi jika hanya butuh 80% maka ceritanya berbeda. Selain itu, usaha untuk menyiapkan AWS dan terus mengasah keterampilan teknis terkait juga tidak bisa diabaikan. Misalnya, alih-alih dashboard AWS, kita bisa memakai alat yang lebih baik seperti grafana. Pada akhirnya semuanya tergantung pada skala dan ragam kebutuhan. Hammer yang paling mahal tidak selalu jawaban terbaik

    • Jika hanya melihat efek penghematannya, artinya mereka menghemat $21.600 per tahun, yaitu 90% dari $24.000 awal. Namun dengan anggaran sebesar itu, Anda tidak bisa merekrut engineer SRE/DevOps di Eropa. Bahkan seiring waktu, karena harus mengelola seluruh infrastruktur sendiri, menurut saya total cost of ownership justru akan naik dalam jangka panjang. Meski begitu, saya tetap mendukung tantangannya

    • Jika mempertimbangkan risiko pemerintah AS memaksa Amazon untuk menangguhkan akun, menggunakan AWS bisa menjadi pilihan berisiko. Menurut saya ini makin relevan ketika belakangan muncul pembicaraan soal perang antara AS dan Eropa (Greenland)

    • Saya rasa perhitungan sederhana $24.000 per tahun itu terlalu naif. Rasanya belum ada estimasi biaya tenaga kerja yang konkret, seperti berapa orang yang dibutuhkan untuk membangun layanan-layanan ini di AWS, atau berapa banyak personel yang diperlukan untuk menurunkan biaya dari $48.000–$100.000 menjadi $24.000

  • Menurut saya, kombinasi Prometheus, Grafana, dan Loki saja sudah cukup untuk mereplikasi, bahkan melampaui, tingkat monitoring yang sebelumnya kami dapatkan di AWS. Saya selalu heran alat-alat ini bisa sebaik itu sementara layanan monitoring AWS mahal, lambat, dan UX-nya mengecewakan. Faktanya, biaya monitoring adalah bagian paling cepat dan paling tidak menyenangkan dari pengalaman saya dengan AWS

    • Saya sampai tertawa melihat bahwa fitur sesederhana log real-time seperti Live Tail pun adalah layanan berbayar. Fitur yang penting untuk melihat log setiap hari saja tidak gratis, jadi CloudWatch (CW) benar-benar terasa menyebalkan
  • Kekurangan utama Hetzner adalah masalah IP yang tercemar akibat pengguna jahat, serta kemungkinan kerusakan hardware atau kebutuhan upgrade. Saya penasaran apakah hal-hal ini tidak membuat khawatir. Saya juga ingin tahu bagaimana mereka mengatasi lonjakan penggunaan memori di Loki, dan apakah ada alternatif lain

    • Masalah IP tercemar ditangani dengan mem-proxy akses pengguna melalui Cloudflare, lalu mengatur firewall (ufw) dan hanya mengizinkan akses dari sumber yang diizinkan melalui IP Cloudflare, sehingga akses dari luar benar-benar diblokir. Gangguan hardware/upgrade bisa ditangani cepat lewat setup Terraform untuk penggantian dan ekspansi kapasitas. Hardware dipantau dengan Prometheus dan node exporter untuk mendapatkan peringatan dini, dan selama 9 bulan belum ada gangguan. Aplikasi hampir tidak memiliki data, sedangkan database sering diuji pemulihannya. Masalah memori Loki diatasi dengan kombinasi beberapa cara: kebijakan retensi dan pemisahan indeks, tuning konkurensi query dan batas memori, penerapan label ala promtail dan structured logging, serta untuk data lama memakai backup object storage atau menggantinya dengan grep

    • Masalah Loki yang kami alami berasal dari kenyataan bahwa konfigurasi deployment default seperti helm belum cukup optimal. Setelah mengikuti tips performa yang disebut di blog — seperti reset indeks, menambah instance read-only, dan menerapkan rekomendasi lain — kami benar-benar melihat peningkatan performa yang jelas. Karena arahnya memang mendorong orang ke layanan cloud mereka sendiri, saya rasa pada awalnya memang perlu sedikit trial and error

    • Sebagai alternatif Loki, saya merekomendasikan Victoria. Jauh lebih cepat dan reputasinya juga baik, tetapi kami memilih Loki dengan mempertimbangkan keragaman maintainer proyek. Kekurangannya kami tutupi dengan cara-cara yang disebut di atas

    • Membagikan tautan https://en.wikipedia.org/wiki/Sybil_attack. Penyedia cloud mahal punya keunggulan karena membangun reputasi IP yang mirip dengan mekanisme PoW (proof of work)

  • ISO 27001 adalah standar manajemen keamanan internasional dan pedoman yang populer di Eropa. Di AS hampir tidak dipakai, dan banyak perusahaan Eropa tampaknya kurang memahami perbedaan ini. Dasar standar keamanan di AS adalah SOC 2, yang lebih longgar daripada ISO 27001 dan lebih familier di pasar Amerika

    • ISO 27001 pada dasarnya bukan standar yang terlalu kaku atau berat, dan umumnya hanya menuntut hal-hal dasar yang memang perlu dilakukan saat menggunakan software. Yang sulit adalah membuktikannya lewat dokumentasi, sedangkan SOC 2 dibanding itu beban dokumentasinya jauh lebih ringan

    • Dari pengalaman menjalani SOC 2 dan ISO 27001, saya merasa audit SOC 2 terlalu bergantung pada kemampuan dan intuisi auditor dibanding kontrol operasional yang nyata, dan itu cukup disayangkan. ISO 27001 terasa jauh lebih jelas dan adil sebagai audit

    • Tolong sebutkan satu saja perusahaan cloud besar AS yang tidak memiliki sertifikasi ISO 27001

  • Saya juga memangkas biaya 90% dengan setup serupa di Azure. Saya merasa perusahaan besar sengaja memaksakan pengalaman abstraksi layanan yang rumit, sehingga operasional yang sederhana makin sulit dilakukan

    • Meminta penjelasan lebih rinci tentang kasus penghematan biaya di Azure
  • Salah satu alasan membayar AWS adalah karena beban operasional berkurang, dan setelah memakai DB terkelola AWS, saya tidak lagi stres soal upgrade cluster mysql seperti dulu. Tentu hal seperti ini saja tidak cukup untuk membenarkan biayanya yang tinggi, tetapi menurut saya nilainya cukup besar

    • Saya setuju dengan poin ini. Untuk benar-benar memiliki sertifikasi ISO 27001 yang bermakna, proses upgrade juga harus diinternalisasi agar kontrol pengembangan/deployment bisa dijalankan secara efektif. Misalnya, AWS RDS tidak otomatis melakukan upgrade mayor/minor untuk Postgres dan MySQL; yang otomatis hanya patch, sisanya tetap harus saya lakukan sendiri. Jadi inti pembahasannya bukan soal mana yang lebih unggul antara cloud dan server Eropa, melainkan tentang cara mengoperasikan lingkungan yang kompleks dan tersertifikasi sendiri. Jika Anda memang harus mengelola infrastruktur sendiri karena pelanggan atau bisnis yang diatur regulasi, maka masuk akal untuk melakukan upgrade sendiri dan memperoleh ISO 27001. Tetapi jika tidak ada tuntutan seperti itu, bergantung pada cloud seperti AWS RDS juga tidak masalah
  • Angkanya tidak masuk akal. Jika dari $24.000 per tahun turun 90%, berarti tinggal $200 per bulan, dan itu cuma setara harga satu server Hetzner. Dalam situasi seperti itu, sepertinya cukup memakai satu server saja tanpa sistem terdistribusi, jadi saya penasaran berapa sebenarnya request per detik atau jumlah penggunanya

    • Untuk mematuhi ISO 27001, tidak bisa beroperasi dengan satu server saja dan juga perlu server terpisah khusus log serta monitoring. Kompleksitas itu tetap wajib ada terlepas dari beban kerja. Karyawan tidak login setiap hari, dan karena sifat aplikasi penjadwalan, ada yang hanya memeriksanya 1–2 kali per minggu. DAU sekitar 10.000–20.000, peak concurrent users sekitar 1.500–2.000 orang, dan rata-rata concurrent users 50–150. Alasan biaya cloud tinggi adalah karena aplikasi ini memiliki beban pemrosesan data yang berat akibat fitur real-time dan aturan ketenagakerjaan yang kompleks. Misalnya, penugasan shift memiliki aturan perhitungan bonus yang berbeda-beda, dan optimasi jadwal juga berat secara komputasi

    • Meluruskan bahwa itu $200, bukan $2.400

  • Saya penasaran bagaimana enkripsi disk dilakukan. Di AWS itu otomatis, tetapi saya belum pernah melihat cara yang benar-benar baik untuk menerapkannya di penyedia hosting biasa. Menyimpan kunci enkripsi di partisi boot juga membuatnya tidak ada gunanya

    • ISO27001 tidak secara mutlak mewajibkan enkripsi disk; yang penting adalah mendefinisikan metode perlindungan yang tepat untuk data penting. Terutama di lingkungan hardware bersama, enkripsi disk adalah cara yang paling umum. Hetzner memiliki data center bersertifikasi ISO27001 dan proses penghapusan data saat disk dibuang, jadi persyaratan sertifikasi bisa dipenuhi
  • Saya benar-benar suka Hetzner, bahkan mesin pencari saya juga berjalan di sana. Menurut saya memakai server fisik itu yang terbaik

  • Selain OVH dan Hetzner, saya juga ingin merekomendasikan UpCloud di antara cloud Eropa. Kelebihannya, CPU core mereka tampaknya semuanya core fisik sungguhan, bukan vCPU berbasis thread. Hanya saja referensi resminya masih kurang. Membandingkan OVH, Hetzner, dan HyperScaler memang tidak mudah, tetapi dalam kasus Hetzner, ada perbedaan karena mereka kebanyakan memakai komponen kelas konsumen. Pengenalan UpCloud

    • Saya heran kenapa cloud murah selalu tidak punya IAM (izin/kebijakan/log) setingkat IaaS yang benar. Yang ada hanya login konsol, tanpa permission atau role yang sesungguhnya, machine ID, sampai audit log bawaan. Padahal OpenStack sudah menyediakan fitur-fitur seperti ini, tetapi cloud murah rasanya seperti membangun ulang semuanya dari nol. Sebagai contoh, pada panduan Crossplane dari UpCloud, API credential dibagikan di level user konsol sehingga tampak berisiko. Kalau lewat Terraform susah dikelola, akhirnya harus memakai upcli atau semacamnya. OpenStack Service Users OpenStack Federation Panduan UpCloud Crossplane Manajemen subaccount UpCloud Pengaturan permission UpCloud