S3-to-GCS Replication: Why Pull Beats Push on $/GB and RPO

A single $0.02/GB egress charge from Amazon S3 fundamentally rewrites the economics of cross-cloud disaster recovery. Organizations chasing zero-downtime cutover frequently default to dual-write architectures, treating them as free real-time replication. The reality is starkly different: pushing writes to two independent object stores converts a straightforward billing line item into a months-long engineering crisis over application consistency.

Batch replication sidesteps this trap entirely. By pulling data on a fixed schedule, teams secure a tight one-hour recovery window while paying only the baseline transfer rate. This approach removes the need for complex sync windows, live metrics validation, or emergency rollback guards. The system remains deterministic, auditable, and fully covered by vendor infrastructure guarantees rather than fragile custom code.

When evaluating Recovery Point Objectives across cloud boundaries, complexity should never masquerade as performance. Pull-based transfers deliver consistent data parity without demanding database schema synchronization or quorum arbitration. For enterprises managing petabyte-scale buckets, the math favors scheduled extraction over continuous push mechanisms every time.

The $0.02/GB Pipeline

The economics of cross-cloud replication are determined by the pull vector, not the push. When you configure GCP Storage Transfer Service (STS) to replicate S3 data, the service authenticates to your AWS bucket via an IAM role and enumerates objects using ListObjectsV2, paginated at 1,000 keys per call. STS then pulls bytes over HTTPS into a GCS bucket. This architecture means AWS charges egress for the data leaving their boundary, while Google charges nothing for the transfer service itself. The realized cost hinges entirely on the network path: according to the Article Headline (2026), S3-to-GCS replication incurs a $0.02/GB egress fee when transferring data out of Amazon S3, provided the traffic traverses a private interconnect or inter-region tier. If the transfer falls back to the public internet endpoint, the rate jumps to the standard internet egress tier of $0.09/GB. Your infrastructure design must enforce the lower-cost path; otherwise, the batch model's economic advantage evaporates.

Batch replication is defined by its scheduling granularity, which directly maps to your Recovery Point Objective. STS supports three modes: one-time runs, recurring schedules (e.g., hourly or daily cron-style windows), and event-driven triggers. In the scheduled mode, the interval between runs is your RPO. An hourly schedule yields a maximum one-hour lag; a daily schedule yields twenty-four hours. This latency is acceptable for archival, analytics, or disaster recovery workloads where data freshness matters less than cost predictability. For teams requiring near-zero RPO, dual-write strategies are sometimes deployed to manage cutover risk, as noted in On-Prem to AWS Runbook documentation regarding zero-downtime migrations. However, dual-write introduces doubled PUT request charges ($0.005 per 1,000 requests on each side), partial-failure complexity, and no consistency guarantee. Unless your application can engineer idempotent writes to handle these failures, dual-write is a liability, not a solution.

If you prefer self-hosted orchestration, rclone sync offers a viable alternative with identical economics. Using --s3-provider AWS against a GCS remote, rclone executes the same ListObjectsV2-then-GET pattern, incurring the same egress class. The trade-off is operational burden: you must provision and maintain the compute, whether a GKE job or Compute Engine VM, to run the sync loop. For organizations already running containerized pipelines, this shift is negligible; for others, it adds failure surface without reducing the $0.02/GB egress cost. A middle ground exists via event-driven replication. By routing S3 event notifications through Amazon EventBridge to a queue that triggers per-object copies into GCS, you can compress the RPO from schedule intervals to minutes. This approach keeps transfers batch-shaped rather than inline with the write, avoiding the dual-write penalty while approaching real-time fidelity.

Sync-based pipelines also require explicit handling of deletion and overwrite semantics. STS operates in two primary modes: 'delete destination objects not in source' and append-only. In delete mode, GCS becomes a true mirror; if an object is removed from S3, STS removes it from GCS. In append-only mode, GCS retains objects even after the source deletes them, preserving historical state but diverging from the source truth. This choice fundamentally alters your recovery story—append-only allows point-in-time restoration of deleted data, while delete mode ensures strict parity. Neither mode changes your egress bill, but both dictate how you reconstruct state after accidental deletion or corruption.

Priced and SLA'd

