Serverless Computing dengan AWS Lambda: Membangun Function yang Scalable tanpa Mengelola Server

Memahami Model Serverless dan Ecosystem AWS Lambda

Serverless computing mengubah cara kita membangun dan menjalankan aplikasi di cloud. Alih-alih menyediakan dan mengelola server secara manual, kita cukup menulis kode function dan membiarkan cloud provider menangani sisanya. AWS Lambda adalah layanan serverless utama di ekosistem AWS yang mengadopsi model compute on-demand: kode kita hanya berjalan ketika ada event yang memicunya.

Model eksekusi Lambda bersifat event-driven. Sebuah function dapat dipicu oleh berbagai sumber — permintaan HTTP dari API Gateway, perubahan data di bucket S3, record baru di DynamoDB Streams, atau pesan dalam antrian SQS. Setiap trigger ini secara otomatis mengirimkan data ke function kita dalam bentuk objek event. Kita tidak perlu memikirkan berapa banyak server yang dibutuhkan karena Lambda menangani scaling secara horizontal dari nol konkurensi hingga ribuan eksekusi simultan.

Keunggulan utama model ini terletak pada skema pricing pay-per-execution. Kita hanya membayar untuk jumlah request dan durasi eksekusi function, bukan untuk resource idle. Namun serverless bukan solusi tanpa batasan. Lambda memiliki timeout maksimal 15 menit per eksekusi, package size limit 250 MB (termasuk Lambda Layers), dan fenomena cold start yang dapat menambah latensi pada request pertama setelah function tidak aktif. Memahami batasan ini penting sebelum memutuskan workload mana yang cocok untuk serverless.

Gambar: Arsitektur serverless AWS Lambda menunjukkan alur event dari berbagai sumber ke Lambda function dan interaksinya dengan layanan AWS — Sumber: [Software Diagrams](https://softwarediagrams.com/diagrams/aws-serverless-architecture/)

Setiap function Lambda membutuhkan IAM execution role yang mengatur izin akses ke layanan AWS lain — misalnya membaca data dari DynamoDB, menulis objek ke S3, atau mengirim log ke CloudWatch. Kita menerapkan prinsip least privilege dengan hanya memberikan izin minimal yang diperlukan oleh function. IAM role ini dilekatkan saat pembuatan function dan dapat diperbarui kapan saja tanpa perlu men-deploy ulang kode, sehingga pengelolaan keamanan tetap fleksibel dan terpusat.

Menulis Handler Function dan Menguji Secara Lokal

Setiap function Lambda di Python memiliki signature yang sama: lambda_handler(event, context). Parameter event membawa data dari source trigger dalam format dictionary. Parameter context menyediakan runtime metadata seperti AWS request ID, sisa waktu eksekusi, dan nama function. Function kita harus mengembalikan response dalam format yang bisa dipahami oleh trigger source.

Berikut contoh handler function sederhana yang memproses input dan mengembalikan response JSON terstruktur:

import json

def lambda_handler(event, context):
    name = event.get("name", "User")
    message = f"Hello, {name}! Selamat datang di serverless."
    
    response = {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json"
        },
        "body": json.dumps({
            "message": message,
            "request_id": context.aws_request_id,
            "remaining_time": context.get_remaining_time_in_millis()
        })
    }
    return response

Output:

{
  "statusCode": 200,
  "headers": {
    "Content-Type": "application/json"
  },
  "body": "{\"message\": \"Hello, Budi! Selamat datang di serverless.\", \"request_id\": \"test-request-id-abc123\", \"remaining_time\": 300000}"
}

Function ini membaca parameter name dari objek event, menyusun pesan sapaan, lalu mengembalikan dictionary dengan statusCode, headers, dan body yang sudah di-serialize ke JSON. Kita juga menyertakan request_id dan waktu tersisa dari objek context untuk kebutuhan tracing.

Untuk menguji function secara lokal sebelum deploy, kita bisa menggunakan AWS SAM CLI atau image lambci/lambda dari Docker. Kedua alat ini mensimulasikan runtime Lambda di lingkungan lokal sehingga kita bisa memverifikasi logika function tanpa harus deploy ke cloud setiap kali melakukan perubahan.

Mengintegrasikan Lambda dengan API Gateway untuk REST Endpoint

Agar function Lambda bisa diakses melalui HTTP, kita perlu menghubungkannya dengan API Gateway. Layanan ini bertindak sebagai pintu masuk yang menerima request dari klien, memetakannya ke format event Lambda, dan meneruskan response kembali ke klien. API Gateway REST API dan HTTP API adalah dua opsi yang tersedia, dengan HTTP API menawarkan latensi lebih rendah dan biaya lebih murah.

Ketika request HTTP masuk, API Gateway mengonversi method, path, headers, query parameters, dan body ke dalam struktur event JSON. Function kita kemudian membaca elemen-elemen ini untuk memproses request secara tepat.

Gambar: Opsi integrasi API Gateway REST API menunjukkan bagaimana API Gateway terhubung ke Lambda function dan berbagai backend lainnya — Sumber: [Playing AWS](https://playingaws.com/posts/comprehensive-guide-to-amazon-api-gateway-integrations/)

Berikut contoh function yang membaca query parameter dan mengembalikan response lengkap dengan CORS headers:

import json

def lambda_handler(event, context):
    http_method = event["requestContext"]["http"]["method"]
    query_params = event.get("queryStringParameters", {}) or {}
    path = event["requestContext"]["http"]["path"]
    
    items = [
        {"id": 1, "name": "Serverless Guide", "price": 150000},
        {"id": 2, "name": "AWS Lambda Cookbook", "price": 200000}
    ]
    
    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json",
            "Access-Control-Allow-Origin": "*",
            "Access-Control-Allow-Methods": "GET, POST, OPTIONS"
        },
        "body": json.dumps({
            "method": http_method,
            "path": path,
            "params": query_params,
            "data": items,
            "total": len(items)
        })
    }

