VPS With Data Centers in Both Frankfurt and Amsterdam: Provider List
Cut EU failover setup from two vendors to one, and skip the 6 ms latency mistake most operators make.
Eight providers run VPS capacity in both Frankfurt and Amsterdam under a single account:
- 1Gbits
- Vultr
- DigitalOcean
- Akamai Linode
- UpCloud
- Gcore
- LeaseWeb, and
- OVHcloud with a caveat I explain below.
Two of the names you will find on most listicles, Hetzner and Contabo, operate in neither city.
One vendor across both sites gives you one invoice, one control panel, one support queue, and in several cases private networking between the two regions at no egress cost. Two vendors give you true vendor redundancy but double the operational surface.
The number that reshapes the architecture is 6 ms. That is the round-trip time I measure between well-peered Frankfurt and Amsterdam nodes, against a theoretical fiber floor of roughly 3.6 ms.
Under 10 ms, synchronous database replication is viable. That single fact means you can run a warm standby with near-zero data loss instead of accepting the minutes of loss that asynchronous replication forces on you.
Below the verified provider list, a latency matrix by user city, the German versus Dutch legal split, cost per gigabyte rather than cost per plan, and the failover build I actually run.
The Short Answer: Providers Running VPS in Both Frankfurt and Amsterdam
Eight qualify. The disqualifications matter as much as the list.
Hetzner does not have a Frankfurt or Amsterdam data center. It operates Nuremberg, Falkenstein, and Helsinki in Europe, plus Singapore, Ashburn, and Hillsboro. Hetzner peers heavily at DE-CIX Frankfurt and AMS-IX, which is where the confusion starts. Peering at an exchange is not the same as having servers in that city. If your compliance document names Frankfurt specifically, Falkenstein will not satisfy it.
Contabo does not qualify either. Its EU cloud hub sits in Lauterbourg on the French-German border, with German facilities in Nuremberg, Munich, and Düsseldorf. No Frankfurt. No Amsterdam.
OVHcloud gets a conditional yes. Amsterdam is real. The German region marketed as Frankfurt is physically in Limburg an der Lahn, roughly 70 km away. For latency purposes that is close enough. For a contract that specifies a Frankfurt facility, it is not.
Prices across those eight rows span roughly 4x for comparable specs. That spread only makes sense once you separate the two distinct reasons people want both cities.
Why You Actually Want Both Cities
Conflating failover with latency splitting is the mistake that wastes the most money. They demand different configurations.
Failover and Disaster Recovery
The 360 km between Frankfurt and Amsterdam covers a specific set of failure domains. Facility-level power loss. A single carrier withdrawing routes. A regional DDoS event saturating one metro. A provider’s regional control plane going down while other regions stay up.
It does not cover everything. Same-vendor two-region setups share a control plane, an account, and a billing relationship. If your payment fails or your account gets suspended for an abuse complaint, both nodes vanish together. That is not vendor redundancy. It is hardware and facility redundancy.
That tradeoff is acceptable when your recovery time objective sits in the minutes, your realistic risk is hardware or a single-site outage, and your business does not depend on surviving a vendor dispute. If you need to survive the vendor itself, you need two vendors, and the operational cost roughly doubles.
Latency Splitting and Audience Routing
Frankfurt serves Germany, Austria, Switzerland, Poland, Czechia, and points east better. Amsterdam serves Benelux, the UK, Ireland, Scandinavia, and the transatlantic path better.
The reason is the exchanges. DE-CIX Frankfurt is the larger internet exchange by peak traffic and dominates central and eastern European routing. AMS-IX carries stronger paths toward the UK, the Nordics, and North America, partly because most transatlantic cable landings feed into it through the UK.
The practical rule I use is that if more than 30 percent of your traffic originates outside the DACH region, the Amsterdam node earns its monthly cost on page-load improvement alone. Below that threshold, put your money into a bigger Frankfurt instance instead.
Which city becomes primary depends on real numbers, so here are the ones I measured.
Latency Between Frankfurt and Amsterdam, and to Your Users
Frankfurt to Amsterdam round-trip lands at 6 to 8 ms on well-peered networks. The great-circle distance is about 365 km. Light in single-mode fiber travels near 200,000 km per second, giving a one-way floor of 1.8 ms and a round-trip floor of 3.6 ms.
The gap between 3.6 and 6 comes from three sources: physical routes are longer than straight lines, every switch and router adds queuing delay, and inter-provider handoffs sometimes route through a third city before coming back.
Those numbers set hard architectural thresholds. Under 10 ms, synchronous replication works and your standby holds committed data. Between 10 and 30 ms, use asynchronous replication and accept measurable lag. Above 50 ms, stop replicating at the database layer and queue at the application layer instead.
The pattern in that data:
- Amsterdam wins London by roughly 8 ms, Dublin by 7 ms, and New York by 8 ms.
- Frankfurt wins Zurich by 7 ms, Berlin by 4 ms, and Istanbul by 5 ms.
- Warsaw goes to Frankfurt but by a smaller margin than most people expect.
Reproduce this yourself before you commit.
Run mtr with at least 100 packets against candidate IPs from a host inside your actual audience geography, not from your laptop.
Test at your traffic peak, not at 3 am. Median matters more than minimum, and the 95th percentile matters more than either if you serve interactive applications.
Latency tells you where to put the node. German and Dutch law tell you what you are allowed to put on it.
Germany vs Netherlands: The Legal Split That Decides Placement
A German VPS is not more GDPR-compliant than a Dutch one. GDPR is a regulation, not a directive, so the text applies identically in both countries. Anyone selling you Frankfurt on GDPR grounds alone is selling you nothing.
The real differences sit elsewhere.
Germany brings BSI IT-Grundschutz as the reference security baseline, which German enterprise and public sector procurement often requires by name. Enforcement culture from the state-level data protection authorities runs stricter than the EU average. The Telemediengesetz imposes imprint obligations on German-facing commercial sites. Copyright enforcement pressure is heavier, and hosts respond to it faster.
The Netherlands brings a mature notice-and-takedown framework, generally faster and more predictable abuse handling, and a hosting market historically built around high-bandwidth and privacy-oriented workloads. Amsterdam’s transit density also means better DDoS absorption capacity at the metro level.
The point most comparisons miss is that a US-parented provider operating in Frankfurt carries exactly the same Article 44 transfer exposure as the same provider operating in Amsterdam.
The CLOUD Act reaches the parent company, not the building. If Schrems II analysis is part of your compliance work, the corporate domicile of your host matters more than which of the two cities you pick.
That is a genuine argument for European-owned or independently owned providers over hyperscaler subsidiaries, and it applies equally to both locations.
With placement settled, the remaining variable is cost per usable resource, and the spread there is wider than the headline prices suggest.
Price per Usable Resource, Not Price per Plan
Entry prices hide the real economics. Compare dollars per gigabyte of RAM per month instead.
1Gbits lists a 2-core, 4 GB DDR5, 100 GB plan at $14.99 per month on a 36-month term, against a $24.99 list rate. That works out to $3.75 per GB per month committed, or $6.25 per GB month to month.
Vultr, DigitalOcean, and Akamai Linode cluster tightly at roughly $6.00 per GB across their standard tiers, with no long-term discount and no commitment.
OVHcloud undercuts everyone in this list at roughly $2.50 to $3.00 per GB on its VPS range, and it is honest to say OVHcloud beats 1Gbits on raw cost per gigabyte.
LeaseWeb runs highest, in the $8 to $10 range, and charges for the enterprise support and network guarantees that justify it for some buyers.
So 1Gbits sits between the hyperscaler-style providers and the discount European hosts. It wins on cost per gigabyte against Vultr, DigitalOcean, and Linode by roughly 38 percent on committed terms. It loses to OVHcloud.
The lines that actually decide total spend are not on the pricing page. Watch bandwidth overage or fair-use throttling thresholds, snapshot and backup pricing charged per gigabyte per month, additional IPv4 addresses now that RIPE has exhausted its pool, and the renewal cliff when a promotional multi-year term ends at list rate.
Be clear-eyed about the 1Gbits structure specifically. The $14.99 figure requires a 36-month commitment against a 7-day refund window. That is $539 committed upfront-equivalent for a seven-day evaluation period.
If you want to test for a month before deciding, price the shorter term and treat the long-term rate as a decision you make after the workload proves out.
Pricing only matters if the two nodes actually work together. Here is the build.
How I Set Up Frankfurt-Amsterdam Failover on One Provider
Active-Passive or Active-Active
Active-passive keeps Amsterdam idle and warm while Frankfurt serves traffic. Active-active splits live traffic across both.
I recommend active-passive for almost every self-hosted operator. Active-active forces you to solve session state sharing and database write conflicts, and both problems get expensive fast. Below roughly 50,000 sessions per day, the engineering time costs more than the second node saves. The exception is if your workload is genuinely read-heavy and stateless, such as a static site or a read-only API, where active-active becomes trivial.
The Build
- For files, run rsync over SSH on a schedule from primary to standby, using a dedicated key restricted by command in authorized_keys. Every 15 minutes handles most content sites. Continuous sync with lsyncd is available if your recovery point objective is tighter.
- For the database, set up native replication rather than file-copying the data directory. With 6 ms between sites, MySQL semi-synchronous replication or PostgreSQL synchronous_commit set to remote_write both work without a meaningful write-latency penalty. That is the direct payoff of the low round-trip time.
- For traffic cutover, use DNS with a 60-second TTL and a health-checking DNS provider. Understand the honest limitation: TTL is advisory. A meaningful share of resolvers and some ISPs ignore short TTLs, so plan for a tail of traffic hitting the dead node for several minutes after cutover. If you need faster and cleaner failover, you need a floating IP or an anycast layer, and only some providers offer either.
- For TLS, issue certificates on both nodes independently with separate ACME accounts rather than syncing certificate files. Synced certificates break when the standby tries to renew a certificate for a domain currently pointing elsewhere.
- For configuration, put your entire server config in version control and deploy to both nodes from the same source. Manual edits on the primary are the single most common cause of failed cutover.
Test It Before You Need It
Schedule a forced cutover once per quarter. Actually route production traffic to Amsterdam, run it there for an hour, then cut back. Record your real recovery time objective, not your estimated one.
The failure I see most often: a cron job that only ever existed on the primary. Backups stop, certificates expire, queues stop draining, and nobody notices for weeks because the standby was never asked to do the job.
That build assumes your provider supports the necessary primitives, which is where the eight differ.
Provider-by-Provider Notes
- Vultr. Strongest API in this list alongside DigitalOcean, hourly billing, and instance deployment in under a minute. Free private networking within a region but not between Frankfurt and Amsterdam, so cross-region traffic crosses the public internet and counts against bandwidth. Pick Vultr if you spin instances up and down programmatically.
- DigitalOcean. The best documentation of any provider here, and the ecosystem of one-click applications genuinely saves setup time. VPC networking is region-scoped, same limitation as Vultr. Pricing is rigid with no volume or term discounts. Pick DigitalOcean if you value predictability and community tutorials over cost.
- Akamai Linode. Backed by Akamai’s global network since the 2022 acquisition, which improved transit quality noticeably. Same $6 per GB tier as its two closest rivals. Object storage and managed databases in both regions make it a reasonable single-vendor stack. US parent company, so factor the CLOUD Act point.
- UpCloud. Finnish-owned, which matters if EU corporate domicile is part of your compliance case. Its MaxIOPS storage benchmarks faster than most competitors at the same price. Smaller footprint and a thinner ecosystem. Pick UpCloud if storage performance is your bottleneck.
- Gcore. Luxembourg-registered with a large edge network, and the CDN integration is genuinely useful if you serve media. Cloud pricing is less transparent than the others and varies by region. Better suited to content delivery workloads than general compute.
- LeaseWeb. Dutch, enterprise-oriented, with real network SLAs and 24/7 human support that answers technical questions rather than reading scripts. Costs two to three times the discount providers. Pick LeaseWeb when downtime has a contractual cost attached to it.
- OVHcloud. French, European-owned, and the cheapest cost per gigabyte in this list. Includes anti-DDoS at no extra charge across all plans, which is unusual. Support quality draws consistent criticism, and the German region is Limburg rather than Frankfurt proper. Pick OVHcloud if budget dominates and you are comfortable self-supporting.
- 1Gbits. Runs both cities on one account with a footprint of 37 locations across 15-plus countries, which matters if you later want a third node in Singapore or Tokyo without a new vendor. Virtualization is VMware ESXi rather than KVM, which changes two things: snapshot behavior is enterprise-grade and reliable, but the OS template range is narrower than a KVM host offers and custom ISO uploads are more constrained. DDR5 memory at the entry tier is uncommon at this price point. Payment accepts Bitcoin, USDT, Ethereum, Perfect Money, WebMoney, PayPal, and cards, which no hyperscaler in this list matches. Third-party ratings sit at 4.5 on HostAdvice across 61 reviews, 4.6 on ProvenExpert across 178, and 4.5 on HostSearch across 299. The honest limitation: the pricing model rewards 36-month commitments and there is no hourly billing, so it suits stable long-lived workloads rather than ephemeral infrastructure.
Which One I Would Pick for Each Scenario
- German-audience WordPress with a warm standby. 1Gbits. Frankfurt primary, Amsterdam standby, both on one invoice, at $3.75 per GB on committed terms. The workload is stable and long-lived, which is exactly what the long-term pricing model is built for.
- Benelux and UK SaaS splitting latency. UpCloud or Akamai Linode. Amsterdam primary given the 8 ms advantage to London, Frankfurt as the eastern node, with the API maturity to automate routing between them.
- Privacy-focused operator paying in cryptocurrency. 1Gbits. It accepts Bitcoin, USDT, and Ethereum directly across both Frankfurt and Amsterdam, and none of Vultr, DigitalOcean, Linode, or UpCloud offer a comparable path.
- Developer wanting API-driven ephemeral instances. Vultr. Hourly billing, sub-minute provisioning, and a mature API. 1Gbits is the wrong tool for this job and I would not recommend it here.
- Fixed annual budget optimizing cost per gigabyte. OVHcloud first at roughly $2.75 per GB, 1Gbits second at $3.75 per GB committed. OVHcloud is cheaper. 1Gbits gives you better support responsiveness and a genuine Frankfurt facility for the difference.
FAQ
Method and Verification Notes
Provider locations were confirmed against each vendor’s own published location page in August 2026, not from third-party comparison sites, which is how the Hetzner and Contabo errors propagate. Prices reflect published list rates on the same date and exclude promotional codes.
Latency figures are median ICMP round-trip times over 100 packets per target, sampled across a 24-hour window from hosts inside each user geography. Peak-hour figures ran 1 to 3 ms higher than the medians shown.
Specifications for 1Gbits, including VMware ESXi virtualization, DDR5 memory, the 7-day refund window, and the 99.99 percent network and power SLA, are provider-stated and were read from live product pages. Third-party review scores come from HostAdvice, ProvenExpert, and HostSearch as displayed in August 2026.
Re-test before you commit. Providers add and retire regions quietly, and a comparison table is accurate only on the day it was built.
