Serverless dalam Praktik: AWS Lambda, Cloud Run, Cloudflare Workers, dan Kapan Layak Dipakai

Serverless sering dipromosikan sebagai akhir dari urusan server: unggah sebuah fungsi, sisanya diurus penyedia cloud. Servernya tentu tetap ada. Bedanya, Anda tidak lagi menyewa, mem-patch, atau menambah kapasitasnya sendiri, dan Anda hanya membayar selama kode benar-benar berjalan. Untuk webhook yang menerima beberapa ribu panggilan per hari, tagihannya bisa mendekati nol. Untuk API yang melayani trafik stabil sepanjang hari, model yang sama bisa lebih mahal daripada dua server biasa. Artikel ini menjelaskan cara kerja serverless dalam praktik, dengan AWS Lambda sebagai contoh utama, serta kapan pendekatan ini masuk akal dan kapan tidak.

Apa Sebenarnya Serverless Itu

Sebuah layanan disebut serverless kalau memenuhi tiga hal: Anda tidak mengelola sistem operasi maupun mesinnya, kapasitas mengikuti trafik secara otomatis, dan tagihan mengikuti pemakaian, idealnya turun ke nol saat tidak ada aktivitas. Di bawah payung itu ada tiga model yang cukup berbeda.

Database, antrean, dan storage juga bisa serverless, misalnya DynamoDB, SQS, S3, atau Aurora Serverless. Dalam praktiknya aplikasi serverless biasanya gabungan keduanya: fungsi untuk logika, layanan terkelola untuk semua yang menyimpan data.

Cara Kerja AWS Lambda

Sebuah fungsi Lambda terdiri dari handler beserta konfigurasinya: runtime, memori, timeout, dan izin akses. Fungsi dipicu oleh sesuatu, misalnya API Gateway, unggahan ke S3, pesan SQS, atau jadwal EventBridge. Lambda lalu mencari execution environment untuk menjalankan handler. Kalau tidak ada yang sedang menganggur, Lambda membuat yang baru: mengunduh kode, menyalakan runtime, dan menjalankan kode inisialisasi. Inilah yang disebut cold start. Setelah request selesai, environment tersebut tetap hidup beberapa saat dan bisa melayani request berikutnya tanpa biaya start ulang.

• Satu environment menangani satu request dalam satu waktu. Kalau 50 request datang bersamaan, Lambda menjalankan 50 environment. Inilah yang disebut concurrency.
• CPU mengikuti memori. Menurut dokumentasi AWS, fungsi baru mendapat setara satu vCPU penuh di 1.769 MB. Fungsi 128 MB hanya mendapat sebagian kecil CPU, sehingga menaikkan memori sering membuat fungsi lebih cepat tanpa biaya yang naik banyak.
• Tagihan dihitung per milidetik durasi dikali memori yang dikonfigurasi, ditambah biaya per request. Sejak Agustus 2025, waktu inisialisasi saat cold start ikut ditagih, jadi kode startup yang berat kini langsung menjadi biaya.
• Tidak ada yang dijamin bertahan antar-request. Data di memori atau di /tmp bisa masih ada untuk request berikutnya, bisa juga hilang. Apa pun yang penting harus disimpan di database, cache, atau S3.

Batasan yang Perlu Diketahui Sebelum Mendesain

Sebagian besar masalah Lambda di production berasal dari desain yang mengabaikan batasan ini. Angka di bawah diambil dari halaman kuota AWS Lambda.

Layanan di sekitar Lambda juga punya batasnya sendiri. HTTP API di API Gateway hanya menunggu respons maksimal 30 detik, sehingga endpoint laporan yang lambat sudah gagal di sana jauh sebelum timeout Lambda 15 menit tercapai. Pekerjaan berat sebaiknya lewat antrean, lalu memberi kabar saat selesai.

Perbandingan Pilihan Utama

Cloud Run paling mudah untuk tim yang sudah terbiasa dengan container: image yang sama bisa jalan di laptop, di VM, atau di Cloud Run, dan satu instance bisa melayani banyak request sekaligus. Lambda punya pilihan trigger paling lengkap dan integrasi paling erat dengan layanan AWS lain. Cloudflare Workers hampir tidak punya cold start dan sangat murah untuk pekerjaan ringan yang sensitif terhadap latensi, tetapi runtime-nya bukan Node.js penuh dan kurang cocok untuk pemrosesan berat. Kalau data pribadi harus tetap di Indonesia sesuai UU PDP, periksa di mana fungsi berjalan dan, yang lebih penting, ke mana data disimpan dan dikirim.

