Compare static vs rotating proxies across session persistence, use cases, and cost. Learn when to use each type and how sticky sessions bridge the gap.
The Core Trade-Off: Identity Persistence vs IP Diversity
Every proxy operation faces a fundamental tension: do you want the target server to see you as the same user across multiple requests, or as a different user every time? Static proxies give you persistence. Rotating proxies give you diversity. The right choice depends entirely on what you're doing, and picking wrong means either getting blocked or losing sessions.
Static proxies assign you a fixed IP address that stays the same for the duration of your subscription — days, weeks, or months. Every request you send exits from that same IP. Rotating proxies assign a different IP address for each request (or each session), drawing from a pool that can span millions of addresses. Each request appears to originate from a unique user.
These aren't just configuration options — they represent different operational philosophies. Static proxies let you build a persistent online identity. Rotating proxies let you distribute activity across an IP surface so wide that no single identity accumulates enough activity to trigger detection. Understanding when each approach applies is the difference between a reliable operation and one that burns through IPs or loses authenticated sessions.
Static proxies assign you a fixed IP address that stays the same for the duration of your subscription — days, weeks, or months. Every request you send exits from that same IP. Rotating proxies assign a different IP address for each request (or each session), drawing from a pool that can span millions of addresses. Each request appears to originate from a unique user.
These aren't just configuration options — they represent different operational philosophies. Static proxies let you build a persistent online identity. Rotating proxies let you distribute activity across an IP surface so wide that no single identity accumulates enough activity to trigger detection. Understanding when each approach applies is the difference between a reliable operation and one that burns through IPs or loses authenticated sessions.
How Static Proxies Work
A static proxy (also called a dedicated proxy or sticky IP) provides you with one or more IP addresses that are exclusively yours. The provider allocates specific IPs from their pool and reserves them for your account. Every connection you make through that proxy exits from the same address, and no other customer's traffic shares it.
Technically, static proxies are simpler than rotating ones. There's no session management, no IP selection logic, no pool rotation algorithms. You connect to a specific proxy endpoint, and your traffic always exits from the assigned IP. The IP's ASN classification depends on the proxy type — static residential IPs come from ISP address space, static datacenter IPs come from hosting providers.
The key property is continuity. When you send 100 requests over an hour to the same website, all 100 arrive from the same IP. The target sees what looks like a single user with consistent behavior. This enables sessions that persist across requests — login cookies remain valid, shopping carts keep their contents, multi-page workflows complete without interruption.
Static IPs also build reputation over time. An IP that has been behaving normally (reasonable request rates, standard browsing patterns) for weeks or months develops a positive history in IP reputation systems. This accumulated trust is an asset — and one that rotating proxies, by definition, cannot build.
Technically, static proxies are simpler than rotating ones. There's no session management, no IP selection logic, no pool rotation algorithms. You connect to a specific proxy endpoint, and your traffic always exits from the assigned IP. The IP's ASN classification depends on the proxy type — static residential IPs come from ISP address space, static datacenter IPs come from hosting providers.
The key property is continuity. When you send 100 requests over an hour to the same website, all 100 arrive from the same IP. The target sees what looks like a single user with consistent behavior. This enables sessions that persist across requests — login cookies remain valid, shopping carts keep their contents, multi-page workflows complete without interruption.
Static IPs also build reputation over time. An IP that has been behaving normally (reasonable request rates, standard browsing patterns) for weeks or months develops a positive history in IP reputation systems. This accumulated trust is an asset — and one that rotating proxies, by definition, cannot build.
How Rotating Proxies Work
Rotating proxies connect you to a gateway that assigns a different IP from a large pool for each request or session. You send traffic to a single proxy endpoint (e.g.,
The rotation happens transparently. Your application connects to the same proxy address for every request — the IP diversity is handled entirely on the provider's side. A scraping script that sends 10,000 requests through a rotating proxy gateway might use 10,000 different IP addresses without any configuration changes between requests.
Pool size directly impacts rotation quality. Databay's pool of 35 million+ residential IPs means consecutive requests can exit through IPs on completely different ISPs, in different subnets, in different cities. This level of diversity makes pattern detection based on IP proximity or subnet clustering effectively impossible. Smaller pools risk reusing IPs too quickly or having too many IPs from the same subnet, which sophisticated detection systems can flag.
Rotating proxies are primarily billed per GB of bandwidth rather than per IP, because you're consuming a shared resource (the pool) rather than reserving dedicated addresses. This pricing model scales naturally — you pay for what you use, and the number of unique IPs involved is irrelevant to your cost.
gw.databay.co:port), and the gateway's routing engine selects a different exit IP each time based on your targeting parameters and the pool's current availability.The rotation happens transparently. Your application connects to the same proxy address for every request — the IP diversity is handled entirely on the provider's side. A scraping script that sends 10,000 requests through a rotating proxy gateway might use 10,000 different IP addresses without any configuration changes between requests.
Pool size directly impacts rotation quality. Databay's pool of 35 million+ residential IPs means consecutive requests can exit through IPs on completely different ISPs, in different subnets, in different cities. This level of diversity makes pattern detection based on IP proximity or subnet clustering effectively impossible. Smaller pools risk reusing IPs too quickly or having too many IPs from the same subnet, which sophisticated detection systems can flag.
Rotating proxies are primarily billed per GB of bandwidth rather than per IP, because you're consuming a shared resource (the pool) rather than reserving dedicated addresses. This pricing model scales naturally — you pay for what you use, and the number of unique IPs involved is irrelevant to your cost.
Session Persistence: Why It Matters
Session persistence determines whether a target website can maintain state across your requests — and many operations require it.
Web servers track users through session mechanisms: cookies, authentication tokens, server-side session stores keyed to client IP. When your IP changes between requests, you can break these mechanisms. A website that sets a session cookie during login might invalidate that cookie if the next request arrives from a different IP — a security measure against session hijacking. Multi-step checkout flows, form submissions spanning multiple pages, and paginated result navigation all rely on the server recognizing consecutive requests as belonging to the same user.
With static proxies, session persistence is automatic and indefinite. The IP never changes, so the server's session tracking works exactly as it would for a normal user. There's no timeout, no risk of mid-session IP change, and no need for any special configuration.
With pure rotating proxies, every request looks like a new user. This breaks any workflow that depends on state persistence. You can't stay logged in, can't complete multi-step processes, and can't maintain cookie-based sessions because the next request arrives from a completely different IP.
This is where sticky sessions — the hybrid approach — become essential. They bridge the gap between rotation and persistence, and they're important enough to deserve dedicated explanation.
Web servers track users through session mechanisms: cookies, authentication tokens, server-side session stores keyed to client IP. When your IP changes between requests, you can break these mechanisms. A website that sets a session cookie during login might invalidate that cookie if the next request arrives from a different IP — a security measure against session hijacking. Multi-step checkout flows, form submissions spanning multiple pages, and paginated result navigation all rely on the server recognizing consecutive requests as belonging to the same user.
With static proxies, session persistence is automatic and indefinite. The IP never changes, so the server's session tracking works exactly as it would for a normal user. There's no timeout, no risk of mid-session IP change, and no need for any special configuration.
With pure rotating proxies, every request looks like a new user. This breaks any workflow that depends on state persistence. You can't stay logged in, can't complete multi-step processes, and can't maintain cookie-based sessions because the next request arrives from a completely different IP.
This is where sticky sessions — the hybrid approach — become essential. They bridge the gap between rotation and persistence, and they're important enough to deserve dedicated explanation.
Sticky Sessions: The Hybrid Approach
Sticky sessions (also called session-based rotation) assign a single IP from the rotating pool for a defined duration — typically configurable from 1 minute to 30 minutes. All requests within that time window exit from the same IP. When the session expires, the next request gets a new IP from the pool.
Implementation varies by provider, but the common mechanism uses a session identifier. With Databay, you encode a session ID in your proxy credentials (e.g.,
Sticky sessions solve the specific problem of needing short-term persistence with long-term diversity. Here's a practical example: you need to log into 500 different accounts, perform 10 actions on each, and then move on. For each account, you create a unique session ID and make your 10 requests — they all exit from the same IP, keeping the session valid. When you move to the next account, you use a new session ID and get a fresh IP. The target sees 500 different "users," each with a consistent IP during their individual session.
The TTL (time-to-live) should match your workflow duration with a buffer. If your per-account workflow takes 5 minutes, set a 10-minute sticky session. Setting it too short risks mid-workflow IP changes; setting it too long keeps you on an IP longer than necessary, increasing the risk of rate limiting on that specific address.
Implementation varies by provider, but the common mechanism uses a session identifier. With Databay, you encode a session ID in your proxy credentials (e.g.,
user-session-abc123). The gateway pins all requests with that session ID to the same residential node for the session's TTL. When you want a fresh IP, you change the session ID. This gives you programmatic control over when rotation happens.Sticky sessions solve the specific problem of needing short-term persistence with long-term diversity. Here's a practical example: you need to log into 500 different accounts, perform 10 actions on each, and then move on. For each account, you create a unique session ID and make your 10 requests — they all exit from the same IP, keeping the session valid. When you move to the next account, you use a new session ID and get a fresh IP. The target sees 500 different "users," each with a consistent IP during their individual session.
The TTL (time-to-live) should match your workflow duration with a buffer. If your per-account workflow takes 5 minutes, set a 10-minute sticky session. Setting it too short risks mid-workflow IP changes; setting it too long keeps you on an IP longer than necessary, increasing the risk of rate limiting on that specific address.
Use Cases for Static Proxies
Static proxies excel when your operation depends on a consistent, long-lived identity.
Social media account management. Platforms like Instagram, Facebook, and LinkedIn track the IP addresses associated with each account. Managing an account from a static residential IP that remains consistent over weeks mimics normal user behavior. Frequent IP changes on the same account trigger security flags — account verification prompts, temporary locks, or permanent bans.
E-commerce account operations. Maintaining seller accounts on Amazon, eBay, or Shopify requires IP consistency. These platforms correlate account activity with IP history, and IP instability signals potentially fraudulent behavior. A static proxy assigned per account provides the stability these platforms expect.
Long-running authenticated sessions. Any workflow that requires staying logged in for extended periods — monitoring dashboards, managing SaaS platforms through automation, maintaining persistent WebSocket connections — needs a fixed IP. Static proxies handle sessions lasting hours or days without interruption.
Brand monitoring from a fixed vantage point. Some brand protection operations need to observe how a specific website or marketplace listing changes over time from a consistent perspective. A static IP ensures you see the same version of the site as a "returning visitor" rather than a new one each time, which can affect what content or pricing you're served.
Email operations. Sending email through proxied SMTP connections requires IP consistency because email reputation systems (sender score, SPF alignment) depend on stable IP identity. Rotating IPs for email will destroy deliverability.
Social media account management. Platforms like Instagram, Facebook, and LinkedIn track the IP addresses associated with each account. Managing an account from a static residential IP that remains consistent over weeks mimics normal user behavior. Frequent IP changes on the same account trigger security flags — account verification prompts, temporary locks, or permanent bans.
E-commerce account operations. Maintaining seller accounts on Amazon, eBay, or Shopify requires IP consistency. These platforms correlate account activity with IP history, and IP instability signals potentially fraudulent behavior. A static proxy assigned per account provides the stability these platforms expect.
Long-running authenticated sessions. Any workflow that requires staying logged in for extended periods — monitoring dashboards, managing SaaS platforms through automation, maintaining persistent WebSocket connections — needs a fixed IP. Static proxies handle sessions lasting hours or days without interruption.
Brand monitoring from a fixed vantage point. Some brand protection operations need to observe how a specific website or marketplace listing changes over time from a consistent perspective. A static IP ensures you see the same version of the site as a "returning visitor" rather than a new one each time, which can affect what content or pricing you're served.
Email operations. Sending email through proxied SMTP connections requires IP consistency because email reputation systems (sender score, SPF alignment) depend on stable IP identity. Rotating IPs for email will destroy deliverability.
Use Cases for Rotating Proxies
Rotating proxies are the right choice when each request should look like it comes from a different user and no state needs to persist between requests.
Large-scale web scraping. Scraping 500,000 product pages from an e-commerce site can't be done from a single IP — you'll hit rate limits within minutes. Rotating proxies distribute these requests across thousands of IPs so that each address makes only a handful of requests to the target. The per-IP request volume stays below detection thresholds. This is the single largest use case for rotating proxies.
SERP monitoring. Checking search engine rankings for thousands of keywords across multiple locations requires requests that look like independent users searching from different places. Each keyword check should come from a different IP in the target geography. Rotating residential proxies with geo-targeting handle this naturally.
Ad verification. Verifying that advertisements display correctly to different users in different locations requires viewing each ad impression from a unique IP. Ad networks are specifically designed to detect repeated views from the same IP (fraud detection), making rotation essential.
Price comparison and monitoring. E-commerce sites adjust prices based on visitor profiles, including IP-based location and visit history. Rotating proxies ensure each price check appears as a first-time visitor from a fresh IP, capturing the unbiased baseline price rather than a personalized one.
Market research surveys. Collecting publicly visible data points across thousands of sources — job listings, real estate listings, product reviews — where each data point is an independent request with no session dependency.
Large-scale web scraping. Scraping 500,000 product pages from an e-commerce site can't be done from a single IP — you'll hit rate limits within minutes. Rotating proxies distribute these requests across thousands of IPs so that each address makes only a handful of requests to the target. The per-IP request volume stays below detection thresholds. This is the single largest use case for rotating proxies.
SERP monitoring. Checking search engine rankings for thousands of keywords across multiple locations requires requests that look like independent users searching from different places. Each keyword check should come from a different IP in the target geography. Rotating residential proxies with geo-targeting handle this naturally.
Ad verification. Verifying that advertisements display correctly to different users in different locations requires viewing each ad impression from a unique IP. Ad networks are specifically designed to detect repeated views from the same IP (fraud detection), making rotation essential.
Price comparison and monitoring. E-commerce sites adjust prices based on visitor profiles, including IP-based location and visit history. Rotating proxies ensure each price check appears as a first-time visitor from a fresh IP, capturing the unbiased baseline price rather than a personalized one.
Market research surveys. Collecting publicly visible data points across thousands of sources — job listings, real estate listings, product reviews — where each data point is an independent request with no session dependency.
Cost Structures: How Pricing Differs
The pricing models for static and rotating proxies reflect their different resource allocation patterns.
Static proxies are priced per IP per time period — typically $2-15 per IP per month depending on the IP type (datacenter IPs are cheapest, static residential IPs are mid-range, static mobile IPs command a premium). You're paying to reserve a specific IP exclusively for your use. Costs scale linearly with the number of IPs you need. Ten accounts requiring ten unique static IPs cost ten times the per-IP price, regardless of how much or how little traffic each generates.
Rotating proxies are priced per GB of data transferred, typically $3-15 per GB for residential and $0.50-2 per GB for datacenter. You're paying for shared access to the pool, metered by usage. The number of unique IPs you consume is irrelevant — using 100 IPs or 1 million IPs over the same data volume costs the same.
This creates clear cost optimization strategies. If you're managing 50 accounts that each generate minimal traffic, static proxies at $5/IP/month cost $250 regardless of data volume — predictable and often cheaper than metered bandwidth. If you're scraping 200 GB of data per month across millions of pages, rotating proxies at $7/GB cost $1,400 — but the per-page cost is fractions of a cent, and you're leveraging millions of IPs without paying per IP.
For large operations, many teams use both: static proxies for account-based workflows and rotating proxies for high-volume data collection.
Static proxies are priced per IP per time period — typically $2-15 per IP per month depending on the IP type (datacenter IPs are cheapest, static residential IPs are mid-range, static mobile IPs command a premium). You're paying to reserve a specific IP exclusively for your use. Costs scale linearly with the number of IPs you need. Ten accounts requiring ten unique static IPs cost ten times the per-IP price, regardless of how much or how little traffic each generates.
Rotating proxies are priced per GB of data transferred, typically $3-15 per GB for residential and $0.50-2 per GB for datacenter. You're paying for shared access to the pool, metered by usage. The number of unique IPs you consume is irrelevant — using 100 IPs or 1 million IPs over the same data volume costs the same.
This creates clear cost optimization strategies. If you're managing 50 accounts that each generate minimal traffic, static proxies at $5/IP/month cost $250 regardless of data volume — predictable and often cheaper than metered bandwidth. If you're scraping 200 GB of data per month across millions of pages, rotating proxies at $7/GB cost $1,400 — but the per-page cost is fractions of a cent, and you're leveraging millions of IPs without paying per IP.
For large operations, many teams use both: static proxies for account-based workflows and rotating proxies for high-volume data collection.
Performance and Reliability Differences
Static and rotating proxies have different performance characteristics that affect operational reliability.
Static proxy performance is highly consistent but dependent on a single point. You know exactly what latency and throughput to expect because you're always using the same IP on the same connection path. If that IP performs well, every request performs well. If the IP goes down or gets blocked, you have zero fallback — you must contact the provider for a replacement or switch to a backup IP. There's no automatic failover.
Rotating proxy performance varies per request because each request routes through a different node. One request might complete in 400ms through a fast residential connection; the next might take 2.5 seconds through a slower one. This variability is inherent to the architecture. However, rotating proxies have built-in resilience: if one node is slow or offline, the gateway automatically routes through another. There's no single point of failure. Failed requests can be retried through a completely different IP and node with no manual intervention.
Rotating proxies also handle blocking more gracefully. If a target site blocks one of your rotating IPs, the next request automatically gets a different IP from the pool. With static proxies, a blocked IP means your entire operation stops until the IP is unblocked or replaced.
For reliability-critical operations, rotating proxies' automatic failover and block recovery make them operationally simpler to manage, despite the per-request latency variability.
Static proxy performance is highly consistent but dependent on a single point. You know exactly what latency and throughput to expect because you're always using the same IP on the same connection path. If that IP performs well, every request performs well. If the IP goes down or gets blocked, you have zero fallback — you must contact the provider for a replacement or switch to a backup IP. There's no automatic failover.
Rotating proxy performance varies per request because each request routes through a different node. One request might complete in 400ms through a fast residential connection; the next might take 2.5 seconds through a slower one. This variability is inherent to the architecture. However, rotating proxies have built-in resilience: if one node is slow or offline, the gateway automatically routes through another. There's no single point of failure. Failed requests can be retried through a completely different IP and node with no manual intervention.
Rotating proxies also handle blocking more gracefully. If a target site blocks one of your rotating IPs, the next request automatically gets a different IP from the pool. With static proxies, a blocked IP means your entire operation stops until the IP is unblocked or replaced.
For reliability-critical operations, rotating proxies' automatic failover and block recovery make them operationally simpler to manage, despite the per-request latency variability.
Decision Flowchart: Static, Rotating, or Sticky
Walk through these questions to determine which approach fits your use case:
Does your workflow require staying logged in or maintaining session state?
If yes, and sessions last hours or days: static proxies. If yes, but sessions last minutes: sticky sessions on rotating proxies. If no: proceed to next question.
Do you need IP consistency for the same account over weeks or months?
If yes (social media management, e-commerce account operations, email sending): static proxies. If no: proceed to next question.
Are you making more than a few hundred requests to a single target domain per day?
If yes: rotating proxies. The IP diversity is essential for avoiding rate limits and blocks at scale. If no: either type works; choose based on cost.
Do you need per-request geographic diversity?
If yes (ad verification, SERP monitoring across locations): rotating proxies with geo-targeting. If no: proceed to next question.
Is your primary concern cost predictability or cost efficiency?
For predictability (fixed monthly cost regardless of traffic): static proxies. For efficiency at high volume (pay per GB used): rotating proxies.
Many mature operations run both types simultaneously — static proxies for account-based workflows that need IP consistency, and rotating proxies for high-volume data collection tasks. This isn't overengineering; it's matching the proxy model to the specific requirements of each task.
Does your workflow require staying logged in or maintaining session state?
If yes, and sessions last hours or days: static proxies. If yes, but sessions last minutes: sticky sessions on rotating proxies. If no: proceed to next question.
Do you need IP consistency for the same account over weeks or months?
If yes (social media management, e-commerce account operations, email sending): static proxies. If no: proceed to next question.
Are you making more than a few hundred requests to a single target domain per day?
If yes: rotating proxies. The IP diversity is essential for avoiding rate limits and blocks at scale. If no: either type works; choose based on cost.
Do you need per-request geographic diversity?
If yes (ad verification, SERP monitoring across locations): rotating proxies with geo-targeting. If no: proceed to next question.
Is your primary concern cost predictability or cost efficiency?
For predictability (fixed monthly cost regardless of traffic): static proxies. For efficiency at high volume (pay per GB used): rotating proxies.
Many mature operations run both types simultaneously — static proxies for account-based workflows that need IP consistency, and rotating proxies for high-volume data collection tasks. This isn't overengineering; it's matching the proxy model to the specific requirements of each task.
Combining Both: Real-World Operational Patterns
In practice, the static vs rotating decision isn't always either-or. Sophisticated proxy operations often use both types as part of a unified strategy.
Pattern 1: Static for account creation, rotating for data collection. You create and warm up social media or e-commerce accounts using static residential proxies — one IP per account, consistent over weeks. Once accounts are established, you switch data collection activities (scraping competitor profiles, monitoring market trends) to rotating proxies. The accounts maintain their identity; the data collection operation gets IP diversity.
Pattern 2: Sticky sessions for authenticated scraping. You need to log into a site, navigate to a dashboard, and scrape data that's only available behind authentication. Use sticky sessions with a 10-15 minute TTL for the login-navigate-scrape workflow. Between scraping runs (say, once per hour), let the session expire so each run uses a fresh IP. This combines per-session persistence with inter-session rotation.
Pattern 3: Rotating for discovery, static for monitoring. Use rotating proxies to discover and catalog thousands of product pages, job listings, or content items across a site. Then assign static proxies to monitor a curated subset of high-value pages for changes. Rotating handles the breadth; static handles the depth.
The key principle: match the proxy behavior to the task's persistence requirements. The same operation can contain sub-tasks with different requirements, and using the appropriate proxy type for each sub-task optimizes both success rates and cost.
Pattern 1: Static for account creation, rotating for data collection. You create and warm up social media or e-commerce accounts using static residential proxies — one IP per account, consistent over weeks. Once accounts are established, you switch data collection activities (scraping competitor profiles, monitoring market trends) to rotating proxies. The accounts maintain their identity; the data collection operation gets IP diversity.
Pattern 2: Sticky sessions for authenticated scraping. You need to log into a site, navigate to a dashboard, and scrape data that's only available behind authentication. Use sticky sessions with a 10-15 minute TTL for the login-navigate-scrape workflow. Between scraping runs (say, once per hour), let the session expire so each run uses a fresh IP. This combines per-session persistence with inter-session rotation.
Pattern 3: Rotating for discovery, static for monitoring. Use rotating proxies to discover and catalog thousands of product pages, job listings, or content items across a site. Then assign static proxies to monitor a curated subset of high-value pages for changes. Rotating handles the breadth; static handles the depth.
The key principle: match the proxy behavior to the task's persistence requirements. The same operation can contain sub-tasks with different requirements, and using the appropriate proxy type for each sub-task optimizes both success rates and cost.
Frequently Asked Questions
Can I use rotating proxies for account management?
Not with pure per-request rotation — the IP change on every request would break authenticated sessions and trigger platform security measures. However, sticky sessions on rotating proxies work for short account interactions (logging in, making a few changes, logging out). For long-term account management where the platform tracks IP consistency over weeks, static proxies are the correct choice because they maintain the same IP indefinitely.
How many static IPs do I need for managing multiple accounts?
The standard practice is one unique static IP per account. Sharing an IP across multiple accounts on the same platform creates association risk — if one account is flagged, the platform may investigate all accounts on that IP. For 50 accounts, you need 50 static IPs. Some operations use a 2:1 or 3:1 account-to-IP ratio for lower-value accounts, but this increases risk.
What happens when a rotating proxy IP gets blocked?
The next request automatically receives a different IP from the pool. This is one of rotating proxies' key advantages — blocked IPs are effectively discarded and replaced instantly. The provider's pool is large enough (millions of IPs) that even if thousands of IPs are blocked by a specific target, the remaining pool continues functioning. Your operation experiences a single failed request rather than a complete stoppage.
How long should I set sticky session duration?
Set the TTL to 1.5-2x the expected duration of your workflow. If your login-and-scrape sequence takes 5 minutes, set a 10-minute sticky session. If your checkout flow takes 3 minutes, set 5-6 minutes. Too short risks mid-workflow IP changes that break sessions. Too long keeps you on one IP longer than necessary, increasing the chance of rate limiting on that specific address.
Are static proxies always more expensive than rotating proxies?
It depends on your usage pattern. Static proxies have a fixed per-IP cost regardless of traffic volume, so they're cheaper for low-bandwidth, high-session-persistence tasks. Rotating proxies charge per GB, so they're cheaper for high-bandwidth tasks where you'd otherwise need many static IPs. A single static IP at $5/month used for light account management is far cheaper than equivalent rotating proxy bandwidth, but scraping 100 GB of data would cost $700+ in rotating bandwidth vs. a single static IP that would get blocked immediately.
