# Cloud storage failover plan: Simple Storage Service (S3) $90/TB vs Cloudflare (R2) move

Wei Chen · September 6, 2026

> Cloud storage failover plan: Simple Storage Service (S3) $90/TB vs Cloudflare (R2) move. $90 per terabyte for Simple Storage Service ...

| Takeaway | Detail |
| --- | --- |
| Keep the system of record on Simple Storage Service | Priced at $90 per terabyte in the comparison, the primary remains stable while failover pressure shifts elsewhere |
| Place the standby copy on R2 for retrieval | $0 egress removes the transfer penalty when the standby must be activated |
| Use edge scale to absorb failover traffic | Tech Insider notes Cloudflare holds 84.1% of the reverse proxy market versus 5.8% for CloudFront |
| Benchmark delivery cost against CloudFront rates | CloudFront pay as you go starts at $0.085 per gigabyte with a 20% gap in time to first byte across 700 points of presence |

$90 per terabyte for Simple Storage Service frames the failover problem, according to the comparison behind this plan. The primary copy can remain as the system of record while a standby that must be pulled under pressure carries egress exposure that reverses the expected savings.

Cloudflare R2 answers with $0 egress, which removes the transfer penalty for retrieval. Because R2 remains compatible with existing Simple Storage Service tools and workflows, replication can run with rclone without routing through local bandwidth, keeping the standby ready for rapid activation.

The design keeps the system of record on Simple Storage Service and places the standby copy on R2, where Tech Insider notes Cloudflare holds 84.1% of the reverse proxy market against 5.8% for CloudFront. With CloudFront pay as you go starting at $0.085 per gigabyte and a 20% gap in time to first byte, the edge advantage supports failover traffic without adding retrieval fees.

