How Much Does Cross-Cloud Transfer Pricing Cost Between AWS, Azure, and Google Cloud?

The Direct Answer on Cross-Cloud Transfer Pricing

Cross-cloud transfer pricing usually refers to the fees charged when an object-storage customer moves data out of one public cloud and into another, especially when that movement is not part of a provider’s free migration path. The headline charge is often called data transfer out, internet egress, or inter-region and inter-cloud data transfer, but the final bill can also include API requests, storage in the destination, temporary transfer infrastructure, and indirect routing through commercial internet providers. As of 28 September 2026, no major provider is expected to charge a universal public-cloud price for every cross-cloud transfer. Rates vary by source region, destination geography, service class, transfer volume, contract, and whether traffic crosses the public internet, a provider’s private backbone, or a dedicated connection.

Also worth reading: How Can Platform Teams Control Cloud Data Transfer Costs Across Providers in 2026? · How do you tune rclone for maximum distributed transfer performance across cloud object storage? · How Do Cloudflare R2, AWS S3, Backblaze B2, and Google Cloud Storage Compare on Price in 2026?

A useful first approximation is to separate migration from normal storage consumption. If 10 TB is copied from AWS to Azure, 10 TB may arrive at Azure, but the customer can still pay for 10 TB of AWS internet egress, possibly an intermediate processing service, and the destination’s retained storage. Public ingress is commonly free, but that does not make the complete migration free. Private connectivity, such as cloud interconnects, can reduce routing constraints and improve consistency, yet circuits commonly add fixed monthly costs, cross-connect fees, and minimum commitments. For a recurring data plane, the comparison should therefore calculate cost per usable terabyte rather than focus on an advertised egress rate alone.

What Determines the Price of Moving Data Between Clouds?

The largest variables are source geography, destination geography, protocol, and transfer scale. Moving data between two cloud regions in the same provider is not automatically the same operation as moving it between AWS, Microsoft Azure, and Google Cloud. Cross-cloud traffic normally traverses the public internet unless the parties use a hosted private connection, and a private connection may still involve third-party colocation, exchange, and carrier charges. Source-side pricing can depend on whether the bytes leave a region through S3, Blob Storage, Google Cloud Storage, an edge endpoint, or a specialized migration appliance. API request charges also matter for millions of small objects even when the aggregate payload is only a few terabytes.

Object count can matter more than expected. Ten terabytes represented by 100,000 objects of roughly 100 KB can generate far more request expense than 10 TB represented by 1,000 objects of 10 MB each. Archive retrieval, minimum storage-duration rules, early-deletion charges, compression, encryption, and checksum verification can further change the cost. Transfers to or from provider-owned services may receive exemptions or special rates, but those discounts do not automatically apply to a platform team’s own independent S3-compatible workload. Contracted enterprise pricing can also differ from public list prices, so any estimate based only on a pricing-page search is incomplete.

Timing is another variable. A short migration may be priced as a one-time event, while continuous replication or multi-region failover is continuous egress. A service that accepts a write once but later replicates it to a geographically distant endpoint may incur charges that are easy to miss because they appear under storage or replication rather than under a line item called transfer. For planning, teams should model average monthly egress, a 95th-percentile burst, the number of objects, the retention period, and the recovery behavior after an outage.

How to Estimate the Cost of a Real Migration

Start with logical usable data rather than the sum of every replica. A database with 20 TB of primary data may contain snapshots, replicas, logs, indexes, and temporary files; copying all of them can multiply both transfer and request costs. Inventory the data by bucket or container, identify objects below a chosen size threshold, separate live data from archives, and remove unnecessary duplicates before movement begins. A practical pilot should move at least 100 GB, but a pilot of 100 GB will not reveal every production constraint involving concurrency, throttling, small files, retries, or sustained throughput.

