Kesalahan Setup AWS Pertama Kali & Cara Optimasi Cost-nya

Pelajaran Berharga dari Kesalahan Setup AWS Pertama Kali (dan Cara Optimasi Cost-nya) Biar Tagihan Nggak Bikin Kaget!

This image was created with the help of partyrock.aws

Saat pertama kali setup layanan di AWS, saya banyak belajar — atau lebih tepatnya, banyak melakukan kesalahan yang akhirnya jadi pembelajaran berharga. Berharga banget, karena yang pertama kali kasih tahu biasanya bukan tim engineering, bukan juga alert monitoring, tapi… billing AWS! Ini gimana nggak berharga, kan yang ngabarin langsung cost-nya yang tiba-tiba naik drastis. 😆

Sebagai sedikit konteks, saya saat ini bekerja sebagai Head of Engineering di sebuah SaaS startup di Medan, Indonesia.

Tapi, kesalahan-kesalahan ini saya alami ketika masih menjadi mobile developer di perusahaan yang sama. Awalnya, saya mulai ikut menangani backend karena sering harus menunggu API dari tim backend. Setelah backend selesai, giliran harus menunggu lagi tim DevOps untuk setup dan deploy ke AWS. Supaya tidak terlalu lama bergantung pada tim lain, saya akhirnya mulai belajar mencoba menghandle langsung AWS dan API backendnya.

Dari sinilah perjalanan saya di AWS dimulai — dan tentunya, kesalahan demi kesalahan juga bermunculan. Lucunya, banyak dari kesalahan ini tidak langsung terlihat di bulan pertama karena masih tertolong oleh free tier. Baru setelah beberapa bulan, mulai terasa dampaknya di billing.

#1 : Mengaktifkan Log di CloudWatch Tanpa Retention dan Log Minimum Level

Salah satu kesalahan pertama yang saya buat adalah mengaktifkan logging di CloudWatch tanpa memperhatikan retensi data dan level log yang disimpan. Secara konsep, logging itu penting banget buat troubleshooting. Kalau nggak ada log, setiap kali ada masalah di service, kita bakal jadi dukun atau cenayang yang harus menebak-nebak apa yang salah. 😂

Tapi, yang saya lakukan waktu itu adalah menyimpan semua log tanpa filter levelnya. Jadi, semua log dari level Info, Warning, Debug, sampai Error disimpan. Hasilnya? Storage log di CloudWatch cepat membengkak, dan biaya log data ingested serta log data scanned dari CloudWatch Logs Insights jadi mahal banget. Masalah ini baru ketahuan setelah beberapa bulan, saat billing CloudWatch mulai merangkak naik.

Solusi yang Kami Lakukan:

Menyesuaikan level log minimum ke Error saja supaya tidak terlalu banyak data yang disimpan.
Menetapkan retensi log sesuai kebutuhan. Kalau log hanya dibutuhkan untuk troubleshooting dalam 7 hari terakhir, set retention ke 7 hari (default-nya adalah “never expire”).
Menggunakan CloudWatch Logs Insights queries hanya saat diperlukan agar tidak memicu biaya berlebihan.

Referensi

#2 : Tidak Mengaktifkan Retention / Lifecycle Policy Rules di ECR

Sebagian besar sistem kami menggunakan Docker container, dan Docker image-nya disimpan di AWS Elastic Container Registry (ECR). Kesalahannya? Saya tidak mengaktifkan retention atau lifecycle policy di repository ECR. Akibatnya, image yang lama-lama tetap tersimpan, dan cost penyimpanan makin lama makin besar.

Masalah ini baru ketahuan setelah lebih dari 6 bulan, karena di awal cost-nya cuma beberapa sen saja. Tapi setelah beberapa bulan, jumlah image bertambah dan storage cost di ECR pun menggulung naik.

Solusi yang Kami Lakukan:

