Saya kembali ke AWS, dan sadar lagi kenapa saya pergi

• Sejak awal mendukung AWS, tetapi setelah penanganan client library diserahkan ke komunitas, lambatnya transisi ke Python 3, penagihan dan IAM yang rumit, serta lock-in AWS Lambda menumpuk, saya tidak lagi menyukai AWS
• Setelah memakai DynamoDB, saya pernah mendapat tagihan 75 dolar dalam sehari, dan meski biaya transfer data turun dari 20 sen menjadi 9 sen per GB, struktur penagihan yang tetap membebankan perpindahan data internal masih dianggap mahal dan sulit dipahami
• Setelah meninggalkan AWS, saya menutup hampir semua akun, tetapi masih menyisakan domain Route53, sebagian backup S3, dan AWS WorkMail, lalu kemudian menerima pemberitahuan bahwa WorkMail akan dihentikan dalam 12 bulan
• Baru-baru ini saya login lagi ke AWS untuk menguji cara kerja Claude/Anthropic di AWS Bedrock dan menguji EC2 Spot 192 core · 1TB RAM; saya menilai Bedrock bekerja sama, tetapi lebih lambat dan jauh lebih mahal dibanding langganan Anthropic
• Saat pengujian EC2 Spot sekitar 3 jam, setelah muncul peringatan Suspected security breach, akun saya dibatasi sehingga email WorkMail untuk bisnis dan pembuatan resource terblokir, dan bahkan setelah tindakan lanjutan serta dukungan chat, pembatasan itu tidak dicabut selama 4 hari sehingga saya memutuskan memindahkan AWS WorkMail dan Route53 juga

---

Dari pendukung awal AWS hingga pergi

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

Keluhan terhadap AWS yang menumpuk seiring waktu

• Client library dan transisi Python

  • Selama 6 tahun awal, AWS tidak membuat client library sendiri dan membiarkan komunitas mengimplementasikan library untuk bahasa seperti Python, yang terasa seperti melempar beban kepada para programmer yang mengorbankan waktunya secara gratis
  • Fakta bahwa AWS butuh waktu terlalu lama untuk berpindah dari Python 2 ke Python 3 juga tetap menjadi keluhan besar

• DynamoDB dan pengalaman biaya

  • Setelah menggunakan DynamoDB, saya mendapat tagihan 75 dolar di akhir hari, dan bukan hanya biayanya, sistem itu sendiri juga terasa seperti bentuk terburuk yang bisa dibayangkan

• Biaya transfer data dan penagihan yang rumit

  • Dulu biaya transfer data keluar AWS adalah 20 sen per GB dan kemudian turun menjadi 9 sen per GB, tetapi saya tetap menganggapnya sangat mahal
  • Perpindahan data antar sistem internal AWS juga dikenai biaya, dan dalam beberapa kasus strukturnya terasa seperti tagihan ganda atau tiga kali, sehingga tanpa pemahaman mendalam sulit menghindari jebakan biaya

• IAM dan kompleksitas secara umum

  • IAM adalah sistem yang menangani autentikasi dan aturan akses, tetapi terasa memiliki struktur yang terlalu rumit
  • Pendukung AWS mengatakan kita harus memakai AWS karena menjalankan Linux, hardware, networking, dan keamanan sendiri terlalu rumit, tetapi saya melihat hampir semua area AWS sendiri juga punya kompleksitas besar, sehingga pada akhirnya tetap memerlukan tim ahli yang mahal

• AWS Lambda dan lock-in

  • AWS Lambda menjanjikan skalabilitas, tetapi menuntut kita menerima waktu startup yang lambat dan kompleksitas pengembangan yang besar
  • Dibanding menjalankan web server sendiri, saya merasa tidak ada keuntungan nyata dan justru banyak kekurangan, dan saat meninggalkan AWS, bagian yang paling sulit dibalikkan adalah AWS Lambda
  • Menggunakan AWS Lambda menjadi pengalaman yang menegaskan bahwa vendor lock-in itu nyata, dan terasa seperti pilihan yang terus harus diyakinkan sendiri sebagai sesuatu yang lebih baik

• Proyek open source dan pendapatan hosting

  • Saya melihat AWS tetap mendorong OpenSearch, Valkey, dan DocumentDB meskipun proyek seperti Elasticsearch, Redis, dan MongoDB telah menyatakan tidak ingin proyek mereka disalin dan dimonetisasi
  • Setelah komunitas dan perusahaan terkait menciptakan pasar, AWS mengambil pendapatan layanan hostingnya, dan akibatnya lisensi defensif seperti SSPL, Elastic License, RSAL, serta model source-available makin bertambah

