{
  "path": "/blog/cross-cloud-egress-aws-s3-azure-bill",
  "title": "Keep your enemies close, but keep your data closer — how we cut AWS from $1,500 to $200/month - PolarCut Blog",
  "description": "Our AWS bill hit $1,500/month because our data lived in S3 while compute ran on Azure. One afternoon fix cut it to $200/month. Here’s the cross-cloud egress trap and how to escape it.",
  "canonical": "https://polarcut.io/blog/cross-cloud-egress-aws-s3-azure-bill",
  "generatedAt": "2026-04-30T10:26:07.267Z",
  "text": "Back to Blog Engineering Infrastructure Cloud Cost\n Keep your enemies close, but keep your data closer — how we cut AWS from $1,500 to $200/month\n Rohan Mehta\n April 30, 2026\n 4 min read\n\n Share:\n\n If you move large files for ML/video workloads, where your data lives matters as much as the code you run.\n\n TL;DR\n\n Cross-cloud data transfer isn’t “networking.” It’s a line item.\n Keep your primary working data and compute in the same cloud and region (ideally the same zone) or you’ll eventually pay an “invisible tax” per GB.\n\n At Polarcut, we process long-form podcast videos and turn them into short clips — downloads, transcriptions, frame analysis, re-encoding. That’s a lot of multi-GB data moving around.\n\n \"The architecture made sense on a whiteboard. On the billing console, it looked like a $1,500/month mistake.\"\n\n The setup that burned us\n\n Two clouds, one expensive handshake\n\n Our raw video assets were stored in AWS S3 . Our AI processing pipeline ran on Azure VMs . Every time we processed a video, data traveled from S3 → internet → Azure. And then outputs often went back the other way.\n\n AWS S3 (data)\n →\n Cross-cloud egress\n ₹₹₹ / GB\n →\n Azure VM (compute)\n\n Do this hundreds of times a day across multi-GB videos and you don’t “notice latency” — you notice a bill.\n\n What actually costs money\n\n AWS charges for data leaving S3 to the public internet (“egress”).\n Transfer to another AWS service in the same region can be cheap. Transfer out to another cloud provider? You pay the egress rate, every byte, every time.\n\n The fix\n\n Move the data to where the compute is\n\n The solution was almost embarrassingly simple: stop using S3 as the primary working store for a pipeline that runs on Azure. We moved working data to Azure Blob Storage in the same region as our VMs.\n\n Azure Blob (data)\n →\n Same-region transfer\n ~₹0\n →\n Azure VM (compute)\n\n Within-cloud, same-region transfers are often free or negligible compared to cross-cloud egress.\n\n The principle\n\n Keep your data and compute in the same cloud, same region, same zone. Cross-cloud data movement is almost never free — it’s just easy to miss until the month ends.\n\n Takeaways\n\n What we now check before any infra decision\n\n - Compute and primary working data live in the same cloud provider.\n\n - Same region (not just same cloud). Cross-region within a cloud isn’t always free either.\n\n - Set up cost alerts specifically for data transfer categories (egress, inter-region, CDN).\n\n - S3 is still excellent for backups, CDN origin, or serving end users — just not as a working store for compute that lives elsewhere.\n\n - When evaluating GPU/VM vendors, check if they have managed object storage in the same region/AZ.\n\n How to stop cloud credits from burning (startup playbook)\n\n If you’re early-stage, credits feel infinite right up until they aren’t. The way credits “mysteriously” burn is rarely compute alone — it’s usually data movement , always-on resources , and lack of guardrails .\n\n 1) Put hard guardrails on spend (day 1)\n\n - Budgets + alerts on total spend and on the top “silent killers”: data transfer, NAT gateway, load balancers, managed DB.\n\n - Kill switches for non-prod: auto-shutdown on nights/weekends, and TTL tags (e.g. delete in 7 days).\n\n - Cost allocation tags per workload (transcription, encode, captions) so you can answer “what burned our credits?” in 60 seconds.\n\n 2) Treat egress like a feature, not an afterthought\n\n - Keep data + compute together (same cloud + region). This post’s core lesson.\n\n - Minimize bytes moved : store mezzanine files once, avoid re-downloading inputs per step, reuse artifacts across stages.\n\n - Cache the hot path : if the same asset is read many times, put it on fast storage near compute (and set lifecycle rules).\n\n - Batch transfers and compress when possible (especially logs and intermediate JSON).\n\n 3) Make compute elastic (and preemptible when you can)\n\n - Autoscale workers on queue depth; avoid “one big VM that’s always on”.\n\n - Spot / preemptible for retryable jobs (encoding, thumbnails, batch analysis). Keep a small on-demand baseline for stability.\n\n - Right-size aggressively : measure CPU/GPU utilization per stage and downgrade until it hurts, then step back one notch.\n\n Simple rule of thumb\n\n If a workload reads a multi‑GB object more than once, assume you’re leaking money until you prove otherwise.\n Make the “bytes moved per job” metric as visible as “seconds per job”.\n\n FAQ\n\n What is cross-cloud egress?\n\n It’s when data leaves one cloud provider (or region) over the public internet to another provider/region — and the source cloud typically charges an egress fee per GB.\n\n Why did S3 → Azure get expensive?\n\n Because AWS bills for internet egress from S3. If your pipeline downloads multi-GB objects repeatedly, those per‑GB charges compound fast.\n\n What’s the simplest fix?\n\n Put your working dataset next to compute: move primary objects to the same cloud + region as the VMs/GPUs that read them, and keep S3 for backups/serving if needed.\n\n Building Polarcut — an AI tool that turns long-form podcasts into short clips. If you’re running AI/video pipelines and want to compare notes on infra costs, I’m happy to chat.\n\n Rohan Mehta\n Cofounder CTO • Connect on LinkedIn\n\n Share this article:"
}