Saya Kembali ke AWS, dan Kembali Sadar Mengapa Saya Pergi

• Sejak awal mendukung AWS, tetapi karena akumulasi ketidakpuasan seperti *skema penagihan yang rumit dan kompleksitas platform secara keseluruhan, penulis tidak lagi menyukai AWS
• Biaya DynamoDB yang tinggi, biaya egress yang mencapai 9 sen per gigabyte, serta penagihan ganda dan bahkan tiga kali untuk perpindahan data internal dinilai tetap mahal dan sulit dipahami
• Penulis kembali untuk menguji Claude di AWS Bedrock dan melakukan benchmark pada mesin 192-core, tetapi aktivitas mendadak pada akun yang lama tidak aktif memicu peringatan dugaan pelanggaran keamanan, sehingga akun ditangguhkan
• Akibat penangguhan akun, AWS WorkMail untuk bisnis juga ikut terhenti, dan selama 4 hari pemulihan akun tidak kunjung terjadi dalam kondisi paket dukungan gratis
• Penulis sampai pada kesimpulan bahwa semua layanan yang masih tersisa di AWS harus dipindahkan dan ia harus benar-benar meninggalkannya sepenuhnya

---

Dari pendukung awal AWS hingga menjauh

• Penulis sangat mendukung AWS sejak masa ketika layanannya masih lebih kecil dan berpusat pada SQS, S3, EC2, dan SimpleDB, bahkan ikut menyelenggarakan acara pertama di Melbourne saat perwakilan AWS dari AS datang untuk memperkenalkan AWS
• Cloud computing merupakan perubahan besar yang memungkinkan startup menjalankan sistem komputernya sendiri dalam hitungan menit tanpa harus memasang dan mengoperasikan sistem di pusat data
• Selama sekitar 15 tahun penulis sangat percaya pada AWS, tetapi seiring waktu hal-hal yang mengganggu terus menumpuk hingga pada suatu titik ia tidak lagi menyukai AWS

Keluhan terhadap AWS yang menumpuk seiring waktu

• Library klien dan transisi Python

  • Selama 6 tahun pertama, AWS tidak membuat library klien sendiri dan membiarkan komunitas mengimplementasikan library untuk bahasa seperti Python, yang dirasakan seperti membebankan pekerjaan itu kepada programmer yang menghabiskan waktunya secara gratis
  • AWS juga membutuhkan waktu terlalu lama untuk berpindah dari Python 2 ke Python 3, dan itu menjadi sumber ketidakpuasan besar

• DynamoDB dan pengalaman biaya

  • Pada hari pertama menggunakan DynamoDB, tagihan sebesar 75 dolar muncul, dan bukan hanya mahal, sistemnya sendiri juga terasa seperti dibangun dengan cara terburuk yang bisa dibayangkan

• Biaya transfer data dan penagihan yang rumit

  • Biaya data keluar AWS dulu sebesar 20 sen per GB dan kemudian turun menjadi 9 sen per GB, tetapi tetap dianggap sangat mahal
  • Bahkan perpindahan data antar sistem internal AWS juga dikenai biaya, dan dalam beberapa kasus strukturnya terasa seperti penagihan ganda atau tiga kali, sehingga tanpa pemahaman yang mendalam sulit menghindari jebakan biaya

• IAM dan kompleksitas keseluruhan

  • IAM (sistem autentikasi dan kontrol akses) adalah sistem yang sangat kompleks
  • Para pendukung AWS mengatakan bahwa mengoperasikan Linux sendiri, hardware, jaringan, dan keamanan itu terlalu rumit sehingga orang harus memakai AWS, tetapi menurut penulis hampir semua bagian AWS sendiri juga memiliki kompleksitas besar dan pada akhirnya tetap memerlukan tim ahli yang mahal

• AWS Lambda dan lock-in

  • Penulis pernah terpikat oleh keunggulan “dapat diskalakan”, tetapi cold start yang lambat dan kompleksitas pengembangan yang besar menjadi masalah
  • Tidak ada keunggulan nyata dibanding server web sendiri, justru lebih banyak kekurangannya, dan saat keluar dari AWS, Lambda adalah bagian yang paling sulit dibongkar, menunjukkan betapa seriusnya vendor lock-in

