Colocation and Latency: Same-Provider vs Cross-Provider, Cross-Region

Latency between regions and clouds varies a lot. And it influences execution latency when it comes to algorithmic trading. To help understand the cross-cloud trading setup, we benchmarked from EC2 in two regions (Tokyo and US East 1) to AWS and GCP Europe endpoints using TCP/TLS timing (getent + curl). From US East 1, connect time to AWS Europe is ~74–104 ms and to GCP Europe ~87–99 ms. From Tokyo to the same endpoints it is ~216–225 ms (AWS) and ~248–262 ms (GCP). So origin region alone can add over 120 ms round-trip. In these tests, same provider (AWS to AWS) is lower than cross-provider (AWS to GCP) by about 30–40 ms. Here is how we measured and how you can run the same script from your own regions.

Benchmarking Methodology

We measure TCP/TLS/HTTP timing with getent (DNS resolution) and curl (HTTPS). We use the connect time from curl as the network round-trip proxy instead of ping.

• Simple and reproducible, because getent and curl run on any Linux instance with no extra deps.
• Real path, because the script reports DNS, TCP connect, TLS handshake, and time to first byte in one run.
• Comparable, because you use the same script across regions and clouds. Change targets or run from different EC2 regions to compare.
• Cross-cloud, so you can compare AWS vs GCP (and other providers) from the same origin.

Note: The connect time is network latency. End-to-end latency to an application can add more (e.g. encoding, processing, routing). So if connect time is 155 ms, total latency might be 155 ms plus tens of milliseconds depending on the service.

Caution: Results against managed service endpoints (e.g. S3, GCP APIs) are useful for comparing regions and clouds, but they are not the same as raw backbone latency between two compute nodes. Managed endpoints can add front-end handling, anycast, or regional routing that changes the path and timing.

Setup: How to Benchmark Your Own Infrastructure

Step 1: Launch EC2 Instances

Launch a t2.micro (free tier eligible) or t3.micro in each region you want to test. (The Tokyo → Europe run below used t3.micro.) For the TCP/TLS timing script, see the Cross-region and cross-cloud section.

Step 2: Connect to Instance Terminal

Open the EC2 Instance Connect or Session Manager terminal in AWS Console (no SSH needed).

Step 3: Run the latency script (any region)

What the script does. One script measures TCP/TLS/HTTP timing using getent (DNS) and curl. No ping. Run it from any EC2 region to compare latency to AWS and GCP. Change the targets list or run from another region (e.g. Frankfurt, Tokyo, New York) to benchmark other pairs.

What you see. For each host you get dns, connect, tls, starttransfer, and total. Treat connect as your network round-trip proxy, because that number best reflects wire latency.

What to expect. Same provider and same region is usually fastest. Cross-region and cross-cloud paths add latency.

Where to find it. The full script is available here.

Cross-region and cross-cloud: Tokyo → Europe

We ran a TCP/TLS timing test from an EC2 t3 micro in ap-northeast-1 (Tokyo) to both AWS and GCP Europe endpoints. The goal was to compare same-provider (AWS Tokyo to AWS Europe) with cross-provider (Tokyo to GCP Europe) latency. Cross-region and cross-cloud paths typically add latency, and same provider in the same region is best.

The script is also available at latency-aws-gcp-europe.md.

Script (getent + curl only; run from any region):

targets=(
  ec2.eu-central-1.amazonaws.com
  s3.eu-central-1.amazonaws.com
  s3.eu-west-1.amazonaws.com
  s3.eu-west-3.amazonaws.com
  storage.europe-west1.rep.googleapis.com
  logging.europe-west3.rep.googleapis.com
  europe-west1-aiplatform.googleapis.com
)

for h in "${targets[@]}"; do
  echo "===== $h ====="
  getent ahosts "$h" | head -n 3

  echo "-- tcp/tls/http timing --"
  curl -4 -s -o /dev/null \
    -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} starttransfer=%{time_starttransfer} total=%{time_total}\n" \
    "https://$h" || echo "HTTPS test failed"

  echo
done

Tokyo → AWS Europe (same provider, cross-region):