Output:

{
  "statusCode": 200,
  "headers": {
    "Content-Type": "application/json",
    "Access-Control-Allow-Origin": "*",
    "Access-Control-Allow-Methods": "GET, POST, OPTIONS"
  },
  "body": "{\"method\": \"GET\", \"path\": \"/items\", \"params\": {\"category\": \"serverless\", \"page\": \"1\"}, \"data\": [{\"id\": 1, \"name\": \"Serverless Guide\", \"price\": 150000}, {\"id\": 2, \"name\": \"AWS Lambda Cookbook\", \"price\": 200000}], \"total\": 2}"
}

Setelah deploy, kita bisa menguji endpoint menggunakan curl. API Gateway juga mendukung deployment stages — kita bisa memiliki environment dev, staging, dan production dengan konfigurasi dan endpoint URL yang berbeda. Ini memungkinkan siklus pengembangan yang aman tanpa mengganggu traffic produksi.

Mengelola Dependencies dan Konfigurasi dengan Lambda Layers

Salah satu tantangan saat membangun Lambda function adalah mengelola dependencies. Jika function kita membutuhkan library kustom seperti requests, Pillow, atau mysql-connector, ukuran package bisa membengkak melebihi batas 250 MB. Solusinya adalah Lambda Layers — mekanisme untuk memisahkan dependencies dari kode function dan membaginya antar beberapa function.

Struktur folder layer harus mengikuti konvensi khusus. Kita menempatkan library dalam folder python/lib/python3.x/site-packages/, lalu mengompresnya menjadi file ZIP. Berikut cara membangun dan mengupload layer:

mkdir -p python/lib/python3.9/site-packages
pip install -r requirements.txt -t python/lib/python3.9/site-packages
zip -r9 layer.zip python

Setelah layer terupload, kita bisa melampirkannya ke function. Kode function kemudian tetap ringan karena hanya berisi logika bisnis. Untuk konfigurasi yang bersifat environment-specific, kita menggunakan Environment Variables di Lambda. Cara mengaksesnya dari kode Python:

import os
import json

def lambda_handler(event, context):
    db_host = os.environ.get("DB_HOST")
    db_name = os.environ.get("DB_NAME")
    stage = os.environ.get("STAGE", "dev")
    
    return {
        "statusCode": 200,
        "body": json.dumps({
            "stage": stage,
            "database": db_host,
            "connected": True
        })
    }

Output:

{
  "statusCode": 200,
  "body": "{\"stage\": \"production\", \"database\": \"prod-db.rumahcoding.co.id\", \"connected\": true}"
}

Pendekatan ini menjaga kode function tetap bersih dan konfigurasi terpisah dari logika aplikasi. Layer dapat digunakan oleh puluhan function sekaligus, yang sangat menghemat waktu build dan mengurangi duplikasi.

Monitoring, Logging, dan Strategi Mengatasi Cold Start

Setiap kali function Lambda dieksekusi, log secara otomatis tercatat di CloudWatch Logs. Setiap invocation mendapatkan log stream terpisah yang berisi output dari perintah print() serta stack trace jika terjadi error. CloudWatch Metrics mencatat metrik penting seperti invocations, errors, duration, dan throttles. Dashboard CloudWatch menjadi pusat observability untuk seluruh serverless application kita.

Cold start adalah tantangan utama pada serverless. Ketika function tidak digunakan selama beberapa waktu, runtime akan dihentikan. Request pertama setelah periode idle membutuhkan waktu tambahan untuk inisialisasi runtime, import library, dan setup koneksi database. Dampak cold start bervariasi tergantung runtime — Python dan Node.js relatif cepat, sementara Java dan .NET lebih lambat.

Strategi mitigasi cold start meliputi:

• Optimasi ukuran package: Semakin kecil package, semakin cepat proses download dan ekstraksi
• Import lazy: Import library hanya di dalam handler, bukan di level modul
• Provisioned Concurrency: Menjaga sejumlah lingkungan eksekusi tetap warm, ideal untuk function latency-sensitive
• Koneksi reuse: Inisialisasi koneksi database atau HTTP client di luar handler agar bisa dipakai ulang antar invocations

Untuk menangani kegagalan yang tidak terduga, Lambda mendukung Dead Letter Queue (DLQ). Ketika function asynchronous gagal setelah seluruh percobaan ulang — secara default Lambda melakukan dua kali retry dengan interval yang meningkat — event yang gagal dapat dikirim ke SQS atau SNS tujuan DLQ untuk dianalisis lebih lanjut. Mekanisme ini memastikan data tidak pernah hilang tanpa jejak dan tim operasional mendapatkan visibilitas penuh terhadap setiap kegagalan eksekusi.

Selain itu, penting untuk memastikan function bersifat idempotent. Lambda dapat mengeksekusi ulang function yang gagal (misalnya karena timeout), sehingga logika bisnis harus bisa menangani duplikasi eksekusi tanpa efek samping. Kombinasi monitoring yang baik, DLQ yang terkonfigurasi, dan strategi cold start yang tepat membuat aplikasi serverless tetap responsif dan andal di bawah beban produksi.

Tertarik mendalami deployment serverless di production? Bootcamp Cloud & DevOps di Rumah Coding membahas arsitektur serverless end-to-end — dari Lambda, API Gateway, DynamoDB, sampai CI/CD pipeline — dengan studi kasus aplikasi nyata.