Proxies for Amazon Scraping: Choosing the Right Type

Which proxy type fits each Amazon scraping job: residential for marketplaces abroad, datacenter for .com, .it and .es, and how to log the ZIP you scraped.

For Amazon, pick the proxy type by marketplace first and volume second. If you scrape storefronts outside the US, Italy and Spain (amazon.de, amazon.co.uk, amazon.co.jp), you need residential exits in those countries. If your work stays on amazon.com, amazon.it or amazon.es, datacenter exits in those countries are cheaper and faster, and the choice between them comes down to how you want to be billed. This guide compares the proxy types Node4 sells for that job; it is a type-selection guide, not a ranking of providers, and Node4 sells every option in it.

What decides whether an Amazon scrape is usable

Getting a 200 response is not the same as getting the right data. Amazon prices, stock, delivery promises and the featured offer (the Buy Box) depend on where Amazon thinks the shopper is, and for a logged-out visitor that starts with the IP address and then the delivery location stored in the session. Three things go wrong most often:

• Wrong marketplace country. A German exit on amazon.com still sees amazon.com, but the delivery estimate, import fees and some offers change.
• Wrong delivery location. Two US exits can show different offers because Amazon placed them in different ZIP codes.
• A soft block. A CAPTCHA page or a "Sorry, something went wrong" page comes back with a normal status code and gets parsed as a product with no price.

So record the location, not just the price. For example, a record shaped like this one (the ASIN and seller are placeholders) catches all three:

asin:            B0EXAMPLE1
marketplace:     amazon.com
exit reported:   US, Ohio
delivery ZIP:    43215 (set in session)
featured offer:  seller "Example Store", $24.99, ships in 2 days
page check:      title + price selector found, no captcha form
status:          ACCEPT

If the delivery ZIP is missing or the page check finds a CAPTCHA form, reject the record and retry on a new connection rather than storing a blank price. Setting the delivery ZIP explicitly at the start of each session makes runs comparable from day to day, which matters more for Buy Box tracking than which proxy you use.

Proxy types for Amazon scraping, compared

Residential: marketplaces outside the US, Italy and Spain

Residential exits come from a partner network of consumer devices, not from Node4's own blocks, so they appear to Amazon as ordinary home connections in the country you request. Of the types in this guide, it is the one that gives a local exit for amazon.de or amazon.co.uk. Target with username segments, for example USERNAME-country-de for Germany, and add -state- or -city- when the delivery region matters; the grammar is in country and city targeting.

The cost to watch is page weight, because residential is billed per gigabyte. Measure your own pages first; for example, suppose a product page with images moves about 2 MB. Fetching 10,000 ASINs once a day at that size is about 20 GB a day, or roughly 600 GB a month, which changes the plan size completely. Blocking images and fonts in your fetcher, or reading the offer data without rendering the full page, can cut that by most of the total. Check that arithmetic against the residential plan prices before committing.

For multi-step flows (set a ZIP, open a product, read the offers), add a session segment so the steps share an exit. Residential sessions are best effort, with a 30-minute ceiling, and can end sooner if the device behind the exit goes offline, so a scraper should detect a changed exit and restart that flow.

Datacenter: amazon.com, amazon.it and amazon.es at volume

Node4's datacenter products all use addresses from blocks Node4 owns in the US, Italy and Spain. Amazon can tell these are hosting-network addresses, so expect more CAPTCHA pages per thousand requests than on residential and keep the soft-block check in your parser. In return you usually get shorter round trips than through a household connection, and billing that does not depend on Amazon's page weight, or depends on it less.

• Rotating Datacenter opens a new exit for each new HTTPS tunnel (and each plain-HTTP request); requests sent through one open tunnel keep its exit. A session ID holds one exit for up to 30 minutes, counted from first assignment, which covers a set-ZIP-then-scrape flow. Billed per gigabyte, so it suits a list that runs a few times a day. See rotating plan prices.
• Rotating Unmetered uses the same exits and charges by concurrent connections instead of data. A monitor that keeps 100 workers busy around the clock is sized at 100 connections plus headroom, and image-heavy pages stop costing more. See connection-based pricing.
• Dedicated datacenter gives you fixed addresses that are yours alone with no data cap. They suit a modest watchlist checked on a steady schedule; for a large catalog, spread the load across more addresses or use rotating instead, because a fixed address that requests thousands of ASINs an hour stands out. See dedicated plans.
• Shared datacenter is for proving a parser works. Up to five customers share each address, so its history on Amazon is not under your control.

The mechanics of rotation, sessions and retries are covered in rotating proxies for web scraping.

Which type to buy

Scraping a marketplace outside the US, Italy and Spain: buy residential and budget by gigabytes per ASIN. Scraping amazon.com, amazon.it or amazon.es: start with Rotating Datacenter if the list runs a few times a day, move to Rotating Unmetered once the monitor runs continuously enough that connection pricing beats per-gigabyte pricing, and use dedicated addresses only for a small, steady watchlist. Whichever you buy, store the exit country, delivery ZIP and page check with every price, so a bad record is rejected instead of charted. For provider comparisons rather than types, see proxy providers for web scraping and datacenter proxy providers compared.