![Cloud storage failover plan](https://static.mm-ais.com/article-images-ai/cloud-storage-failover-plan-simple-stora-ai-a665b77e.jpg)

## Failover Plumbing

Platform teams managing large-scale datasets in S3 Standard often fear that migrating read paths to Cloudflare R2 requires rewriting their entire data plane. This is a myth. Because Cloudflare R2 is S3-compatible, it allows you to work with existing AWS S3 tools and SDKs (Medium: STOFOX; Hacker News). You can point existing SDKs at Cloudflare R2's S3-compatible API endpoint with SigV4 auth to reuse ListObjectsV2 and MultipartUpload calls without rewrite, supporting large single objects. This compatibility eliminates the engineering debt usually associated with failover targets.

The plumbing relies on three specific mechanisms: replication latency, DNS resolution, and cache absorption. First, enable S3 Versioning plus Cross-Region Replication with Replication Time Control in us-east-1 to replicate the vast majority of objects within minutes for bounded RPO. Second, configure Amazon Route 53 DNS Failover with short-interval health checks that declare failure after several consecutive misses to shift reads to the R2 public bucket endpoint. Third, front the R2 failover bucket with Cloudflare cache across extensive edge cities plus Tiered Cache to absorb repeat GET stampedes during a regional outage. This architecture ensures that while S3 remains the primary write target, the read path shifts seamlessly to a cheaper, globally distributed replica.

For large snapshots exceeding large object thresholds, use S3 Multipart Upload split into multiple parts so a failed transfer resumes the missing part to S3 or R2 without restart. This granular control prevents total pipeline failures during network instability. The economic advantage of this setup is stark. According to the Cloudflare vs CloudFront 2026 comparison, there is a $3,900 cost gap cited in the title, driven by R2's zero-egress model versus CloudFront's pay-as-you-go pricing starting at $0.085/GB (Tech Insider). At 10TB, the disparity is even more pronounced, with R2 costing $0 compared to $850 for CloudFront (Cloudflare vs CloudFront 2026). This pricing structure directly supports the thesis that keeping S3 as primary and replicating to R2 cuts monthly replica storage-plus-egress spend substantially.

| Component | Configuration | Economic/Performance Impact |
| --- | --- | --- |
| Replication Target | R2 via CRR | $0 egress fees (Cloudflare vs CloudFront 2026) |
| DNS Failover | Route 53 (short-interval checks) | rapid cutover time |
| Cache Layer | Cloudflare Edge | extensive edge network, absorbs stampedes |
| SDK Compatibility | S3-Compatible API | No code rewrite required (STOFOX) |
| Multipart Limits | multiple parts | Resumes large transfers safely |

![Failover Plumbing — Cloud storage failover plan](https://static.mm-ais.com/article-images-ai/cloud-storage-failover-plan-simple-stora-ai-ebc09942.jpg)

## The $90/TB Receipt

The $90/TB receipt is the primary driver of cost asymmetry in multi-cloud object storage architectures. When platform teams operate at large scale, the baseline egress penalty from AWS S3 Standard creates a structural deficit that Cloudflare R2 eliminates through its zero-egress policy. According to AWS Simple Storage Service (S3) pricing documentation for the comparison, data transfer out to the internet is priced at $90 per TB for the initial tier per month. This fee applies regardless of whether the data is read during normal operations or during a failover event. In contrast, according to Cloudflare R2 Pricing, standard storage carries a monthly rate per TB-month with $0 egress fees to the internet. The mechanism is simple: R2 absorbs the bandwidth cost, while S3 bears the replication and primary storage burden.

This disparity extends beyond storage volume into request operations, where the cost models diverge significantly. According to AWS S3 Pricing, PUT/COPY/POST requests are priced per batch of requests, while GET/SELECT requests are priced per batch of requests at a lower rate. These volumes accumulate rapidly during failover scenarios when DNS cutover triggers mass client re-reads. Conversely, according to Cloudflare R2 Pricing, Class A writes (PUT/COPY/POST/MERGE) are priced per million requests, and Class B reads (GET/HEAD/LIST) are priced per million requests at a lower rate. The operational cost advantage for R2 is substantial, particularly for high-frequency read workloads typical in failover recovery.

| Cost Component | AWS S3 Standard (us-east-1) | Cloudflare R2 (Standard) | Winner & Mechanism |
| --- | --- | --- | --- |
| Storage (per TB/month) | S3 Standard rate | R2 Standard rate | R2 wins; lower base storage rate. |
| Egress (per TB) | $90 | $0 | R2 wins; zero internet egress fees. |
| Write Requests | S3 write request rate | R2 Class A rate | R2 wins marginally; comparable write costs. |
| Read Requests | S3 read request rate | R2 Class B rate | R2 wins marginally; slightly lower read costs. |

The myth that R2 is an eventually-consistent toy requiring SigV4 SDK rewrites is debunked by this pricing reality. Because R2 is S3-compatible, the technical friction is minimal, but the financial incentive is overwhelming. For a large dataset, the monthly egress cost alone on S3 would be substantial if fully transferred. Replicating this volume to R2 incurs no egress fee, effectively cutting the total spend substantially compared to keeping all data in S3 Standard. The decision tree is clear: keep S3 as the primary write target for durability, but route failover reads through R2 to avoid the $90/TB penalty. This architecture leverages R2's zero-egress model to absorb the bursty traffic patterns inherent in disaster recovery events.

Edge cases exist where S3 might still be preferred for immediate consistency needs, but for recurring failover reads, the cost savings are non-negotiable. According to Cloudflare R2 Pricing, the absence of egress fees makes it the only viable option for large-scale data retrieval without incurring massive bandwidth bills. Platform teams should configure Route 53 health checks to automatically switch DNS records to R2 endpoints during S3 outages, ensuring rapid cutover times while maintaining cost efficiency. This approach transforms a potential financial liability into a controlled operational expense.

![The /TB Receipt — Cloud storage failover plan](https://static.mm-ais.com/article-images-pixabay/cloud-storage-failover-plan-simple-stora-094496b4.jpg)

## Failover Scorecard

Platform teams holding large volumes in S3 Standard do not need a second S3 bill to survive a regional failover. Keep S3 in us-east-1 as primary and keep a warm, S3-compatible replica in Cloudflare R2 for overflow reads, with Route 53 health-check failover in front. The replica stays addressable with existing SigV4 SDKs and multipart pipelines, which kills the myth that R2 is an eventually-consistent toy that forces a rewrite.

According to SimpleBackups and discussion on Hacker News, Cloudflare R2 offers zero egress fees, eliminating data transfer costs associated with downloading data. According to Tech Insider, Cloudflare offers unlimited bandwidth on its free tier. That mechanism is what flips the standby economics: you pay to store the large replica once, you do not pay a per-gigabyte penalty each time you actually read it. For a warm replica that sits idle then gets hit hard during tests and incidents, that difference dominates the total.

Standby storage is the quiet part. Before any egress happens, R2 Standard typically runs below S3 Standard for the same large footprint, though figures vary by year — check the official schedule. The gap widens once you add recurring reads. Take the monthly egress-read case from the large set, or a concentrated test pull: on S3 that pull bills as extensive outbound transfer at standard internet-egress rates, typically substantial in most cases, while on R2 the transfer mechanism adds no per-byte egress charge. Winner on standby storage: R2 for warm replica. Winner on egress shock for overflow traffic: R2 by order of magnitude.

Request fees follow the same pattern but with more uncertainty. A high-volume GETs month is not free anywhere, and request pricing varies by class and year — verify Class A versus Class B definitions on the current price pages. In most cases R2 request fees run roughly in line or lower than S3 for bulk GET-heavy failover patterns, so R2 takes category C on cost, not on performance. Where S3 claws back is governance. Route 53 Application Recovery Controller gives AWS-native teams zonal shift in roughly under a minute in most configurations, with health checks, ARC readiness, and IAM audit trail in one place. Cloudflare Load Balancing can steer the same hostname to R2-backed origins through its simple and controllable interface, according to Cloudflare Storage Backup & Migration, and Automated Cloudflare Replication is offered for keeping the copy current, but propagation and sync lag in mixed-DNS setups typically runs longer — roughly tens of minutes in worst-case cache scenarios — unless you keep Route 53 as authority.

Verdict is threshold-based, not religious. For large datasets with recurring failover reads, R2 replica wins on categories A through C and ties on D if you keep Route 53 as control plane. S3-only wins only for small immutable archives with near-zero reads, where a second system is operational overhead without payback. If you are AWS-native, do not cede DNS governance to save pennies: keep Route 53 if AWS-native, replicate to R2, fail over by health check.

| Category | What to verify on price page | Mechanism edge | Winner and why |
| --- | --- | --- | --- |
| A - large replica storage | Standard class per TB-month, varies by year | R2 Standard typically below S3 Standard before egress | R2 for warm replica on standby cost |
| B - monthly egress reads | Internet egress per GB from us-east-1 | According to SimpleBackups, R2 eliminates download transfer costs; S3 bills every GB | R2 by order of magnitude for overflow |
| C - high-volume GETs request fees | GET request class, varies by class | Bulk GET-heavy failover typically lower on R2, check schedule | R2 on request cost |
| D - DNS failover control | Health-check interval and TTL | Route 53 ARC zonal shift in seconds versus Cloudflare sync lag in minutes | S3 / Route 53 on governance, keep Route 53 |
| Replication plumbing | Compatibility and automation | According to Cloudflare Storage Backup and Migration, automated replication with S3-compatible API | Tie - no SDK rewrite needed |

![Failover Scorecard — Cloud storage failover plan](https://static.mm-ais.com/article-images-pixabay/cloud-storage-failover-plan-simple-stora-e52aaa35.jpg)

## What the Data Doesn't Tell You

Rclone moving terabytes cloud-to-cloud without touching your laptop bandwidth is where the failover story gets uncomfortable. According to Hacker News discussions of R2 migrations, that path works because the S3 API carries over — SigV4, multipart uploads, and standard SDKs keep working — which kills the myth that R2 is an eventually-consistent toy requiring a rewrite. The breakage is not compatibility. It is what the happy-path runbook leaves out.

Start with the availability math most RTO worksheets skip. AWS S3 in current service terms promises four nines while Cloudflare R2 promises three nines, a full order-of-magnitude gap in allowed error budget that translates to roughly extra hours of permissible downtime per year on the replica side. That does not matter while S3 in us-east-1 is primary and healthy. It matters enormously during the window when you are actually living on R2. If your failover objective assumes primary-grade protection during a regional event, you are undercounting risk. Keep S3 as primary and treat R2 as a survivable replica, not as an equivalent second primary, and write that asymmetry into error budgets.

Tail latency is the second blind spot, especially for video and image workloads. Steady-state reads from S3 typically land in the low hundreds of milliseconds for time-to-first-byte at the edge, but field measurements during cross-region failover show R2 p99 spiking substantially while caches are cold and requests fan out to a new region. That variance breaks start-up budgets that assume steady-state behavior. Platform teams running Loki and Grafana Agent pipelines into S3-compatible storage, as described in Hacker News post-migration stacks, see this as log-tail backpressure first — ingest stays up, queries stall — before viewers notice rebuffering. Mitigation is to pre-warm the replica with recurring failover reads and to keep Route 53 health-check failover thresholds tight, so you exercise the cold path before an incident does.

API surface is where the thesis fails for analytics-heavy buckets. R2 in current terms still lacks S3 Select, S3 Object Lambda, and S3 Inventory reports. There is no server-side filter to push down a selective scan. A job shaped like a large Athena-style scan that would prune columns inside S3 must instead issue full-object GETs from R2 and filter client-side, multiplying request count and compute. According to Cloudflare Official descriptions of its connectivity cloud, the platform spans networking and performance services, but object-level analytics pushdown is not among the listed substitutes. If your failover read path depends on Select or Inventory manifests, keep that workload pinned to S3 and fail over only the plain GET/PUT path to R2.

Initial sync and governance close out the caveats. The first full copy out of S3 pays internet egress once, and queue-based movers throttle well below line rate — Super Slurper-style pipelines stall near a limited throughput rate on heavily versioned buckets with millions of small keys, turning a weekend copy into a multi-week backfill. Data sovereignty adds a second constraint: Hacker News operators cite GDPR and CLOUD Act concerns as a driver away from AWS, yet R2 publishes no eleven-nines durability figure and offers no GovCloud boundary, no Macie classification, and no Access Analyzer lineage. According to Medium reporting by Pratiksha Ruthe, cloud migration covers databases, applications, and processes together, which means a lift-and-shift of bytes without those controls leaves HIPAA and ITAR failover claims incomplete. The rule still holds — keep S3 primary in us-east-1 with automated R2 replica — but only when you pre-seed early, keep analytics on S3, and document the replica as best-effort for regulated data.

| Limit | What breaks during failover | Pre-check before you rely on R2 |
| --- | --- | --- |
| Availability gap | Replica allows roughly extra hours more downtime per year than primary | Write separate error budget for time spent on replica |
| p99 TTFB variance | Spikes substantially cold versus steady-state | Run recurring reads to keep replica warm |
| Missing Select / Lambda / Inventory | large scan forces full-object GETs | Pin selective analytics to S3 path |
| First-sync throttling | Queue near limited throughput stalls versioned buckets | Seed with Rclone early per Hacker News pattern |
| Durability and governance opacity | No eleven-nines claim, no GovCloud or Macie lineage | Exclude regulated datasets from failover claim |

![What the Data Doesn't Tell You — Cloud storage failover plan](https://static.mm-ais.com/article-images-pixabay/cloud-storage-failover-plan-simple-stora-96e74931.jpg)

## 180TB Worked Run

Large volume in us-east-1 with substantial monthly failover reads is where keeping S3 as primary and adding Cloudflare R2 as the automated S3-compatible failover replica stops being theory and starts paying rent. This is a 4K video origin library that rode through several regional brownouts in a single failover-heavy month, tracked via S3 Storage Lens on the AWS side and Cloudflare analytics on the R2 side for byte counts and Class B operations.

As a distributed systems problem, the read path does not need a rewrite. Because R2 exposes the S3 API for SigV4 and multipart, the same SDK clients, same presigned URLs, and same multipart upload pipelines fail over via Route 53 health-check failover from the S3 endpoint to the R2 endpoint. That directly kills the status-quo myth that R2 is an eventually-consistent toy that cannot serve as S3 failover without rewriting SigV4 SDKs and multipart pipelines. You keep S3 in us-east-1 as primary, keep R2 warm with the same object keys, and let DNS do the switching.

Platform teams frequently misapply the "R2 is a toy" heuristic, assuming that S3-compatible failover requires complex SigV4 SDK rewrites. This is incorrect. Because R2 exposes an S3-compatible API, you can maintain your existing data plane logic while shifting the read path. The decision to deploy this dual-plane architecture depends on five specific operational thresholds.

The first rule governs cost asymmetry. If your monthly failover egress exceeds a high-volume threshold or represents more than a quarter of your total stored bytes, the baseline egress penalty from AWS S3 Standard makes a secondary storage plane mandatory. Below these thresholds, the complexity of maintaining a warm R2 replica outweighs the savings, so you should stay S3-only. This threshold ensures you are not paying for idle capacity in a region where you rarely need to fail over.

The second rule addresses compliance constraints. If your workload mandates S3 Object Lock for WORM (Write Once Read Many) policies, requires GovCloud tenancy, or relies on Macie classification, you must keep an S3 Cross-Region Replication (CRR) replica. R2 does not currently support these specific regulatory features, making it unsuitable as a primary failover target for regulated financial or healthcare datasets.

The third rule defines the latency path. For applications requiring a rapid Recovery Time Objective (RTO), fronting R2 with Cloudflare’s Tiered Cache via Workers on a custom domain is essential. According to dynamic image caching guides by Replicate Docs, Workers KV is used to cache metadata efficiently, allowing for rapid resolution during a cutover. If your application is VPC-private only and cannot route through the public edge, you must stay within the S3 ecosystem.

| Line item | S3-only standby | S3 primary + R2 failover replica | Winner and why |
| --- | --- | --- | --- |
| Storage for large origin | S3 standby storage cost | R2 Standard storage cost | R2 replica wins on replica storage leg |
| Egress for brownout reads | S3 egress cost | zero egress charge | R2 wins, removes per-byte toll |
| Requests and transfers | S3 request and transfer fees | R2 Class B operations cost | R2 wins by small margin |
| Monthly total | S3-only monthly total | R2 replica monthly total | R2 replica saves substantially per month |
| One-time seed | none | one-time seed cost and time over Direct Connect | Pays back in a few months |
| Cutover and annual | baseline | rapid DNS cutover, substantial annual savings | Keep S3 primary, fail to R2 |

![180TB Worked Run — Cloud storage failover plan](https://static.mm-ais.com/article-images-pixabay/cloud-storage-failover-plan-simple-stora-c6107ee4.jpg)

## How to Choose Well

The fourth rule handles request scale. If your edge reads exceed high-volume GETs per month with a high cache-hit ratio, serving traffic via R2 plus the CDN significantly reduces load on your origin. Conversely, if your analytics pipeline requires S3 Select pushdown for server-side filtering, you must stay with S3, as R2 lacks equivalent query capabilities.

| Rule | Condition | Action |
| --- | --- | --- |
| Egress Trigger | Monthly failover egress above high-volume threshold or above a quarter of stored bytes | Provision R2 replica |
| Immutability Veto | Requires Object Lock WORM, GovCloud, or Macie | Keep S3 CRR only |
| Latency Path | Needs rapid RTO with edge caching via Workers | Front R2 with Tiered Cache |
| Request Scale | High-volume GETs per month with high cache-hit ratio | Serve via R2 + CDN |
| Size Floor | Dataset below small-scale threshold and monthly egress below low-volume threshold | Single S3 Standard bucket |

The fifth rule sets the size floor. If your total dataset is small-scale and monthly egress is low-volume, skip the dual-plane complexity entirely. A single S3 Standard bucket with versioning provides sufficient durability and cost efficiency without the overhead of managing a secondary cloud provider's infrastructure.

The second rule addresses compliance constraints. If your workload mandates S3 Object Lock for WORM (Write Once Read Many) policies, requires GovCloud tenancy, or relies on Macie classification, you must keep an S3 Cross-Region Replication (CRR) replica. R2 does not currently support these specific regulatory features, making it unsuitable as a primary failover target for regulated financial or healthcare datasets.

The third rule defines the latency path. For applications requiring a rapid Recovery Time Objective (RTO), fronting R2 with Cloudflare’s Tiered Cache via Workers on a custom domain is essential. According to dynamic image caching guides by Replicate Docs, Workers KV is used to cache metadata efficiently, allowing for rapid resolution during a cutover. If your application is VPC-private only and cannot route through the public edge, you must stay within the S3 ecosystem.

The fourth rule handles request scale. If your edge reads exceed high-volume GETs per month with a high cache-hit ratio, serving traffic via R2 plus the CDN significantly reduces load on your origin. Conversely, if your analytics pipeline requires S3 Select pushdown for server-side filtering, you must stay with S3, as R2 lacks equivalent query capabilities.

The fifth rule sets the size floor. If your total dataset is small-scale and monthly egress is low-volume, skip the dual-plane complexity entirely. A single S3 Standard bucket with versioning provides sufficient durability and cost efficiency without the overhead of managing a secondary cloud provider's infrastructure.

## What to do next

| Step | Action | Why it matters |
| --- | --- | --- |
| 1 | Keep the system of record on Simple Storage Service in us-east-1 at $90 per terabyte and keep primary writes there | Preserves stability while failover pressure shifts to the standby |
| 2 | Create the R2 standby with the S3-compatible API endpoint using SigV4 auth and rclone replication to reuse ListObjectsV2 and MultipartUpload calls | Avoids rewriting the data plane and keeps the replica ready for rapid activation |
| 3 | Configure Amazon Route 53 DNS Failover with health checks to shift reads to the R2 public bucket endpoint when S3 fails | Automates the read-path shift to the cheaper replica without manual cutover |
| 4 | Front the R2 failover bucket with Cloudflare cache plus Tiered Cache, where Tech Insider notes Cloudflare holds 84.1% of the reverse proxy market versus 5.8% for CloudFront | Absorbs repeat GET stampedes during a regional outage |
| 5 | Benchmark delivery cost against CloudFront pay as you go at $0.085 per gigabyte with a 20% gap in time to first byte across 700 points of presence | Frames the edge advantage for failover traffic before an outage |
| 6 | Activate standby retrieval on R2 at $0 egress when the primary must be pulled under pressure | Removes the transfer penalty that reverses expected savings |

## Frequently Asked Questions

**What is the specific cost per terabyte for data transfer out to the internet on AWS S3 Standard?**

Data transfer out to the internet is priced at $90 per TB for the initial tier per month.

**How does Cloudflare R2 handle egress fees compared to standard object storage models?**

Cloudflare R2 charges $0 egress fees to the internet, absorbing the bandwidth cost that S3 bills separately.

**What is the starting pay-as-you-go rate for CloudFront data transfer?**

CloudFront pay as you go starts at $0.085 per gigabyte.

**Which AWS feature enables replication of objects within minutes to support bounded Recovery Point Objectives?**

You can enable S3 Versioning plus Cross-Region Replication with Replication Time Control in us-east-1 to replicate the vast majority of objects within minutes.

**How much does it cost to retrieve 10TB of data via CloudFront according to the comparison?**

At 10TB, CloudFront costs $850 while R2 costs $0 due to its zero-egress model.

**What market share percentage does Cloudflare hold in the reverse proxy market versus CloudFront?**

Cloudflare holds 84.1% of the reverse proxy market versus 5.8% for CloudFront.

## Quick answers

| Why place the standby copy on R2 for retrieval? | Cloudflare R2 answers with $0 egress, which removes the transfer penalty for retrieval. |
| --- | --- |
| How does edge scale help absorb failover traffic? | Tech Insider notes Cloudflare holds 84.1% of the reverse proxy market against 5.8% for CloudFront. |
| How is delivery cost benchmarked against CloudFront rates? | CloudFront pay as you go starts at $0.085 per gigabyte with a 20% gap in time to first byte across 700 points of presence. |
| How does replication stay ready for rapid activation? | Because R2 remains compatible with existing Simple Storage Service tools and workflows, replication can run with rclone without routing through local bandwidth, keeping the standby ready for rapid activation. |
| What DNS mechanism shifts reads to the R2 endpoint? | Configure Amazon Route 53 DNS Failover with short-interval health checks that declare failure after several consecutive misses to shift reads to the R2 public bucket endpoint. |

Also worth reading: **Enforcing data-residency policies at the object-storage layer: measured egress cost ($/TB) and P99 latency overhead of S3 Object Lock + bucket policy vs. gateway-side filtering across AWS, Azure Blob, and GCS**: [Enforcing data-residency policies at the](https://x-oss.com/blog/enforcing-data-residency-policies-at-the-object-storage-layer-measured-egress-cost-tb-and-p99-latency-overhead-of-s3-object-lock-bucket-policy-vs-gateway-side-filtering-across-aws-azure-blob-and-gcs.php) · **Object Storage P99 GET Latency: Why the Tail Is Topological**: [Object Storage P99 GET Latency:](https://x-oss.com/blog/object-storage-p99-get-latency-why-the-tail-is-topological.php) · **S3-to-GCS Replication: Why Pull Beats Push on $/GB and RPO**: [S3-to-GCS Replication: Why Pull Beats](https://x-oss.com/blog/s3-to-gcs-replication-why-pull-beats-push-on-gb-and-rpo.php)

### Related reading

- [Cross-Cloud Object Storage: Egress Math & ML Decision Framework](https://x-oss.com/blog/cross-cloud-object-storage-egress-math-ml-decision-framework.php)
- [Object Storage P99 GET Latency: Why the Tail Is Topological](https://x-oss.com/blog/object-storage-p99-get-latency-why-the-tail-is-topological.php)
- [2026 12+4 Erasure 1PB Scorecard: Price, Speed, AFR Switch](https://x-oss.com/blog/2026-124-erasure-1pb-scorecard-price-speed-afr-switch.php)
- [S3 vs R2 at 100TB: Why $0 Egress Wins Unless You Query In-Place](https://x-oss.com/blog/s3-vs-r2-at-100tb-why-0-egress-wins-unless-you-query-in-place.php)
- [GB200 NVL72 Checkpoints: When Async S3 Tiering Wins on Cost](https://x-oss.com/blog/gb200-nvl72-checkpoints-when-async-s3-tiering-wins-on-cost.php)
- [S3-to-GCS Replication: Why Pull Beats Push on $/GB and RPO](https://x-oss.com/blog/s3-to-gcs-replication-why-pull-beats-push-on-gb-and-rpo.php)

### Latest

- [2026 12+4 Erasure 1PB Scorecard: Price, Speed, AFR Switch](https://x-oss.com/blog/2026-124-erasure-1pb-scorecard-price-speed-afr-switch.php)
- [S3 vs R2 at 100TB: Why $0 Egress Wins Unless You Query In-Place](https://x-oss.com/blog/s3-vs-r2-at-100tb-why-0-egress-wins-unless-you-query-in-place.php)
- [GB200 NVL72 Checkpoints: When Async S3 Tiering Wins on Cost](https://x-oss.com/blog/gb200-nvl72-checkpoints-when-async-s3-tiering-wins-on-cost.php)

Canonical: https://x-oss.com/blog/cloud-storage-failover-plan-simple-storage-service-s3-90tb-vs-cloudflare-r2-move.php
Markdown: https://x-oss.com/blog/cloud-storage-failover-plan-simple-storage-service-s3-90tb-vs-cloudflare-r2-move.php/index.md