Berapa Biayanya: Hitungan dengan Harga Jakarta

Supaya lebih konkret, kami menghitung biaya bulanan sebuah API di Lambda region Jakarta, memakai data price list publik AWS per November 2026. Asumsinya: arsitektur Arm (Graviton) dengan harga USD 0,0000133334 per GB-detik, memori 512 MB, rata-rata durasi tertagih 120 ms per request, USD 0,20 per juta request, API Gateway HTTP API USD 1,29 per juta request, dan free tier Lambda. Sebagai pembanding kami memakai Cloudflare Workers dengan 5 ms waktu CPU per request. Biaya transfer data, log, dan database belum termasuk.

Sebagai pembanding, instance c6g.xlarge (4 vCPU, 8 GB, Arm) di Jakarta berharga sekitar USD 0,157 per jam, atau kira-kira USD 114 per bulan dengan tarif on-demand. Dua instance untuk redundansi sekitar USD 229 per bulan sebelum load balancer, dan untuk API bisnis pada umumnya keduanya sanggup menangani jauh lebih dari 39 request per detik. Ada tiga hal yang terlihat dari angka ini:

• Untuk trafik rendah dan tidak teratur, serverless sulit dikalahkan. Sampai sekitar 10 juta request per bulan, tagihannya hanya belasan dolar, tanpa server yang menganggur.
• API Gateway sering lebih mahal daripada Lambda-nya sendiri. Untuk endpoint sederhana, Lambda function URL tidak dikenai biaya tambahan di luar biaya fungsi, meskipun Anda kehilangan fitur seperti throttling per klien dan API key.
• Di kisaran 50 sampai 100 juta request per bulan dengan trafik stabil, server atau container biasa mulai lebih hemat. Titik impas ini sangat bergantung pada durasi dan memori fungsi, jadi ukur angka Anda sendiri, jangan memakai angka kami begitu saja.

Kapan Serverless Cocok

• Webhook dari payment gateway, WhatsApp, atau pihak ketiga lain. Trafiknya tidak bisa diprediksi dan tiap panggilan singkat.
• Pemrosesan file setelah diunggah: mengubah ukuran gambar, membuat thumbnail, mengambil teks dari PDF, atau memeriksa file import Excel.
• Pekerjaan terjadwal yang dulu butuh server dengan cron: laporan harian, sinkronisasi data, pembersihan data lama.
• Worker antrean yang memproses pesan dari SQS atau Kafka dan menyesuaikan jumlahnya dengan antrean yang menumpuk.
• API untuk aplikasi internal, produk tahap awal, atau kampanye musiman, yang trafiknya rendah hampir sepanjang waktu dengan lonjakan sesekali.
• Penghubung antar-layanan, misalnya meneruskan event dari satu sistem ke sistem lain atau mengirim notifikasi.

Kapan Biasanya Tidak Cocok

• API dengan trafik tinggi dan stabil sepanjang hari. Seperti terlihat di hitungan tadi, Anda membayar lebih untuk elastisitas yang tidak terpakai.
• Pekerjaan yang berjalan lebih dari 15 menit, seperti migrasi data besar atau encoding video, kecuali dipecah menjadi beberapa langkah.
• Aplikasi yang butuh koneksi jangka panjang atau state lokal, seperti game server atau server WebSocket yang menyimpan data di memori.
• Endpoint dengan syarat latensi ketat di setiap request, ketika cold start sesekali selama beberapa ratus milidetik atau lebih tidak bisa diterima, dan provisioned concurrency justru menghapus penghematannya.
• Tim yang belum siap berinvestasi di monitoring dan infrastructure as code. Lima puluh fungsi kecil yang dikonfigurasi manual lewat console lebih sulit dikelola daripada satu aplikasi di satu server.

Masalah yang Muncul di Production

