Lambda #

AWS Lambda adalah layanan Function-as-a-Service (FaaS) pionir yang diluncurkan oleh Amazon Web Services pada tahun 2014. Kehadirannya memicu gelombang adopsi arsitektur serverless secara global. Sebelum adanya Lambda, mendeploy aplikasi selalu berarti menyewa server virtual (VM), mengonfigurasi sistem operasi, dan membiarkannya menyala terus-menerus. AWS Lambda mengubah aturan main ini secara radikal: kita cukup mengunggah kode aplikasi, dan AWS akan menangani seluruh proses eksekusi, skalabilitas, keamanan, dan ketersediaannya secara otomatis.

Dalam praktik arsitektur cloud modern di AWS, Lambda bertindak sebagai “perekat” (glue service) yang menghubungkan berbagai layanan AWS secara responsif dan event-driven. Artikel ini akan mengupas tuntas AWS Lambda mulai dari arsitektur internalnya, cara kerja eksekusi, integrasi trigger, konfigurasi performa, hingga contoh kode implementasi nyata dan praktik terbaik untuk lingkungan produksi.

Arsitektur Internal AWS Lambda #

Untuk menulis fungsi Lambda yang efisien dan berkinerja tinggi, kita harus memahami apa yang terjadi di belakang layar ketika AWS menerima permintaan eksekusi fungsi kita.

Teknologi Isolasi: AWS Firecracker #

Di awal peluncurannya, Lambda menggunakan container EC2 standar untuk menjalankan fungsi pengguna. Namun, untuk menangani jutaan invokasi per detik dari ribuan pelanggan secara aman dan terisolasi, AWS mengembangkan teknologi virtualisasi internal bernama AWS Firecracker.

Firecracker adalah teknologi open-source yang tertulis dalam bahasa Rust untuk membuat MicroVM (Micro Virtual Machines) yang sangat ringan dan aman di atas hypervisor KVM (Kernel-based Virtual Machine) Linux. MicroVM menggabungkan keunggulan keamanan isolasi perangkat keras tingkat VM tradisional dengan kecepatan booting dan efisiensi resource tingkat container kontemporer. Sebuah MicroVM Firecracker dapat melakukan booting dari kondisi mati total hanya dalam waktu kurang dari 5 milidetik dan mengonsumsi memori kurang dari 5 MB.

Siklus Hidup Eksekusi (Cold Start vs. Warm Start) #

Siklus hidup lingkungan eksekusi AWS Lambda terbagi menjadi tiga fase utama:

flowchart TD
    Start["Request Invokasi Masuk"] --> Check{"Apakah ada runtime\nidle yang tersedia?"}
    Check -- "Tidak (Cold Start)" --> Phase1["Fase 1: Init\n- Download kode fungsi\n- Buat MicroVM Firecracker\n- Jalankan bahasa runtime\n- Inisiasi kode di luar handler"]
    Check -- "Ya (Warm Start)" --> Phase2["Fase 2: Invoke\n- Jalankan handler kode\n- Kirim parameter event\n- Tunggu response"]
    Phase1 --> Phase2
    Phase2 --> Phase3["Fase 3: Shutdown\n- Runtime dibekukan sementara\n- Jika idle terlalu lama, dihancurkan"]

1. Fase Inisialisasi (Init Phase) #

Pada fase ini, AWS Lambda mengunduh kode fungsi dari bucket internal S3, membuat MicroVM Firecracker baru dengan alokasi resource sesuai konfigurasi, menginisiasi runtime bahasa pemrograman (misalnya Node.js atau Python), dan mengeksekusi kode di luar fungsi utama (handler). Proses inilah yang dikenal sebagai Cold Start.

2. Fase Invokasi (Invoke Phase) #

Setelah lingkungan eksekusi siap, AWS Lambda memanggil fungsi handler yang sesungguhnya dan menyuntikkan data parameter event. Setelah eksekusi selesai dan mengembalikan respon, lingkungan eksekusi ini akan dibekukan sementara untuk menghemat CPU.

3. Fase Shutdown (Shutdown Phase) #

