Sparticuz Chromium AWS Lambda Cost: What Chrome and Puppeteer on Lambda Really Cost Per PDF

Lambda pricing has exactly three inputs and no hidden multiplier. You choose a memory size, AWS measures how long your function ran, and you pay for the product of the two plus a token charge per invocation. The formula is:

cost per render = (memory in GB) x (duration in seconds) x (rate per GB-second) + (rate per request)

At 1,600 MB, which is 1.5625 GB, and 4 seconds, that is 6.25 GB-seconds. Multiply by the US East x86 rate of $0.0000166667 and you get $0.000104167, plus $0.0000002 for the request. One hundred thousand of those is $10.44. There is no per gigabyte data charge for the PDF you return through the function response, though there is if you write it to S3 and serve it out.

The reason this matters more than the result is that duration is the only input you control and the only one that moves. Memory is fixed by what Chromium needs to not crash. The request charge is a rounding error. So your bill is a linear function of how long your pages take to render, and it scales with it exactly:

• 2 second renders: $5.23 a month on x86, $4.19 on Arm.
• 4 second renders: $10.44 on x86, $8.35 on Arm.
• 8 second renders: $20.85 on x86, $16.69 on Arm.

Doubling render time doubles the bill. This is why a page that waits on a slow third party font or an analytics script you do not need is not just a latency problem, it is a line item. It is also why the single highest leverage optimization on a self-hosted renderer is not the architecture, it is making the page stop loading things.

Search for what Puppeteer on Lambda costs and you will find confident figures that do not reconcile. One widely shared analysis puts a million renders at about $2.28. Another puts twenty thousand renders at roughly one euro, which would be around fifty times more per render. Both are arithmetic on undisclosed assumptions, and the two assumptions that produce almost all of the spread are memory size and the free tier.

AWS includes 400,000 GB-seconds and one million requests per month at no charge. Against our 6.25 GB-seconds per render, that allowance covers:

• 128,000 renders a month free at 2 seconds each.
• 64,000 renders a month free at 4 seconds each.
• 32,000 renders a month free at 8 seconds each.

This is the trap in the whole category. A team prototyping a PDF feature runs a few thousand renders a month, sees a $0 line on the AWS bill, and concludes that rendering is free. It is not free, it is below the free tier. The bill appears at exactly the moment the feature succeeds, and it appears alongside the concurrency limits and cold start complaints that also only show up under load. If you are sizing this decision, assume the free tier is already spent, because on a production AWS account carrying other Lambdas it is.

Google Cloud Run has the same structure with different numbers: 180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests free per month, based on us-central1 active pricing.

AWS charges $0.0000133334 per GB-second on Arm against $0.0000166667 on x86. That is a clean 20 percent reduction, and it is the largest single lever on the compute line. On our job it is worth $2.08 a month, or $25 a year.

Getting it is not a checkbox. @sparticuz/chromium states plainly that "The npm package (@sparticuz/chromium) includes only x64 binaries. For arm64, use the @sparticuz/chromium-min package." The -min variant exists because, as the same documentation notes, "chromium.br is over 50 MB" and therefore does not fit inside a standard deployment package, so it expects you to host the Brotli compressed binary yourself and point the library at it. Switching to Arm means adding a hosting location for a browser binary, a download step at cold start, and a version pin you now own.

Nobody should do that work for $25 a year. It is worth doing at a volume where the compute line is genuinely large, which on this arithmetic means several million renders a month, and at that point you are having a different conversation anyway. We flag it because the 20 percent figure gets quoted as though it were free, and the packaging split is the thing that makes it not free.

Put the two live options side by side at 100,000 renders a month. Self-hosted on Lambda x86: $10.44. Managed browsers at $140 for the Starter tier: $140. The managed option is 13.4 times the price and the difference is $129.56 a month, or $1,554.76 a year.

Now price that annual difference in the currency it is actually spent in. At a fully loaded US engineering cost of:

• $75 an hour, the managed premium buys 20.7 hours a year, about 1.7 hours a month.
• $100 an hour, it buys 15.5 hours a year, about 1.3 hours a month.
• $150 an hour, it buys 10.4 hours a year, under an hour a month.