Endpoint	dns	connect	tls	total
ec2.eu-central-1.amazonaws.com	~0.6 ms	~225 ms	~680 ms	0.91 s
s3.eu-central-1.amazonaws.com	~1.2 ms	~225 ms	~453 ms	0.68 s
s3.eu-west-1.amazonaws.com	~1.1 ms	~219 ms	~440 ms	0.66 s
s3.eu-west-3.amazonaws.com	~1.2 ms	~217 ms	~438 ms	0.66 s

Tokyo → GCP Europe (cross-provider, cross-region):

Endpoint	connect	tls	total	Notes
storage.europe-west1.rep.googleapis.com	~248 ms	~501 ms	1.76 s	Actual EU
logging.europe-west3.rep.googleapis.com	~262 ms	~535 ms	0.79 s	Actual EU
europe-west1-aiplatform.googleapis.com	~2.5 ms	~14 ms	1.48 s	Anycast, resolved to Japan and not Europe; exclude from Europe comparison

Caveat: europe-west1-aiplatform.googleapis.com is anycast and resolved from Tokyo to a local/Japan IP (~2.5 ms connect), so it does not represent Europe latency. The Europe comparison above uses only the two GCP EU endpoints (storage, logging).

Summary: Connect time from Tokyo to AWS Europe is ~216–225 ms and to GCP Europe (real EU endpoints) ~248–262 ms. Same provider is lower than cross-provider by ~30–40 ms. Run this script from different EC2 regions (or adjust targets) to compare TCP/TLS/HTTP timing across regions and clouds.

US East 1 (N. Virginia) → Europe

We ran the same script from an EC2 instance in us-east-1 (N. Virginia) to the same AWS and GCP Europe endpoints. So you can compare directly to the Tokyo run.

US East 1 → AWS Europe (same provider, cross-region):

Endpoint	dns	connect	tls	total
ec2.eu-central-1.amazonaws.com	~14 ms	~104 ms	~289 ms	0.38 s
s3.eu-central-1.amazonaws.com	~10 ms	~102 ms	~198 ms	0.29 s
s3.eu-west-1.amazonaws.com	~6 ms	~74 ms	~146 ms	0.21 s
s3.eu-west-3.amazonaws.com	~0.5 ms	~83 ms	~172 ms	0.26 s

US East 1 → GCP Europe (cross-provider, cross-region):

Endpoint	connect	tls	total	Notes
storage.europe-west1.rep.googleapis.com	~99 ms	~203 ms	1.31 s	Actual EU
logging.europe-west3.rep.googleapis.com	~87 ms	~178 ms	0.27 s	Actual EU
europe-west1-aiplatform.googleapis.com	~2.2 ms	~14 ms	0.10 s	Anycast, resolved to US and not Europe; exclude from Europe comparison

Summary: From US East 1, connect time to AWS Europe is ~74–104 ms and to GCP Europe (real EU endpoints) ~87–99 ms. That’s about 120–165 ms lower than from Tokyo to the same endpoints. Same script, same targets: origin region alone can add or remove over 100 ms per round-trip, so region and provider choice matter when you care about latency.

Next Steps: Running Your Own Benchmarks

To measure latency from your region:

1. Launch an EC2 instance (t2.micro or t3.micro) in each region you want to test (e.g. Frankfurt, Tokyo, New York).
2. Open the instance terminal (EC2 Instance Connect or Session Manager in AWS Console).
3. Run the getent + curl script from the Cross-region and cross-cloud section. Use the default targets or change the list to the endpoints you care about.
4. Note the connect and total times for each host. Use connect as your network RTT proxy.
5. Email results to divyasshree@zohomail.in.

Include:

• Source region (where your instance is)
• Target hosts or regions you measured
• Connect and total times (or paste the script output)
• Instance type (t2.micro, t3.micro, etc.)

Your benchmark data helps us build a global latency map across regions and providers.

Infrastructure and latency

If you care about latency, region and provider choice matter. In our runs, cross-region connect times differed by over 100 ms depending on origin. Same provider (e.g. AWS to AWS) was lower than cross-provider (e.g. AWS to GCP) by about 30–40 ms. Choosing a region close to your targets can save tens to hundreds of milliseconds per round-trip.

We have helped teams choose regions and providers, optimize latency, and design multi-region setups. Consulting available →

All latency measurements use the getent + curl script (connect time as RTT proxy). Test results vary by time of day and network load. Have different numbers? Email us and we will map regional latency across providers.