• Proyek open source dan pendapatan hosting

  • Menurut penulis, AWS tetap mendorong OpenSearch, Valkey, dan DocumentDB meskipun proyek seperti Elasticsearch, Redis, dan MongoDB telah menunjukkan bahwa mereka tidak ingin proyeknya disalin dan dimonetisasi
  • Setelah komunitas dan perusahaan terkait membangun pasar, AWS mengambil pendapatan dari layanan hosting, dan akibatnya lisensi defensif seperti SSPL, Elastic License, dan RSAL serta model source-available semakin banyak bermunculan

Beberapa layanan yang masih ditinggalkan setelah keluar dari AWS

• Setelah rasa suka pada AWS hilang, penulis memindahkan hampir semuanya ke luar AWS dan menutup hampir seluruh akunnya
• Namun, saat itu ia masih menyisakan beberapa layanan yang menurutnya memang merupakan solusi yang tepat
• Domain tetap di Route53, sebagian backup tetap di S3, dan email bisnis tetap di AWS WorkMail
  • AWS WorkMail telah memberi pemberitahuan bahwa layanan akan dihentikan dalam 12 bulan

Alasan sempat kembali ke AWS

• Baru-baru ini penulis login lagi ke AWS untuk riset dan pengujian
• Ia ingin memeriksa seberapa baik Claude/Anthropic berjalan di AWS Bedrock, dan menurut standar Claude Code hasilnya sama tetapi lebih lambat dan jauh lebih mahal dibanding langganan Anthropic
• Perangkat rumah tercepat yang dimiliki hanya CPU 20-core dan RAM 32GB, sehingga ia ingin melakukan benchmark seberapa cepat kode itu berjalan pada mesin dengan 192-core dan RAM 1TB
• Sekitar sebulan sebelumnya, pengujian AWS Bedrock selesai tanpa masalah, dan semuanya dimatikan setelah tes selesai
• AWS Bedrock bisa berguna jika membutuhkan privasi, tetapi karena biayanya penulis tidak akan kembali memakai Claude lewat AWS Bedrock

Pembatasan akun saat menguji EC2 Spot

• Setelah itu, saat menjalankan instance EC2 Spot 192-core dan mengujinya selama sekitar 3 jam, penulis menerima email dari AWS bertuliskan “Suspected security breach of your account”
• Menurut penulis, kemungkinan besar alarm keamanan internal AWS terpicu karena akun yang hampir dorman tiba-tiba mulai memakai sumber daya komputasi yang mahal
• Tujuan AWS untuk melindungi pengguna itu sendiri dipahami dan dinilai positif
• Namun AWS menangguhkan atau membatasi akun tersebut, dan akibatnya akun email bisnis utama yang menggunakan AWS WorkMail berhenti berfungsi
• Tidak ada lagi yang bisa mengirim email kepadanya, dan ia juga tidak bisa membuat resource AWS apa pun, sehingga pengujian yang semula ingin dilakukan pun tidak dapat dilanjutkan

Respons dukungan dan keterlambatan

• Penulis membalas notifikasi dukungan AWS dan menjelaskan bahwa akunnya tidak diretas serta tidak ada masalah maupun kejanggalan tagihan, tetapi tidak ada respons
• Karena tidak memakai dukungan premium, ia harus menunggu waktu respons 24 jam yang disebut AWS, tetapi bahkan setelah 3 hari pun tanggapan dukungan AWS belum datang
• Setelah meminta bantuan di forum AWS, ia mendapat saran untuk mengikuti instruksi di email dan menggunakan chat alih-alih web
• Ia melakukan semua langkah yang diminta seperti mengganti kata sandi, menghapus access token, dan memeriksa riwayat penagihan, lalu menunggu sekitar 30 menit hingga tersambung ke chat dan berbicara lama dengan staf AWS
• Staf itu tampak puas dan mengatakan akan meminta tim internal terkait menanganinya, tetapi setelah 24 jam pembatasan tetap belum dicabut
• Saat ia melakukan tindak lanjut 8 jam kemudian, jawaban yang didapat hanya “harap menunggu”

Kesimpulan yang kembali ditegaskan

• Bahkan setelah 4 hari sejak akun dibatasi, pekerjaan yang ingin diuji pada mesin besar masih tersisa, dan penulis mulai khawatir harus kembali mengajukan permintaan “quota” untuk itu
• Sistem email bisnisnya masih tetap tidak berfungsi
• Pengalaman kembali kali ini sekali lagi menegaskan alasan ia meninggalkan AWS, dan ia memutuskan harus keluar dari AWS WorkMail, memindahkan domain dari Route53, dan tidak pernah kembali lagi
• Ia sangat bersyukur dulu sudah memindahkan banyak hal keluar dari AWS, tetapi sistem email yang masih ia percayakan dan tinggalkan di sana justru terhenti selama proses kembali ke AWS kali ini dan menimbulkan kerugian nyata
• AWS mungkin saja suatu saat membuka kembali pembatasan akunnya, tetapi tidak ada yang tahu kapan itu akan terjadi

