How much does it cost to scrape 1 million pages in 2026?
DIY proxies, compute and engineer time versus a flat $299 for 1,000,000 credits: the real cost to scrape 1 million pages, checked August 2026.
“How much does it cost to scrape a million pages” sounds like a single number. It is not. It is at least three numbers (bandwidth, compute, engineering time) that nobody adds up until the invoice for a hobby proxy plan shows up next to the AWS bill.
Here is the honest decomposition for both routes, DIY and API, at 1,000,000 pages a month.
The DIY route: what actually shows up on the bill
Bandwidth. Scraping at any real scale means residential or mobile proxies, because datacenter IPs get blocked fast on anything that cares. Two current pay-as-you-go rates, checked in August 2026: Bright Data lists residential proxies at $4.00/GB pay-as-you-go (a discounted rate off an $8.00/GB list price), and Oxylabs lists residential proxies starting at $6.00/GB pay-as-you-go.
A plain HTML page, no images or scripts counted, runs roughly 50-150KB depending on the site. Assume 100KB average for 1,000,000 static pages: that is about 100GB, so somewhere between $400 and $600 in proxy bandwidth alone, before a single line of parsing code runs.
If the pages need a real browser (JS-rendered content, infinite scroll, content behind an SPA), a headless session pulls down the full page weight, scripts and assets included, not just the HTML. That routinely runs 1-3MB per page. At 1,000,000 pages that is 1-3TB, or roughly $4,000-$18,000 in proxy bandwidth on the same rates. This is the number that surprises people: JS rendering does not add a bit to the bill, it multiplies it, because the unit is now the whole page weight instead of the HTML.
Compute. Static fetches are cheap to run in parallel: a modest worker fleet processing 1,000,000 plain HTTP requests a month is on the order of $50-$200 in cloud compute. Headless Chrome instances are a different animal: each one holds real memory and CPU for the seconds it takes to render a page, so a fleet sized for 1,000,000 JS-rendered pages a month is more realistically $500-$2,000, depending on how aggressively you can batch and recycle browser contexts.
Engineering time. This is the line nobody puts in the spreadsheet, and the one that never goes to zero. Anti-bot measures change, selectors drift when a site redesigns, and proxy pools need monitoring for ban rates. Even a conservative 10-15 hours a month of an engineer’s time at $75-150/hour is $750-$2,250, and that estimate assumes nothing breaks badly enough to need a weekend.
Put together, a static 1,000,000-page job DIY lands somewhere around $1,200-$3,000 a month once bandwidth, compute and maintenance are counted honestly. A JS-rendered job lands closer to $5,000-$20,000, with bandwidth doing most of the damage.
The API route: one number, no maintenance line
On FastAF, /scrape costs 1 credit for a static page, 5 credits with dynamic=true (JS rendering), 10 with premium=true (residential/anti-bot network), and 25 with both.
1,000,000 static pages = 1,000,000 credits = the Pro pack, $299 flat for 1,000,000 credits, 5 concurrent requests. That is the whole bill. No proxy invoice, no headless browser fleet to size, no on-call rotation for when a site changes its markup.
1,000,000 pages with JS rendering (dynamic=true) = 5,000,000 credits. That is one Business pack (3,000,000 credits, $799) plus two Pro packs ($598), $1,397 at list price, or a custom volume deal sized to it (worth asking about directly rather than stacking packs).
| Scenario | Credits needed | FastAF cost | DIY estimate (bandwidth + compute + time) |
|---|---|---|---|
| 1M pages, static | 1,000,000 | $299 (Pro) | ~$1,200-$3,000/month |
| 1M pages, JS rendering | 5,000,000 | ~$1,397 (Business + 2x Pro) or custom | ~$5,000-$20,000/month |
import requests
API_KEY = "faf_live_..."
def scrape(url, dynamic=False, premium=False):
resp = requests.get(
"https://api.fastaf.co/v1/scrape",
params={"url": url, "dynamic": str(dynamic).lower(), "premium": str(premium).lower()},
headers={"Authorization": f"Bearer {API_KEY}"},
timeout=60,
)
resp.raise_for_status()
return resp.text
page = scrape("https://example.com/product/123", dynamic=True)
print(page[:500])The part that changes the math either way
Failed requests are the detail every comparison above quietly assumes away, and it should not be assumed. On FastAF, credits are reserved when a request starts and returned if it does not come back with a result: a blocked attempt does not cost you anything. If you run the DIY numbers above and your ban rate is 15-20% on a hard target, the effective bandwidth and compute cost per usable page is 15-20% higher than the sticker price, and that is before the engineer time spent chasing the block down.
The short version
For static pages at real volume, DIY is a few hundred dollars in proxies plus a maintenance job that never fully goes away; the API route is a flat $299 Pro pack with nothing to maintain. For JS-rendered pages the gap gets much wider in both directions, because page weight (DIY) and credit cost (API) both scale up together. Run your own page-weight and volume numbers through the same math before committing to either route: pricing has the full credit table, and the free tier gives you 500 credits with no card to test against your actual pages first.