Playwright AWS Lambda cost: what Chromium on Lambda bills per run

Playwright on AWS Lambda costs the same per second as Puppeteer, because AWS bills memory and time and does not care which library allocated them. At 1,600 MB and a 4 second render that is $0.000104 a run, or $10.44 for 100,000 runs a month in US East. Every guide to running Playwright on Lambda stops there, and the figure is close to useless on its own, because the thing that actually moves a Playwright bill is not the successful runs. It is the ones that hang.

Lambda bills duration whether your function succeeded or not, and a function that hangs is billed at its configured timeout, not at the four seconds a healthy render takes. That single detail turns a small reliability problem into a large invoice, and it is the reason Playwright deployments so often cost more than the arithmetic predicted. Figures below use the AWS published rate of $0.0000166667 per GB-second plus $0.20 per million requests, read on 6 September 2026.

What a clean Playwright run costs on Lambda

The formula has three inputs: memory, duration, and a token charge per invocation. The maintainers of the Chromium build most Lambda deployments use state that you should allocate "at least 512 MB of RAM to your instance; however, 1600 MB (or more) is recommended." At 1,600 MB, which is 1.5625 GB, a 4 second run consumes 6.25 GB-seconds.

• 2 second runs: $0.0000523 each, $5.23 per 100,000.
• 4 second runs: $0.0001044 each, $10.44 per 100,000.
• 8 second runs: $0.0002085 each, $20.85 per 100,000.

Linear, predictable, and cheap. If your Playwright functions all finish in a few seconds, the compute line on your AWS bill will be smaller than most people expect and smaller than almost any managed alternative. That is the honest starting position, and it is why so many teams self-host.

The number that actually decides the bill: what a timeout costs

Lambda charges for the time your function is running. If a page never fires the event Playwright is waiting for, the function does not fail fast. It sits there until the timeout you configured, and you are billed for all of it. Here is what a single hung invocation costs at 1,600 MB, expressed as a multiple of a clean 4 second render.

Now apply a realistic hang rate. Teams running browser automation against pages they do not fully control commonly see a few percent of runs stall on a font, an analytics beacon, a lazy loaded image or a networkidle condition that never settles.

• 2 percent hangs at a 30 second timeout: $12.00 a month against $10.44 clean. A 15 percent increase from a 2 percent failure rate.
• 5 percent hangs at a 30 second timeout: $14.34. A 37 percent increase from a 5 percent failure rate.
• 5 percent hangs at a 60 second timeout: $18.25. A 75 percent increase.
• 10 percent hangs at a 30 second timeout: $18.25, the same 75 percent.

This is the finding worth taking away: your cost overrun is not proportional to your failure rate, it is proportional to your failure rate multiplied by the ratio of your timeout to your render time. A 5 percent hang rate does not add 5 percent, it adds 37 percent, because each hang is billed at eight times a healthy render. And the instinctive fix when renders start failing, raising the timeout to give slow pages more room, doubles the penalty rather than reducing it.

The practical response is the opposite of the instinct. Set the timeout close to your real p99 render time rather than generously above it, so a hang costs two or three renders instead of eight. Then retry once. A fast failure and a retry is cheaper than one patient hang, and it is also better for your queue.

Why Playwright hangs get more frequent the longer a container stays warm

There is a documented, Playwright specific reason the hang rate is not constant. The maintainers of the serverless Chromium build note that "Playwright does not automatically clean up its user data directory between invocations on a warm Lambda. Over time, /tmp fills up."

Lambda reuses execution environments. A warm container may serve hundreds of invocations, and each one leaves a user data directory behind. Eventually writes to /tmp fail, and a browser that cannot write its profile does not return a clean error, it stalls. So the failure mode is a container that works perfectly for hours and then starts producing timeouts, while a fresh container serves the same input fine.

That shape is genuinely nasty to diagnose. It looks intermittent, it does not reproduce locally, it correlates with traffic rather than with any particular URL, and it costs eight times a normal render every time it happens. The fix is a few lines, cleaning the user data directory explicitly at the end of each invocation, but you have to know to write them, and this is the kind of thing that is only obvious after it has already been in production for a month.

