EU vs US Hosting: Latency, Law, and Cost
Choosing between EU and US hosting isn't a contest for the "better" region. It's three separate trade-offs — latency, legal exposure, and cost — and each one points at a different thing. Here's how each axis actually breaks down, and a simple way to pick.
At some point in setting up a new project you hit a dropdown labelled "region," and the choice feels bigger than a dropdown should. Europe or the United States? It looks like a coin flip, and plenty of teams treat it as one, then spend the next year explaining a slow app to European users or a surprise question in a security review. The decision isn't hard because the options are close. It's hard because "EU or US" is really three different questions wearing one label.
This walks through those three questions in order: how fast the app feels, what legal weight the location carries, and where the money actually goes. Then it ends with a way to pick that doesn't rely on a gut feeling. None of it is legal advice. It's the engineering and business context that makes the region dropdown a decision instead of a guess.
The wrong question: which region is "better"?
There is no better region in the abstract. A US region isn't faster or cheaper or safer than an EU one as a general fact; it depends entirely on what you're measuring against. The reason the choice feels slippery is that three independent things get bundled into it, and they don't all point the same way. Once you separate them, each one has a clear answer.
| Axis | What it actually measures | Points you toward |
|---|---|---|
| Latency | How far requests physically travel | The region closest to most of your users |
| Law | Which country's rules and courts apply | The jurisdiction where your obligations sit |
| Cost | Where paid borders sit in your stack | The region with the fewest of them |
Read that as three compasses rather than one scoreboard. Each axis answers a "closest to what" question, and the useful work is figuring out what each one is closest to for your specific app. Sometimes all three needles land on the same region and the decision is easy. When they don't, you at least know which trade-off you're making instead of averaging them into a shrug.
Latency: the axis that's pure physics
Latency is the one axis nobody gets to argue with, because it's set by the speed of light. Light travels through fibre at roughly two-thirds of its vacuum speed, which works out to about one millisecond of one-way delay for every 200 kilometres of cable. That's a floor, not an estimate: no amount of engineering moves data faster than that, and real routes are never straight, so the practical number is always worse.
Frankfurt to the US East Coast is roughly 6,000 kilometres of ocean. A round trip across it costs somewhere in the region of 80 to 90 milliseconds before your server has done a single thing: no query, no render, just the packet getting there and an acknowledgement coming back. Cross to the US West Coast and it's worse. For a European user hitting a US-hosted app, that tax is added to every request that has to reach the origin, and it stacks: a page that makes a handful of sequential calls can feel sluggish purely from distance.
What a CDN does and doesn't fix
A CDN caches static assets — images, scripts, stylesheets — at edge locations near your users, and for those it erases the distance. What it can't cache is the dynamic part: a login, a checkout, anything that writes to the database or is unique per user. Those still travel all the way to the origin and back, so a CDN in front of a distant server speeds up the wrapper while the app underneath stays slow.
So the latency rule is simple and it's not EU-flavoured: put the origin near the majority of your users. If your audience is mostly European, an EU region wins the requests a CDN can't touch. If it's mostly American, a US region wins for exactly the same reason, and hosting in Europe would be the mistake. Latency doesn't care about your compliance story; it cares about a map.
Law: convenience now versus stability later
The legal axis is where "EU or US" stops being about performance. If you hold personal data on people in the EU, storing it in the US is a transfer of that data outside the Union, and GDPR treats transfers as something you have to justify rather than something you're free to do. We covered the mechanics in where to store EU user data; the short version is that a transfer needs a legal basis, and the legal bases for the US have a habit of collapsing.
The 2020 Schrems II ruling struck down the Privacy Shield framework thousands of companies relied on. A newer adequacy decision, the EU-US Data Privacy Framework, restored a cleaner path in 2023, but it applies only to US organisations that self-certify under it and sits against a history of such arrangements being invalidated in court. On top of that, the US CLOUD Act lets US authorities compel US-based providers to hand over data they control regardless of which region it's stored in. None of this makes US hosting illegal. It makes it legal-but-conditional: it works until the framework underneath it is renegotiated again.
Keeping EU data in the EU sidesteps the whole apparatus. There's no transfer to justify, no framework to monitor, no assessment to redo when the legal ground shifts. For a team selling into European enterprises, that's not an abstraction; it's the difference between a security questionnaire that takes a paragraph and one that takes a lawyer. The broader picture, including the GDPR roles and the DPA that goes with them, is in the EU hosting guide. The point for this decision: on the legal axis, US hosting buys convenience today against fragility later, and EU hosting buys stability.
Cost: it's not per-GB, it's per-border
Cost is the axis people expect to be a simple price comparison, and it usually isn't. Raw compute doesn't differ enough between a reputable EU host and a US hyperscaler like AWS to drive the decision. What actually moves the bill is borders — the points where data crosses between regions or leaves for the public internet, each of which tends to carry a charge. The relevant question isn't "which region is cheaper per gigabyte," it's "how many paid borders does this architecture create."
- Egress and cross-region transfer. Moving data out to the internet, or replicating it between a US region and an EU one for latency or durability, is often the largest line on an object-storage or bandwidth bill. We broke the maths down in S3 egress fees; a single-region stack simply never generates the cross-region version of that charge.
- Currency and tax friction. A European business billed in dollars carries exchange-rate exposure and the overhead of reconciling foreign invoices and VAT, none of which shows up in the sticker price but all of which is real cost.
- The hidden compliance bill. The moment EU data lands in the US, you inherit the work of keeping the transfer lawful: transfer impact assessments, Standard Contractual Clauses to maintain, subprocessor lists to audit. That's engineering and legal time, and it recurs every time the legal ground moves.
Put plainly: US compute isn't inherently pricier than EU compute. Borders are what cost money, and a stack split across two continents has more of them — in bandwidth, in currency, and in compliance overhead — than one that stays in a single region.
A framework: pick the region closest to what matters
You don't need to weigh the three axes against each other with a spreadsheet. You need to answer three questions honestly and see where they land.
- Where are most of your users? That answers latency. Host the origin near the bulk of your traffic; a CDN handles the static assets for everyone else. If your audience straddles both continents, weight it by where the requests a CDN can't cache come from.
- Whose rules do you actually have to satisfy? That answers law. If you hold EU personal data and sell to EU customers, EU hosting removes the transfer question entirely. If your obligations and your users are American, a US region is the honest answer and EU hosting would only add friction.
- How many paid borders does the choice create? That answers cost. A single-region stack avoids cross-region egress, currency friction, and the recurring compliance overhead of a transfer. Count the borders before you count the per-gigabyte price.
When the three answers disagree, they at least disagree legibly. A US-facing product with a few European users belongs in the US, with a CDN and, if it touches EU data, a proper transfer mechanism. There's no universal winner here, and it's worth saying clearly that hosting in the EU is not a compliance certificate on its own. Residency removes the hardest question, but a lawful basis, data-subject processes, and security are still yours to handle.
When all three axes point to the EU
For a large share of teams — anyone building for a mostly European audience while holding data on European users — the three needles land on the same spot. The users are in Europe, so latency wants an EU origin. The obligations are European, so the law wants EU residency. And keeping everything in one region is what keeps the border count, and the bill, down. At that point the interesting question isn't the region, it's how to keep the whole stack there without it fragmenting across a dozen providers.
That's the setup Runsite is built around. Web Services run your app containers, environment variables, build artifacts, and logs in a Frankfurt, Germany region, with no replication to non-EU regions and no fallback to overseas infrastructure. Put managed PostgreSQL and S3-compatible object storage alongside them and the database, its backups, and your files sit in the same region rather than scattered across borders. A signed GDPR Data Processing Agreement comes with every plan, so the legal axis is answered in the contract rather than as an enterprise upsell.
The payoff is that the three questions collapse into one region. European users get an origin on their continent for the requests a CDN can't cache, the transfer question never arises because nothing crosses a border, and the cross-region charges never appear because there's no second region to cross to. You're not balancing the axes anymore; they've all pointed at the same place.
The short version
"EU or US hosting" isn't one decision, it's three. Latency is physics: put the origin near your users, and know that a CDN speeds up static assets but not the dynamic requests that reach your server. Law is about stability: US hosting of EU data leans on transfer frameworks with a record of being struck down, while EU residency removes the question. Cost is about borders, not per-gigabyte rates: a single-region stack avoids the cross-region, currency, and compliance charges a split one racks up. Answer the three questions for your own app, and if they all point to Europe, the simplest way to honour that is a stack that never leaves it. Deploy in an EU region and the region dropdown stops being a gamble.