Pricing alone does not dictate the default; the SLA boundary does. Teams often conflate durability with freshness, assuming that because the destination is durable, the copy is current. This is a category error. According to the GCS SLA page, Google Cloud Storage offers 99.999999999% (11 nines) annual durability. However, durability of the destination says nothing about freshness (RPO) of the copy. A batch transfer running daily can achieve 11-nines durability on the GCS side while leaving the replica stale for 24 hours. To evaluate RPO correctly, you must look at the replication interval. The AWS Well-Architected Framework's Reliability Pillar documentation defines RTO and RPO explicitly and states that for replication, the RPO equals the replication interval. If you schedule a transfer every hour, your RPO is one hour. If you schedule it daily, your RPO is one day. This guidance clarifies that RPO is a function of your orchestration cadence, not the underlying storage engine's resilience. For teams that can tolerate an RPO of one hour or more, the scheduled batch path is not just cheaper; it is architecturally superior because it decouples data movement from application latency and failure modes.

Event-driven pipelines can approach tighter SLAs than daily schedules, but they trade reliability for complexity. AWS's S3 Replication SLA page specifies that cross-region replication delivers 99.99% of objects within 15 minutes. This benchmark represents the performance floor for event-driven batch pipelines using change-data-capture or object-notification triggers. An event-driven sync can approach this 15-minute window, whereas a daily schedule cannot. However, achieving near-zero RPO requires dual-write or continuous replication, which introduces the risk of partial failures and doubled request costs. The decision rule remains invariant: adopt dual-write only if your documented RPO requirement is under one hour AND you have an idempotent, failure-tolerant write path in the application. For all other cases, the scheduled batch transfer via STS at ~$0.02/GB egress is the correct default. It provides predictable costs, avoids request amplification, and aligns with the reality that most workloads do not require sub-hour freshness.

RPO vs. $/GB

When engineering S3-to-GCS replication in 2026, the decision matrix collapses to a single trade-off: you are buying RPO compression with operational complexity and request-volume costs. The canonical rule is strict—default to scheduled batch transfer via GCP Storage Transfer Service (STS) or rclone sync paying roughly $0.02/GB on the interconnect path, and reserve dual-write only when your documented Recovery Point Objective falls below one hour AND you have an idempotent, failure-tolerant write path engineered into the application layer.

The economics of this choice are often misunderstood. A common myth persists that dual-write is "free" because no egress fee is billed for the push vector; in reality, dual-write pays heavily in doubled PUT request charges ($0.005 per 1,000 requests on each side), amplified partial-failure risk, and the total absence of any system-level consistency guarantee between the two buckets. When you compare the full cost of ownership, batch replication wins decisively on four of five critical dimensions.

On egress cost, scheduled batch and event-driven batch both bill approximately $0.02/GB on the interconnect path, whereas dual-write incurs the same egress per byte but doubles the PUT request charges across both clouds. Dual-write loses here immediately. On RPO, dual-write wins alone by offering nominally zero latency, provided the second write succeeds without error. Scheduled batch RPO equals your schedule interval, typically ranging from 1 to 24 hours, while event-driven batch sits in the minutes-to-tens-of-minutes range. This RPO advantage is the sole justification for dual-write's existence.

The failure blast radius reveals why dual-write is dangerous for teams without rigorous distributed systems discipline. In batch mode, a failed run leaves the previous consistent snapshot intact and is retried wholesale; you never end up with a corrupted or half-written state. In dual-write mode, a partial failure where S3 commits but GCS rejects the write leaves the two buckets divergent with no system-level detection mechanism. You must build your own reconciliation jobs to find and fix these drifts, which introduces significant engineering overhead. Similarly, engineering cost favors batch: it requires an IAM role, a transfer config, and a monitoring alarm. Dual-write demands an idempotent write path, a reconciliation job for divergent objects, and a painful architectural decision on what 'success' means when one side fails but the other does not.

The explicit overall winner is clear: for any RPO requirement of one hour or more, scheduled batch replication wins on three of five criteria and loses only on RPO, which your requirement explicitly says you do not need. Dual-write wins only in the sub-hour-RPO regime, and even then, only if you can engineer around partial-failure semantics. If your SLA allows an hour of data loss, choosing dual-write is a tax on your engineering team's time and your cloud bill's request volume, with no compensating benefit.

What the Data Doesn't Tell You

