Cloud egress charges nobody budgets for
Most scraping budgets have a line for proxies and a line for compute. Almost none of them have a line for egress, and that’s the one that shows up as a surprise at the end of the month. Egress isn’t exotic. It’s just the cost of data leaving a cloud provider’s network, and scraping workloads produce a lot of it in places people don’t think to look.
Where the meter actually starts
Cloud providers price inbound and outbound traffic asymmetrically. Getting data into a VM or a storage bucket is usually free or close to it. Getting data out, to the internet, to another region, or even to another availability zone in the same region, is metered per gigabyte. This is true across AWS, GCP, and Azure in slightly different shapes, but the principle is the same everywhere: ingress is cheap because providers want your data, egress is billed because that traffic costs them peering and transit capacity.
For a normal web app this barely matters, because most of the bytes flow inward from users. A scraper is the opposite. Every response body, every rendered page, every image or script a headless browser pulls down, is data that lands in your cloud account and then, at some point, has to leave it again, either to your own machine, to a downstream pipeline, or to storage in a different region. Scraping is an egress-heavy workload by nature, and the billing model wasn’t built with that in mind.
The proxy layer doubles the meter without anyone noticing
If your scrapers run on cloud VMs and route through a proxy provider, the response for a single request crosses the network twice: once from the target site to the proxy, and once from the proxy back to your VM. From your cloud bill’s perspective, the second leg is just ingress, so it’s typically free. But the moment you self-host any part of the proxy layer, a rotating gateway, a SOCKS relay, a sticky-session pool, inside your own cloud account, that architecture changes. Traffic now has to leave the gateway instance to reach your worker instances, and if those workers sit in a different region or a different cloud entirely, that hop is billed as egress on top of whatever the proxy provider itself charges for bandwidth.
This is the part that catches people off guard. They compare proxy providers on cost per GB and pick the cheapest one, without noticing that their own cloud architecture is charging them a second, unrelated per-GB fee just to move that same traffic between their own instances.
NAT gateways are a quiet source of it
A lot of scraper fleets run in private subnets for isolation, with a NAT gateway handling outbound internet access. NAT gateways on the major clouds charge per gigabyte processed, in addition to the standard data transfer rate. If your workers are firing thousands of requests an hour through proxies, all of that outbound traffic and its corresponding inbound response passes through the NAT gateway, and it gets billed on volume, not on how the traffic is used. It’s easy to set this up once during infrastructure provisioning and never think about it again, right up until the bill reflects a job that scaled up.
Cross-region and cross-AZ traffic adds up faster than it should
Scraping projects often grow in pieces. Workers get added in a region with cheaper compute. A storage bucket gets created wherever it was convenient at the time. A database or queue ends up in whatever region the original prototype used. None of that matters for latency in most scraping work, but it matters for the bill, because moving data between regions, and in some cases between availability zones within the same region, is billed as transfer, not treated as internal traffic.
A scraper that pulls a page, ships the raw HTML to storage in another region, and later pulls it back out for a different region’s processing job is paying egress twice on the same bytes, for no reason related to the scraping itself. This is architecture debt showing up on a scraping bill, and scraping workloads make it visible fast because of the sheer request volume.
Headless rendering multiplies the payload, not just the request count
If your pipeline uses a headless browser instead of a plain HTTP client, every page load can pull in images, fonts, stylesheets, and third party scripts that a raw HTTP request would never touch. A page that’s a few kilobytes of HTML can easily become a megabyte or more once the browser renders it in full. Multiply that by request volume and the egress difference between a lightweight HTTP scraper and a full browser-based one can be an order of magnitude, even though both are technically scraping the “same” page. This is one of the most overlooked line items in cost estimates that were built by testing with curl and then deployed with a browser automation stack.
Storing the response body creates a second bill later
A common pattern is to store raw responses (HTML, JSON, screenshots) in object storage before parsing, so failed parses can be replayed without re-fetching. That’s a reasonable engineering decision. The cost trap is that every time a downstream job reads that object back out for parsing, especially from a different region or a different cloud than where it’s stored, it’s billed as egress again. Data that was already paid for once on the way in from the target site gets paid for a second and third time just moving between your own systems. None of this is proxy cost. It’s pure cloud architecture cost that scraping projects generate because of how much they store and re-read.
Keeping the meter honest
None of this requires exotic fixes, just paying attention to where bytes cross a billing boundary.
Keep worker instances, proxy gateways you self-host, and storage in the same region. If a project has grown organically across regions, that alignment is worth doing as a cleanup pass, not just a new-project decision.
Parse and discard before storing when you can. If you don’t need to replay a raw response, extract what you need and store the structured result instead of the full payload. Structured data is a fraction of the size.
Use a plain HTTP client wherever the target doesn’t require JavaScript execution. Reach for a headless browser only for the pages that actually need it, and block unnecessary asset types (images, fonts, ad scripts) in the browser context when you do use one.
Check whether your NAT gateway is actually necessary for your traffic pattern, versus a cheaper egress path like a managed proxy or a direct route, depending on your cloud provider’s options.
Separate the proxy provider’s bandwidth bill from your cloud provider’s egress bill when you’re evaluating cost per request. They’re two different meters, and a cheap proxy plan sitting on top of an expensive cross-region architecture can still add up to more than a pricier proxy plan on a well-aligned one.
Egress is boring to think about because it is plumbing rather than a feature or a technique. But for a workload that lives entirely on pulling data across the internet at volume, plumbing is most of the cost. Treating it as a fixed line item is how it stays a surprise.
If you’re weighing proxy types, providers, or the rest of a scraping stack against costs like these, the rest of our writeups on Proxy Scraping go through it from the same angle: what it actually costs to run, not just what it costs to sign up for.
Get new guides and videos first — join the Telegram channel.