Arsitektur Serverless Modern dengan AWS Lambda dan Edge Functions

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap pengembangan web modern, arsitektur serverless dan edge computing telah mengubah paradigma bagaimana infrastruktur web dirancang, di-deploy, dan diskalakan. Secara historis, infrastruktur web sangat bergantung pada server fisik atau Virtual Private Server (VPS) seperti AWS EC2, DigitalOcean Droplets, atau server on-premise yang dikelola secara manual dengan tumpukan klasik Nginx/Apache, PHP-FPM, MySQL/MariaDB, serta Redis untuk caching. Pendekatan konvensional ini memiliki kelemahan mendasar dalam hal pemeliharaan (maintenance), pengelolaan kapasitas (capacity planning), dan inefisiensi biaya operasional.

Bottleneck Performa dan Keamanan Dunia Nyata

1. Over-provisioning & Under-utilization: Server tradisional harus dibayar berdasarkan kapasitas alokasi tetap (CPU dan RAM), terlepas dari apakah server tersebut sedang melayani trafik atau dalam keadaan idle (0% CPU load). Hal ini menyebabkan pemborosan biaya operasional yang masif.
2. Skalabilitas Reaktif: Kenaikan trafik secara mendadak (misalnya flash sale atau kampanye pemasaran viral) sering kali menyebabkan server kehabisan memori (Out of Memory), koneksi database jenuh, atau kegagalan pada lapisan reverse proxy Nginx sebelum autoscaling grup selesai melakukan provisioning instance baru.
3. Latensi Geografis: Server yang diletakkan di satu region tunggal (misalnya Jakarta atau Singapura) akan memberikan latensi tinggi bagi pengguna yang mengakses dari belahan dunia lain atau bahkan dari luar pulau utama, karena jarak fisik paket jaringan yang harus ditempuh.
4. Kerentanan Keamanan Infrastruktur: Mengelola sistem operasi berbasis Linux secara mandiri memerlukan pembaruan rutin (patching), konfigurasi firewall (iptables/UFW), perlindungan terhadap serangan DDoS, dan mitigasi kerentanan zero-day pada tingkat OS dan web server.

Perbandingan Kondisi: Sebelum vs Sesudah Penerapan

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur serverless modern menggabungkan komputasi terdistribusi tingkat tinggi yang memisahkan logika aplikasi menjadi fungsi-fungsi independen yang dieksekusi berdasarkan event. Dalam ekosistem AWS dan Cloudflare, arsitektur ini melibatkan komponen kunci: Cloudflare Workers (Edge Routing & Caching), AWS API Gateway (HTTP Entrypoint), dan AWS Lambda (Compute Backend).

Alur Eksekusi Data (Under the Hood)

[ Client Browser ] 
       │
       ▼ (HTTPS Request)
[ Cloudflare Edge Workers ] ──(Cache Hit?)──► [ Return Cached Asset ]
       │ (Cache Miss / API Call)
       ▼
[ AWS API Gateway (REST/HTTP) ]
       │
       ▼ (Invoke)
[ AWS Lambda Execution Environment ]
       ├─► [ Container Initialization (Cold Start jika belum ada *warm instance*) ]
       └─► [ Handler Execution (Node.js / Python / Go / Rust) ]
              │
              ▼
       [ Aurora Serverless / DynamoDB / Redis ]

1. Edge Interception: Pengguna mengirimkan permintaan HTTP ke URL domain. Cloudflare Workers menangkap permintaan tersebut di edge location terdekat dari lokasi geografis pengguna (dari 300+ kota di seluruh dunia).
2. Edge Routing & Filtering: Cloudflare melakukan validasi JWT, rate limiting, WAF inspection, dan pengecekan cache storage lokal. Jika konten statis tersedia, data langsung dikembalikan tanpa menyentuh server AWS.
3. API Gateway Translation: Jika permintaan memerlukan pemrosesan dinamis, Cloudflare meneruskannya ke AWS API Gateway. API Gateway memvalidasi otorisasi (IAM, Cognito, atau Custom Authorizer) dan mengubah payload HTTP menjadi format event JSON untuk Lambda.
4. Lambda Execution: AWS Lambda menerima event. Jika instance fungsi sedang warm (aktif di memori), eksekusi langsung berjalan. Jika cold, AWS melakukan alokasi kontainer baru, memuat runtime, mengunduh deployment package, dan mengeksekusi fungsi handler.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun sistem backend nir-server, terdapat dua pendekatan utama dalam menjalankan logika komputasi: AWS Lambda (Region-based Compute) dan Cloudflare Workers (Edge-based Compute). Pemilihan yang salah dapat berdampak fatal pada performa latensi dan struktur biaya bulanan.

[!WARNING] Jangan pernah menghubungkan AWS Lambda secara langsung ke database relasional tradisional (seperti MySQL/PostgreSQL RDS) tanpa menggunakan sistem koneksi pooling pihak ketiga seperti RDS Proxy atau Prisma Data Proxy. Lonjakan trafik serverless dapat membuka ribuan koneksi simultan yang langsung merontokkan proses database Anda.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum mulai mengonfigurasi infrastruktur, pastikan lingkungan lokal Anda memenuhi persyaratan teknis berikut:

Spesifikasi & Tools yang Dibutuhkan

• Node.js: Versi 20.x LTS atau lebih tinggi.
• AWS CLI: Versi 2.x yang telah dikonfigurasi dengan kredensial IAM yang memiliki akses administratif ke AWS Lambda, API Gateway, dan IAM Roles.
• Wrangler CLI: CLI resmi dari Cloudflare (npm install -g wrangler).
• Terraform / AWS SAM CLI: Untuk otomatisasi Infrastructure as Code (IaC).

Verifikasi Kredensial AWS

Jalankan perintah berikut di terminal untuk memastikan AWS CLI terhubung dengan benar:

aws sts get-caller-identity

Pastikan output JSON menampilkan Account, UserId, dan Arn yang valid.

5. Panduan Implementasi Langkah demi Langkah

Berikut adalah implementasi praktis pembuatan fungsi AWS Lambda dengan Node.js, integrasi AWS API Gateway, dan pengaturan Edge Routing menggunakan Cloudflare Workers.

Langkah 1: Membuat AWS Lambda Function (Node.js)

Buat direktori proyek baru dan inisialisasi:

mkdir -p serverless-core/lambda
cd serverless-core/lambda
npm init -y
npm install aws-sdk @aws-sdk/client-dynamodb

Buat file index.js yang bertindak sebagai handler Lambda:

// index.js - AWS Lambda Production Handler
const { DynamoDBClient } = require("@aws-sdk/client-dynamodb");

const dynamoClient = new DynamoDBClient({ region: process.env.AWS_REGION || "ap-southeast-1\