Decentralised News Research · Trading Infrastructure 2027
A crypto trading bot should usually run near the exchange path it actually uses, not near the trader's desk. London, Frankfurt, Singapore, Tokyo and Northern Virginia are strong candidate hubs because major cloud providers operate mature regions there, but no city is universally fastest. The correct region is the one that wins a repeatable endpoint-level test for your exact account, product and API domain.
Last verified: 20 October 2026 · DN Region Selection Framework v1.0
Do not choose a VPS from a generic “closest server” list. Measure the actual REST, WebSocket and order-entry path your bot will use. Geography creates a shortlist; production measurements choose the region. London and Frankfurt are strong European candidates, Singapore and Tokyo are strong Asian candidates, and Northern Virginia is a strong U.S.-East candidate.
DN Evidence Block
- Scope
- Five deployment hubs, four cloud/VPS ecosystems, one exchange regional-domain case and one professional private-connectivity case.
- Primary evidence
- Official AWS, Google Cloud, Microsoft Azure, DigitalOcean, OKX and Deribit documentation.
- Original DN work
- Region Selection Matrix, 24-hour test protocol, DN Jitter Proxy, Region Regret and interactive Region Fit Diagnostic.
- Observed winner
- Not claimed. This edition does not fabricate a “fastest city” leaderboard.
- Limitation
- Cloud-region availability does not prove exchange latency. Routing changes by endpoint, account region, carrier, protocol and time.
The execution worker should sit close to the best measured exchange path, not necessarily close to the human operator. Human dashboard latency and trading-path latency are different engineering problems.
Five Regions Worth Testing First
| Hub | AWS | Google Cloud | Azure | DigitalOcean | Use case |
|---|---|---|---|---|---|
| London | eu-west-2 | europe-west2 | UK South | lon1 | General European execution and multi-cloud tests. |
| Frankfurt | eu-central-1 | europe-west3 | Germany West Central | fra1 | Continental Europe and EU deployment. |
| Singapore | ap-southeast-1 | asia-southeast1 | Southeast Asia | sgp1 | Broad APAC benchmark candidate. |
| Tokyo | ap-northeast-1 | asia-northeast1 | Japan East | — | Northeast Asia and Japan-focused routes. |
| N. Virginia / Ashburn | us-east-1 | us-east4 | U.S.-East family | Richmond available nearby | U.S.-East routing and professional connectivity. |
AWS documents London, Frankfurt, Singapore and Tokyo as production regions. Google Cloud exposes corresponding regions in London, Frankfurt, Singapore, Tokyo and Ashburn. Azure lists UK South, Germany West Central, Southeast Asia and Japan East. DigitalOcean currently exposes Droplet capacity in London, Frankfurt and Singapore. These facts establish deployment availability, not exchange proximity.
The Best Region Is Exchange-Specific
Public exchange hostnames may terminate at different edges, use different carriers or enforce different regional domains. OKX is a clear example: its current documentation requires different API domains for some account regions, including us.okx.com for U.S./Australian registrations and eea.okx.com for EU registrations.
Why Ping Is Not Enough
ICMP is a weak execution benchmark. Measure the protocol path the strategy actually consumes:
- REST: DNS/TLS plus request-response time and errors.
- WebSocket: connect time, first message, ongoing delay, gap detection and reconnect time.
- Orders: send-to-ACK and send-to-authoritative-state using testnet or tightly controlled micro-live orders.
London vs Frankfurt
For European bots, test both. Google Cloud's cross-cloud mapping pairs London europe-west2 with AWS eu-west-2, and Frankfurt europe-west3 with AWS eu-central-1. Choose the city that wins the actual P95/P99 endpoint test, not the one that sounds geographically closer.
Singapore vs Tokyo
Singapore is a logical first APAC benchmark because AWS, Google Cloud, Azure and DigitalOcean all operate there. Tokyo should be tested beside it where Northeast-Asian routes matter. Do not infer the exchange gateway location from the exchange company's headquarters.
Northern Virginia and the Professional-Connectivity Exception
Public VPS placement stops being the whole problem once an exchange offers private connectivity. Deribit began a phased Starbase production rollout in July 2026 with gateway access through colocation, cross-connects and AWS PrivateLink for approved professional users.
What About South Africa?
Local cloud can be excellent for monitoring, data collection and risk supervision. For execution, benchmark South Africa against London, Frankfurt and Singapore rather than assuming the closest server to the trader is closest to the exchange. Keep the control plane local if convenient and move only the latency-sensitive worker when the measurements justify it.
Cloud Provider vs Simple VPS
| Provider | Best for | Strength | Main trade-off |
|---|---|---|---|
| AWS | Professional/multi-region stacks | Broad regions and private-connectivity ecosystem. | Higher operational complexity and cost surface. |
| Google Cloud | Quant/data-heavy stacks | Clear global regions and strong data/network tooling. | More tuning than a simple VPS. |
| Azure | Microsoft-standardized institutions | Large region footprint and enterprise governance. | Often overkill for one lightweight bot. |
| DigitalOcean | Independent quants | Simple Droplets in London, Frankfurt and Singapore. | Fewer specialist private-connectivity options. |
DN Latency Budget
Track P50, P95 and P99. A region can look excellent on median latency while producing dangerous tail spikes.
DN Region Fit Diagnostic
Run the same test from every candidate region and enter the measured values below. The score is a comparison aid, not a universal benchmark.
Compare One Candidate Region
DN Region Fit Score: —
The DN 24-Hour Region Test
- Deploy identical small instances in at least three candidate regions.
- Synchronise clocks and record clock offset.
- Use the exact production API hostname allowed for the account.
- Measure fresh and reused REST connections separately.
- Measure WebSocket connect, first message, continuity and reconnect time.
- Record P50/P95/P99 across Asia, Europe and U.S. trading hours.
- Use testnet or micro-size live order tests sparingly; do not create fake liquidity or abusive traffic.
One Region or Two?
A warm standby can improve resilience, but do not run two uncontrolled active order writers. Use explicit leader fencing and independent state reconciliation before promoting the standby.
Static IPs and Allowlisting
Reserve stable outbound IPs where the exchange supports API-key IP restrictions. Before migration, verify the new egress IP, exchange allowlist, firewall rules, secret distribution, clock sync and monitoring.
DN Alpha Thesis: Region Rotation Is Operational Alpha
If the primary region's P95 deteriorates materially relative to a tested standby, that is an operational signal worth investigating. It does not automatically justify failover because order state and active-writer safety matter more than a few milliseconds.
What DN Should Measure Next
| Region | Provider | Endpoint | P50 | P95 | P99 | Reconnects | Order ACK |
|---|---|---|---|---|---|---|---|
| London | AWS/GCP/VPS | Exact production host | Observed | Observed | Observed | Observed | Observed |
| Frankfurt | AWS/GCP/VPS | Exact production host | Observed | Observed | Observed | Observed | Observed |
| Singapore | AWS/GCP/VPS | Exact production host | Observed | Observed | Observed | Observed | Observed |
| Tokyo | AWS/GCP/Azure | Exact production host | Observed | Observed | Observed | Observed | Observed |
| N. Virginia | AWS/GCP/Azure | Exact production host | Observed | Observed | Observed | Observed | Observed |
Methodology & Limitations
This framework uses official provider documentation for region availability and exchange routing/connectivity claims. It does not claim that DN independently measured cross-region latency in this edition. Actual performance varies by carrier, VM host, availability zone, exchange gateway, account region and protocol.
Evidence Classification
- Provider-reported: cloud region, exchange domain or private-connectivity capability.
- Modelled: DN architecture framework and tool outputs.
- Calculated: jitter and Region Fit values derived from explicit inputs.
- Observed: direct DN matched regional testing; not yet claimed here.
Primary Research Sources
- AWS Regions
- Google Cloud Locations
- Google/AWS Paired Locations
- Azure Regions
- DigitalOcean Regional Availability
- OKX API V5
- Deribit Starbase Rollout
FAQ
What is the best VPS region for crypto trading bots?
There is no universal winner. Test London, Frankfurt, Singapore, Tokyo or Northern Virginia as relevant, using the exact production exchange endpoint and P50/P95/P99 plus continuity.
Should I run my bot in the same country as me?
Not necessarily. Put the execution worker near the best measured exchange path and manage it remotely.
Does lower ping guarantee faster orders?
No. Order latency also includes session, serialization, gateway, risk and matching-engine processing.
Do I need colocation?
Usually not. Colocation/private connectivity matters when the strategy is truly latency-sensitive and the exchange offers an eligible professional path.
Final Takeaway
DN principle: deploy small, measure the exact exchange path, optimize for P95/P99 and recovery, and keep a validated failover route that cannot become a second uncontrolled order writer.
About the Author