[GN⁺]

Opini Hacker News

• Beberapa tahun lalu saya bergabung dengan sebuah perusahaan untuk memimpin tim pengembangan dan diminta merilis produk dalam 3 bulan, tetapi saat hendak menambah mesin baru di AWS, struktur harga yang tidak ditampilkan di UI terasa seperti sinyal hubungan yang bermusuhan dan eksploitatif
  Saya harus membuka tabel spesifikasi dan daftar harga secara terpisah lalu mencocokkannya, dan dari pengalaman sebelumnya saya merasa kalau melihat sinyal seperti ini lalu tetap tidak pergi, maka akibat setelahnya menjadi tanggung jawab saya sendiri
  Jadi saya membuat akun DigitalOcean dan memindahkan semuanya ke sana, lalu mengatur agar CI/CD juga melakukan deployment ke sana, dan dalam dua bulan tersisa saya fokus pada produk hingga rilis sebulan lebih cepat dari janji
  Dulu saya pernah melihat video orang menggali lubang di tepi sungai lalu menghubungkannya ke sungai dengan pipa agar ikan masuk sendiri ke perangkap, dan saya sangat terkesan bahwa memilih jalur dengan hambatan paling kecil dan tidak membatalkan kesalahan adalah cara untuk berakhir seperti ikan itu

  • Salah satu hal yang saya sukai dari Azure adalah, meski mereka tidak terlalu memaksakan harga setiap kali membuat item satu per satu, untuk item yang bisa mahal umumnya ada keseimbangan berupa penampilan harga
    Saya belum pernah dikejutkan oleh tagihan sejauh ini
  • Budaya engineering Amazon tampaknya cukup berbasis produk yang digerakkan engineer, jadi sering kali developer juga bertanggung jawab atas UX dan alurnya
    Saya pernah merekrut developer junior yang baru selesai magang di AWS, dan dia menunjukkan dashboard yang dibuat sendirian sepanjang musim panas tanpa bantuan product manager atau desainer, dan tampilannya benar-benar mengerikan
    Beberapa developer memang punya sense produk/UX yang bagus, tetapi sebagian besar sangat lemah dalam UX, jadi kemungkinan besar ini bukan sesuatu yang disengaja melainkan sekadar budaya UX yang buruk
  • Cara yang benar adalah memilih penyedia infrastruktur yang membantu Anda merilis
    AWS itu bagus, tetapi tidak cocok untuk semua orang; ada posisi di antara layanan seperti Heroku dan bare metal yang banyak mengabstraksikan maintenance sambil tetap memberi sebagian kendali atas arsitektur penskalaan
    Artinya, sebagai penyedia cloud AWS membantu untuk scaling, tetapi bukan alat untuk membuat konfigurasi yang paling murah dan sederhana
    Jika Anda punya pendanaan VC dan menonjolkan pertumbuhan, AWS bisa menjadi pilihan yang aman, dan berkat kredit startup 2 tahun lewat accelerator, selama 18 bulan pertama Anda bisa lebih fokus membangun daripada anggaran infrastruktur
    Jika Anda bootstrap atau developer indie, pilih yang sederhana dan terjangkau, dan Hetzner atau DigitalOcean sudah lebih dari cukup
  • AWS punya kalkulator harga yang cukup bagus dan preset yang lumayan berguna, tetapi tentu saja itu aplikasi yang sepenuhnya terpisah
    Amazon mungkin memang ingin ada sedikit gesekan saat orang mencoba melihat informasi harga dengan mudah, tetapi alasan utamanya tampak seperti hukum Conway
    AWS masih mengekspor bagan organisasinya sebagai produk
  • Saya setuju sampai batas tertentu, tetapi harga AWS tidak sesederhana satu angka statis di UI yang cukup untuk menghitung berapa yang akan dibayar
    Jika membuka dua tab untuk membandingkan biaya terasa merepotkan, mungkin lebih baik menghindari bukan hanya AWS tetapi semua penyedia cloud
    Begitu ada NAT gateway, CloudFront, S3, auto scaling, load balancer, menghitung biaya menjadi lebih mirip seni daripada ilmu pasti
    Jika Anda tidak memakai hal-hal itu, tidak banyak alasan memakai AWS, dan ada banyak penyedia VPS murah