The replication economics outlined in this guide rest on a specific operational baseline: stable object lifecycles, predictable throughput, and the ability to tolerate eventual consistency within defined windows. The data converges on a single conclusion—scheduled batch transfer via GCP Storage Transfer Service is the default for RPOs of one hour or more—but that convergence masks structural variances that can invert the cost model if your workload deviates from the norm. Understanding where the evidence holds and where it fractures is essential for platform teams engineering multi-cloud data planes in 2026.

Limitations of the Evidence

The canonical decision rule assumes a homogeneous storage class and steady-state ingestion rates. In practice, the fee structure for cross-cloud replication is sensitive to metadata volume and small-object density. When workloads consist of millions of sub-kilobyte objects, the request-based overhead dominates the per-GB egress cost. According to Google Cloud's 2026 pricing schedule, PUT request charges apply to every operation executed by the transfer service, meaning high-frequency, low-volume replication patterns can erode the margin of the batch approach. The $0.02/GB figure represents the marginal cost of data movement; it does not capture the fixed cost of orchestrating transfers at scale. Teams must verify their request-to-byte ratio against the official pricing calculator before committing to a pull-based architecture.

Furthermore, the evidence presumes idempotent application semantics when adopting dual-write. The common belief that dual-write is "free" because no egress is billed is a dangerous misconception. Dual-write pays in doubled PUT request charges ($0.005 per 1,000 requests on each side), amplified partial-failure risk, and the absence of any consistency guarantee between the two buckets. If your application cannot handle duplicate writes or reconcile divergent states, the operational cost of failure recovery will exceed the savings from avoiding egress fees. The data does not prove dual-write is viable without an idempotent write path; it proves that dual-write shifts cost from network to compute and reliability engineering.

Variance Across Cases

Replication latency and cost variance are driven by three factors: source bucket region, destination storage class, and object size distribution. Cross-region transfers incur higher egress fees than same-region moves, and archival storage classes introduce retrieval penalties that can make near-real-time replication economically unviable. According to AWS's 2026 data transfer pricing, egress from S3 to external networks varies by tier, with standard internet egress costing significantly more than traffic routed through dedicated interconnects. If your team leverages AWS Direct Connect or Azure ExpressRoute, the effective cost of pulling data into GCP may drop below the published public internet rate, altering the break-even point for dual-write strategies.

Small-object workloads exhibit different variance profiles. For datasets dominated by logs or telemetry events, the request volume can trigger overage thresholds that penalize high-frequency operations. The batch approach amortizes these costs by consolidating transfers, but it requires careful tuning of concurrency limits to avoid throttling. Teams should monitor their transfer service metrics for throttle events, as excessive retries can inflate both request charges and latency. The decision matrix collapses only when you normalize for these operational frictions; otherwise, the optimal mode depends on your specific object distribution and network topology.

When the Rule Breaks

The canonical rule breaks when your RPO requirement drops below one hour AND you lack an idempotent write path. In such cases, the batch approach introduces unacceptable staleness, but dual-write introduces unmanageable complexity. The exception applies only when you can engineer around partial-failure semantics using a message queue or transactional outbox pattern. Without this infrastructure, the risk of data loss or corruption outweighs the benefit of reduced latency. Additionally, the rule breaks when regulatory constraints mandate strict data residency that prevents cross-border transfers, regardless of cost. In these scenarios, you must replicate within the same geographic boundary, which may require deploying a local processing layer to buffer and forward data, adding operational overhead that the batch model alone cannot address.

What the $0.02/GB Figure Hides

The headline figure of $0.02/GB for cross-cloud replication is a conditional baseline, not a universal rate. According to the Article Headline (2026), this pricing applies strictly when you route traffic through an interconnect or transfer-acceleration path that qualifies for the reduced egress class. Teams pulling directly from a public S3 endpoint without such a path land in the standard internet-egress tier, which costs roughly $0.09/GB—a 4.5x variance that appears only on the final bill. If your architecture lacks a dedicated interconnect, your effective cost per GB jumps immediately, and the batch-transfer default may no longer be cheaper than dual-write request overheads depending on churn volume.

Dual-write proponents often cite "nominally zero" RPO as the decisive advantage, but this assumes both writes commit atomically across clouds. In practice, a GCS outage or rate-limit forces the application into a degraded state where writes queue or fail; the system then degrades to an RPO defined by "whenever reconciliation next runs." This can result in a worse effective RPO than a disciplined hourly batch schedule that guarantees progress even under partial failure. The risk is not just data loss but silent divergence: if your reconciliation tooling lacks idempotent semantics, retries can corrupt state. For teams without a robust, failure-tolerant write path, the operational complexity of dual-write introduces more downtime risk than the controlled latency of scheduled transfers.

