# How Do You Benchmark S3 Cross-Cloud Performance and Cost in 2026?

x-oss.com · September 27, 2026

> What Is an S3 Cross-Cloud Benchmark? An S3 cross-cloud benchmark is a repeatable test of how quickly data can move between Amazon S3 and an alternative...

## What Is an S3 Cross-Cloud Benchmark?

An S3 cross-cloud benchmark is a repeatable test of how quickly data can move between Amazon S3 and an alternative object-storage provider or compatible data-plane service. It normally measures sustained throughput, request latency, small-object performance, large-transfer efficiency, egress charges, and operational complexity. The results are useful because “S3-compatible” describes an API and behavior, not identical performance: providers may differ in backend design, regional topology, request handling, durability settings, and pricing. A valid benchmark should therefore use the same dataset, object sizes, concurrency, credentials, and measurement window on both sides. As of 27 September 2026, the most useful comparison is not a single headline number but a profile showing where each provider performs best and what workload it can support economically.

**Also worth reading:** [How Should Platform Teams Benchmark Object Storage Performance Across Clouds?](https://x-oss.com/knowledge/how_should_platform_teams_benchmark_object_storage_performance_across_clouds.php) · [How Do You Optimize Multi-Cloud Egress Costs Without Sacrificing Performance in 2026?](https://x-oss.com/knowledge/how_do_you_optimize_multi-cloud_egress_costs_without_sacrificing_performance_in_2026.php) · [How Does Cross-Cloud Object Storage SaaS Work for B2B Data Platforms in 2026?](https://x-oss.com/knowledge/how_does_cross-cloud_object_storage_saas_work_for_b2b_data_platforms_in_2026-3.php)

The term can also mean benchmarking a gateway or data-movement service that presents an S3 interface while moving bytes between clouds. That interpretation matters for platform teams because the endpoint being tested may be a cloud provider, a specialist object-storage vendor, or a cross-cloud SaaS layer. The test should distinguish control-plane operations, such as listing buckets and creating multipart uploads, from the data plane, where objects are uploaded, downloaded, copied, or synchronized. Without that separation, a service can look fast during setup but be unsuitable for production transfers. The benchmark should record both technical outcomes and billable units, including stored gigabytes, transferred terabytes, API requests, and retrieval or minimum-duration charges.

## What Should an S3 Cross-Cloud Benchmark Measure?\n

The primary metrics are sequential throughput, time to first byte, inter-request latency, aggregate request rate, and completion time for a fixed workload. A practical test might include 1 MiB objects for application-like traffic, 16 MiB objects for ordinary analytics, and 1 GiB objects for bulk migration or backup. It should test at least three concurrency levels—for example, 8, 32, and 128 parallel requests—because a provider may perform well with one stream but become limited by queueing or per-tenant throttling. Report the median and 95th or 99th percentile rather than only the average, since tail latency often determines whether an interactive application feels responsive.

The benchmark must also record failure behavior. Measure retry rates, multipart-upload completion, checksum validation, eventual-consistency incidents, and the percentage of successful requests after throttling. Record the region on both sides, because cross-region traffic can be materially slower and more expensive than same-region traffic. Keep test data realistic but non-sensitive, and use compression only if the production workload would use it. A transfer speed of 1 Gbit/s, for example, is 125 MB/s in decimal terms or roughly 119 MiB/s in binary terms; confusing those units makes comparisons misleading. Publishing the exact command, SDK version, object count, and start time makes the results reproducible.

| Feature | Direct S3-to-S3 Transfer | Cross-Cloud S3-Compatible Service |
| --- | --- | --- |
| Typical setup | Two AWS endpoints and buckets | Two cloud endpoints, possibly through a data-plane gateway |
| Main advantage | Low protocol translation and familiar AWS tooling | Provider flexibility and potentially better route or cost optimization |
| Main risk | AWS egress and inter-region charges | Extra hop, gateway limits, vendor-specific billing, and operational debugging |
| Test emphasis | Throughput, request rate, retries, and AWS charges | End-to-end latency, transfer completion, policy controls, and total cost |
| Best use case | AWS-centric analytics or migration | Multi-cloud resilience, portability, or workload placement |

## How to Run a Reproducible Cross-Cloud Test
Begin by defining a fixed success criterion before running either provider. A reasonable initial target for a noninteractive bulk transfer is sustained throughput above 500 Mbit/s, but the correct threshold depends on the workload; backup completion within an eight-hour maintenance window may matter more than peak speed. For interactive workloads, an object read under 100 ms at the median and below 250 ms at the 95th percentile may be more relevant than raw aggregate bandwidth. Record whether the test measures service time from the client or end-to-end time including TLS setup, DNS, retries, and application processing. Predefined thresholds prevent a provider from appearing acceptable simply because it completed the test first.

Create identical buckets or prefixes with versioning, encryption, and lifecycle policies matched to the intended production state. Use separate credentials and a dedicated test account so that logs can identify retries, throttling, and unauthorized requests. Warm up the path with a small object before starting measurements, then run the same 10, 50, and 100 GiB dataset through both clouds. Repeat each run at least three times on different periods, because shared infrastructure, background maintenance, and cache state can materially affect results. Capture timestamps at the client, gateway, and destination if available, and export provider request logs afterward. The research context includes guidance on applying data-loading practices with Amazon S3 clients, which is relevant because client-side part sizing, concurrency, and retry configuration can dominate observed performance.

Calculate cost using the provider’s actual meter rather than a simplified storage-only price. The relevant formula is storage cost plus PUT, GET, LIST, multipart, retrieval, replication, and data-transfer charges. A nominal $9/TB storage price does not make a service cheaper if every cross-cloud read incurs substantial egress or if the product includes minimum commitments. State the billing region, currency, tax treatment, and whether prices are list or negotiated rates. For a fair comparison, calculate the complete workload cost for 1 TB stored monthly, 1 TB transferred out, 10 million small requests, and a 10 TB migration separately. These use cases produce very different rankings and expose whether a benchmark is really a storage comparison or a data-movement comparison.

## How Do Results Usually Differ Between Cloud Providers?\n

Amazon S3 often benefits from mature integrations with AWS compute, IAM, CloudTrail, analytics services, and established client tooling. That does not automatically make it the cheapest or fastest option for data leaving AWS, particularly when transfer fees, object layout, or application architecture are unfavorable. A direct comparison with another S3-compatible provider can show that the alternative has stronger performance in a particular region or a more attractive egress model. However, compatibility may cover only a subset of behavior: multipart uploads, conditional writes, object locking, checksums, lifecycle rules, encryption options, and event notifications may differ. The benchmark must therefore test the API features the application actually uses, not assume that every S3 implementation behaves identically.

The result should be interpreted by workload class rather than by a universal winner. Large sequential transfers may favor a provider with high bandwidth and efficient multipart handling, while millions of small objects may depend more on request rate, metadata operations, and pricing per request. A gateway can improve manageability by centralizing credentials and policy, but an extra service hop may add latency or create a throughput ceiling. Regional distance matters too: a 10,000-kilometer path cannot be evaluated independently of routing, congestion, and the provider’s virtual network. If the business goal is portability, the benchmark may show that a slightly slower route is acceptable because it reduces dependency on one cloud. If the goal is a nightly backup, completion time and predictable retry behavior may matter more than peak throughput.

Do not treat a single impressive run as proof of production behavior. Providers can throttle by account, bucket, request type, or region, and sustained performance may decline after initial burst capacity. Ask whether the service has documented limits, service-level objectives, or support commitments, then load-test gradually until either the target is met or a limit is observed. A result that reaches 900 Mbit/s for 30 seconds but drops to 80 Mbit/s for an hour is not equivalent to 80 Mbit/s of reliable capacity for a backup. Publish both sustained and burst figures, and include the workload duration.

## What Cost Model Should Platform Teams Use?\n

Use total cost of ownership rather than a headline price per terabyte. The model should include source storage, destination storage, request fees, transfer out, transfer in, retrieval, replication, support, network, and labor. For a 10 TB monthly cross-cloud transfer, a difference of $0.05 per GB changes the bill by approximately $500 before requests or other fees; small differences therefore become material at scale. Conversely, a provider with a higher storage rate can still be cheaper if its egress and request charges are much lower for the actual access pattern. The benchmark should report a cost per successful terabyte and cost per million operations, not just a monthly subscription equivalent.

Pricing claims also need a date and scope. The supplied research context references a 2026 cloud-backup offer at $9/TB, but that figure is not enough to compare an S3 cross-cloud data plane without knowing retention, retrieval, minimum term, region, and transfer terms. Do not infer that $9/TB includes unlimited cross-cloud egress. Obtain current pricing pages or a contract quote, document the effective date as 27 September 2026 where applicable, and rerun the estimate when prices change. Negotiated enterprise prices can differ substantially from public list prices, so a public benchmark should label whether it uses list rates, sample rates, or a vendor quote. A useful internal report may show a low, expected, and high scenario rather than presenting false precision.

The cost comparison should include engineering time. A direct S3-to-S3 transfer may be operationally simpler for an AWS-native team, while a cross-cloud service may require account setup, policy mapping, monitoring, and incident procedures. Assign a conservative labor estimate, for example 20 to 80 hours for initial integration and testing, but replace it with measured internal effort rather than treating the range as a universal fact. Include observability and support plans if they are required. A service that saves $300 per month but adds 60 hours of engineering and on-call work is not automatically economical, especially for a small team.

## Common Mistakes in S3 Compatibility Testing

The most common mistake is testing only large sequential uploads. That favors bandwidth and hides the request-rate limits that affect databases, image pipelines, event-driven systems, and backup software with many small files. Another mistake is comparing compressed test data with uncompressed production data, or using a local disk cache that makes the destination appear faster. Compatibility labels also invite assumptions: test conditional writes, range reads, metadata, checksums, multipart aborts, object lock, versioning, and lifecycle transitions where supported. A service that passes basic PUT and GET tests may still lack the semantics needed for a compliance archive.

Measurement errors are equally damaging. Ensure the client does not silently retry failed requests, because counting attempts as completed requests inflates apparent speed. Separate the upload phase from multipart finalization, and do not omit the time required to verify object integrity. Avoid comparing a warm cache with a cold destination, and use identical region pairs. If traffic crosses the public internet, report whether the provider’s optimized route or direct internet path was used. Finally, do not publish credentials, bucket names containing sensitive information, or unverified vendor claims. Reproducible tooling and configuration matter as much as the headline result.

## When Should a Team Act on the Benchmark Results?

Act quickly when a workload has a hard deadline, a regulatory retention rule, or a dependency on one cloud that could affect recovery objectives. If a backup must finish every night before 02:00, a service with higher average speed but poor 99th-percentile behavior may still be inadequate. If the current design is portable, the team can validate alternatives before an emergency migration rather than committing under pressure. For new applications, establish the benchmark during architecture review and include object size, request rate, region placement, encryption, and expected three-year growth. For existing systems, monitor production behavior for at least 30 days before changing the data plane; a controlled test cannot reveal every seasonal or application-specific pattern.

The decision should include exit criteria. Define the maximum acceptable monthly cost, minimum sustained throughput, maximum retry rate, required availability, and regions that must remain supported. Require the chosen service to pass a replay or restore test, not merely a transfer test. For backup, verify that objects can be discovered, decrypted, checksummed, and restored using a second tool or account. For analytics, verify that downstream systems can read the object layout without rewriting the entire dataset. If no option meets all criteria, the answer may be a hybrid design: keep authoritative data in the primary cloud, use a lower-cost secondary tier, and reserve expensive cross-cloud copies for recovery or audit requirements.

Do not switch solely to obtain a lower storage rate. Switch when the tested service improves an explicit business objective—lower transfer cost, faster recovery, reduced vendor dependence, or better regional coverage—without violating security and compliance controls. Record a rollback plan, expected savings, and the date for another review. As of 27 September 2026, re-evaluate the benchmark whenever pricing, provider regions, API behavior, encryption requirements, or workload volume change materially; a 20% increase in stored data can make a previously secondary provider economically relevant.

## A Practical Decision Framework for B2B Data-Plane Teams

Start with the application’s actual access pattern, then choose the closest benchmark scenario. For a 100 TiB archive read once per quarter, prioritize retrieval cost, integrity, and predictable restore time. For a continuously written telemetry stream, prioritize ingestion rate, small-request handling, event delivery, and regional placement. For a multi-region analytics lake, test simultaneous reads and writes because contention can change results. For a regulated backup, include immutability, legal hold, encryption-key ownership, and evidence of deletion behavior. A provider that wins the raw transfer test may lose on governance features that are more important than speed.

The final report should be understandable to procurement, security, and platform engineering. Include the date, regions, test duration, dataset, object-size distribution, concurrency, client version, retries, median and tail latency, sustained throughput, failure rate, and complete cost assumptions. Use a table similar to the one above, but add actual measurements and a three-year projection. Mark any result as vendor-supplied or internally measured. The conclusion should say what the team recommends, what conditions would reverse that recommendation, and which metrics remain uncertain. This is more defensible than declaring one “best S3” service, because cross-cloud performance is a property of a route, workload, configuration, and commercial agreement rather than of an API name alone.

## Quick answers

### Is an S3-compatible provider automatically as fast as Amazon S3?

No. S3 compatibility primarily concerns API and object-operation behavior; it does not guarantee identical networking, storage hardware, request scheduling, or regional capacity. Test the exact workload, regions, object sizes, concurrency, and failure behavior before drawing a performance conclusion.

### What is a reasonable target for cross-cloud object-storage throughput?

There is no universal target. For a bulk transfer, 500 Mbit/s or more may be a useful initial threshold, while a nightly backup may require enough sustained throughput to finish within a fixed window. Interactive workloads should be judged primarily by median and 99th-percentile latency rather than average bandwidth.

### How do I compare costs when providers advertise different prices per terabyte?

Calculate storage, requests, transfer, retrieval, replication, support, and labor for the same workload. A $9/TB figure is not comparable by itself unless it states the region, retention model, retrieval terms, and whether cross-cloud egress is included.

### Should I use one large test file or many small objects?

Use both. Large files reveal sequential throughput and multipart efficiency, while small objects reveal request-rate limits, metadata overhead, and per-request charges. A realistic backup or analytics dataset should determine the weighting of each test.

### Can a cross-cloud benchmark predict disaster-recovery performance?

Only partly. It can estimate transfer and restore throughput under the tested conditions, but disaster recovery also depends on availability, credentials, DNS, routing, operator procedures, and the ability to reconstruct the workload. Run a timed restore test and document the recovery-point and recovery-time objectives.

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