• Jika hanya melihat OpenSearch dan Valkey, penjelasan bahwa “AWS membuat fork sehingga memicu perubahan lisensi” itu sepenuhnya terbalik
  AWS baru membuat fork setelah proyek upstream mengubah lisensinya, dan khususnya Valkey dibuat oleh anggota mantan tim inti Redis

  • Cukup banyak proyek seperti ini beroperasi dengan model bisnis membuka produk inti sebagai open source lalu menawarkan layanan premium, instalasi, maintenance, dan layanan fully managed
    Karena AWS menawarkan layanan fully managed dan mengelabui mereka, dalam kasus ini saya jadi berpihak pada orang-orang yang membuat proyek tersebut
    Pada dasarnya AWS merebut sumber nafkah mereka, dan mereka terpaksa mengubah lisensi
  • Perubahan lisensi itu sendiri adalah respons terhadap AWS yang memonetisasi pekerjaan mereka dari proyek upstream dengan cara yang tidak berkelanjutan
  • Saya penasaran seberapa besar dampaknya jika Amazon membayar para pembuat dan maintainer perangkat lunak open source yang mereka jual hanya 1 sen per periode penagihan penggunaan
    Saya juga penasaran apakah itu akan menjadi sejumlah uang yang berarti bagi tim open source, dan mungkin membuat mereka mau berkontribusi pada perbaikan produk tanpa menanggung risiko besar
  • Sejak pertama kali saya mengirim patch ke Redis lalu ada committer yang tidak membalas pesan saya, memasukkan patch itu atas namanya sendiri, simpati saya terhadap filosofi banyak proyek open source berkurang banyak
    Mereka memang pantas mengalami Valkey
    Saya juga masih ingat JBoss dan Marc Fleury
  • Wajar saja AWS baru membuat fork setelah lisensinya diubah agar mereka tidak bisa lagi menghasilkan uang dari kode proyek itu
    Itulah inti persoalannya

• Saya sudah beberapa kali bolak-balik antara layanan cloud dan self-hosting
  Awalnya saya memakai Vercel, dan karena proyeknya Next.js pengalamannya cukup baik, tetapi terasa mahal harus membayar $20 per bulan untuk proyek dengan bahkan belum 100 pengguna, padahal kebutuhan performanya rendah
  Setelah itu saya menyiapkan server sendiri dengan Hetzner dan Coolify; karena Coolify bersifat open source saya hanya perlu membayar biaya VPS, dan dengan $5 per bulan saya bisa menjalankan instance PostgreSQL dan web server
  Tetapi maintenance PostgreSQL dan Redis tetap memakan banyak tenaga, dan walaupun ada di dalam container Docker, meneruskan variabel sistem dan environment variable antar layanan tetap merepotkan
  Jadi belakangan saya pindah ke Cloudflare Workers, D1 Database, Cloudflare KV, dan karena bisa dipanggil langsung dari dalam Worker, saya tidak perlu meneruskan environment variable
  Pengalaman development lokalnya juga bagus dan harganya masuk akal, jadi sejak itu saya terus memakai seluruh rangkaian produk Cloudflare

  • Fitur yang disediakan Cloudflare sekarang makin mendekati apa yang saya harapkan dari AWS
    Aplikasi full-stack dan deployment file dasar menjadi jauh lebih sederhana, dan AWS sekarang bahkan jauh lebih sulit daripada self-hosting
  • Saya penasaran apakah Docker benar-benar membuat pengelolaan PostgreSQL lebih mudah
    Satu-satunya masalah yang saya alami dengan PostgreSQL hanyalah sedikit pekerjaan migrasi saat pindah ke major version baru
    Saya juga penasaran apakah urusan meneruskan variabel sistem dan environment variable antar layanan justru jadi lebih sulit karena Docker
  • Saya ingin menyukai Cloudflare Workers dan mungkin memang ada alasan teknis yang bagus, tetapi cara harus memakai proyek Wrangler untuk tugas seperti mengaktifkan email terasa seperti tinggal selangkah lagi dari vendor lock-in
    Untuk mengizinkan email saya harus mengatur binding yang diperlukan, tetapi tampaknya itu bahkan tidak bisa diatur di konsol, dan setelah diatur oleh Wrangler pun seolah tidak bisa dilihat

