Chromium ist ungefähr 280 MB groß. Das ungepackte Limit für AWS Lambda liegt bei 250 MB. Wer schon einmal versucht hat, npm install puppeteer auszuführen und dann direkt auf Lambda zu deployen, weiß, wie diese Rechnung ausgeht: gar nicht.
Ich habe schon genug Nächte mit dem Fehler „Failed to launch the browser process“ verbracht, um zu wissen, dass dieses Thema einen echten Vergleich verdient – nicht noch ein Tutorial, das nur einen Weg zeigt und bei den anderen beiden offene Fragen lässt. Genau darum geht es hier: Layers vs. Container Images vs. direkter ZIP-Upload, eine aktuelle Versionskompatibilitäts-Matrix für 2026 und ein Troubleshooting-Teil zu den fünf Fehlern, die statistisch am ehesten auftauchen.
Was ist Puppeteer auf AWS Lambda – und warum überhaupt?
Puppeteer ist eine Node.js-Bibliothek, mit der sich Headless Chromium über das Chrome DevTools Protocol steuern lässt. Lambda ist AWS’ serverloses Rechenmodell: Sie zahlen pro Aufruf, die Skalierung läuft automatisch und Sie müssen sich nie um einen Server kümmern. Zusammengenommen erhalten Sie damit ein Browser-Automatisierungs-Setup, das Hunderte paralleler Ausführungen bewältigen kann, ohne dass Sie auch nur eine einzige EC2-Instanz bereitstellen müssen.
Die Anwendungsfälle sind teamübergreifend ziemlich ähnlich: Web Scraping, das Erzeugen von Screenshots und PDFs, Synthetic Monitoring, das Vorab-Rendern von Single-Page-Apps für SEO und automatisierte UI-Tests. Das Problem ist immer dasselbe wie oben erwähnt: die Größe von Chromium im Verhältnis zu den Paketlimits von Lambda. Deshalb deployt niemand das vollständige puppeteer auf Lambda – es bringt nämlich seinen eigenen Chromium-Download mit. Stattdessen nutzt man puppeteer-core ohne eingebauten Browser zusammen mit einem für Lambda optimierten Chromium-Binary, meistens @sparticuz/chromium.
Allein dieser Wechsel – puppeteer-core statt puppeteer – löst rund 80 % des Größenproblems, noch bevor Sie eine einzige Zeile Deployment-Konfiguration geschrieben haben.
Layers vs. Container Image vs. ZIP: Erst den Weg wählen
Während meiner Recherche hat mich vor allem eines gestört: Fast jede bestehende Anleitung behandelt genau nur eine Deploy-Methode. Die AWS-SAM-Tutorials arbeiten mit Layers. Die CDK-Beispiele nutzen Docker. Irgendein Substack-Artikel zeigt einen rohen ZIP-Upload mit einem auf S3 gehosteten Chromium-Binary. Niemand stellt die Optionen nebeneinander – und genau dadurch fällt die erste wirklich wichtige Entscheidung unter den Tisch: Welche Deploy-Methode passt eigentlich zu meinem Fall?
Also machen wir es ordentlich.
| Kriterium | Lambda Layers | Container Image (Docker) | Direkter ZIP-Upload |
|---|---|---|---|
| Maximale Paketgröße | 250 MB ungepackt (über alle Layers hinweg) | 10 GB Image | 250 MB ungepackt |
| Komplexität des Deployments | Mittel (Layer-ARN-Verwaltung) | Höher (Dockerfile + Push zu ECR) | Am einfachsten (ZIP packen und hochladen) |
| Einfluss auf Cold Starts | Moderat | Etwas höher (größerer Image-Pull) | Moderat |
| Workflow für Chromium-Updates | Layer-Version neu veröffentlichen | Image neu bauen | ZIP neu hochladen |
| Am besten geeignet für | Schnelle Prototypen, Serverless-Framework-Nutzer | Produktions-Workloads, Teams mit Docker-CI | Einfache Einzel-Funktionen |
| IaC-Unterstützung | SAM, Serverless Framework | CDK, SAM, Terraform | Konsole, jedes IaC |
Sowohl die 250-MB- als auch die 10-GB-Grenze stammen direkt aus der AWS-Lambda-Quotendokumentation – das ist keine Zahl, die sich groß verändert hat, aber genau diese eine Begrenzung bestimmt Ihre gesamte Deploy-Strategie von Anfang an.
Meine Faustregel: Wenn Sie prototypen oder ohnehin schon Serverless Framework verwenden, starten Sie mit Layers. Wenn Sie produktiv ausliefern und Ihr Team bereits Docker CI/CD hat, nehmen Sie Container Images – die 10 GB schaffen Luft. Wenn Sie nur eine einzelne Funktion brauchen, die gelegentlich Screenshots erstellt, ist der direkte ZIP-Upload am wenigsten aufwendig.
Unter allen drei Wegen steckt dieselbe Kern-Kombination: puppeteer-core + @sparticuz/chromium. Die Deploy-Methode entscheidet nur darüber, wie Sie das Paket zusammenstellen – nicht, was Sie zusammenstellen.
Die Versionskompatibilitäts-Matrix für 2026 (bitte nicht mehr raten)
Das ist der Punkt, an dem Leute Monate verlieren, nicht Stunden. Die lauteste Beschwerde auf Stack Overflow und in GitHub-Issues ist nicht „Wie deploye ich das?“ – sondern „Warum ist mein funktionierendes Deployment nach einem npm-Update plötzlich kaputt?“ Der Auslöser ist fast immer ein Versionskonflikt zwischen @sparticuz/chromium, puppeteer-core und der Node.js-Runtime.
Wichtiger Hinweis zuerst: chrome-aws-lambda (das ursprüngliche alixaxel-Paket) ist veraltet. Es funktioniert auf Node 18+ nicht zuverlässig und hält mit Chromium-Releases nicht mehr Schritt. Wenn Sie eine Anleitung sehen, die darauf verweist, können Sie den Tab schließen – das ist überholt. Jede aktuelle Anleitung sollte stattdessen auf @sparticuz/chromium verweisen.
Nutzen Sie lieber diese Kompatibilitätsregel statt Paket-Hauptversionen nach Augenmaß zu matchen:
| Komponente | Versionsregel | Was Sie vor dem Deploy prüfen sollten |
|---|---|---|
puppeteer-core | Wählen Sie die Puppeteer-Version, die Ihre Anwendung benötigt | Suchen Sie den Chromium-Build heraus, den diese Puppeteer-Version unterstützt |
@sparticuz/chromium | Die Hauptversion folgt der Chromium-Hauptversion, nicht der Puppeteer-Hauptversion | Gleichen Sie sie mit dem Chromium-Build aus der Puppeteer-Support-Tabelle ab und lesen Sie die Sparticuz-Release Notes |
| AWS Lambda Node.js Runtime | Verwenden Sie eine aktuell unterstützte Lambda-Runtime | Führen Sie nach jeder Runtime- oder Paketaktualisierung einen Invoke-Test aus |
| Architektur | Das npm-Paket enthält x64-Binaries; arm64-Support beginnt ab Chromium v135 über ein arm64-Layer oder Remote-Pack | Lambda-Architektur, Layer-/Pack-Artefakt und Chromium-Version müssen exakt zusammenpassen |
Ich nenne hier bewusst kein festes Paketpaar, weil @sparticuz/chromium dem Chromium-Releasezyklus folgt und kein klassisches Semantic Versioning verwendet. Starten Sie mit der offiziellen Puppeteer-Chromium-Support-Seite, notieren Sie die von Ihrer gewählten Puppeteer-Version unterstützte Chromium-Hauptversion und wählen Sie anschließend die entsprechende Hauptversion von @sparticuz/chromium. Lesen Sie danach die Sparticuz-Release Notes auf patchbezogene Breaking Changes und Architekturdetails. Installieren Sie nicht einfach dieselbe Hauptversionsnummer für beide Pakete, außer diese Zuordnung ist durch genau diese beiden Quellen bestätigt.
Puppeteer auf AWS Lambda mit Lambda Layers deployen
Mit einem Lambda Layer können Sie Chromium getrennt von Ihrem Funktionscode verpacken. Dadurch bleibt Ihr Handler klein und Sie können denselben Chromium-Layer in mehreren Funktionen wiederverwenden. Das kommt einem „Quick Start“ in diesem Bereich am nächsten.
Schritt 1: puppeteer-core und das -min-Paket installieren
Wenn die Chromium-Dateien in einem Lambda Layer liegen, halten Sie das Funktionspaket klein, indem Sie @sparticuz/chromium-min verwenden. Ersetzen Sie die Platzhalter durch die oben verifizierten kompatiblen Versionen:
npm install puppeteer-core@$PUPPETEER_VERSION \
@sparticuz/chromium-min@$CHROMIUM_VERSION
Sie installieren puppeteer-core – nicht puppeteer –, weil dabei der automatische Browser-Download entfällt. Das -min-Paket liefert die Start-Helfer, während der Layer die Brotli-komprimierten Chromium-Dateien unter /opt/chromium bereitstellt.
Schritt 2: Einen Chromium-Lambda-Layer erstellen oder referenzieren
Verwenden Sie das architektur-spezifische Layer-Archiv eines offiziellen Sparticuz-Releases oder bauen Sie das Archiv aus dem offiziellen Repository selbst. Für x86_64-Lambda lautet der dokumentierte Build:
git clone --depth=1 https://github.com/sparticuz/chromium.git
cd chromium
make chromium.x64.zip
Dadurch entsteht chromium.x64.zip. Laden Sie es nach S3 hoch und veröffentlichen Sie es als Lambda Layer mit der Runtime und Architektur, die Sie tatsächlich verwenden. Für arm64 nehmen Sie das passende arm64-Release-Artefakt oder den entsprechenden Build-Target; hängen Sie kein x64-Archiv an eine arm64-Funktion.
Wenn Sie SAM verwenden, binden Sie die Layer-ARN direkt in Ihrer template.yaml ein:
Resources:
PuppeteerFunction:
Type: AWS::Serverless::Function
Properties:
Layers:
- arn:aws:lambda:us-east-1:XXXXXXXXXXXX:layer:chromium-layer:1
Schritt 3: Den Lambda-Handler schreiben
Hier ist ein funktionierendes Handler-Muster, das eine URL aufruft und den Seitentitel zurückgibt:
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();
}
};
Achten Sie auf den finally-Block. Schließen Sie den Browser dort immer – andernfalls sammeln sich in warmen Lambda-Umgebungen Zombie-Browserprozesse über mehrere Aufrufe hinweg an, und irgendwann stoßen Sie auf seltsame Speicherfehler, die mit Ihrem eigentlichen Code nichts zu tun haben.
Schritt 4: Speicher, Timeout und Architektur konfigurieren
Setzen Sie den Speicher auf mindestens 1024 MB – ich würde für alles außer einem trivialen Screenshot-Task 1536–2048 MB empfehlen. Stellen Sie das Timeout auf mindestens 60 Sekunden. Legen Sie die Architektur auf x86_64 fest, sofern Sie arm64-Support nicht für Ihre exakte Chromium-Version ausdrücklich bestätigt haben (das kann sich von Release zu Release ändern).
Schritt 5: Deployen und testen
sam build && sam deploy --guided
Starten Sie anschließend einen Test-Event und prüfen Sie sofort die CloudWatch Logs, falls etwas schiefgeht – 90 % der Fehler aus dem Troubleshooting-Teil unten sind dort klar sichtbar.
Puppeteer auf AWS Lambda mit Container Images (Docker) deployen
Container Images lösen das 250-MB-Problem vollständig, weil stattdessen ein 10-GB-Limit gilt. Für Produktions-Workloads ist das in der Regel die bessere Wahl, besonders wenn Ihr Team Docker ohnehin schon in der CI-Pipeline hat.
Schritt 1: Das Dockerfile anlegen
Starten Sie mit einem offiziellen AWS-Lambda-Basisimage für Node.js, installieren Sie Ihre Abhängigkeiten und setzen Sie den Handler:
FROM public.ecr.aws/lambda/nodejs:20
COPY package*.json ./
RUN npm install --production
COPY . .
CMD ["index.handler"]
Je nach Chromium-Paket müssen Sie eventuell einige gemeinsame Bibliotheken per yum install nachziehen (mehr dazu im Troubleshooting-Teil) – @sparticuz/chromium bringt allerdings bereits den größten Teil der benötigten Abhängigkeiten mit, was deutlich weniger Aufwand bedeutet als ein manuelles Installieren von Chrome.
Schritt 2: Zu Amazon ECR bauen und pushen
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
Halten Sie das Image in derselben Region wie Ihre Lambda-Funktion – regionenübergreifende Image-Pulls erzeugen nur unnötige Latenz.
Schritt 3: Die Lambda-Funktion aus dem Container Image erstellen
Verweisen Sie Ihre Funktion per CLI oder CDK auf die ECR-Image-URI und setzen Sie Speicher (1536–2048 MB) sowie Timeout (60–120 Sekunden) genauso wie bei einer Layer-basierten Bereitstellung.
Schritt 4: Deployen und testen
Starten Sie einen Test-Event und prüfen Sie die Ausgabe. Der wichtigste Trade-off gegenüber Layers: etwas längere Cold Starts durch den größeren Image-Pull, dafür aber deutlich mehr Spielraum für Abhängigkeiten.
Puppeteer auf AWS Lambda per direktem ZIP-Upload deployen
Das ist die unkomplizierte Variante: keine Layers, kein Docker-Build. Gut für Prototypen oder eine einzelne Funktion, die nicht zu einer ganzen Browser-Automationsplattform anwachsen muss.
Schritt 1: Abhängigkeiten lokal installieren
Für ein eigenständiges ZIP verwenden Sie puppeteer-core + @sparticuz/chromium und halten beide Versionen fest. Das vollständige Paket enthält die komprimierten Chromium-Dateien und entpackt sie zur Laufzeit nach /tmp. Verwenden Sie @sparticuz/chromium-min nur dann, wenn diese Dateien separat über einen Lambda Layer oder eine schnelle Remote-Pack-URL bereitgestellt werden; das -min-Paket enthält die Brotli-Dateien nicht selbst.
Schritt 2: Die Funktion bundeln und zippen
npm install --production
zip -r function.zip . -x "*.git*"
Das --production-Flag ist hier wichtig – Dev-Dependencies fressen Ihr 250-MB-Budget ohne jeden Nutzen.
Schritt 3: Die Lambda-Funktion hochladen und konfigurieren
aws lambda update-function-code --function-name my-puppeteer-fn --zip-file fileb://function.zip
Wenn Ihr ZIP größer als 50 MB ist, können Sie es nicht direkt über die Konsole oder einen einfachen CLI-Aufruf hochladen – dann müssen Sie es zuerst nach S3 hochladen und stattdessen die S3-URI angeben. Speicher, Timeout und Architektur konfigurieren Sie genauso wie bei den beiden anderen Methoden.
Schritt 4: Deployen und testen
Nutzen Sie denselben Ablauf aus Aufruf und Log-Prüfung. Beim vollständigen Paket braucht chromium.executablePath() kein Argument. Bei chromium-min übergeben Sie den exakten Layer-Ordner oder die Remote-Pack-URL, zum Beispiel chromium.executablePath("/opt/chromium") für das oben beschriebene Layer-Layout. Ein Remote Pack fügt dem ersten Cold Start zusätzliche Download-Arbeit hinzu – hosten Sie es also möglichst nah an der Funktion und prüfen Sie Artefaktversion sowie Architektur.
Die puppeteer.launch()-Args, die auf Lambda wirklich funktionieren
Das ist der Snippet, den alle kopieren – also machen wir ihn korrekt. Die Lambda-Umgebung hat kein /dev/shm, keinen GPU-Zugriff und läuft mit eingeschränkten Rechten. Das heißt: Der Standardaufruf von puppeteer.launch(), der auf dem Laptop problemlos läuft, funktioniert hier einfach nicht.
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,
});
Das chromium.args-Array aus @sparticuz/chromium enthält bereits die Flags, die für eine serverlose Umgebung wichtig sind – --no-sandbox, --disable-gpu, --disable-dev-shm-usage und ähnliche. Genau deshalb nutzt man dieses Paket statt eine eigene Flag-Liste zu bauen: Es hält mit den Chromium-Anforderungen Schritt, damit Sie es nicht müssen.
Troubleshooting: 5 Fehler, die jeder Entwickler irgendwann sieht
Keine der Anleitungen, die ich gefunden habe, enthält einen vernünftigen Troubleshooting-Teil – was etwas verwundert, denn wahrscheinlich lesen Sie diesen Artikel genau wegen eines Fehlers.
„Failed to launch the browser process“
Ursache: fehlende Shared Libraries (libnss3.so, libatk usw.) oder ein falscher executablePath.
Lösung: @sparticuz/chromium bringt die meisten benötigten Abhängigkeiten bereits mit, weshalb es die empfohlene Wahl gegenüber einem selbst zusammengestellten Chromium-Binary ist. Bei Docker-Deployments sollten Sie die fehlenden Libraries, falls das Problem weiter besteht, explizit in Ihrem Dockerfile per yum install nachinstallieren.
„Unzipped size must be smaller than 262144000 bytes“
Ursache: Sie haben das vollständige puppeteer-Paket installiert, das seinen eigenen Chromium-Download mitbringt (ca. 400 MB).
Lösung: Wechseln Sie zu puppeteer-core + @sparticuz/chromium. Wenn Sie wirklich mehr Platz brauchen, gehen Sie auf Container Images mit ihrem 10-GB-Limit.
„Browser disconnected“ oder Timeout bei browser.newPage()
Ursache: zu wenig Lambda-Speicher oder fehlende Flags wie --disable-gpu in den Launch-Args.
Lösung: Setzen Sie den Speicher auf mindestens 1024 MB (ich würde höher gehen – siehe Benchmarks unten) und stellen Sie sicher, dass Sie chromium.args übergeben und nicht eine abgespeckte eigene Liste.
Funktionierender Code bricht nach einem Lambda-Runtime-Update
Ursache: AWS patcht die zugrunde liegende Runtime regelmäßig, wodurch sich Shared-Library-Versionen oder Node.js-Patch-Versionen ändern können.
Lösung: Pinnen Sie Ihre @sparticuz/chromium-Version explizit, pinnen Sie die Node-Runtime-Version in der Funktionskonfiguration und – diesen Punkt überspringen viele – testen Sie nach jeder AWS-Runtime-Ankündigung erneut, nicht erst wenn etwas kaputtgeht.
„Protocol error: Connection closed“ nach etwa 30 Sekunden
Ursache: Ihr Lambda-Timeout ist kürzer als die Zeit, die die Seite zum Laden und Rendern braucht.
Lösung: Erhöhen Sie das Timeout auf 60–120 Sekunden, setzen Sie page.setDefaultNavigationTimeout() explizit und tauschen Sie waitUntil: 'networkidle0' gegen waitUntil: 'domcontentloaded' aus, wenn Sie nicht darauf warten müssen, dass wirklich alle Netzwerkaufrufe abgeschlossen sind.
Produktionshärtung: Speicher, Cold Starts und Kosten
Die meisten Anleitungen sagen nur: „Mehr Speicher zuweisen“ – und hören dann auf. Das ist nicht besonders hilfreich. Hier sehen Sie, was sich tatsächlich verändert, wenn Sie den Speicher erhöhen.
Speicher vs. Performance
Lambda weist CPU proportional zum Speicher zu – genau das übersehen viele. Mehr Speicher bedeutet also nicht nur „mehr RAM“, sondern auch schnellere CPU, was das Rendering durch Chromium direkt beschleunigt. In der Praxis berichten Teams, die Puppeteer benchmarken, von deutlich schnelleren Laufzeiten zwischen 512 MB und dem Bereich von 1536–2048 MB. Die exakten Zahlen hängen allerdings stark von den jeweiligen Zielseiten ab. Statt eine statische Benchmark-Tabelle zu zitieren, die ohnehin beim Lesen schon wieder veraltet ist, sollten Sie Ihren eigenen Test mit 512 MB, 1024 MB, 1536 MB und 2048 MB gegen Ihre echten Zielseiten laufen lassen – das ist eine Sache von zehn Minuten und zeigt Ihnen genau, wo Ihr Sweet Spot zwischen Kosten und Performance liegt.
Provisioned Concurrency gegen Cold Starts
Wenn Sie ein latenzkritisches Szenario betreiben – etwa Synthetic Monitoring oder eine Screenshot-API in Echtzeit – sind Cold Starts Ihr Gegner. Provisioned Concurrency hält eine definierte Zahl an Ausführungsumgebungen warm und einsatzbereit und beseitigt damit den Cold-Start-Aufschlag. Bezahlen müssen Sie dafür allerdings die Leerlaufkapazität. Das lohnt sich immer dann, wenn Latenz wichtiger ist als maximale Kosteneffizienz.
arm64 (Graviton) zur Kostenersparnis
Graviton-basierte Lambda-Funktionen sind ungefähr 20 % günstiger als x86_64-Äquivalente. Der Haken: Die arm64-Unterstützung von @sparticuz/chromium war historisch eingeschränkter als x86_64. Prüfen Sie also für Ihre fest gepinnte Version ausdrücklich, bevor Sie in Produktion auf Graviton setzen.
VPC vs. kein VPC
Früher brachte eine Funktion in einem VPC spürbare Cold-Start-Latenz mit sich; AWS hat diese Lücke in den letzten Jahren stark verkleinert, ganz verschwunden ist sie aber nicht. Stecken Sie Ihre Funktion nur dann in ein VPC, wenn sie wirklich auf private Ressourcen wie RDS oder ElastiCache zugreifen muss – ansonsten lassen Sie es.
Wann Sie Lambda ganz verlassen sollten
Wenn Ihre Browser-Tasks regelmäßig länger als 15 Minuten laufen, mehr als 10 GB Speicher brauchen oder persistente Browser-Sessions über mehrere Requests hinweg erfordern, arbeitet Lambda gegen Sie. ECS Fargate ist genau für solche Fälle gemacht: langlaufende, konfigurierbare, sekundengenau abgerechnete Workloads. Lambda ist großartig für kurze, burstartige und gut parallelisierbare Browser-Aufgaben – aber das falsche Werkzeug, sobald Ihr Workload wie ein dauerhafter Service aussieht.
Wann Puppeteer auf Lambda die falsche Wahl ist
Ein ehrlicher Blick darauf lohnt sich: Ein großer Teil der Entwickler, die bei „Puppeteer + Lambda“ landet, will eigentlich ein Datenextraktionsproblem lösen – kein Browser-Automatisierungsproblem. Wenn Sie in Wirklichkeit strukturierte Daten aus Webseiten brauchen – Produktlisten, Kontaktdaten, Seiteninhalte – dann ist all das Chromium-Packaging, die Versionsbindung und die Layer-Verwaltung oben nur Overhead, den Sie sich nicht hätten aufladen müssen.
Bleiben Sie bei Lambda + Puppeteer, wenn Sie echte Browser-Steuerung brauchen: individuelle Formularinteraktionen, Screenshot-/PDF-Pipelines, Synthetic Monitoring oder browserbasiertes Testing, bei dem Sie das DOM wirklich programmatisch manipulieren.
Denken Sie über eine Scraping-API nach, wenn Ihr Ziel am Ende strukturiertes JSON aus einer Webseite ist – nicht eine Browser-Session, die Sie selbst steuern. Thunderbits Open API übernimmt JS-Rendering, Anti-Bot-Maßnahmen und CAPTCHAs hinter einem einzigen HTTP-Aufruf: Mit POST /extract und JSON Schema erhalten Sie strukturierte Daten, mit POST /distill sauberes Markdown. Zusätzlich gibt es einen MCP-Server (thunderbit_extract, thunderbit_distill), wenn Sie einen KI-Agenten bauen und Daten mitten im Workflow abrufen müssen, ohne einen eigenen Browser zu starten.
| Faktor | Lambda + Puppeteer (DIY) | Extraktions-API (z. B. Thunderbit) |
|---|---|---|
| Einrichtungszeit | Stunden (Packaging, Layers, Debugging) | Minuten (API-Key + HTTP-Call) |
| Wartung | Laufend (Versionen pinnen, Runtime-Updates) | Vom Anbieter übernommen |
| Anti-Bot-Handling | Manuell (Stealth-Plugins, Proxies) | Integriert |
| Ausgabeformat | Rohes HTML/Screenshots, die Sie selbst parsen | Strukturiertes JSON per Schema |
| Am besten geeignet für | Vollständige Browser-Automatisierung, Tests, Custom-Flows | Datenextraktion, Scraping, Content-Ingestion |
Ich formuliere es klar: Wenn Sie Stunden damit verbringen, Chromium-Binaries zu debuggen, nur um JSON aus Produktseiten zu ziehen, dann lösen Sie wahrscheinlich das falsche Problem. Heben Sie sich den DIY-Lambda-Weg für Fälle auf, in denen Sie wirklich einen Browser steuern müssen – für Extraktion gibt es einen direkteren Weg. Wenn Sie diesen Trade-off für ein konkretes Projekt abwägen, erklärt unser Leitfaden zu AI Web Scrapers die Landschaft ausführlicher, und die Thunderbit Chrome Extension lohnt sich, wenn Sie den Extraktions-first-Ansatz erst testen möchten, bevor Sie sich für einen Weg entscheiden.
Fazit
Drei Deploy-Methoden, ein wiederkehrendes Muster: Versionen pinnen, Chromium genug Speicher geben und die Deployment-Methode an Ihren tatsächlichen Rahmenbedingungen ausrichten – nicht an dem Tutorial, das Sie zuerst gefunden haben. Layers für schnelle Iteration, Container Images für Produktionsskalierung, ZIP für die einfache Einzelaufgabe. Und wenn Sie eigentlich Daten extrahieren statt Browser automatisieren, kann eine spezialisierte Extraktions-API Ihnen das Packaging-Problem komplett ersparen.
FAQs
Kann man Puppeteer 2026 auf AWS Lambda ausführen?
Ja – mit puppeteer-core zusammen mit @sparticuz/chromium, bereitgestellt über Layers, Container Image oder direkten ZIP-Upload. Das vollständige puppeteer-Paket und das veraltete chrome-aws-lambda-Paket funktionieren auf aktuellen Lambda-Runtimes nicht mehr zuverlässig.
Wie groß darf das AWS-Lambda-Paket maximal sein? 250 MB ungepackt für Layers- und ZIP-Deployments; 10 GB für Container-Image-Deployments, laut AWS-Lambda-Quoten.
Wird chrome-aws-lambda noch gepflegt?
Nein. Das ursprüngliche Paket chrome-aws-lambda von alixaxel ist veraltet und bricht auf Node 18+ ab. Nutzen Sie stattdessen @sparticuz/chromium – es ist derzeit der aktiv gepflegte Standard.
Wie viel Speicher braucht Puppeteer auf AWS Lambda? 1024 MB sind das praktische Minimum; 1536–2048 MB sind der Bereich, in dem die Performance wirklich angenehm wird. Unter 1024 MB müssen Sie mit deutlich langsamerer Ausführung rechnen, weil Lambda die CPU-Zuteilung an den Speicher koppelt.
Wie reduziere ich Cold Starts für Puppeteer auf Lambda? Weisen Sie mehr Speicher zu, was gleichzeitig mehr CPU bedeutet, ziehen Sie Provisioned Concurrency in Betracht, wenn Latenz kritisch ist, und halten Sie Ihr Deployment-Paket so schlank wie möglich – jede zusätzliche Abhängigkeit kostet zusätzliche Cold-Start-Zeit.
