Chromium ukurannya sekitar 280MB. Sementara itu, batas paket AWS Lambda setelah diekstrak hanya 250MB. Kalau kamu pernah coba npm install puppeteer lalu langsung deploy ke Lambda, kamu pasti sudah kebayang hasilnya—nggak akan muat.
Saya sudah cukup sering begadang sampai jam 2 pagi gara-gara error "Failed to launch the browser process" untuk tahu bahwa topik ini butuh penjelasan yang benar-benar jelas, bukan sekadar tutorial yang cuma nunjukin satu cara lalu membiarkan kamu menebak dua cara lainnya. Jadi, itulah isi artikel ini: perbandingan Layers vs. Container Image vs. upload ZIP langsung, matriks kompatibilitas versi yang relevan untuk 2026, dan bagian troubleshooting untuk lima error yang paling mungkin kamu temui.
Apa Itu Puppeteer di AWS Lambda (dan Kenapa Perlu Dipakai)
Puppeteer adalah library Node.js yang mengendalikan headless Chromium lewat Chrome DevTools Protocol. Lambda adalah komputasi serverless dari AWS — kamu bayar per eksekusi, skalanya otomatis, dan kamu tidak perlu ngurus server. Kalau digabung, kamu dapat setup otomasi browser yang bisa menjalankan ratusan proses paralel tanpa perlu menyediakan satu pun instance EC2.
Kasus penggunaannya cukup konsisten di berbagai tim: web scraping, pembuatan screenshot dan PDF, synthetic monitoring, pre-rendering aplikasi single-page untuk SEO, serta pengujian UI otomatis. Masalahnya selalu sama seperti yang saya sebut di atas — ukuran Chromium versus batas paket Lambda. Itulah sebabnya tidak ada yang men-deploy puppeteer penuh (yang ikut membawa download Chromium sendiri) ke Lambda. Sebagai gantinya, kamu memakai puppeteer-core (tanpa browser bawaan) yang dipasangkan dengan binary Chromium yang dioptimalkan untuk Lambda, paling sering @sparticuz/chromium.
Pergantian sederhana itu — puppeteer-core daripada puppeteer — sudah menyelesaikan 80% masalah ukuran bahkan sebelum kamu menulis satu baris konfigurasi deploy.
Layers vs. Container Image vs. ZIP: Tentukan Jalurmu Dulu
Ada satu hal yang cukup bikin saya terganggu saat riset topik ini: hampir semua panduan yang ada cuma membahas satu metode deploy. Tutorial AWS SAM pakai Layers. Contoh CDK pakai Docker. Post acak di Substack pakai ZIP mentah dengan binary Chromium yang di-host di S3. Tidak ada yang menaruh semuanya berdampingan, jadi keputusan pertama yang benar-benar kamu butuhkan — metode deploy mana yang paling cocok — malah sering dilewati.
Jadi mari kita bereskan itu.
| Kriteria | Lambda Layers | Container Image (Docker) | Upload ZIP Langsung |
|---|---|---|---|
| Ukuran paket maksimal | 250 MB setelah diekstrak (semua layer digabung) | 10 GB image | 250 MB setelah diekstrak |
| Kompleksitas deploy | Menengah (manajemen ARN layer) | Lebih tinggi (Dockerfile + push ke ECR) | Paling rendah (zip lalu upload) |
| Dampak cold start | Sedang | Sedikit lebih tinggi (tarik image lebih besar) | Sedang |
| Alur update Chromium | Terbitkan ulang versi layer | Build ulang image | Upload ulang zip |
| Paling cocok untuk | Prototipe cepat, pengguna Serverless Framework | Beban kerja produksi, tim dengan Docker CI | Fungsi sederhana satu kali pakai |
| Dukungan IaC | SAM, Serverless Framework | CDK, SAM, Terraform | Console, semua IaC |
Baik batas 250MB maupun 10GB itu berasal langsung dari dokumentasi kuota Lambda milik AWS — angka ini memang tidak banyak berubah, tapi justru itulah batas utama yang menentukan strategi deploy kamu sejak awal.
Heuristik saya, kalau boleh berbagi: kalau kamu sedang prototyping atau sudah pakai Serverless Framework, mulai dari Layers. Kalau kamu menargetkan production dan timmu sudah punya Docker CI/CD, pilih Container Image — batas 10GB memberi ruang yang jauh lebih lega. Kalau kamu cuma butuh satu fungsi untuk ambil screenshot sesekali, direct ZIP adalah opsi paling sederhana.
Ketiga jalur ini pada dasarnya memakai pasangan dependency inti yang sama: puppeteer-core + @sparticuz/chromium. Metode deploy hanya mengubah cara kamu mengemas pasangan itu, bukan apa yang kamu kemas.
Matriks Kompatibilitas Versi 2026 (Berhenti Menebak)
Bagian ini justru yang paling sering menghabiskan waktu berbulan-bulan, bukan berjam-jam. Keluhan paling keras di Stack Overflow dan GitHub issues bukanlah "bagaimana cara deploy ini" — melainkan "kenapa deployment yang tadinya jalan tiba-tiba rusak setelah update npm." Penyebabnya hampir selalu mismatch antara @sparticuz/chromium, puppeteer-core, dan runtime Node.js.
Pertama, catatan penting: chrome-aws-lambda (package asli dari alixaxel) sudah deprecated. Package itu bermasalah di Node 18+ dan sudah tidak mengikuti rilis Chromium. Kalau kamu menemukan tutorial yang masih menyebutnya, tutup tab itu — isinya sudah usang. Semua panduan terbaru seharusnya mengarahkan kamu ke @sparticuz/chromium.
Gunakan aturan kompatibilitas ini, bukan cuma menyamakan major version package secara kasat mata:
| Komponen | Aturan versi | Yang perlu diverifikasi sebelum deploy |
|---|---|---|
puppeteer-core | Pilih versi Puppeteer yang dibutuhkan aplikasi kamu | Cek build Chromium yang didukung oleh rilis Puppeteer tersebut |
@sparticuz/chromium | Major version-nya mengikuti major Chromium, bukan major Puppeteer | Cocokkan dengan build Chromium dari tabel dukungan Puppeteer dan baca catatan rilis Sparticuz |
| AWS Lambda Node.js runtime | Gunakan runtime Lambda yang masih didukung saat ini | Jalankan tes invokasi setelah setiap update runtime atau package |
| Arsitektur | Package npm menyertakan binary x64; dukungan arm64 dimulai dengan Chromium v135 melalui layer arm64 atau remote pack | Cocokkan arsitektur Lambda, artifact layer/pack, dan versi Chromium secara tepat |
Saya sengaja tidak mengunci pasangan package tertentu di sini karena @sparticuz/chromium mengikuti siklus rilis Chromium dan tidak memakai semantic versioning biasa. Mulailah dari halaman resmi Puppeteer Chromium Support, catat major Chromium yang didukung oleh versi Puppeteer pilihanmu, lalu pilih major yang sesuai dari @sparticuz/chromium. Setelah itu, baca catatan rilis Sparticuz untuk perubahan breaking di level patch dan detail arsitektur. Jangan menginstal major number yang sama untuk kedua package kecuali pemetaan itu memang sudah dikonfirmasi oleh dua sumber tersebut.
Cara Men-deploy Puppeteer di AWS Lambda dengan Lambda Layers
Lambda Layer memungkinkan kamu mengemas Chromium secara terpisah dari kode fungsi, sehingga handler utama tetap kecil dan Chromium layer yang sama bisa dipakai ulang di banyak fungsi. Ini adalah opsi yang paling mendekati "quick start" di seluruh ekosistem ini.
Langkah 1: Install puppeteer-core dan package -min
Saat file Chromium disimpan di Lambda Layer, jaga agar paket fungsi tetap kecil dengan memakai @sparticuz/chromium-min. Ganti placeholder dengan versi yang kompatibel yang sudah kamu konfirmasi di atas:
npm install puppeteer-core@$PUPPETEER_VERSION \
@sparticuz/chromium-min@$CHROMIUM_VERSION
Kamu menginstal puppeteer-core — bukan puppeteer — karena package ini tidak mengunduh browser secara otomatis. Package -min menyediakan helper untuk meluncurkan browser, sementara layer menyediakan file Chromium yang dikompresi Brotli di bawah /opt/chromium.
Langkah 2: Buat atau Gunakan Chromium Lambda Layer
Gunakan archive layer yang spesifik untuk arsitektur dari rilis resmi Sparticuz, atau build archive-nya dari repository resmi. Untuk Lambda x86_64, build yang terdokumentasi adalah:
git clone --depth=1 https://github.com/sparticuz/chromium.git
cd chromium
make chromium.x64.zip
Perintah itu akan menghasilkan chromium.x64.zip. Upload ke S3 dan publish sebagai Lambda Layer dengan runtime dan arsitektur yang benar-benar kamu pakai. Untuk arm64, gunakan artifact rilis arm64 yang sesuai atau target build yang cocok; jangan menempelkan archive x64 ke fungsi arm64.
Kalau kamu memakai SAM, tempelkan ARN layer langsung di template.yaml:
Resources:
PuppeteerFunction:
Type: AWS::Serverless::Function
Properties:
Layers:
- arn:aws:lambda:us-east-1:XXXXXXXXXXXX:layer:chromium-layer:1
Langkah 3: Tulis Lambda Handler
Berikut pola handler yang bekerja untuk membuka URL dan mengembalikan judul halaman:
import puppeteer from "puppeteer-core";
import chromium from "@sparticuz/chromium-min";
export const handler = async () => {
const browser = await puppeteer.launch({
args: puppeteer.defaultArgs({ args: chromium.args, headless: "shell" }),
executablePath: await chromium.executablePath("/opt/chromium"),
headless: "shell",
});
try {
const page = await browser.newPage();
await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
return { title: await page.title() };
} finally {
await browser.close();
}
};
Perhatikan blok finally. Browser harus selalu ditutup di sana — kalau tidak, environment Lambda yang hangat akan menumpuk proses browser zombie di berbagai invokasi, dan akhirnya kamu akan menemui error memori aneh yang sama sekali tidak berkaitan dengan kode inti kamu.
Langkah 4: Atur Memory, Timeout, dan Arsitektur
Set memory minimal 1024 MB — saya akan merekomendasikan 1536–2048 MB untuk apa pun selain tugas screenshot yang sangat sederhana. Atur timeout minimal 60 detik. Kunci arsitektur ke x86_64 kecuali kamu sudah benar-benar mengonfirmasi dukungan arm64 untuk versi Chromium yang kamu pakai (ini bisa berbeda pada tiap rilis).
Langkah 5: Deploy dan Uji
sam build && sam deploy --guided
Jalankan dengan test event, lalu segera cek CloudWatch Logs kalau ada yang tidak beres — 90% error di bagian troubleshooting di bawah akan terlihat jelas di log tersebut.
Cara Men-deploy Puppeteer di AWS Lambda dengan Container Image (Docker)
Container image menyelesaikan masalah 250MB sepenuhnya dengan memberi kamu batas 10GB. Ini biasanya pilihan yang lebih baik untuk production, terutama kalau timmu sudah memakai Docker di pipeline CI.
Langkah 1: Buat Dockerfile
Mulailah dari AWS Lambda base image resmi untuk Node.js, install dependency, lalu set handler:
FROM public.ecr.aws/lambda/nodejs:20
COPY package*.json ./
RUN npm install --production
COPY . .
CMD ["index.handler"]
Tergantung package Chromium yang kamu pakai, mungkin kamu perlu yum install beberapa shared library (lebih lanjut di bagian troubleshooting) — @sparticuz/chromium sudah menyertakan sebagian besar kebutuhan, jadi jauh lebih minim repot dibanding install Chrome penuh secara manual.
Langkah 2: Build dan Push ke Amazon ECR
aws ecr create-repository --repository-name puppeteer-lambda
docker build -t puppeteer-lambda .
docker tag puppeteer-lambda:latest <account-id>.dkr.ecr.<region>.amazonaws.com/puppeteer-lambda:latest
aws ecr get-login-password | docker login --username AWS --password-stdin <account-id>.dkr.ecr.<region>.amazonaws.com
docker push <account-id>.dkr.ecr.<region>.amazonaws.com/puppeteer-lambda:latest
Simpan image di region yang sama dengan Lambda function kamu — pull image lintas region cuma menambah latensi yang sebenarnya tidak perlu.
Langkah 3: Buat Lambda Function dari Container Image
Arahkan fungsi kamu ke URI image ECR lewat CLI atau CDK, lalu set memory (1536–2048 MB) dan timeout (60–120 detik) seperti kamu mengatur deployment berbasis layer.
Langkah 4: Deploy dan Uji
Jalankan test event dan verifikasi outputnya. Tradeoff utama dibanding Layers: cold start sedikit lebih tinggi karena proses pull image yang lebih besar, tetapi kamu mendapat ruang yang jauh lebih lega untuk dependency.
Cara Men-deploy Puppeteer di AWS Lambda dengan Upload ZIP Langsung
Ini opsi tanpa banyak embel-embel — tanpa layer untuk dikelola, tanpa Docker untuk dibangun. Cocok untuk prototipe atau satu fungsi yang tidak perlu berkembang menjadi platform otomasi browser penuh.
Langkah 1: Install Dependency Secara Lokal
Untuk ZIP yang mandiri, gunakan puppeteer-core + @sparticuz/chromium dan kunci kedua versinya. Package penuh berisi file Chromium yang dikompresi dan mengekstraknya ke /tmp saat runtime. Gunakan @sparticuz/chromium-min hanya kalau file-file tersebut disediakan terpisah melalui Lambda Layer atau URL remote pack yang cepat; package -min sendiri tidak menyertakan file Brotli.
Langkah 2: Bundle dan ZIP Fungsi
npm install --production
zip -r function.zip . -x "*.git*"
Flag --production penting di sini — dependency development hanya akan memakan jatah 250MB kamu tanpa alasan yang jelas.
Langkah 3: Upload dan Konfigurasi Lambda Function
aws lambda update-function-code --function-name my-puppeteer-fn --zip-file fileb://function.zip
Kalau ZIP kamu melebihi 50MB, kamu tidak bisa mengunggahnya langsung lewat console atau panggilan CLI sederhana — kamu harus upload ke S3 terlebih dahulu lalu mereferensikan URI S3 tersebut. Set memory, timeout, dan arsitektur sama seperti dua metode sebelumnya.
Langkah 4: Deploy dan Uji
Gunakan alur yang sama: jalankan, lalu cek log. Dengan package penuh, chromium.executablePath() tidak perlu argumen. Dengan chromium-min, berikan direktori layer atau URL remote pack yang tepat, misalnya chromium.executablePath("/opt/chromium") untuk layout layer di atas. Remote pack menambahkan pekerjaan unduhan di cold start pertama, jadi host-lah di dekat fungsi dan verifikasi versi artifact serta arsitekturnya.
Argumen puppeteer.launch() yang Benar-benar Berfungsi di Lambda
Ini snippet yang paling sering di-copy-paste, jadi mari kita buat benar. Environment eksekusi Lambda tidak punya /dev/shm, tidak memberi akses GPU, dan berjalan dengan izin terbatas — artinya panggilan puppeteer.launch() default yang baik-baik saja di laptop kamu akan... tidak bekerja di sini.
const viewport = {
width: 1920,
height: 1080,
deviceScaleFactor: 1,
isMobile: false,
hasTouch: false,
isLandscape: true,
};
const browser = await puppeteer.launch({
args: await puppeteer.defaultArgs({ args: chromium.args, headless: "shell" }),
executablePath: await chromium.executablePath(),
headless: "shell",
defaultViewport: viewport,
});
Array chromium.args dari @sparticuz/chromium sudah berisi flag yang penting untuk environment serverless — --no-sandbox, --disable-gpu, --disable-dev-shm-usage, dan sejenisnya. Itulah alasan memakai package ini alih-alih menyusun daftar flag sendiri: package ini mengikuti kebutuhan Chromium, jadi kamu tidak perlu menebaknya.
Troubleshooting: 5 Error yang Hampir Pasti Akan Kamu Temui
Tidak ada panduan yang saya temukan yang menyertakan bagian troubleshooting yang layak, padahal error justru hampir pasti menjadi alasan kamu membaca artikel ini.
"Failed to launch the browser process"
Akar masalah: shared library hilang (libnss3.so, libatk, dan lain-lain) atau executablePath yang salah.
Solusi: @sparticuz/chromium sudah menyertakan sebagian besar dependency yang dibutuhkan, dan itulah sebabnya package ini direkomendasikan dibanding membuat binary Chromium sendiri. Untuk deployment Docker, kalau masalah ini masih muncul, install library yang hilang secara eksplisit di Dockerfile kamu lewat yum install.
"Unzipped size must be smaller than 262144000 bytes"
Akar masalah: kamu menginstal package puppeteer penuh, yang membawa download Chromium sendiri (~400MB).
Solusi: beralihlah ke puppeteer-core + @sparticuz/chromium. Kalau kamu benar-benar butuh ruang lebih, pindah ke pendekatan Container Image dengan batas 10GB.
"Browser disconnected" atau Timeout pada browser.newPage()
Akar masalah: memory Lambda tidak cukup, atau kamu tidak menyertakan flag seperti --disable-gpu di launch args.
Solusi: set memory minimal 1024MB (saya sarankan lebih tinggi — lihat benchmark di bawah) dan pastikan kamu meneruskan chromium.args, bukan daftar custom yang dipangkas.
Kode yang sebelumnya jalan tiba-tiba rusak setelah Lambda Runtime di-update
Akar masalah: AWS secara berkala menambal runtime dasar, dan itu bisa menggeser versi shared library atau patch Node.js di bawah kamu.
Solusi: kunci versi @sparticuz/chromium secara eksplisit, kunci versi Node runtime di konfigurasi fungsi, dan — bagian yang sering dilewati orang — uji ulang setelah setiap pengumuman runtime AWS, bukan cuma saat ada yang rusak.
"Protocol error: Connection closed" setelah sekitar 30 detik
Akar masalah: timeout Lambda lebih pendek daripada waktu yang dibutuhkan halaman untuk benar-benar loading dan rendering.
Solusi: naikkan timeout ke 60–120 detik, set page.setDefaultNavigationTimeout() secara eksplisit, dan ganti waitUntil: 'networkidle0' menjadi waitUntil: 'domcontentloaded' kalau kamu tidak perlu menunggu semua request jaringan selesai sepenuhnya sebelum lanjut.
Hardening untuk Production: Memory, Cold Start, dan Biaya
Kebanyakan panduan hanya menyuruh kamu "naikkan memory" lalu berhenti di situ. Itu bukan saran yang bisa langsung dipakai — berikut apa yang sebenarnya berubah saat kamu menaikkan memory.
Memory vs. Performance
Lambda mengalokasikan CPU secara proporsional terhadap memory, dan detail inilah yang sering mengecoh orang. Memory yang lebih besar bukan cuma berarti "RAM lebih banyak" — tapi juga CPU yang lebih cepat, yang langsung mempercepat rendering Chromium. Dalam praktiknya, tim yang menjalankan benchmark Puppeteer biasanya melihat eksekusi yang jauh lebih cepat saat naik dari 512MB ke kisaran 1536–2048MB, meski angka pastinya sangat bergantung pada halaman yang kamu render. Daripada mengutip tabel benchmark yang akan cepat usang, lakukan tes sendiri di 512MB, 1024MB, 1536MB, dan 2048MB terhadap halaman targetmu — ini pekerjaan sepuluh menit yang akan menunjukkan titik optimal cost/performance kamu dengan sangat jelas.
Provisioned Concurrency untuk Mengurangi Cold Start
Kalau kamu menjalankan workload yang sensitif terhadap latensi — synthetic monitoring, API screenshot real-time — cold start adalah musuhmu. Provisioned Concurrency menjaga sejumlah environment eksekusi tetap hangat dan siap pakai, sehingga penalti cold start hilang, dengan konsekuensi kamu membayar kapasitas idle tersebut. Ini layak dipakai khususnya ketika latensi lebih penting daripada efisiensi biaya mentah.
arm64 (Graviton) untuk Hemat Biaya
Fungsi Lambda berbasis Graviton biasanya sekitar 20% lebih murah dibanding x86_64. Tantangannya: dukungan arm64 dari @sparticuz/chromium secara historis lebih terbatas daripada x86_64, jadi verifikasi secara eksplisit untuk versi yang kamu kunci sebelum memutuskan memakai Graviton di production.
VPC vs. Non-VPC
Menempatkan fungsi kamu di VPC dulu menambah latensi cold start yang cukup terasa; AWS sudah memperkecil gap itu dalam beberapa tahun terakhir, tapi tidak hilang sepenuhnya. Masukkan fungsi ke VPC hanya kalau memang perlu mengakses resource privat seperti RDS atau ElastiCache — kalau tidak, lewati saja.
Kapan Harus Pindah Sepenuhnya dari Lambda
Kalau tugas browser kamu rutin melebihi 15 menit, membutuhkan memory lebih dari 10GB, atau memerlukan sesi browser persisten lintas request, berarti Lambda sudah bukan tempat yang tepat. ECS Fargate memang dirancang untuk ini — komputasi yang berjalan lama, resource yang bisa diatur, dan bayar per detik. Lambda sangat bagus untuk tugas browser yang singkat, meledak sesaat, dan bisa diparalelkan; ini pilihan yang keliru begitu workload kamu mulai terasa seperti service persisten.
Kapan Deploy Puppeteer di Lambda Bukan Pendekatan yang Tepat
Ada satu hal yang patut dipikirkan dengan jujur: sebagian besar developer yang mencari panduan "Puppeteer + Lambda" sebenarnya sedang mencoba menyelesaikan masalah ekstraksi data, bukan otomasi browser. Kalau yang kamu butuhkan adalah data terstruktur dari halaman web — daftar produk, informasi kontak, isi halaman — maka semua urusan packaging Chromium, pinning versi, dan manajemen layer di atas hanya menjadi overhead yang sebenarnya tidak perlu kamu ambil.
Tetap gunakan Lambda + Puppeteer kalau kamu benar-benar butuh kontrol browser: interaksi form yang kustom, pipeline screenshot/PDF, synthetic monitoring, atau pengujian berbasis browser yang memang memanipulasi DOM secara programatik.
Pertimbangkan scraping API kalau tujuan akhir kamu adalah JSON terstruktur dari sebuah halaman web, bukan sesi browser yang kamu kendalikan sendiri. Thunderbit Open API menangani rendering JS, proteksi anti-bot, dan CAPTCHA lewat satu panggilan HTTP — POST /extract dengan JSON Schema akan memberi kamu data terstruktur, sementara POST /distill menghasilkan Markdown yang bersih. Ada juga server MCP (thunderbit_extract, thunderbit_distill) kalau kamu sedang membangun AI agent yang perlu mengambil data di tengah workflow tanpa harus menyalakan browser sendiri.
| Faktor | Lambda + Puppeteer (DIY) | Extraction API (misalnya Thunderbit) |
|---|---|---|
| Waktu setup | Beberapa jam (packaging, layer, debugging) | Beberapa menit (API key + panggilan HTTP) |
| Maintenance | Berkelanjutan (pinning versi, update runtime) | Ditangani oleh penyedia |
| Penanganan anti-bot | Manual (stealth plugin, proxy) | Sudah bawaan |
| Format output | HTML/screenshot mentah yang harus kamu olah sendiri | JSON terstruktur via schema |
| Paling cocok untuk | Otomasi browser penuh, testing, alur kustom | Ekstraksi data, scraping, ingest konten |
Saya akan bilang terus terang: kalau kamu menghabiskan berjam-jam untuk debug binary Chromium hanya demi menarik JSON dari halaman produk, itu tanda kamu sedang menyelesaikan masalah yang salah. Simpan jalur DIY Lambda untuk saat kamu benar-benar perlu mengendalikan browser — untuk ekstraksi data, ada jalan yang lebih langsung. Kalau kamu sedang menimbang tradeoff ini untuk proyek tertentu, panduan AI web scraper kami membahas lanskapnya lebih dalam, dan Thunderbit Chrome Extension layak dicoba kalau kamu ingin menguji pendekatan extraction-first sebelum berkomitmen ke salah satu jalur.
Penutup
Tiga metode deploy, satu tema utama: kunci versi kamu, beri Chromium cukup memory untuk bernapas, dan cocokkan metode deploy dengan batasan nyata kamu — bukan dengan tutorial pertama yang kamu temukan. Layers untuk iterasi cepat, Container Image untuk skala production, ZIP untuk kasus sederhana satu kali pakai. Dan kalau yang sebenarnya kamu lakukan adalah ekstraksi data, bukan otomasi browser, mungkin ada baiknya mengecek apakah API ekstraksi yang memang dibuat khusus bisa menghemat kamu dari ribetnya packaging sama sekali.
FAQ
Bisakah Puppeteer dijalankan di AWS Lambda pada 2026?
Ya — dengan puppeteer-core yang dipasangkan dengan @sparticuz/chromium, lalu dideploy lewat Layers, Container Image, atau ZIP langsung. Package puppeteer penuh dan package chrome-aws-lambda yang sudah deprecated tidak lagi bekerja dengan andal pada runtime Lambda saat ini.
Berapa ukuran paket maksimal untuk AWS Lambda? 250MB setelah diekstrak untuk deployment Layers dan ZIP; 10GB untuk deployment Container Image, sesuai kuota Lambda AWS.
Apakah chrome-aws-lambda masih dipelihara?
Tidak. Package asli chrome-aws-lambda (oleh alixaxel) sudah deprecated dan rusak di Node 18+. Gunakan @sparticuz/chromium sebagai gantinya — saat ini itulah standar yang aktif dipelihara.
Berapa banyak memory yang dibutuhkan Puppeteer di AWS Lambda? 1024MB adalah batas minimum yang realistis; 1536–2048MB adalah rentang di mana performanya mulai terasa nyaman. Di bawah 1024MB, eksekusi akan terasa jauh lebih lambat karena Lambda mengaitkan alokasi CPU dengan memory.
Bagaimana cara mengurangi cold start untuk Puppeteer di Lambda? Alokasikan memory lebih besar (yang sekaligus memberi CPU lebih banyak), pertimbangkan Provisioned Concurrency kalau latensi sangat penting untuk use case kamu, dan jaga deployment package tetap sesederhana mungkin — setiap dependency tambahan berarti tambahan waktu cold start.