• Saya agak terkejut penulis membenci DynamoDB
  Itu salah satu layanan AWS favorit saya, tersedia dengan baik, hampir tanpa beban operasional, dan setiap kali saya memakainya biayanya juga cukup rendah
  Hanya saja, Anda memang harus meluangkan waktu untuk merancang model datanya sejak awal, dan untuk itu Anda perlu membaca dan memahami dokumentasi layanannya

  • DynamoDB sangat bagus jika dipakai sesuai cara yang dimaksudkan
    Pada dasarnya itu harus dipandang sebagai penyimpanan key-value yang relatif sederhana dengan durabilitas yang baik dan skalabilitas ukuran tabel yang nyaris tak terbatas, bukan sesuatu yang dipakai seperti database SQL
    Cara termudah menghasilkan tagihan $75 dari kode prototipe adalah melakukan vibe coding seolah-olah itu database SQL yang mendukung JOIN dan GROUP BY
    Tempat ia benar-benar bersinar adalah saat Anda butuh 1~2 tabel kecil untuk penyimpanan persisten tetapi tidak ingin mengelola seluruh RDBMS, atau saat Anda ingin meng-query satu tabel yang sangat besar dengan cara sederhana tanpa memaksakannya cocok ke RDBMS
  • Banyak layanan seperti DynamoDB dan Lambda punya kasus penggunaan yang sangat spesifik
    Jangan memakai key-value store yang menyenangkan sebagai database
  • Beberapa tahun lalu saat membuat aplikasi, saya butuh DB untuk menyimpan sekitar 50 juta record, sekitar 10 ribu operasi baca+tulis per bulan, dan 1 indeks
    Biaya pemuatan awal sekitar $50, lalu biaya maintenance setelahnya ada di level seperti 10 sen per bulan

• Tulisan seperti ini selalu membuat saya tersenyum
  Sekaligus benar dan salah, dan sistem harus dibuat “sesederhana mungkin, tetapi tidak lebih sederhana dari itu”
  Jika Anda merasa bisa mengabaikan detail, nanti justru kerepotannya lebih besar
  IAM memang kompleks
  Saya tidak terpikir satu pun contoh implementasi yang benar-benar sederhana untuk user, group, role, policy, identity provider, dan OIDC
  Saya pernah melihat seseorang yang menolak adopsi Kubernetes karena “terlalu kompleks”, lalu akhirnya merekayasa ulang Kubernetes dengan cara buruk dan serba sementara memakai Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash, ludah, dan tali rafia sambil membuat banyak kesalahan
  Kadang Anda merasa fitur tertentu tidak dibutuhkan, lalu akhirnya ternyata dibutuhkan
  Dari pengalaman bekerja sebagai satu-satunya penanggung jawab infrastruktur di startup, AWS masih berada dalam cakupan yang bisa dipelajari kebanyakan orang, dan bagian yang jelek biasanya bisa dihindari
  Kalau tidak suka Lambda, jangan pakai; pakai saja EKS, ECS, EC2

  • Dari sudut pandang internal, IAM memang punya ribuan opsi, tetapi intinya hanyalah “apa yang bisa diakses dan dilakukan role ini terhadap apa (aksi+resource)” dan “siapa yang bisa mengakses role ini”
    Jika dilihat dari ketinggian 10.000 kaki, cuma itu isinya
    Alasan IAM bagus adalah karena hal yang sama berlaku untuk pihak luar maupun pihak dalam
    Tim internal AWS tidak otomatis punya akses lebih besar; jika mereka mendapat hak untuk melakukan sesuatu di akun pelanggan demi menjalankan layanan tertentu, itu karena pelanggan memasukkan service principal ke dalam hubungan kepercayaan IAM untuk mengizinkan akses, dan pelanggan bisa melihat serta mengauditnya
    Misalnya Lambda punya Lambda role, karena Anda tentu tidak ingin layanan Lambda membaca bucket S3 hanya dengan alasan “kami AWS, jadi aksesnya otomatis”
    Bahkan akses internal AWS pun bisa dilihat dan dikendalikan dengan jelas oleh pelanggan
  • Pola “X terlalu kompleks” lalu menghalangi adopsi, tetapi akhirnya merekayasa ulang X dengan cara buruk, sangat sering muncul dalam teknologi dan perangkat lunak
    Beberapa hal sekarang sudah jelas menjadi standar, tetapi banyak orang tetap menolak meluangkan waktu untuk mempelajarinya dengan benar
  • AWS mungkin lebih mahal daripada self-hosting, tetapi penghematan itu menjadi kecil dibanding biaya engineering
    Jika seorang engineer infrastruktur yang lumayan menghabiskan dua bulan pada setup OVH demi “menghemat uang”, itu akan lebih mahal daripada uang yang bisa dihemat dengan tidak langsung memakai Fargate atau RDS