So the real question is not what AWS charges. It is whether keeping a headless Chromium deployment healthy costs you more or less than roughly one to two hours a month. That is the whole decision, and it is a question about your team rather than about a rate card.

Here is what lands in those hours, all of it documented rather than hypothetical. The 50 MB deployment limit and the layer or -min workaround it forces. Cold starts, which on a Chromium function are seconds rather than milliseconds and which you pay for. Chrome version upgrades, because the binary is pinned and the pin ages. Font packages, because the Lambda runtime ships almost none and your PDFs will render in a fallback face until you add them. Memory tuning, because too little crashes and too much is billed. And disk: @sparticuz/chromium warns that "Playwright does not automatically clean up its user data directory between invocations on a warm Lambda. Over time, /tmp fills up."

None of those is hard. Every one of them is an afternoon, and they do not arrive on a schedule. If your team has an engineer who enjoys this and has the time, self-hosting is genuinely the cheaper answer and we would not pretend otherwise. If rendering is a feature your product needs rather than a thing your team wants to own, the premium is about ninety minutes a month.

The two pricing models measure different things, and comparing them at one duration hides the most useful thing about them. Lambda bills continuously, by the gigabyte-millisecond. Browserless bills in blocks: a Unit is "any time a browser is started with our API/library and is used for up to 30 seconds", and "A new Unit is charged every 30 seconds of a running Session."

That means a 3 second render and a 29 second render cost exactly the same on a unit model and almost ten times differently on Lambda. So the cheaper platform is not a fixed answer, it depends on how long your pages take.

The crossover is worth knowing precisely. At the Starter tier, $140 for 180,000 units, a fully used unit costs $0.000778. Lambda x86 at 1,600 MB costs $0.0000260417 per second of render time. Set those equal and the two models meet at about 29.9 seconds of render time.

The 30 second unit is priced almost exactly at the Lambda break-even. Below roughly 30 seconds of browser time, self-hosting is cheaper on compute, and the shorter your renders the more dramatically so. At 30 seconds the two are level. Past it the unit model starts a second block and the comparison resets. Whether that is deliberate design or arithmetic coincidence we cannot say, but it is a good sanity check: if your renders take 4 seconds you are paying a managed service for a 30 second block you use an eighth of, and that is where the 13x multiple comes from.

Worth noting that the 13x is a property of the unit, not of managed browsers generally. A managed platform that meters elapsed time continuously rather than in blocks lands in a completely different place on the same job: Browserbase bills browser hours, so 100,000 four second renders cost about $21.33 there against $140 on a 30 second unit model, roughly 6.6 times less for identical work. That puts it within about 2x of self-hosting, which changes the build-versus-buy answer considerably. The comparison is worked out in what a browser hour actually buys for PDF generation.

We normalized eight managed browser and screenshot vendors on a common job, including the unit and per second models side by side, in our Browserbase and Browserless pricing comparison.

This page is published by a rendering API, so it is worth being explicit about where we are the wrong choice.

Keep it on Lambda when the browser work is not just rendering. If you are driving sessions, filling forms, logging into things, scraping behind auth or running tests, you need a browser you control, not a document endpoint. Sizing that market properly means comparing browser platforms rather than PDF APIs.

Keep it when the volume is genuinely large and steady. The 13x multiple is trivial at 100,000 renders and material at 10 million. At that scale the compute line justifies an owner, Arm becomes worth the packaging work, and a long-running container beats per invocation billing outright.

Keep it when the content cannot leave your infrastructure. If the HTML contains regulated data and your compliance position is that it does not transit a third party, that is a real constraint and no price comparison overrides it. We cover the middle ground, where a vendor is acceptable but the data handling has to be documented, in our note on HTML to PDF data residency.

Stop self-hosting when rendering is incidental to your product. If nobody on the team wants to own a Chromium binary, if the PDF feature is one of forty things on the roadmap, or if you have already lost a sprint to fonts and page breaks, the arithmetic above says the premium is about ninety minutes a month of engineering time. That is usually the correct trade and it is the reason this category exists.