Jika tidak ada request baru masuk setelah beberapa menit, AWS Lambda akan mencairkan lingkungan eksekusi tersebut untuk membersihkan resource dan menghancurkan MicroVM secara permanen.

Jika ada request baru masuk saat lingkungan eksekusi dalam status beku (frozen), AWS Lambda akan langsung mencairkannya dan masuk ke Fase Invokasi tanpa mengulangi Fase Inisialisasi. Proses instan ini disebut Warm Start.

Model Billing dan Skalabilitas #

AWS Lambda menerapkan model ekonomi cloud yang sangat adil dan efisien: kita hanya membayar apa yang kita gunakan secara tepat.

Perhitungan Tagihan (Billing Model) #

Tagihan AWS Lambda dihitung berdasarkan dua metrik utama:

  1. Jumlah Request (Invokasi): Jumlah total pemanggilan fungsi. Biayanya sangat murah, sekitar $0.20 per 1 juta request.
  2. Durasi Komputasi (GB-Detik): Dihitung dari lamanya kode berjalan (dibulatkan dalam presisi milidetik) dikalikan dengan kapasitas memori (RAM) yang kita alokasikan.

Contoh Simulasi Perhitungan Biaya: #

Misalkan kita mengalokasikan memori sebesar 1024 MB (1 GB) untuk fungsi kita, dan fungsi tersebut dipanggil sebanyak 3 juta kali dalam satu bulan dengan rata-rata durasi eksekusi 200 ms per request.

  • Biaya Invokasi: 3.000.000 request × $0.0000002 = $0.60
  • Total Durasi: 3.000.000 request × 0.2 detik = 600.000 detik
  • Total GB-Detik: 600.000 detik × 1 GB = 600.000 GB-detik
  • Biaya Durasi (Harga standar AWS sekitar $0.0000166667 per GB-detik): 600.000 GB-detik × $0.0000166667 = $10.00
  • Total Biaya Bulanan: $0.60 + $10.00 = $10.60 (Sangat murah dibandingkan menyewa VM 24/7).

Skalabilitas Horizontal Bawaan #

Ketika beban traffic aplikasi melonjak, AWS Lambda melakukan scaling secara horizontal dengan membuat instans lingkungan eksekusi (MicroVM) tambahan secara paralel.

Secara default, kuota kapasitas eksekusi paralel simultan (concurrency limit) adalah 1.000 fungsi paralel per region per akun AWS (limit ini dapat ditingkatkan dengan mengajukan permohonan ke AWS Support). Jika invokasi baru melebihi limit tersebut, AWS akan menolak request dengan status error 429 (throttling).

Sumber Event (Triggers) & Pola Invokasi #

AWS Lambda bertindak sebagai konsumen event. Ada tiga pola utama bagaimana fungsi Lambda dipicu oleh layanan AWS lainnya:

1. Sinkron (Synchronous Invocation) #

Pada model ini, pengirim request menunggu respon langsung dari fungsi Lambda sebelum melanjutkan prosesnya.

  • Sumber Event: Amazon API Gateway, Application Load Balancer (ALB), Cognito.
  • Penanganan Error: Jika fungsi Lambda gagal atau timeout, pengirim request akan langsung menerima HTTP 500 error. Retry logic harus ditangani di sisi pengirim.

2. Asinkron (Asynchronous Invocation) #

Pengirim request hanya mengirimkan data event ke antrean internal Lambda, menerima konfirmasi instan (HTTP 202), dan langsung melanjutkan tugasnya tanpa menunggu fungsi Lambda selesai berjalan.

  • Sumber Event: Amazon S3 (file upload), Amazon SNS, EventBridge.
  • Penanganan Error: AWS Lambda secara otomatis mengelola antrean internal dan akan mencoba mengeksekusi ulang fungsi yang gagal sebanyak 2 kali tambahan secara default sebelum membuangnya ke Dead Letter Queue (DLQ) atau mengirimkannya ke Lambda Destinations.

3. Pemetaan Sumber Event (Event Source Mapping / Polling) #