• Saya penasaran kapan kisah yang sama akan mulai muncul juga untuk Anthropic, OpenAI, dan sejenisnya
  Arus AI saat ini berbau mirip masa awal AWS, dan semua orang tampaknya akan ikut naik lalu belakangan sadar bahwa mereka telah membangun ketergantungan besar yang tidak mudah dilepas

• Lambda benar-benar keren, dan menurut saya itu cara terbaik menjalankan layanan deployment dengan siklus iterasi cepat tanpa bikin pusing
  Tidak harus sampai memakai microservices atau memecah kode ke puluhan miliar repositori kecil
  Selama Anda tidak berharap bisa berbagi state dalam server antar-request, web server standar bisa dipindahkan ke Lambda

• Saya tidak bekerja di bidang itu, jadi AWS paling cuma saya sentuh sesekali untuk proyek iseng pribadi, dan setiap kali rasanya seperti mimpi buruk
  Saya cuma ingin membuat satu server permainan kartu untuk eksperimen, bukan mendirikan lembaga keuangan baru, tetapi semuanya terlihat seolah-olah dibuat untuk siap diskalakan tanpa batas besok juga, dengan asumsi organisasi seribu orang dan anggaran VC
  Untungnya ada layanan seperti Netlify yang menutupi permukaannya sehingga saya tidak perlu merebus lautan
  Mungkin suatu hari saya harus benar-benar belajar IAM, VPN, dan entah apa lagi, tetapi sampai saat itu setiap kali menyentuh AWS rasanya mata saya mau copot

  • Tinggal jalankan VPS mentah di EC2 atau Lightsail, pasang IP publik, lalu selesai
    Tidak harus menerapkan semua pola enterprise
  • Menakjubkan bahwa Heroku hampir 20 tahun lalu benar-benar tepat sasaran dalam memenuhi kebutuhan sebagian besar web app
  • Jika belum pernah memakai Azure, mungkin hanya AWS yang terasa seperti mimpi buruk
  • Saya pindah ke Cloudflare dan rasanya benar-benar lega
    Semua yang saya butuhkan ada, dan harganya masuk akal
  • AWS menargetkan enterprise, bukan proyek pribadi
    Proyek pribadi pada akhirnya hanya peduli biaya sehingga tidak memberi AWS pendapatan yang berarti

• Sejak 2023, tenaga teknis di AWS dikosongkan secara sistematis
  Itu terjadi lewat PHK besar-besaran atau dua putaran performance improvement plan, dan banyak rekan yang kompeten di prapenjualan maupun support sudah tidak lagi berada di AWS
  Sebaliknya, saya sering melihat orang-orang dengan rekam kerja paling samar justru bertahan dan dipromosikan
  AWS dipakai dengan risiko masing-masing, dan Paul Vixie tidak akan datang untuk menyelamatkan Anda

• Sejak lama ElastiCache terasa sangat mengganggu bagi saya
  RDS memberi nilai tambah seperti skalabilitas, konfigurasi yang cukup dioptimalkan, dan backup yang tidak perlu dipikirkan, jadi saya masih bisa menerima membayarnya
  Tetapi ElastiCache hampir tidak memberi nilai tambah, sementara harganya terasa eksploitatif
  Dibanding instalasi Redis biasa, ia lebih lambat, kurang dioptimalkan, kurang stabil, dan Redis tanpa konfigurasi apa pun mendukung banyak DB sedangkan ElastiCache hanya mendukung satu
  Ada sedikit peningkatan skalabilitas, tetapi karena Redis biasa di instance serupa sudah jauh mengungguli ElastiCache, kasus di mana peningkatan itu benar-benar dibutuhkan sangat jarang

  • ElastiCache jelas salah satu layanan yang layak dipertimbangkan untuk self-hosting
    AWS tidak banyak menambahkan dari sisi API atau kematangan produk, sementara Redis/Valkey justru merupakan salah satu layanan yang paling sederhana untuk di-host sendiri