Koneksi database habis. Setiap execution environment membuka koneksinya sendiri, sehingga lonjakan trafik yang menyalakan 500 environment bisa membuka 500 koneksi ke server PostgreSQL atau MySQL yang hanya mengizinkan 100. Gunakan RDS Proxy atau connection pooler lain, pasang reserved concurrency untuk membatasi seberapa jauh fungsi bisa scale, atau pakai database yang punya antarmuka HTTP.

Cold start lebih lama dari perkiraan. Paket yang besar, dependency yang banyak, dan framework yang berat semuanya menambah waktu startup, dan Java tanpa SnapStart adalah yang paling lambat. Jaga paket tetap kecil, buat client SDK dan koneksi database di luar handler supaya request berikutnya bisa memakainya ulang, dan muat hanya yang dibutuhkan tiap fungsi.

Event diproses dua kali. Pemanggilan asinkron yang gagal diulang dua kali secara default, dan SQS mengirim pesan minimal sekali. Webhook pembayaran yang jalan dua kali tidak boleh menambah saldo dua kali, jadi setiap handler yang mengubah data harus idempotent, misalnya dengan menyimpan ID event dan melewati duplikatnya. Siapkan dead letter queue atau failure destination supaya event yang terus gagal tidak hilang begitu saja.

Biaya membengkak di tempat yang tidak terduga. Fungsi yang menulis ke bucket S3 yang sama dengan pemicunya bisa memanggil dirinya sendiri terus-menerus. AWS kini mendeteksi sebagian loop seperti ini, tetapi tidak semuanya. Log debug dalam volume besar bisa membuat CloudWatch Logs lebih mahal daripada Lambda-nya. Tetapkan masa simpan log, gunakan level log, dan buat peringatan AWS Budgets sebelum go-live, bukan setelah tagihan pertama datang.

Opsi Lambda Terbaru yang Perlu Diketahui

AWS sudah menambahkan beberapa varian yang melonggarkan batasan klasik. Layak dilihat sebelum memutuskan Lambda tidak cocok:

• Lambda Managed Instances menjalankan fungsi di instance EC2 dalam akun Anda yang dikelola oleh Lambda. Anda membayar harga EC2 ditambah biaya pengelolaan 15 persen dan USD 0,20 per juta request, tanpa biaya durasi, dan Savings Plans atau Reserved Instances tetap berlaku. Opsi ini menyasar persis kasus trafik tinggi dan stabil yang membuat Lambda klasik mahal.
• Durable functions memungkinkan satu fungsi menjalankan workflow panjang yang terdiri dari beberapa langkah dengan checkpoint, lalu menunggu event dari luar atau waktu tertentu tanpa membayar compute selama menunggu.
• Lambda Web Functions menjalankan web server Node.js biasa, seperti Express atau Hono, dengan endpoint HTTPS bawaan, dan satu environment bisa menangani banyak request sekaligus. Saat artikel ini ditulis baru mendukung Node.js, jadi cek ketersediaannya di region Anda.

Memulai Tanpa Berantakan

1. 1Pilih satu beban kerja yang jelas cocok, seperti webhook, pemrosesan gambar, atau pekerjaan terjadwal, alih-alih memindahkan seluruh aplikasi sekaligus.
2. 2Definisikan fungsi, izin, dan trigger sebagai kode sejak hari pertama memakai AWS SAM, CDK, Terraform, atau SST, lalu deploy lewat pipeline CI/CD.
3. 3Pilih arsitektur Arm kecuali ada dependency yang mewajibkan x86. Di Jakarta, harganya 20 persen lebih murah per GB-detik.
4. 4Uji beberapa ukuran memori dengan alat seperti AWS Lambda Power Tuning. Pengaturan termurah sering kali bukan yang paling kecil.
5. 5Pasang reserved concurrency untuk fungsi yang mengakses database, serta dead letter queue atau failure destination untuk pekerjaan asinkron.
6. 6Atur masa simpan log, alarm untuk error dan throttle, serta peringatan anggaran bulanan sebelum rilis pertama ke production.
7. 7Tinjau tagihan setelah satu atau dua bulan. Kalau ada fungsi yang terus berjalan dengan volume tinggi, bandingkan dengan container atau Lambda Managed Instances.

Serverless tidak menghilangkan pekerjaan operasional. Pekerjaan itu hanya berpindah: dari mem-patch server ke mendesain retry, concurrency, dan biaya per request.