The arm64 saving is real and probably not worth claiming

AWS prices Arm at $0.0000133334 per GB-second against $0.0000166667 on x86, exactly 20 percent less. On 100,000 clean 4 second runs that takes $10.44 down to $8.35, a saving of $2.08 a month.

Claiming it means changing how you package the browser. The standard npm distribution "includes only x64 binaries. For arm64, use the @sparticuz/chromium-min package", and the -min variant exists because "chromium.br is over 50 MB" and will not fit in a normal deployment package, so it expects you to host the compressed binary somewhere and fetch it. You are adding a storage location, a cold start download, and a version pin you now maintain, in exchange for $25 a year. Skip it until the compute line is large enough to notice.

When the answer is a container, and when it is not a browser at all

If your renders are long or your volume is steady, per invocation billing stops being the right shape. A single always on container running Playwright serves requests back to back with no cold start and no per invocation charge, and above a few million renders a month it wins outright. The tradeoff is that you are now running a server: provisioning it, deploying to it without dropping requests, patching it and watching it. If that is the direction you are heading, having something that will provision the box and ship deploys with zero downtime takes most of the tedium out of it.

Before you go there, it is worth asking whether you need a browser at all or only its output. Driving sessions, filling forms, testing flows and scraping behind authentication all genuinely require a browser you control. Turning a URL or a block of HTML into a PDF does not. That job is one HTTP call to a rendering API, with no memory setting to tune, no timeout to price, no /tmp to clean and no Chromium version to pin, and the failure modes become someone else's operational problem rather than a line on your invoice.

We worked the full comparison, including Cloud Run and managed browser platforms priced on the same 100,000 render job, in our breakdown of what Chrome on AWS Lambda really costs per PDF. The short version: self-hosting is about 13 times cheaper on compute, and the entire annual difference is worth 10 to 21 hours of engineering time, so the decision is about maintenance hours rather than about the AWS bill. If you want the setup detail rather than the arithmetic, our notes on Puppeteer PDF generation on AWS Lambda cover the deployment gotchas, and the Puppeteer alternative page covers what changes when you stop managing Chrome yourself.

Frequently asked questions

How much does Playwright cost to run on AWS Lambda?

About $0.000104 per run at 1,600 MB and 4 seconds, which is $10.44 for 100,000 runs a month in US East. AWS charges $0.0000166667 per GB-second on x86 plus $0.20 per million requests. Playwright and Puppeteer cost the same, because Lambda bills allocated memory and elapsed time regardless of which library you used.

Does AWS Lambda charge for failed or timed out invocations?

Yes, and at the full configured timeout rather than the time useful work took. At 1,600 MB a 30 second timeout costs $0.000781, which is eight times a clean 4 second render, and a 15 minute timeout costs $0.023438, or 225 times. This is why a small hang rate produces a large cost increase.

How much memory should I give a Playwright Lambda function?

The serverless Chromium maintainers recommend "at least 512 MB of RAM to your instance; however, 1600 MB (or more) is recommended." Under-allocating rarely saves money, because memory and duration are multiplied together in the bill and a starved browser runs slower and crashes more, which costs full duration each time.

Why does my Playwright Lambda function work and then start timing out?

Most often because /tmp has filled up on a warm container. The maintainers note that Playwright "does not automatically clean up its user data directory between invocations on a warm Lambda. Over time, /tmp fills up." A container serves hundreds of invocations, each leaving a profile directory, and once writes fail the browser stalls rather than erroring cleanly. Clean the user data directory at the end of each invocation.

Is Playwright or Puppeteer cheaper on AWS Lambda?

Neither, on compute. The bill is memory multiplied by duration, so identical settings and identical render times produce identical costs. The difference is operational: Playwright carries the documented warm container /tmp growth, and both share the 50 MB deployment package limit and the x64 only npm distribution that makes arm64 extra work.

Should I raise my Lambda timeout if renders are failing?

Usually not. Raising the timeout increases what every hang costs without reducing how often hangs happen. Moving from 30 to 60 seconds takes a 5 percent hang rate from a 37 percent cost increase to a 75 percent one. Set the timeout near your real p99 render time and retry once instead.