For a transparent example, suppose a team plans to move 50 TB from one provider’s US region to another provider’s US region. If the source charges $0.09 per GB for internet egress, the theoretical transfer charge is 50,000 GB multiplied by $0.09, or $4,500. A rate of $0.02 per GB would produce $1,000. These calculations are illustrative rather than quotations because provider tiers, negotiated terms, and exact routes change. Add destination storage, PUT or copy operations, private connectivity, labor, and the cost of maintaining the source until verification is complete. If the same data must remain in both clouds for 30 days, calculate dual storage and possible replication during that overlap.

A sensible acceptance threshold should combine cost and engineering risk. A $300 private connection may be unjustified for a 20 TB one-time migration, but it could be rational for continuous multi-terabyte replication with strict availability requirements. The break-even point is the monthly avoided transfer and network cost minus the circuit and equipment cost. Teams should rerun that calculation at 1, 5, 10, and 50 TB per month because fixed connectivity costs become less dominant as volume rises, while egress and operational complexity continue to scale.

AWS, Azure, and Google Cloud Compared

The table below is a planning framework, not a current quote. Exact prices must be checked for the selected regions and service classes on the provider’s official pricing page, and enterprise agreements may override the public figures. The important structural point is that all three providers can charge for outbound transfer, API operations, and retained storage, while inbound internet traffic is often free but subject to service policies and special services.

Neither Azure Blob Storage nor Google Cloud Storage should be assumed to be cheaper simply because another provider’s storage price appears lower. Moving data out of the expensive environment can erase the apparent saving, particularly when the dataset is short-lived. By contrast, moving every cold object across clouds may be wasteful if it will never be read and can remain in lower-cost archive storage. Price optimization starts by asking whether movement is necessary, not merely by selecting the cheapest destination.

Public Internet, Direct Connect, Interconnect, and Third-Party Tools

There are two common technical routes. The first uses HTTPS, S3-compatible APIs, rclone, or a provider migration utility over the public internet. It is usually simplest for a one-time move and provides no minimum hardware commitment, although throughput depends on internet capacity, packet loss, endpoint throttling, and source concurrency. The second route uses private connectivity, such as AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, or a cross-cloud connection built through a carrier or colocation facility. It can offer controlled routing, stable bandwidth, and less exposure to public transit, but it is not automatically cheaper.

Cross-cloud transfer pricing also has a performance dimension. A 1 Gbps connection has a theoretical ceiling of about 11.25 GB per second and transfers roughly 32.4 TB per day at full, uninterrupted utilization. In practice, protocol overhead, retransmissions, storage reads, encryption, throttling, and maintenance windows can reduce that to 70–90% or less. Teams that choose a connection merely to obtain a larger number should also pay for the port, cross-connects, virtual circuits, carrier service, and engineering time. For burst migrations, temporary high-bandwidth transfer services may be more economical than a permanent 1 Gbps circuit.

A data-plane SaaS or OSS service can provide a managed control plane, policy enforcement, transfer scheduling, observability, and compatibility with multiple providers. That convenience is useful when teams lack connectivity expertise, but it introduces another pricing question: is the vendor reselling carrier bandwidth, operating cloud infrastructure, or charging a platform fee? The contract should state whether fees include source egress, destination operations, retries, minimum commitments, and support. A lower service subscription can still produce a higher all-in cost if it encourages frequent cross-cloud movement.

Practical Steps for a Controlled Cross-Cloud Move

Begin with a data inventory and a written retention decision. Confirm whether every object must move immediately, whether some records have legal-hold requirements, and whether application clients can be switched atomically. Record object counts, median object size, checksum algorithms, encryption keys, source region, destination region, and expected read frequency. This information is necessary to estimate request charges and to avoid an expensive migration followed by expensive duplicate storage.

Next, run a representative pilot using production-like data. Include small files, large objects, unicode names, deep directory paths, archived classes, and objects requiring retrieval. Measure sustained throughput, failure rate, retry behavior, API throttling, checksum mismatches, and total billed cost. Do not infer performance from a single unthrottled stream; 32, 64, or 128 parallel streams may improve transfer speed, while excessive concurrency can trigger limits. Preserve an audit log of source object, destination object, size, checksum, transfer time, and operator decision.