Beberapa layanan yang masih ditinggalkan setelah keluar dari AWS

• Setelah ketertarikan saya pada AWS benar-benar hilang, saya memindahkan semuanya ke luar AWS dan menutup hampir semua akun
• Namun, saat itu saya tetap menyisakan beberapa layanan yang menurut saya memang merupakan solusi yang tepat
• Yang saya sisakan adalah domain di Route53, sebagian backup di S3, dan AWS WorkMail
• AWS WorkMail kemudian memberi tahu bahwa layanan itu akan dihentikan dalam 12 bulan

Alasan saya sempat kembali ke AWS

• Baru-baru ini saya login lagi ke AWS untuk riset dan pengujian
• Saya ingin memeriksa seberapa baik Claude/Anthropic berjalan di AWS Bedrock, dan untuk Claude Code saya menilai hasilnya sama, tetapi lebih lambat dan jauh lebih mahal dibanding langganan Anthropic
• Perangkat rumah tercepat yang saya miliki adalah CPU 20 core dengan RAM 32GB, dan saya ingin melakukan benchmark seberapa cepat kode berjalan di mesin 192 core dan 1TB RAM
• Sekitar sebulan lalu, pengujian AWS Bedrock selesai tanpa masalah, dan setelah pengujian semuanya dimatikan
• AWS Bedrock mungkin berguna jika privasi dibutuhkan, tetapi karena biayanya saya merasa tidak akan memakai Claude lagi melalui AWS Bedrock

Pembatasan akun saat pengujian EC2 Spot

• Setelah itu saya menjalankan instance EC2 Spot 192 core dan sedang mengujinya selama sekitar 3 jam ketika menerima email AWS bertuliskan “Suspected security breach of your account”
• Saya menduga alarm keamanan internal AWS mungkin terpicu karena akun yang hampir dorman tiba-tiba mulai memakai resource komputasi mahal
• Saya memahami dan menilai positif tujuan AWS untuk melindungi pengguna
• Namun AWS menangguhkan atau membatasi akun saya, dan akibatnya akun email bisnis utama yang memakai AWS WorkMail berhenti berfungsi
• Tidak ada lagi yang bisa mengirim email kepada saya, dan saya juga tidak bisa membuat resource AWS apa pun, sehingga pengujian yang semula ingin saya lakukan pun tidak bisa dilanjutkan

Respons dukungan dan keterlambatan

• Saya membalas notifikasi dukungan AWS dan memberi tahu bahwa akun saya tidak diretas serta tidak ada masalah maupun keanehan penagihan, tetapi tidak ada respons
• Karena saya tidak memakai premium support, saya harus menunggu waktu respons 24 jam yang disebut AWS, tetapi bahkan setelah 3 hari tetap tidak ada balasan dari dukungan AWS
• Setelah meminta bantuan di forum AWS, saya mendapat saran untuk mengikuti instruksi di email dan memakai chat alih-alih web
• Saya melakukan semua tindakan yang diminta seperti mengganti kata sandi, menghapus access token, memeriksa riwayat tagihan, lalu menunggu sekitar 30 menit sampai terhubung ke chat dan berbicara lama dengan petugas AWS
• Petugas itu tampak puas dan berkata akan meminta tim internal terkait menanganinya, tetapi bahkan setelah 24 jam pembatasan itu tetap tidak dicabut
• Delapan jam kemudian, saat saya menindaklanjuti lagi, saya hanya mendapat jawaban “harap menunggu”

Kesimpulan yang kembali ditegaskan

• Bahkan setelah 4 hari sejak akun dibatasi, saya masih punya pekerjaan yang ingin diuji di mesin besar, dan saya mulai khawatir harus mengajukan permintaan “quota” lagi untuk itu
• Sistem email bisnis saya masih belum berfungsi
• Pengalaman kembali kali ini kembali menegaskan alasan saya meninggalkan AWS, dan saya memutuskan harus keluar dari AWS WorkMail serta memindahkan domain di Route53 agar tidak pernah kembali lagi
• Saya sangat bersyukur dulu sudah memindahkan banyak hal keluar dari AWS, tetapi fakta bahwa sistem email yang saya percaya dan biarkan tetap di sana ikut terhenti dalam proses kembali ke AWS ini saya anggap sebagai kegagalan
• AWS mungkin suatu saat akan membuka kembali pembatasan akun saya, tetapi tidak ada yang tahu kapan waktunya

[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