AWS Lambda secara aktif melakukan polling (penarikan data) dari layanan berbasis antrean atau stream, membaca pesan dalam jumlah tertentu (batch), lalu mengirimkannya ke fungsi Lambda.

  • Sumber Event: Amazon SQS, Amazon Kinesis, DynamoDB Streams.
  • Penanganan Error: Jika eksekusi gagal, Lambda akan terus mencoba kembali memproses batch yang bermasalah tersebut sampai masa kedaluwarsa data habis (retry-until-expire) guna menjaga urutan data yang presisi.

Konfigurasi Esensial dan Tuning Performa #

Mengonfigurasi parameter yang tepat di AWS Lambda menentukan performa eksekusi dan efisiensi biaya aplikasi kita.

Alokasi Memori dan Hubungannya dengan CPU #

Di AWS Lambda, kita tidak bisa memilih jumlah vCPU secara mandiri. Kita hanya mengonfigurasi kapasitas memori (RAM) mulai dari 128 MB hingga 10.240 MB (10 GB).

AWS akan mengalokasikan daya CPU secara proporsional. Misalnya, jika kita melipatgandakan RAM dari 256 MB menjadi 512 MB, fungsi kita juga akan mendapatkan daya CPU dua kali lipat lebih besar.

AWS Lambda Power Tuning: Menambah memori sering kali menurunkan biaya total. Mengapa? Karena alokasi CPU yang lebih besar membuat fungsi berjalan jauh lebih cepat, sehingga mengurangi durasi milidetik eksekusi secara signifikan. Kita harus melakukan benchmark performa menggunakan tool open-source AWS Lambda Power Tuning untuk menemukan titik temu paling optimal antara kecepatan eksekusi dan biaya.

VPC Configuration (Virtual Private Cloud) #

Secara default, fungsi Lambda berjalan di jaringan internal AWS terisolasi yang aman dengan akses keluar ke internet publik. Namun, jika fungsi kita perlu mengakses database privat di dalam VPC kita (seperti Amazon RDS PostgreSQL), kita harus mengonfigurasi fungsi tersebut agar terhubung ke VPC kita.

Dulu, menghubungkan Lambda ke VPC memicu penambahan cold start yang sangat lambat karena perlunya pembuatan Elastic Network Interface (ENI). Kini, AWS telah menerapkan arsitektur jaringan baru bernama AWS Hyperplane yang membagi ENI secara bersamaan (shared ENI), membuat cold start di dalam VPC sama cepatnya dengan di luar VPC.

Contoh Kode Implementasi Praktis #

Berikut adalah contoh implementasi fungsi AWS Lambda menggunakan Node.js (JavaScript ES Modules) yang mendemonstrasikan penulisan handler, pembacaan parameter event, pemanggilan database (simulasi), dan penulisan log terstruktur berformat JSON.

// BENAR: Inisialisasi client database di luar handler (Global Scope)
// Keuntungan: Koneksi DB dapat digunakan kembali pada pemanggilan Warm Start berikutnya
import { Client } from 'pg';

const dbClient = new Client({
    connectionString: process.env.DATABASE_URL
});

// Flag untuk melacak status koneksi database
let isDbConnected = false;

async function connectDatabase() {
    if (!isDbConnected) {
        console.log(JSON.stringify({ message: "Membuat koneksi baru ke database..." }));
        await dbClient.connect();
        isDbConnected = true;
    }
}