The cutover should normally be read-only, incremental, and reversible. Perform an initial bulk copy, perform a second pass for changes, enter a short controlled-write window, copy the final delta, verify totals and random samples, and only then change the application endpoint. Keep the source available until the agreed rollback period expires. A migration that is technically complete but fails a compliance check is not finished, and deleting source data before verification can turn a temporary cost issue into a recovery incident.

Common Cost and Performance Mistakes

The most common mistake is treating free ingress as a free cross-cloud transfer. The destination may accept bytes without charging for inbound internet data, while the source still bills outbound traffic and the project still pays for operations and retained storage. Another mistake is comparing storage rates without comparing egress rates or request classes. A low destination price per GB-month can be irrelevant for data that is moved frequently or replaced every 30 days.

Small-file transfers are another trap. A migration of 10 TB can create millions of PUT requests, LIST calls, and metadata operations. A provider may charge only fractions of a cent per request, but a million operations at $0.0004 each already equals $400 before support or tooling. Compression can reduce payload size only when the data is compressible; images, encrypted objects, and already compressed archives may gain little. Parallel workers improve throughput but can increase API pressure and cost.

Teams also underestimate overlap. Source deletion, destination retention, backups, snapshots, and security copies can mean three or more active copies during migration. Private circuits add another category of expense when only a one-time transfer is needed. Finally, organizations often omit labor from the business case. Engineers still have to maintain endpoints, rotate credentials, investigate failures, validate legal requirements, and support both providers during transition. A $20,000 transfer invoice may be reasonable or unreasonable depending on whether the alternative is a two-week outage, a manual re-entry process, or a $3,000 transfer.

When to Act and When to Keep the Data in Place

Act quickly when a migration has a fixed deadline, a provider commitment, a regulatory requirement, or a demonstrated unit-cost advantage. For example, a team moving 100 TB every month can compare a managed service against public egress and a dedicated circuit because the volume creates repeatable economics. A team moving 1 PB once should also model specialized bulk-transfer terms, staged transfer nodes, and direct cloud-to-cloud options rather than relying on ordinary streaming.

Delay movement when the dataset is rarely accessed, the source has favorable committed-use pricing, or the destination would introduce compliance and key-management work. Keep the data in place if estimated egress plus duplicate storage exceeds the expected benefit over the retention period. Calculate at least a 12-month horizon, and test sensitivity with 30%, 50%, and 100% higher volumes. If the result is profitable only under optimistic throughput or undercounted requests, the case is not ready for approval.

For recurring replication, require a written service-level objective and a tested failure mode. Determine whether the service continues when one region is unavailable, whether it can limit bandwidth during business hours, and whether replication is resumable. Ask whether the provider retains customer data, where keys are held, who pays each cloud’s egress, and how price increases are communicated. The right answer can be different for a 5 TB monthly report archive and a 500 TB monthly analytics lake, even if both use the same object-storage interface.

A Decision Framework for Platform Teams

The best option is the one with the lowest risk-adjusted total cost for a defined workload, not the one with the lowest headline rate. Platform teams should create a model containing source egress, destination requests, destination storage, retrieval and deletion fees, connectivity, migration software, engineering labor, support, and the cost of running both clouds during transition. They should also record throughput, recovery time, and operational effort as requirements rather than afterthoughts.

For a one-time internet migration of up to a few terabytes, managed open-source tools such as rclone or an object-copy workflow may be sufficient. For sustained multi-cloud traffic, a private connection or a managed data-plane service can reduce operational burden, but the business case should include its fixed monthly charge. For high-volume one-time migrations, compare bulk-transfer programs and temporary high-bandwidth routes with standard egress. For infrequent reads, retain the object in the cheapest suitable class and pay retrieval when needed rather than moving it merely for theoretical portability.

As of 28 September 2026, the practical answer is therefore conditional: cross-cloud movement can range from modest egress charges to a substantial connectivity and operations commitment. Obtain a current quote using exact regions, object counts, transfer direction, and monthly volume; then validate it with a billed pilot. That method is more reliable than relying on a generic “cloud transfer” number, because it accounts for the parts of the bill that storage and egress calculators often omit.