Why We Give Away $1,500/mo in Cloud Interconnect Fees (And How It Changes Your Architecture)
Let's talk about something that sounds almost too good to be true: we don't charge egress fees. Not reduced egress fees. Not "first 10 TB free" egress fees. Zero. Unlimited 1 Gbps bandwidth included in every server tier, no asterisks.
We hear the same reaction from engineers pretty often — "okay, but what's the catch?" So let's just get into it. What does $0 egress actually mean in practice, and more importantly, how should it change the way you think about your architecture?
First, What Are You Actually Paying Right Now?

If you're running a data-heavy workload on AWS, Azure, or GCP, egress fees are probably one of those costs that sneak up on you. AWS charges between $0.05 and $0.09 per GB for data leaving their network. That sounds small until you're moving serious volumes.
A team running 200 TB of outbound data per month — not unusual for analytics pipelines, ML training workflows, or video processing — is looking at roughly $10,000–$18,000/month just in egress. Every month. Just to move your own data.
We've talked to CTOs who didn't fully realize how much of their cloud bill was egress until they actually broke it down line by line. It's one of those costs that hides in plain sight.
At Bit Refinery, that number is $0. You move as much data as you want. Our Denver and Seattle facilities both sit sub-2ms from major public clouds, so you're not trading latency for savings either.
The Architecture Shift Nobody Talks About
Here's where it gets interesting. When egress is free, it doesn't just save you money — it changes what architectures are even worth considering.
You Can Actually Run a Hybrid Setup Without Bleeding Out
Our core philosophy is "own the base, rent the spike." Dedicate bare metal for your steady-state workloads, and burst into cloud resources only when demand actually spikes. In theory, every infrastructure team knows this is the right model. In practice, most of them don't do it — because every time your bare metal talks to your cloud environment, you're paying egress fees in both directions (well, ingress is usually free, but egress back to your systems isn't).
When egress is $0, that hybrid model becomes genuinely practical. Your ClickHouse cluster sits on bare metal in Denver, your burst compute runs on AWS, and data flows between them freely. No one's doing math on whether a query is "worth" the bandwidth cost.
Your Data Lake Doesn't Have to Live in One Place
A lot of teams keep everything in S3 — not because it's architecturally ideal, but because moving data out is expensive. So the data lake, the analytics layer, the ML training data, all of it stays in one place to avoid egress.
But what if your ClickHouse cluster could pull from MinIO on bare metal, and your cloud-based Spark jobs could reach back to the same data without you paying $0.09/GB for the privilege? You'd actually build the architecture that makes sense for your query patterns, not the one that minimizes your AWS bill.
We run MinIO deployments on bare metal — S3-compatible, so your existing tooling works fine — and with $0 egress, the data can live where it performs best rather than where it's cheapest to leave alone.
Real-Time Pipelines Stop Being a Negotiation
Streaming architectures are expensive on cloud because you're paying for compute and the constant movement of data. Kafka topics feeding into ClickHouse, log pipelines, telemetry from distributed systems — these generate enormous data volumes that flow continuously.
When you move that infrastructure to bare metal with free egress, the economics flip. You're paying a flat monthly rate for your server. The pipeline can be as chatty as it needs to be. Engineers stop making decisions like "should we batch this to reduce data transfer costs?" and start making decisions like "what's the best architecture for latency and reliability?"
That's a genuinely different way to work.
What Sub-2ms to the Cloud Actually Enables
The zero-egress story only works if the latency is acceptable. And honestly, sub-2ms to AWS, Azure, and GCP from our Denver and Seattle facilities is fast enough for almost any workload that isn't doing something exotic.
For ClickHouse queries that need to join against data in S3, for Trino federating across multiple sources, for ML inference that pulls models from cloud storage — 2ms round trips are fine. You're not going to notice that in your query times.
This is what makes the hybrid model real rather than theoretical. It's not "bare metal for stuff that doesn't need cloud" — it's bare metal as your primary compute layer, with cloud as genuine overflow capacity, all connected at speeds that don't require you to architect around the latency.
The Numbers, Because You're Going to Ask
Let's put some concrete numbers on this. A Bit Refinery Gold server — 80 cores, 1 TB RAM, 44 TB RAID6 SSD — runs $2,800/month. A comparable AWS configuration (r6i.metal plus 40 TB storage) runs around $10,658/month. Add $16,200+ in heavy egress fees on top of that and you're looking at a 10x cost difference.
Even if your workload is lighter than that, the math tends to work out similarly. The fixed monthly pricing means you know exactly what you're paying. No surprise bills at the end of the month because some process ran longer than expected or a data export went sideways.
One More Thing Worth Saying
We're not anti-cloud. AWS and Azure are genuinely great for certain things — managed services, global distribution, serverless compute for spiky workloads. The point isn't to replace cloud entirely, it's to stop paying cloud prices for workloads that don't need cloud flexibility.
If you're running ClickHouse analytics, a Trino cluster, GPU training jobs, or any data-intensive workload with predictable resource requirements — that's a bare metal workload. The cloud is for the stuff that actually needs elasticity.
And when those two environments need to talk to each other constantly, you really don't want to be paying $0.09/GB for the conversation.
Curious what your current egress bill is actually costing you, or what a hybrid architecture might look like for your stack? We're happy to talk through it.
