Mengikuti panduan resmi AWS Amplify malah ditagih biaya $1.100

 (elliott-king.github.io)
1 poin oleh GN⁺ 2024-11-15 | 1 komentar | Bagikan ke WhatsApp
  • Setelah bereksperimen dengan panduan resmi integrasi OpenSearch di AWS Amplify, biaya Amazon OpenSearch Service naik hingga $1.124,88 dalam sebulan meski pemakaian tidak banyak
  • Biaya terjadi karena domain OpenSearch yang dibuat oleh npx ampx sandbox tetap tertinggal setelah sandbox dihentikan dan dihapus, lalu domain baru ditambahkan pada eksekusi berikutnya sehingga terakumulasi
  • Konfigurasi resmi secara default membuat instans r5.large.search, tetapi nilai dasar minimum sekitar $134 per bulan tidak terlihat jelas di kode boilerplate maupun panduan
  • AWS Support memberikan kredit satu kali untuk OpenSearch dan storage, serta meminta pengaturan AWS Budgets untuk mencegah kejadian serupa
  • Saat memakai Amplify dan OpenSearch bersama, perlu memeriksa langsung resource yang tersisa setelah menghapus sandbox dan tipe instans default agar terhindar dari tagihan tak terduga

Biaya OpenSearch yang tak terduga

  • Setelah mengikuti panduan resmi integrasi OpenSearch di AWS Amplify, beberapa minggu kemudian tagihan AWS muncul lebih dari $1.200
  • Layanan yang terdeteksi lewat permintaan ke Support adalah Amazon OpenSearch Service, dengan total bulanan $1.124,88
  • Penulis juga pernah memakai Amplify dan OpenSearch pada 2020, dan untuk penggunaan pribadi biasanya sekitar $50 per bulan—mahal, tetapi bukan sampai $1.200
  • Setelah peninjauan detail, AWS Customer Support memproses penyesuaian tagihan dalam bentuk one time courtesy untuk biaya tak terduga tersebut
  • Dalam proses Support, diberikan kredit untuk OpenSearch dan layanan storage, serta diminta menyiapkan AWS Budgets
    • AWS Budgets dapat memproyeksikan pengeluaran mendatang untuk layanan tertentu atau seluruh AWS, lalu mengirim notifikasi jika diperkirakan melewati anggaran

Resource yang dibuat panduan resmi

  • Quickstart Amplify membuat aplikasi contoh TODO note memakai kode yang disediakan AWS, dan Amplify membuat database DynamoDB serta permintaan CRUD terautentikasi
  • Bisa dijalankan secara lokal, tetapi Amplify juga membuat domain yang bisa diakses
  • Pada tahap konfigurasi OpenSearch, ditulis boilerplate TypeScript untuk mendeklarasikan resource Amplify
    • Menetapkan tabel DynamoDB sebagai variabel untuk dirujuk di pipeline
    • Membuat instans OpenSearch, index, dan indexMapping
    • Menulis kueri untuk mengakses data yang ada di OpenSearch
    • Membuat pipeline OpenSearchIngestionService yang menyalin data dari DynamoDB ke OpenSearch
  • Konfigurasi terkait dikelola sebagai TypeScript/JavaScript di dalam repositori bersama kode frontend
  • npx ampx sandbox menyalakan layanan AWS dan otomatis memodifikasi layanan AWS yang ada ketika mendeteksi perubahan konfigurasi

Domain yang tersisa meski sandbox dihapus

  • Konfigurasi ini mencakup database DynamoDB, 1 layanan OpenSearch, 1 pipeline OSIS, role IAM, dan berbagai resource lain
  • Boilerplate resmi secara default membuat instans OpenSearch r5.large.search
    • Nilai default ini tidak ditampilkan secara eksplisit di kode boilerplate maupun panduan
    • r5.large.search menelan biaya minimum sekitar $134 per bulan
  • Setelah selesai bekerja seharian dan menghentikan sandbox dengan CTRL-C, muncul prompt yang menanyakan apakah ingin menghapus permanen, dan pengguna bisa memilih Y
  • Pada saat itu DynamoDB memang dihapus, tetapi di AWS Console domain OpenSearch tetap tertinggal
  • Keesokan harinya saat menjalankan npx ampx sandbox lagi, instans OpenSearch baru dibuat, dan npx ampx sandbox delete juga tidak menghapus instans yang lama
  • Jika proses yang sama diulang, beberapa domain OpenSearch akan tertinggal di latar belakang dalam proyek yang sama dan biayanya terus menumpuk