Mengaktifkan lifecycle policy di ECR berdasarkan image count, jadi hanya menyimpan beberapa versi terbaru saja. Kalau butuh image lama, tinggal rebuild ulang dari CI/CD.

Referensi

Automate the cleanup of images by using lifecycle policies in Amazon ECR

#3 : Menjalankan Web Frontend di ECS Alih-alih Amazon S3 + CloudFront

Karena hampir semua layanan kami berbasis Docker, frontend web kami awalnya juga dijalankan di Amazon ECS. Apa yang terjadi? Biaya data transfer-nya cukup tinggi!

Setelah membaca beberapa referensi, akhirnya kami memutuskan untuk migrasi ke Amazon S3 + CloudFront. Dari CI/CD, source code frontend dibuild dan dikompilasi ke S3, lalu CloudFront akan melayani permintaan dari S3. Keuntungan lainnya:

Cache aktif di CloudFront, sehingga mengurangi biaya transfer data.
Free tier 1TB per bulan untuk data transfer keluar ke internet.
Keamanan lebih baik dengan fitur seperti AWS WAF (Web Application Firewall).

Referensi

#4 : Vertical Scaling di ECS untuk Service dengan Temporary Spike

Ketika service di ECS sering mengalami spike, solusi awal yang terpikir adalah menaikkan ukuran CPU dan memori (vertical scaling). Masalahnya, spike ini hanya terjadi sesekali, misalnya saat user melakukan export data. Jadi, secara resource tidak efisien karena lebih banyak idle daripada digunakan.

Solusi yang Kami Lakukan:

Menganalisis penyebab spike dan pola penggunaannya.
Menggunakan auto-scaling di ECS, sehingga task akan bertambah ketika ada spike.
Memindahkan proses berat ke AWS Lambda. Contohnya, saat user melakukan export data, ECS hanya mengirim queue ke Amazon SQS, lalu Lambda memprosesnya dan menyimpan hasilnya di S3.

#5 : Tidak Menggunakan EC2 Spot Instances untuk Penghematan Biaya

Di awal, semua ECS instance kami menggunakan EC2 On-Demand. Padahal, EC2 Spot Instance bisa menghemat biaya hingga 90% dibandingkan On-Demand.

Tapi, tidak semua workload cocok dengan Spot Instances, karena instance ini bisa kapan saja dihentikan oleh AWS jika harga naik atau kapasitas dibutuhkan oleh pelanggan lain. Oleh karena itu, kami hanya menggunakan Spot Instances untuk environment staging dan development.

Selain itu, untuk memastikan Spot Instance tetap tersedia, kami menggunakan multiple instance types dengan strategi price-capacity-optimized, yang secara otomatis memilih instance dengan harga terbaik dan risiko penghentian paling rendah.

Referensi

Mungkin tips dari saya untuk membantu agar lebih aware dan lebih cepat mengetahui ketika melakukan kesalahan, beberapa yg sering salah lakukan akhir-akhir ini adalah :

Aktifkan billing alert dari billing & cost managementnya, baik itu dalam bentuk threshold atau forecast, sehingga Anda tidak tiba2 terkejut di akhir bulan ketika sudah dapat tagihan 😀
Sempatkan waktu baik itu per minggu, 2 minggu atau perbulan untuk review cost / servicenya untuk mengetahui polanya dan service mana saja terus mengalami kenaikkan cost
Ikuti release / rekomendasi terbaru dari AWS, biasanya di AWS Portalnya kadang ada rekomendasi menggunakan cara tertentu contohnya.

Semoga pengalaman ini bisa membantu kalian yang baru mulai menggunakan AWS supaya nggak mengalami “pembelajaran berharga” yang sama! 😆

This article is also available in English:

Valuable Lessons from My First AWS Setup Mistakes (and How to Optimize Costs to Avoid Bill Shock!)

Ifan Jaya Suswanto Zalukhu @ifanzalukhu97