// Handler utama AWS Lambda
export const handler = async (event, context) => {
    // ✓ Structured logging menggunakan format JSON agar mudah dibaca di CloudWatch
    console.log(JSON.stringify({ 
        message: "Request invokasi Lambda diterima", 
        requestId: context.awsRequestId,
        eventData: event 
    }));

    try {
        // Inisiasi koneksi database secara aman
        await connectDatabase();

        // 1. Ekstrak data dari parameter event (Asumsi trigger dari API Gateway)
        const body = event.body ? JSON.parse(event.body) : {};
        const userId = body.userId;

        if (!userId) {
            // ✓ Mengembalikan response terstruktur dengan status code yang tepat
            return {
                statusCode: 400,
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify({ error: "userId wajib dikirimkan dalam request body" })
            };
        }

        // 2. Simulasi query database
        const res = await dbClient.query('SELECT name, email FROM users WHERE id = $1', [userId]);
        
        if (res.rows.length === 0) {
            return {
                statusCode: 404,
                headers: { 'Content-Type': 'application/json' },
                body: JSON.stringify({ error: "User tidak ditemukan" })
            };
        }

        const userData = res.rows[0];

        // 3. Kembalikan data response sukses
        return {
            statusCode: 200,
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({
                success: true,
                user: userData
            })
        };

    } catch (error) {
        // ✗ JANGAN abaikan logging error! Tulis detail error ke stderr
        console.error(JSON.stringify({
            message: "Terjadi kesalahan internal pada fungsi Lambda",
            error: error.message,
            stack: error.stack
        }));

        return {
            statusCode: 500,
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ error: "Kesalahan internal pada server" })
        };
    }
};

Praktik Terbaik di Lingkungan Produksi #

Untuk memastikan fungsi AWS Lambda berjalan stabil, aman, dan efisien pada skala produksi, kita harus mengikuti panduan praktik terbaik berikut:

1. Terapkan Prinsip Keamanan Hak Akses Minimum (Least Privilege) #

Setiap fungsi Lambda harus memiliki IAM Execution Role tersendiri yang dikonfigurasi secara ketat. Jika fungsi Lambda A hanya bertugas mengambil file dari satu bucket S3 tertentu, berikan izin s3:GetObject khusus untuk ARN bucket tersebut. Hindari penggunaan wildcard seperti "Action": "s3:*" atau "Resource": "*".

2. Kelola Variabel Lingkungan secara Aman (Secrets Management) #

Jangan pernah menulis kunci API, token, atau kredensial database secara mentah (hardcoded) di dalam kode sumber maupun sebagai environment variables standar. Gunakan layanan terkelola seperti AWS Secrets Manager atau Systems Manager (SSM) Parameter Store untuk mengambil rahasia tersebut secara aman saat runtime.

3. Tulis Kode yang Idempotent #

Karena model pemanggilan asinkron Lambda memiliki mekanisme retry otomatis saat terjadi kegagalan, ada kemungkinan sebuah fungsi Lambda menerima event yang sama lebih dari satu kali (at-least-once delivery). Pastikan kode fungsi kita aman dijalankan berulang kali dengan input yang identik tanpa menimbulkan efek samping ganda (misalnya double payment).

4. Terapkan Observability Sejak Awal #

Aktifkan tracing AWS X-Ray untuk memantau waktu yang dihabiskan oleh fungsi Lambda saat melakukan panggilan ke layanan eksternal (seperti database RDS atau API luar). Gunakan structured logging dalam format JSON untuk memudahkan pemantauan dan pembuatan visualisasi log menggunakan CloudWatch Insights.

Ringkasan #

  • AWS Lambda adalah layanan FaaS yang mengeksekusi kode secara dinamis berbasis event, mengabstraksikan seluruh pengelolaan server dari developer.
  • MicroVM Firecracker adalah teknologi virtualisasi di belakang layar Lambda yang menyediakan isolasi hardware yang aman dengan kecepatan boot di bawah 5 ms.
  • Model billing dihitung secara granular berdasarkan jumlah request dan durasi komputasi (milidetik dikalikan kapasitas memori RAM yang dialokasikan).
  • Alokasi CPU berbanding lurus dengan RAM — menaikkan kapasitas memori sering kali menurunkan biaya karena durasi eksekusi menjadi jauh lebih cepat.
  • Desain fungsi harus bersifat stateless, idempotent, memiliki hak akses minimum (least privilege), dan memanfaatkan inisialisasi variabel di luar handler untuk pemanggilan warm start.

← Sebelumnya: Pros & Cons Serverless   Berikutnya: Fargate →

About | Author | Content Scope | Editorial Policy | Privacy Policy | Disclaimer | Contact