Chromium yaklaşık 280 MB yer kaplar. AWS Lambda’nın sıkıştırılmamış paket limiti ise 250 MB’tır. Daha önce npm install puppeteer yapıp bunu doğrudan Lambda’ya dağıtmaya çalıştıysanız, bu hesabın neden tutmadığını zaten biliyorsunuzdur — tutmaz.
Gece 2’de "Failed to launch the browser process" hatalarını ayıklamaya yeterince zaman harcadım; bu yüzden bu konunun tek bir yöntemi gösterip kalan iki seçeneği belirsiz bırakan başka bir anlatımı hak etmediğini düşünüyorum. Bu içerik tam olarak bunun için var: Layers, Container Images ve doğrudan ZIP yükleme arasındaki farklar; 2026 için güncel bir sürüm uyumluluk matrisi; ve istatistiksel olarak en çok karşınıza çıkma ihtimali olan beş hata için bir sorun giderme bölümü.
Puppeteer AWS Lambda’da Nedir ve Neden Kullanılır?
Puppeteer, Chrome DevTools Protocol üzerinden headless Chromium’u kontrol eden bir Node.js kütüphanesidir. Lambda ise AWS’nin sunucusuz işlem servisidir — kullanım başına ödeme yaparsınız, otomatik ölçeklenir ve sunucu yönetmezsiniz. İkisini birleştirdiğinizde, tek bir EC2 örneği bile kurmadan yüzlerce paralel çalışmayı destekleyebilen bir tarayıcı otomasyon altyapısı elde edersiniz.
Takımlar arasında kullanım alanları oldukça benzer: web scraping, ekran görüntüsü ve PDF üretimi, sentetik izleme, SEO için tek sayfalık uygulamaları önceden render etme ve otomatik UI testleri. Sorun yine aynı: Chromium’un boyutu ile Lambda’nın paket limitleri arasındaki uyumsuzluk. Bu yüzden kimse tam puppeteer paketini — kendi Chromium indirmesiyle birlikte — Lambda’ya koymaz. Bunun yerine, tarayıcı içermeyen puppeteer-core ile Lambda için optimize edilmiş bir Chromium ikilisi kullanılır; en yaygın seçenek @sparticuz/chromium’dur.
Bu tek değişiklik — puppeteer yerine puppeteer-core kullanmak — dağıtım konfigürasyonuna tek satır yazmadan önce boyut probleminin %80’ini çözer.
Layers, Container Image ve ZIP: Önce Hangi Yolu Seçeceğinize Karar Verin
Araştırırken beni en çok rahatsız eden şeylerden biri şuydu: mevcut rehberlerin neredeyse hepsi yalnızca tek bir dağıtım yöntemini anlatıyor. AWS SAM rehberleri Layers kullanıyor. CDK örnekleri Docker’dan gidiyor. Rastgele bir Substack yazısı ise S3 üzerinde barındırılan Chromium binary’siyle ham ZIP yöntemini anlatıyor. Kimse bunları yan yana koymuyor; bu da aslında ilk vermeniz gereken kararı — hangi dağıtım yöntemi benim için doğru? — tamamen atlıyor.
O yüzden bunu birlikte netleştirelim.
| Kriter | Lambda Layers | Container Image (Docker) | Doğrudan ZIP Yükleme |
|---|---|---|---|
| Maksimum paket boyutu | 250 MB (tüm layer’lar sıkıştırılmamış halde) | 10 GB image | 250 MB sıkıştırılmamış |
| Dağıtım karmaşıklığı | Orta (layer ARN yönetimi) | Daha yüksek (Dockerfile + ECR push) | En düşük (zipleyip yükleme) |
| Cold start etkisi | Orta | Biraz daha yüksek (daha büyük image pull) | Orta |
| Chromium güncelleme süreci | Layer sürümünü yeniden yayınlama | Image’i yeniden build etme | ZIP’i yeniden yükleme |
| Kimler için uygun | Hızlı prototipler, Serverless Framework kullanıcıları | Prod ortamları, Docker CI kullanan ekipler | Basit, tek seferlik fonksiyonlar |
| IaC desteği | SAM, Serverless Framework | CDK, SAM, Terraform | Konsol, herhangi bir IaC |
250 MB ve 10 GB sınırları doğrudan AWS Lambda kota dokümantasyonundan geliyor — bu rakamlar çok sık değişmiyor, ama dağıtım stratejinizi en baştan belirleyen kritik kısıt tam da bu.
Benim pratik yaklaşımım şöyle: prototip yapıyorsanız veya zaten Serverless Framework kullanıyorsanız Layers ile başlayın. Prod’a çıkıyorsanız ve ekibinizin Docker tabanlı CI/CD’si varsa Container Image seçin — 10 GB sınır size ciddi nefes alanı sağlar. Sadece ara sıra ekran görüntüsü alacak tek bir fonksiyona ihtiyacınız varsa, doğrudan ZIP en az uğraştıran seçenektir.
Üç yol da temelde aynı bağımlılık ikilisini kullanır: puppeteer-core + @sparticuz/chromium. Dağıtım yöntemi, ne paketlediğinizi değil, o paketi nasıl hazırladığınızı değiştirir.
2026 Sürüm Uyumluluk Matrisi (Tahmin Etmeyi Bırakın)
İnsanların aylarını alan kısım burası; saatlerini değil. Stack Overflow ve GitHub issue’larında en çok duyulan şikâyet "nasıl dağıtırım" değil — "çalışan dağıtımım neden npm güncellemesinden sonra sessizce bozuldu" sorusu. Nedeni neredeyse her zaman @sparticuz/chromium, puppeteer-core ve Node.js runtime arasındaki uyumsuzluktur.
Önce en önemli not: chrome-aws-lambda (orijinal alixaxel paketi) artık kullanılmıyor. Node 18+ sürümlerinde sorun çıkarıyor ve Chromium güncellemelerine ayak uyduramadı. Bir rehberde buna atıf görürseniz sekmeyi kapatın — güncel olmayan bir şey okuyorsunuz demektir. Güncel tüm rehberler sizi bunun yerine @sparticuz/chromium’a yönlendirmeli.
Sürüm eşleştirmesini göz kararı major numaralarla yapmak yerine bu uyumluluk kuralını kullanın:
| Bileşen | Sürüm kuralı | Dağıtımdan önce ne kontrol edilmeli |
|---|---|---|
puppeteer-core | Uygulamanızın ihtiyaç duyduğu Puppeteer sürümünü seçin | O Puppeteer sürümünün desteklediği Chromium build’ini kontrol edin |
@sparticuz/chromium | Major sürümü Puppeteer’ın major sürümünü değil, Chromium major sürümünü takip eder | Puppeteer destek tablosundaki Chromium build’iyle eşleştirin ve Sparticuz release notlarını okuyun |
| AWS Lambda Node.js runtime | Hâlen desteklenen bir Lambda runtime kullanın | Her runtime veya paket güncellemesinden sonra bir invocation testi çalıştırın |
| Mimari | npm paketi x64 binary’leri içerir; arm64 desteği Chromium v135 ile, arm64 layer veya remote pack üzerinden başlar | Lambda mimarisi, layer/pack artefaktı ve Chromium sürümü birebir aynı olmalı |
Burada kasıtlı olarak sabit bir paket çifti vermiyorum; çünkü @sparticuz/chromium, Chromium’un yayın döngüsünü takip eder ve klasik semantik sürümleme mantığıyla çalışmaz. Önce resmî Puppeteer Chromium Support sayfasından seçtiğiniz Puppeteer sürümünün desteklediği Chromium major numarasını bulun, ardından @sparticuz/chromium’un o major sürümünü seçin. Son olarak, Sparticuz release notlarını okuyarak yama seviyesindeki kırılmalar ve mimari detaylarını kontrol edin. İki paket için de aynı major numarayı yalnızca bu eşleşmenin gerçekten doğrulandığından eminseniz kullanın.
Lambda Layers ile Puppeteer AWS Lambda’ya Nasıl Dağıtılır?
Lambda Layer, Chromium’u fonksiyon kodunuzdan ayrı paketlemenizi sağlar. Böylece asıl handler dosyanız küçük kalır ve aynı Chromium layer’ını birden fazla fonksiyonda yeniden kullanabilirsiniz. Bu alandaki en yakın "hızlı başlangıç" çözümü budur.
Adım 1: puppeteer-core ve -min paketini kurun
Chromium dosyaları bir Lambda Layer içinde duruyorsa, fonksiyon paketini küçük tutmak için @sparticuz/chromium-min kullanın. Aşağıdaki yer tutucuları, yukarıda doğruladığınız uyumlu sürümlerle değiştirin:
npm install puppeteer-core@$PUPPETEER_VERSION \
@sparticuz/chromium-min@$CHROMIUM_VERSION
puppeteer değil puppeteer-core kuruyorsunuz; çünkü bu paket otomatik tarayıcı indirmesini atlar. -min paketi başlatma yardımcılarını sağlar, layer ise /opt/chromium altında Brotli ile sıkıştırılmış Chromium dosyalarını sunar.
Adım 2: Bir Chromium Lambda Layer oluşturun veya referans verin
Resmî Sparticuz release’ine ekli mimariye özel layer arşivini kullanın ya da arşivi resmî repodan derleyin. x86_64 Lambda için belgelenmiş build şu şekildedir:
git clone --depth=1 https://github.com/sparticuz/chromium.git
cd chromium
make chromium.x64.zip
Bu işlem chromium.x64.zip üretir. Bunu S3’e yükleyin ve kullandığınız runtime ve mimariyle Lambda Layer olarak yayınlayın. arm64 için ilgili arm64 release artefaktını ya da build hedefini kullanın; x64 bir arşivi arm64 fonksiyona bağlamayın.
SAM kullanıyorsanız, layer ARN’sini template.yaml içinde doğrudan ekleyin:
Resources:
PuppeteerFunction:
Type: AWS::Serverless::Function
Properties:
Layers:
- arn:aws:lambda:us-east-1:XXXXXXXXXXXX:layer:chromium-layer:1
Adım 3: Lambda Handler’ı yazın
Aşağıda bir URL’ye gidip sayfa başlığını döndüren çalışan bir handler örneği var:
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();
}
};
finally bloğuna dikkat edin. Tarayıcıyı her zaman burada kapatın — kapatmazsanız, sıcak Lambda ortamlarında biriken zombie browser süreçleri zamanla gerçek kodunuzla ilgisi olmayan garip bellek hatalarına yol açar.
Adım 4: Bellek, timeout ve mimariyi ayarlayın
Belleği en az 1024 MB yapın — basit bir ekran görüntüsü işi dışında 1536–2048 MB öneririm. Timeout’u en az 60 saniyeye ayarlayın. Özellikle arm64 desteğini kendi Chromium sürümünüz için doğrulamadıysanız mimariyi x86_64 olarak sabitleyin (bu sürümden sürüme değişebilir).
Adım 5: Dağıtın ve test edin
sam build && sam deploy --guided
Bir test event’i ile tetikleyin; ardından bir şey ters giderse hemen CloudWatch Logs’a bakın — aşağıdaki sorun giderme bölümündeki hataların %90’ı orada net şekilde görünür.
Container Image (Docker) ile Puppeteer AWS Lambda’ya Nasıl Dağıtılır?
Container image’lar, 250 MB sıkıştırılmamış paket derdini tamamen ortadan kaldırıp yerine 10 GB sınırı getirir. Özellikle ekibinizin CI hattında zaten Docker varsa, prod iş yükleri için genellikle daha doğru tercihtir.
Adım 1: Dockerfile oluşturun
Node.js için resmî bir AWS Lambda base image ile başlayın, bağımlılıkları kurun ve handler’ı tanımlayın:
FROM public.ecr.aws/lambda/nodejs:20
COPY package*.json ./
RUN npm install --production
COPY . .
CMD ["index.handler"]
Kullandığınız Chromium paketine göre birkaç paylaşımlı kütüphaneyi yum install ile eklemeniz gerekebilir (bunun detayını sorun giderme bölümünde anlatacağım) — @sparticuz/chromium, ihtiyacı olan şeylerin çoğunu zaten içerir; bu da tam Chrome’u elle kurmaya kıyasla süreci ciddi ölçüde kolaylaştırır.
Adım 2: Amazon ECR’ye build edip push edin
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
Image’i Lambda fonksiyonunuzla aynı bölgede tutun — farklı bölgeden çekilen image’lar gereksiz gecikme ekler.
Adım 3: Lambda fonksiyonunu container image’dan oluşturun
Fonksiyonunuzu CLI veya CDK ile ECR image URI’sine bağlayın; bellek (1536–2048 MB) ve timeout (60–120 saniye) ayarlarını da layer tabanlı kurulumda olduğu gibi yapın.
Adım 4: Dağıtın ve test edin
Bir test event’i ile çalıştırın ve çıktıyı doğrulayın. Layers’a göre temel fark: image pull daha büyük olduğu için cold start biraz artar, ama bağımlılıklar için çok daha fazla alan kazanırsınız.
Doğrudan ZIP Yükleme ile Puppeteer AWS Lambda’ya Nasıl Dağıtılır?
Bu, gösterişsiz seçenektir — yönetilecek layer yok, build edilecek Docker yok. Prototipler veya tam bir tarayıcı otomasyon platformuna dönüşmeyecek tek seferlik fonksiyonlar için idealdir.
Adım 1: Bağımlılıkları lokal olarak kurun
Kendi içinde çalışan bir ZIP için puppeteer-core + @sparticuz/chromium kullanın ve her iki sürümü de sabitleyin. Tam paket, sıkıştırılmış Chromium dosyalarını içerir ve runtime’da bunları /tmp içine çıkarır. @sparticuz/chromium-min paketini yalnızca bu dosyalar bir Lambda Layer veya hızlı bir remote pack URL’si ile ayrıca sağlanıyorsa kullanın; -min paketi Brotli dosyalarını kendi başına içermez.
Adım 2: Fonksiyonu paketleyip ZIP’leyin
npm install --production
zip -r function.zip . -x "*.git*"
Burada --production bayrağı önemli — geliştirme bağımlılıkları 250 MB kotanızı boş yere tüketir.
Adım 3: Lambda fonksiyonunu yükleyin ve yapılandırın
aws lambda update-function-code --function-name my-puppeteer-fn --zip-file fileb://function.zip
ZIP’iniz 50 MB’ı aşarsa bunu konsoldan ya da basit bir CLI çağrısıyla doğrudan yükleyemezsiniz — önce S3’e yükleyip S3 URI’sini kullanmanız gerekir. Bellek, timeout ve mimari ayarlarını diğer iki yöntemdeki gibi yapın.
Adım 4: Dağıtın ve test edin
Aynı çalıştırma ve log kontrol akışını kullanın. Tam paket kullanıyorsanız chromium.executablePath() için argüman vermeniz gerekmez. chromium-min kullanıyorsanız, layer yapısı için yukarıda gösterildiği gibi tam layer dizinini veya remote pack URL’sini verin; örneğin chromium.executablePath("/opt/chromium"). Remote pack, ilk cold start’a indirme işi ekler; bu yüzden dosyayı fonksiyona yakın bir yerde barındırın ve artefakt sürümüyle mimarisini doğrulayın.
Lambda’da Gerçekten İşe Yarayan puppeteer.launch() Argümanları
Herkesin kopyaladığı snippet bu olduğuna göre, doğru yapalım. Lambda’nın çalışma ortamında /dev/shm yoktur, GPU erişimi verilmez ve izinler kısıtlıdır — yani dizüstü bilgisayarınızda çalışan varsayılan puppeteer.launch() çağrısı burada çalışmaz, hatta doğrudan başarısız olur.
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,
});
@sparticuz/chromium içindeki chromium.args dizisi, sunucusuz ortam için gerekli bayrakları zaten içerir — --no-sandbox, --disable-gpu, --disable-dev-shm-usage ve benzerleri. Bu paketi kendi bayrak listenizi sıfırdan yazmak yerine kullanmanın amacı da budur: Chromium’un ihtiyaçlarını sizin yerinize takip eder.
Sorun Giderme: Her Geliştiricinin Karşılaştığı 5 Hata
Bulabildiğim hiçbir rehber düzgün bir sorun giderme bölümü içermiyor; bu biraz garip, çünkü bu yazıyı okuyorsanız büyük ihtimalle sebep tam olarak hatalar.
"Failed to launch the browser process"
Kök neden: eksik paylaşımlı kütüphaneler (libnss3.so, libatk vb.) veya yanlış bir executablePath.
Çözüm: @sparticuz/chromium, gerekli bağımlılıkların çoğunu paketler; bu yüzden kendi Chromium binary’nizi elle yönetmek yerine önerilir. Docker dağıtımında hâlâ aynı hatayı alıyorsanız, eksik kütüphaneleri Dockerfile içinde açıkça yum install ile ekleyin.
"Unzipped size must be smaller than 262144000 bytes"
Kök neden: Tam puppeteer paketini kurmuşsunuzdur; bu paket kendi Chromium indirmesini de içerir (~400 MB).
Çözüm: puppeteer-core + @sparticuz/chromium kombinasyonuna geçin. Gerçekten daha fazla alana ihtiyacınız varsa, Container Image yaklaşımına geçin; 10 GB sınırı sizi rahatlatır.
"Browser disconnected" veya browser.newPage() üzerinde timeout
Kök neden: Lambda belleği yetersizdir veya launch args içinde --disable-gpu gibi bayraklar eksiktir.
Çözüm: Belleği en az 1024 MB yapın (ben daha yükseğini öneririm — aşağıdaki benchmark bölümüne bakın) ve sadeleştirilmiş özel bir liste yerine chromium.args geçtiğinizden emin olun.
Çalışan Kodun Lambda Runtime Güncellemesinden Sonra Bozulması
Kök neden: AWS periyodik olarak alttaki runtime’ı yamalar; bu da paylaşımlı kütüphane sürümlerini veya Node.js patch sürümünü sessizce değiştirebilir.
Çözüm: @sparticuz/chromium sürümünü açıkça sabitleyin, fonksiyon konfigürasyonunda Node runtime sürümünü sabitleyin ve insanların sık atladığı kısmı da yapın: sadece bir şey bozulduğunda değil, her AWS runtime duyurusundan sonra yeniden test edin.
Yaklaşık 30 Saniye Sonra "Protocol error: Connection closed"
Kök neden: Lambda timeout’unuz, sayfanın gerçekten yüklenip render olması için gereken süreden kısadır.
Çözüm: Timeout’u 60–120 saniyeye çıkarın, page.setDefaultNavigationTimeout() değerini açıkça belirleyin ve devam etmeden önce tüm ağ isteklerinin bitmesini zorunlu kılmıyorsanız waitUntil: 'networkidle0' yerine waitUntil: 'domcontentloaded' kullanın.
Prod Ortamı İçin Sertleştirme: Bellek, Cold Start ve Maliyet
Birçok rehber size sadece "belleği artırın" der ve konuyu kapatır. Bu, uygulanabilir bir öneri değil — ölçek büyüdükçe gerçekten neyin değiştiğine bakalım.
Bellek ve Performans
Lambda, CPU’yu belleğe orantılı olarak ayırır; insanların kafasını karıştıran detay da budur. Daha fazla bellek yalnızca "daha fazla RAM" demek değildir — aynı zamanda daha hızlı CPU demektir ve bu da Chromium’un render süresini doğrudan azaltır. Pratikte, Puppeteer benchmark’ı yapan ekipler 512 MB’tan 1536–2048 MB bandına çıkınca belirgin hız artışı bildiriyor; ancak sizin gerçek rakamlarınız render ettiğiniz sayfalara çok bağlı olacaktır. Bu yazıyı okurken eskimiş olacak bir benchmark tablosu vermek yerine, kendi hedef sayfalarınıza karşı 512 MB, 1024 MB, 1536 MB ve 2048 MB testleri çalıştırın — on dakikalık bir egzersizle maliyet/performance dengenizin tam olarak nerede olduğunu görürsünüz.
Cold Start için Provisioned Concurrency
Düşük gecikmenin kritik olduğu bir şey yapıyorsanız — sentetik izleme, gerçek zamanlı ekran görüntüsü API’si — cold start sizin düşmanınızdır. Provisioned Concurrency, belirli sayıda çalışma ortamını sıcak ve hazır tutarak cold start cezasını ortadan kaldırır; karşılığında bu boş kapasitenin maliyetini ödersiniz. Gecikme, ham maliyet verimliliğinden daha önemliyse buna değer.
Maliyet Tasarrufu için arm64 (Graviton)
Graviton tabanlı Lambda fonksiyonları, x86_64 eşdeğerlerine göre yaklaşık %20 daha ucuz çalışır. Ancak bir uyarı var: @sparticuz/chromium arm64 desteği tarihsel olarak x86_64 kadar geniş değildi; bu yüzden prod ortamında Graviton’a geçmeden önce sabitlediğiniz sürüm için açık doğrulama yapın.
VPC ve VPC Olmayan Kurulum
Fonksiyonu bir VPC içine almak eskiden ciddi cold start gecikmesi eklerdi; AWS son yıllarda bu farkın büyük kısmını kapattı, ama sıfıra indirmedi. Sadece RDS veya ElastiCache gibi özel kaynaklara erişmesi gerçekten gerekiyorsa VPC kullanın — aksi halde kullanmayın.
Lambda’dan Tamamen Ne Zaman Çıkmalı?
Tarayıcı işleriniz düzenli olarak 15 dakikayı aşıyorsa, 10 GB’tan fazla belleğe ihtiyaç duyuyorsa veya istekler arasında kalıcı tarayıcı oturumları istiyorsa, Lambda artık size hizmet etmiyordur. ECS Fargate tam da bunun için tasarlandı: uzun süre çalışan, kaynakları ayarlanabilir, saniye bazlı ücretlendirilen işlem. Lambda; kısa, ani ve paralelleştirilebilir tarayıcı işleri için harikadır; ancak iş yükünüz kalıcı bir servise benzemeye başladığında yanlış araç olur.
Lambda’da Puppeteer Dağıtmak Ne Zaman Yanlış Yaklaşımdır?
Burada dürüst olmakta fayda var: "Puppeteer + Lambda" rehberlerine gelen geliştiricilerin önemli bir kısmı aslında tarayıcı otomasyonu değil, veri çıkarma problemi çözüyor. Gerçek ihtiyacınız web sayfalarından yapılandırılmış veri almaksa — ürün listeleri, iletişim bilgileri, sayfa içeriği — yukarıdaki tüm Chromium paketleme, sürüm sabitleme ve layer yönetimi aslında gereksiz bir yük olabilir.
Lambda + Puppeteer’da kalın eğer gerçekten tarayıcı kontrolüne ihtiyacınız varsa: özel form etkileşimleri, ekran görüntüsü/PDF akışları, sentetik izleme veya DOM’u programatik olarak manipüle ettiğiniz tarayıcı tabanlı testler.
Bir scraping API’sini değerlendirin eğer nihai hedefiniz, kendi yönettiğiniz bir tarayıcı oturumu değil de web sayfasından yapılandırılmış JSON almaksa. Thunderbit’in Open API’si, JavaScript render’ını, bot korumalarını ve CAPTCHA’ları tek bir HTTP çağrısının arkasında yönetir — POST /extract ile JSON Schema kullanarak yapılandırılmış veri alırsınız, POST /distill ile temiz Markdown elde edersiniz. Ayrıca, kendi tarayıcısını ayağa kaldırmadan iş akışının ortasında veri çekmesi gereken bir AI ajanı geliştiriyorsanız bir MCP sunucusu da var (thunderbit_extract, thunderbit_distill).
| Faktör | Lambda + Puppeteer (Kendin Yap) | Extraction API (ör. Thunderbit) |
|---|---|---|
| Kurulum süresi | Saatler (paketleme, layer’lar, hata ayıklama) | Dakikalar (API anahtarı + HTTP çağrısı) |
| Bakım | Sürekli (sürüm sabitleme, runtime güncellemeleri) | Sağlayıcı tarafından yönetilir |
| Bot koruması | Manuel (stealth eklentileri, proxy’ler) | Yerleşik |
| Çıktı formatı | Kendi parse ettiğiniz ham HTML/ekran görüntüleri | Şemaya göre yapılandırılmış JSON |
| En uygun kullanım | Tam tarayıcı otomasyonu, test, özel akışlar | Veri çıkarma, scraping, içerik içe aktarma |
Bunu açık söyleyeyim: ürün sayfalarından JSON çekmek için saatlerce Chromium binary’si debug ediyorsanız, muhtemelen yanlış problemi çözüyorsunuz. Gerçekten bir tarayıcıyı kontrol etmeniz gerekiyorsa DIY Lambda yolunu saklayın — çıkarım için daha doğrudan bir yöntem var. Bu dengeyi belirli bir proje için tartıyorsanız, AI web scraper rehberimiz konuyu daha ayrıntılı ele alıyor; doğrudan önce çıkarım odaklı yaklaşımı denemek istiyorsanız Thunderbit Chrome Extension incelemeye değer.
Sonuç
Üç dağıtım yöntemi, tek bir ortak tema: sürümleri sabitleyin, Chromium’a rahat çalışacak kadar bellek verin ve dağıtım yöntemini ilk bulduğunuz rehbere göre değil, gerçek kısıtlarınıza göre seçin. Hızlı iterasyon için Layers, prod ölçeği için Container Images, basit tek seferlik işler için ZIP. Ve asıl yaptığınız şey tarayıcı otomasyonu değil de veri çıkarma ise, özel olarak tasarlanmış bir extraction API’si paketleme derdini tamamen ortadan kaldırabilir.
SSS
2026’da AWS Lambda üzerinde Puppeteer çalıştırılabilir mi?
Evet — puppeteer-core ile @sparticuz/chromium birlikte kullanılarak, Layers, Container Image veya doğrudan ZIP ile dağıtılabilir. Tam puppeteer paketi ve artık desteği olmayan chrome-aws-lambda paketi güncel Lambda runtime’larında güvenilir şekilde çalışmaz.
AWS Lambda için maksimum paket boyutu nedir? AWS Lambda kotalarına göre, Layers ve ZIP dağıtımlarında sıkıştırılmamış 250 MB; Container Image dağıtımlarında ise 10 GB.
chrome-aws-lambda hâlâ güncelleniyor mu?
Hayır. Orijinal chrome-aws-lambda paketi (alixaxel tarafından) artık kullanılmıyor ve Node 18+ sürümlerinde bozuluyor. Bunun yerine @sparticuz/chromium kullanın — şu anda aktif olarak sürdürülen standart budur.
Puppeteer AWS Lambda’da ne kadar bellek ister? 1024 MB pratik minimumdur; 1536–2048 MB ise performansın gerçekten rahatladığı aralıktır. 1024 MB’ın altında, Lambda’nın CPU tahsisini belleğe bağlaması nedeniyle belirgin yavaşlık bekleyin.
Puppeteer’ın Lambda’daki cold start süresini nasıl azaltırım? Belleği artırın (bu size daha fazla CPU da kazandırır), kullanım senaryonuz için gecikme kritikse Provisioned Concurrency düşünün ve dağıtım paketini olabildiğince hafif tutun — her ekstra bağımlılık, ek cold start süresi demektir.