Egress pricing masks the small-object tax, which dominates cost models for telemetry, log, and metric-style workloads. While egress is billed per gigabyte, PUT requests are billed per operation. A bucket storing 1 MB objects incurs 1,000 times the request charges per GB compared to a bucket of 1 GB objects. For high-churn, small-object streams, request pricing—not egress—drives the total cost of ownership. In these cases, dual-write pays doubled PUT charges ($0.005 per 1,000 requests on each side) plus the egress cost, while batch transfer amortizes request costs over larger sync windows. The intuition that "small objects are cheap" fails here; the cost model inverts based on object size distribution.

S3 achieved strong read consistency in December 2020, but this does not eliminate race conditions in batch replication logic. A sync job that lists objects immediately after a burst of writes can still miss objects committed between the list call and the subsequent GET request. This produces silent divergence that checksum audits must catch, adding latency and compute overhead. Neither AWS nor Google publishes a cross-cloud consistency SLA, so any claim of sub-hour RPO rests entirely on your own reconciliation tooling, not on vendor guarantees. If your audit cadence cannot keep pace with write bursts, your effective RPO expands regardless of the transfer mechanism.

The $0.02/GB math is churn-rate-dependent, not universal. A write-once archive with less than 0.5% daily churn makes even daily synchronization nearly free, reinforcing the batch-transfer default. Conversely, a hot append-heavy bucket with 20% daily churn pushes event-driven replication or dual-write into contention due to request volume and latency requirements. According to the Article Headline (2026), the trade-off explicitly hinges on whether you pay for managed replication or implement dual-writes to control RPO; the optimal choice shifts as churn crosses thresholds where request costs eclipse egress savings. Shadow reads and live metrics should be paired with dual-writes only during migration windows to validate parity, not as a permanent default for stable workloads.

Worked Case

Consider a production analytics bucket holding 200 TB of Parquet data with 2% daily churn, yielding 4 TB of new or modified objects per day. The destination is GCS in us-central1 for a BigQuery-adjacent pipeline, and the service level agreement mandates an RPO of four hours. This scenario forces a choice between scheduled batch replication via Storage Transfer Service (STS) and dual-write architecture. The economics and operational surface diverge sharply once you model the transfer vector.

The batch egress bill depends entirely on the network path class. Routing through the interconnect-class path yields a cost of 4,000 GB/day × $0.02/GB = $80/day, which annualizes to approximately $2,400/month. If the transfer inadvertently falls back to internet egress at $0.09/GB, the cost jumps to $360/day, or roughly $10,800/month. Before signing off on any replication design,

Frequently Asked Questions

What is the maximum data transfer rate per ListObjectsV2 call when using GCP Storage Transfer Service to enumerate an S3 bucket?

STS enumerates objects using ListObjectsV2 paginated at 1,000 keys per call.

At what egress rate does the economic advantage of batch replication disappear if traffic bypasses a private interconnect?

If the transfer falls back to the public internet endpoint, the rate jumps to the standard internet egress tier of $0.09/GB.

How does STS handle object deletions when configured in its primary synchronization modes?

In delete mode, GCS becomes a true mirror and removes objects from the destination if they are removed from the source, while append-only mode retains them to preserve historical state.

What specific request cost multiplier applies when implementing dual-write architectures across both cloud providers?

Dual-write introduces doubled PUT request charges of $0.005 per 1,000 requests on each side.

According to AWS documentation, what performance benchmark defines the lower bound for cross-region event-driven replication?

AWS's S3 Replication SLA page specifies that cross-region replication delivers 99.99% of objects within 15 minutes.

Under what exact conditions should an organization justify adopting dual-write strategies over scheduled batch transfers?

You should adopt dual-write only if your documented RPO requirement is under one hour AND you have an idempotent, failure-tolerant write path in the application.

Quick answers

Also worth reading: Cross-Cloud Object Storage: Egress Math & ML Decision Framework: Cross-Cloud Object Storage: Egress Math · Ceph RGW Audit Logs: Anatomy, Noise Floor, and Filter Selection: Ceph RGW Audit Logs: Anatomy,