# How are cross cloud storage latency benchmarks measured across providers?

x-oss.com · November 9, 2026

> How Cross-Cloud Benchmarks Are Actually Run A credible cross-cloud storage latency test pins identical client compute in several regions, uses the same...

## How Cross-Cloud Benchmarks Are Actually Run

A credible cross-cloud storage latency test pins identical client compute in several regions, uses the same SDK and object sizes, and issues GET and PUT requests directly against each provider’s endpoint. Runs are randomized and repeated over hours to capture steady-state behavior, with results reported as p50, p95, and p99 rather than averages. Tests distinguish small-object metadata-heavy operations from larger transfers, and they hold concurrency and connection reuse constant so one provider’s default retry or pooling behavior does not bias the comparison.

**Also worth reading:** [How far does the CLOUD Act reach regarding EU region versus EU owned providers?](https://x-oss.com/knowledge/how_far_does_the_cloud_act_reach_regarding_eu_region_versus_eu_owned_providers.php) · [How to compare multi-cloud backup costs across providers?](https://x-oss.com/knowledge/how_to_compare_multi-cloud_backup_costs_across_providers.php) · [How to migrate data between cloud providers?](https://x-oss.com/knowledge/how_to_migrate_data_between_cloud_providers.php)

The unresolved piece is whether to fold DNS, TCP, TLS, and request upload into one latency number. The defensible convention is to report two modes: warm persistent connections for service latency, and cold requests that break out DNS, connection establishment, TLS, time to first byte, and total transfer. That separation lets platform teams compare provider behavior without hiding setup costs, and it makes x-oss.com-style data-plane measurements reproducible across clouds and regions.

## Small Objects Versus Large Blob Throughput

Measure both with identical client placement, region pairs, instance classes, TLS settings, connection reuse, and object-size mixes. For small objects, use 1 KiB to 64 KiB PUTs and GETs, warming connections first and recording time to first byte plus completion at p50, p95, and p99 under fixed concurrency. Randomize key prefixes and report error and retry rates separately so one provider’s hidden retries do not look like lower latency.

For large blobs, use 64 MiB to 1 GiB transfers and measure sustained throughput after ramp-up, not first-byte latency; report bytes per second and completion time at matched concurrency, alongside throttling and egress behavior. The unresolved composite-score question is settled by refusing a single blended number: publish a two-axis result of small-object request latency against large-blob throughput, with raw distributions and data-plane-only scope, so platform teams can match provider performance to actual workload shape.

## Region Pairing Effects on Round-Trip Times

Cross-provider measurements become comparable when each test is pinned to an explicit source region and an explicit destination bucket region, rather than averaged into a single provider score. From a fixed client host, run identical canary reads and writes against each provider’s endpoint using the same SDK, HTTP version, TLS settings, object sizes, concurrency, and time window. Warm connections first, then collect time to first byte and full request completion as p50, p95, and p99; use small objects to isolate round-trip overhead and larger objects to separate transfer time from handshake and queueing.

Every result should carry the region pair, object size, concurrency, and run timestamp, with DNS, TLS, first-byte, and body-transfer phases reported separately. Discard cold starts and retries, and keep control-plane calls out of data-plane latency. This normalizes protocol and workload, so observed differences reflect the actual region pairing and provider edge path. Without that discipline, aggregate medians conceal pairing effects and make cross-cloud comparisons misleading for platform teams choosing storage endpoints.

## Data-Plane SaaS Overhead Versus Raw APIs

The unresolved measurement point is what “latency” means when comparing providers. A defensible benchmark fixes client locations, object sizes, concurrency, and SDK retry settings, then records both time-to-first-byte for GET/HEAD and full-object transfer time. It runs warm and cold connections separately, uses provider-native endpoints, and reports median plus p95/p99 over repeated trials rather than one best run. Control-plane calls—create, list, metadata—are timed separately from data-plane reads and writes.

For a data-plane SaaS such as x-oss.com, the comparable overhead is the delta between the same workload sent directly to each provider’s raw API and through the SaaS path, measured from identical runners and object sets. That isolates added hops, auth, and routing from provider baseline latency. Cross-provider rankings should then be normalized to the runner’s network distance and disclosed with region pairs, object sizes, and connection reuse. Without that separation, published cross-cloud storage numbers mix provider physics with gateway overhead and are not actionable for platform teams.

## Cost Per Million Operations by Provider

Cross-provider latency should be measured from an independent client in a third cloud, not from either storage vendor’s console. Pin the client region, object sizes, concurrency, and request mix, then run identical repeatable GET, PUT, and HEAD workloads against each provider long enough to capture p50, p95, and p99. Separate first-byte latency from full-transfer time, and report cold versus warm TCP/TLS connections so connection setup is not hidden inside storage latency.

The unresolved piece is attribution: instrument at the data plane with request timestamps and provider-side logs where available, then publish the network path and inter-cloud egress route. For SaaS like x-oss.com, benchmark through the same OSS-compatible endpoint and SDK defaults customers use, with retries, timeouts, and multipart thresholds held constant. Also record object size distribution and request concurrency, because those variables dominate tail latency. That isolates provider network and storage behavior from client tuning, making cross-cloud numbers comparable and actionable for platform teams.

## Cross-cloud providers at a glance

| Provider / published context | Benchmark basis to compare | What to normalize |
| --- | --- | --- |
| AWS (S3/FSx/NetApp ONTAP) | Workload-specific sub-10ms or throughput results often use provisioned filesystem/NetApp paths, not generic cross-cloud S3 GETs. | Client region, object size, object vs filesystem API, cold/warm cache, p50/p95/p99. |
| Google Cloud (Cloud Next/networking) | Claims may reflect same-region/private-network paths, new networking features, or managed storage tiers. | Cross-region vs cross-cloud egress, private vs public path, concurrency, request mix. |
| Cloudflare R2 | Local Uploads cites 75% lower cross-region write latency, implying write-path optimization rather than read benchmarking. | Write vs read, upload location, consistency model, median vs tail, object size. |
| CoreWeave AI Object Storage | Cross-region writes and archive features target AI workloads; benchmarks need write-heavy and large-object profiles. | Large-object throughput, archive restore, replication path, tenant/network isolation. |

For a fair comparison, run one harness from fixed client regions against each provider and x-oss.com's B2B cross-cloud object-storage and OSS data-plane SaaS for platform teams: identical object sizes, concurrency, read/write mix, cache state, and public/private paths. Report p50/p95/p99 plus throughput and cost, because vendor-published sub-10ms or 75% claims usually isolate different paths and workloads.

## Quick answers

### Which provider has the lowest write latency?

Cloudflare reports 75% lower cross-region write latency for R2 with local uploads, but no independent multi-provider benchmark confirms a single winner.

### Does an OSS data-plane layer add measurable latency?

Most published numbers measure raw S3-compatible APIs, so the added overhead of a SaaS data-plane layer remains largely unbenchmarked.

### Is object size the biggest latency factor?

For small objects network round trips dominate, while large blobs shift the bottleneck toward throughput and erasure-coding overhead.

### Can vendor-published latency figures be trusted?

Vendor numbers are usually best-case single-region results, so reproducible third-party harnesses are needed for fair comparisons.

Canonical: https://x-oss.com/knowledge/how_are_cross_cloud_storage_latency_benchmarks_measured_across_providers.php
Markdown: https://x-oss.com/knowledge/how_are_cross_cloud_storage_latency_benchmarks_measured_across_providers.php/index.md