Kemungkinan bug dan tipe instans default

  • Perilaku ini terlihat seperti footgun besar, dan bahkan setelah tiket AWS Support dibuat, saat itu masalahnya belum terselesaikan
  • Ada laporan bug lama yang berkaitan, tetapi tidak ditemukan entri dalam 1 tahun terakhir
  • Mungkin saja domain OpenSearch terhapus dengan benar di v1 tetapi tidak di v2, namun penyebab pastinya belum dikonfirmasi
  • Alur saat ini dijalankan lewat npx, bukan Amplify CLI
  • Fakta bahwa r5.large.search menjadi tipe mesin default juga tetap menjadi faktor risiko
    • Akan lebih baik jika ditetapkan sebagai field wajib tanpa nilai default
    • Jika panduan menampilkan r5.large.search sebagai default, pengguna akan lebih mudah menyadarinya
    • Default ini bukan khusus Amplify, melainkan bagian dari AWS CDK, sehingga tidak dianggap sepenuhnya tanggung jawab tim Amplify

Hal yang perlu diperhatikan saat memakai Amplify dan OpenSearch

  • Memang sudah diduga bahwa alat yang mempercepat pengembangan teknologi baru bisa lebih mahal daripada bare metal, tetapi biaya kali ini dinilai sudah jauh melampaui itu
  • Dengan budget console AWS, pengguna bisa mendapat peringatan saat pengeluaran yang diperkirakan melebihi anggaran
  • Hanya dengan mengikuti bagian OpenSearch saja, akan dibuat akun IAM, domain OpenSearch, pipeline OSIS, log group, dan storage S3, sehingga ada banyak resource tersembunyi
  • OpenSearch adalah layanan yang sering dipakai pelanggan enterprise, sehingga dianggap sebagai layanan “lanjutan” dan pengguna mungkin diasumsikan lebih memahami ekosistem AWS
  • OpenSearch dipakai karena dukungan kueri bounding-box geo_point, tetapi penulis tidak yakin apakah produk yang lebih sederhana sebenarnya sudah cukup
  • Menurut pembaruan, panduan AWS kemudian diperbaiki; tiga bulan sebelumnya saat masalah pertama kali diangkat belum diperbarui, tetapi sebelum tulisan dipublikasikan tampaknya pekerjaan PR dokumentasi sudah dimulai

Bacaan terkait

1 komentar

 
GN⁺ 2024-11-15
Opini Hacker News

  • Peringatan tagihan itu seperti lelucon; yang sebenarnya dibutuhkan adalah batas pengeluaran keras
    Saat onboarding, mereka juga harus menyediakan cara untuk menetapkan batas itu
    Membangun bisnis di atas cek kosong dan penagihan tak disengaja itu mencurigakan, dan juga menjadi hambatan adopsi yang besar
    Semakin sering developer melihat kasus seperti “saya mengikuti tutorial 20 menit lalu ditagih sebesar tabungan seumur hidup; kali ini dukungan pelanggan membebaskannya, tapi lain kali sepertinya mereka akan mengambil rumah saya juga”, semakin mereka tidak ingin mengeksplorasi produk AWS

    • Ini bukan hanya masalah AWS; penyedia cloud pada umumnya tampaknya hanya terbagi dua
      Yang mengalihkan risiko ke pelanggan seperti AWS atau DigitalOcean, dan yang menjual paket harga mencurigakan “tanpa batas”·“tanpa metering”
      Keduanya bukan bentuk yang saya inginkan
      Saya berharap ada penyedia yang memungkinkan perencanaan kapasitas dengan benar lewat batas yang jelas dan terdokumentasi, sementara risiko ketersediaan ditanggung pelanggan tetapi risiko finansial ditanggung penyedia
      Kalau tidak berlebihan, saya juga bersedia membayar biaya tetap yang lebih tinggi
    • Batas pengeluaran keras hampir kontraproduktif bagi pelanggan enterprise, pelanggan inti AWS
      Hampir tidak ada penagihan tak disengaja yang murah dibandingkan downtime atau kehilangan data pada aplikasi penting
      Meski hanya berupa opsi, tim akuntansi bisa menekan agar itu digunakan, dan saat terjadi masalah ada risiko berujung pada insiden kehilangan data
      Ini mungkin masuk akal untuk penyedia cloud yang berfokus pada developer indie atau UKM
    • Beberapa komentar HN pernah menyebut bahwa kode billing AWS adalah kode spaghetti raksasa, sehingga secara internal ada ketakutan besar untuk menyentuh perubahan besar
      Ini termasuk salah satu urusan internal yang cukup menarik yang saya ketahui dari sana
    • Saya pernah tertarik pada AWS, tetapi karena alasan seperti ini saya tidak pernah benar-benar berani masuk
      Lebih aman memakai VPS yang murah dan berbiaya tetap daripada menyesal
    • Ini harus diregulasi
      Meminta Amazon melakukan sesuatu tidak banyak artinya
      Amazon dan perusahaan lain harus dipaksa lewat hukum untuk menghormati uang pengguna
      Perusahaan pada dasarnya tidak melakukan hal yang etis atau baik bagi ekonomi, melainkan hal yang menghasilkan uang

  • Dibandingkan ini memang sepele, tetapi ketika mencoba men-deploy aplikasi ke ECS, saya mendapat tagihan 100 dolar dan memutuskan tidak akan memakai AWS lagi
    Error yang membuat layanan tidak berjalan memang masalah di aplikasi saya, tetapi log CloudWatch hanya keluar sekitar 20%, jadi untuk mendapatkan log saya harus redeploy lima kali, memperbaiki, lalu redeploy lima kali lagi
    Setiap deployment yang gagal ditagih, dan setelah sekitar dua hari bergulat saya menghapus akun lalu men-deploy ke DigitalOcean App Platform
    Di sana deployment juga gagal karena error aplikasi, tetapi log selalu muncul setiap kali; dalam 10 menit saya memperbaikinya dan menjalankannya, dengan total tagihan hanya beberapa sen
    Sejak hari itu saya bertekad tidak akan pernah memakai AWS jika ada pilihan, dan juga tidak akan merekomendasikannya

    • Saya hanya pernah memakai Azure, dan ECS sepertinya setara dengan Azure Container Apps
      Untuk pengembangan dan pengujian, model penagihan berbasis konsumsi sangat murah
      Saya tidak tahu bagaimana untuk workload besar, tetapi ditagih per deployment itu aneh
    • Saya menyerah pada AWS setelah mengetahui bahwa tidak bisa men-deploy container langsung ke EC2 seperti di GCP
      Untuk proyek besar mungkin dukungannya lebih baik, tetapi untuk skala kecil hingga menengah, GCP jauh lebih baik
      Ia punya komponen dasar yang sesuai dengan cara penggunaan container saat ini, dan juga ada BigQuery

  • Sepertinya ada bug yang jelas pada skrip yang dijalankan perintah npx itu
    Penulisnya benar; kalau ini tutorial, 100% harus memilih resource termurah, dan menjalankan sub-skrip delete harus membersihkan resource
    Tidak adil mengharapkan developer, setelah menjalankan hal seperti ini, memeriksa seluruh akun AWS secara paranoid untuk mencari resource yang tersisa
    Kalau sebuah startup berperilaku seperti ini, apakah orang akan menganggapnya sekadar “memang hal seperti ini terjadi, jadi harus hati-hati”?
    Saya tidak mengerti mengapa AWS diberi standar yang berbeda

    • Itulah bagian paling menyebalkan dari AWS
      Tidak ada cara mudah untuk melihat semua resource yang saat ini sedang saya bayar
      Kalaupun ada, saya belum menemukannya
      Tanpa ringkasan yang mudah dipahami, rasanya saya tidak sepenuhnya mengendalikan akun saya
    • Saat harus memakai sesuatu yang baru, hal pertama yang saya cek adalah apakah saya bisa mendapat tagihan tetap setiap bulan
      Saya juga melihat apa yang terjadi jika pemakaian melebihi itu, dan apakah penagihan tak terduga bisa dibatasi
      Kalau tidak bisa, saya mencari yang lain
      Sejak perubahan billing Google Maps beberapa tahun lalu, kami juga sangat berhati-hati untuk terlalu terikat pada layanan Google yang “gratis”, dan pada akhirnya itu memakan biaya besar
    • Apakah memang ada cara sederhana untuk mencantumkan semua resource yang ada di akun AWS?
      Selama ini saya harus mengecek per layanan dan per region, dan itu membosankan sekaligus rawan error
    • Dari sudut pandang Amazon, ini bukan bug melainkan fitur, karena bisa menghasilkan 1000 dolar dengan mudah
      Bahkan kalau mereka menganggapnya bug, prioritasnya pasti jauh lebih rendah daripada hal lain yang langsung merugikan laba-rugi mereka
    • Saya setuju bahwa tidak adil mengharapkan developer melakukan pemeriksaan paranoid
      Namun secara realistis, itu masuk akal
      Saat membuat sesuatu di AWS, saya memperlakukan AWS seperti lembaga keuangan bermusuhan yang lepas kendali

  • Karena kasus seperti ini, sudah bertahun-tahun saya menunda untuk mendalami AWS
    Seharusnya ada kurikulum standar yang memungkinkan orang bereksperimen secara gratis tanpa meminta informasi kartu kredit
    Namun sepertinya ada orang-orang kantoran yang menghitung bahwa mereka bisa menarik ribuan dolar dari sana-sini sebagai “kesalahan pengguna”
    Tagihan seperti ini sulit dibantah, dan dalam beberapa kasus bahkan mustahil
    Saya rasa bukan cuma saya yang menghindari lingkungan AWS karena ketakutan yang wajar bahwa suatu hari bisa bangun dan melihat tagihan besar

    • Dalam situasi seperti ini, sangat tidak biasa bagi AWS untuk tidak memberi pengembalian dana, jadi sulit melihatnya sebagai strategi untuk memeras ribuan dolar dari kesalahan pengguna
      Kemungkinan besar mereka menilai memproses pengembalian dana lebih ringan bebannya daripada menyediakan tutorial yang akurat dan murah
      Itu tidak membenarkan tindakannya, tetapi saya pernah berhasil membatalkan tagihan 600 dolar yang sebenarnya sah muncul saat menggunakan AWS Textract
      Saat itu saya bekerja di perusahaan bernilai puluhan miliar dolar
    • Menurut saya alasan orang terjebak dalam situasi pembayaran seperti ini adalah karena mereka sebenarnya tidak mendalami AWS
      Daftar harga mudah diakses dan tidak selalu mudah dipahami, tetapi sebagian besar biaya meningkat hampir secara linear, sehingga relatif mudah diuji
      Sebaiknya hindari layanan wrapper seperti AWS Amplify, CloudFormation, dan berbagai jenis Stack
      Gunakan layanan intinya secara langsung
      Setiap layanan punya API, dan mendapatkan API key yang terikat ke pengguna IAM semudah mengklik tombol
      Sisanya bisa dikelola dengan caching yang tepat dan menyesuaikan model biaya dengan model pendapatan
      Buat biaya layanan yang autoscaling menjadi proporsi pendapatan yang hampir tetap, terlepas dari permintaan saat ini
      Bandwidth adalah mimpi buruk yang sebenarnya di AWS, tetapi konsol menyediakan diskon jangka panjang otomatis, dan melalui perwakilan sales Anda bisa mendapatkan diskon kontrak yang sedikit lebih baik
      Karena itu saya cenderung menghindari EC2; bandwidth internal EC2 juga lebih mahal, jadi menurut saya lebih baik memakai Lambda + S3 + CloudFront secara langsung
      Setelah sekitar 3 bulan, saya menjadi cukup mudah memprediksi kombinasi layanan mana yang paling hemat biaya saat mengimplementasikan fitur baru yang berhadapan dengan pengguna
    • A Cloud Guru / Pluralsight punya fitur yang mereka sebut “Cloud Playground” atau “sandboxes”
      Mungkin bisa dipakai untuk tujuan seperti itu, tetapi saya belum mencobanya langsung jadi tidak yakin
    • Uang yang muncul dari kesalahan pengguna semacam ini kemungkinan hanya setetes air di lautan bagi AWS secara keseluruhan
      Dari pengalaman saya, AWS lebih cenderung menghindari masalah yang bisa menimbulkan biaya lebih besar akibat rusaknya reputasi
      AWS tidak murah, dan dalam beberapa kasus sangat mahal terutama untuk biaya transfer data, tetapi menurut saya menipu pelanggan agar secara tidak sengaja menghabiskan beberapa ratus dolar lebih banyak bukanlah cara kerja mereka

  • Menurut saya ini sangat khas AWS
    Beberapa bulan lalu saya mengikuti panduan quick start SageMaker resmi untuk menjalankan Llama 2; memang benar-benar cepat menyala, tetapi keesokan harinya saya melihat biaya 400 dolar per hari sedang berjalan
    Tagihannya berhasil dibatalkan, tetapi saya jelas belajar bahwa panduan resmi tidak boleh dipercaya begitu saja

    • SageMaker adalah salah satu yang paling mengecewakan dari sudut pandang produk, dan merupakan contoh jelas enshittification
      Pada masa awal produk, sekitar 2017–2018, pengaturannya cukup intuitif
      Notebook instance, inference, REST API untuk serving, sedikit EFS, dan fakta bahwa pusat layanannya adalah S3 semuanya jelas
      Harganya juga tertutup, jadi tidak ada kejutan
      Secara keseluruhan rasanya seperti DigitalOcean, dan data scientist dengan pengetahuan dasar infrastruktur serta rasa ingin tahu pun bisa membuat konfigurasi yang murah, dapat diprediksi, dan sederhana
      Sekarang ada Wrangler, Feature Store, RStudio; pengalaman pengguna konsol notebook buruk sekali, dan di dalamnya berbagai layanan memindahkan data lalu menagihnya

  • Karena keadaan tertentu saya harus mengirim permintaan HTTP mentah alih-alih SDK AWS yang bongsor, dan gagal dengan header content-type: application/json tetapi berhasil dengan content-type: application/x-amz-json-1.0
    Saya benar-benar berharap nonsense seperti ini berhenti

    • Saya merasakan hal serupa di hampir semua bagian AWS yang pernah saya sentuh sepanjang karier
      Terlalu bongsor tanpa manfaat yang jelas, terlalu rumit, atau banyak implementasi buatan sendiri yang aneh
    • Jujur saja, itu detail internal yang bocor keluar
      Secara internal sebagian besar aplikasi memakai framework Coral lama, dan menggunakan format JSON ini yang memiliki bentuk input, output, dan error yang terdefinisi dengan baik

  • Semua panduan resmi AWS dirancang agar Anda memakai sebanyak mungkin layanan AWS, dan risiko pengeluaran pun meningkat sebanding dengan itu
    Anda harus sangat kritis terhadap apa pun yang direkomendasikan AWS: default GUI, tool CLI, panduan, arsitektur rekomendasi, dan sebagainya
    Ada alasan mengapa perusahaan punya posisi bergaji tinggi untuk memandu rekan kerja agar menggunakan AWS secara hemat biaya dan berisiko rendah

    • Benar
      Dalam deployment kecil atau pengujian, bagian paling mahal hampir selalu hal-hal sampingan, atau layanan terbaru yang direkomendasikan alih-alih alternatif yang lebih sederhana

  • Jika Anda memakai OpenSearch karena kueri bounding box geo_point, bagaimana dengan PostgreSQL + PostGIS?
    https://postgis.net/docs/using_postgis_query.html

  • Menurut saya setup yang tanpa hambatan seperti ini, pengalaman dan antarmuka pengguna yang tidak intuitif, rendahnya kewaspadaan terhadap pendaftaran kartu kredit, serta penagihan terbundel antar layanan seperti AWS Batch + Lambda + EC2 adalah bagian dari model bisnisnya
    Saya tidak tahu harus menggambarkannya bagaimana, tetapi ini mirip taman hiburan modern: setelah membayar tiket masuk, semua wahana dan bahkan toilet pun harus dibayar terpisah

    • Saya juga merasakannya begitu
      Model penagihan cloud memindahkan tanggung jawab ke pengguna atas nama “fleksibilitas” dan “kustomisasi”
      Bayangkan perusahaan rental mobil menagih setiap komponen dalam satuan milidetik—putaran camshaft mesin, putaran ban, kerja wiper, waktu pemanas kursi—lalu berkata pelanggan “mengendalikan” pemakaian dan anggarannya karena bisa memasang notifikasi untuk tiap item
      Sejak default-nya, ini adalah model biaya yang berbahaya dan memusuhi pengguna