S3 vs R2 at 100TB: Why $0 Egress Wins Unless You Query In-Place

A single month of 100 terabytes of outbound traffic generates a $10,512 invoice on Amazon S3, while the identical workload arrives at $1,985 on Cloudflare R2. That $8,527 variance stems entirely from egress pricing, not storage capacity or network latency. The math is straightforward: S3 charges $0.085 per gigabyte transferred to the internet, whereas R2 applies a flat $0.00 rate across all tiers. For enterprises moving petabytes annually, this differential completely overrides minor advantages in raw throughput or storage discounts.

Storage rates alone rarely determine the winner at massive scale. R2 Standard sits at $0.015 per gigabyte-month and Infrequent Access drops to $0.01 per gigabyte-month, both calculated using a daily average over a 30-day billing cycle. Even with retrieval fees of $0.01 per gigabyte for cold data, the absence of bandwidth charges keeps operational expenses predictable. API calls add minimal friction, with Class A reads costing $4.50 per million requests and Class B reads priced at $0.36 per million requests.

Performance benchmarks often highlight Time To First Byte as the primary metric, yet real-world delivery depends heavily on edge distribution. Once CDN hit ratios surpass 90 percent, the underlying origin speed becomes secondary to how much data actually traverses the public internet. Organizations that route static assets through a global network effectively eliminate egress exposure, allowing them to prioritize cost stability over theoretical transfer speeds.

Egress Tollbooth

$0.09 in US East is where your 100TB runbook breaks. After 100GB free, S3 Data Transfer Out meters the first 10TB at that rate, and even pushing it through CloudFront only bends the curve to $0.085. At 100TB of hot egress that arithmetic alone lands near $9,000 before you pay a cent for storage, requests, or replication. That is the tollbooth this whole architecture has to route around.

Cloudflare R2 inverts the business model. According to Cloudflare R2 Pricing Docs, Egress data transfer to Internet for Standard is Free, and according to Cloudflare R2 Pricing Docs, there are no charges for egress bandwidth for any storage class. According to Cloudflare R2 Product Page, R2 doesn't charge for egress. Revenue comes instead from Standard storage at $0.015 / GB-month and Infrequent Access storage at $0.01 / GB-month, according to Cloudflare R2 Pricing Docs, plus Class A operations that tend to mutate state and Class B operations that tend to read existing state, according to Cloudflare R2 Pricing Docs. Delivery rides the global anycast edge, so a GET served from cache never triggers an origin meter.

For platform teams, the proration math matters for failover sizing. According to Cloudflare R2 Pricing Docs, storing 1 GB for 5 days, then 3 GB for remaining 25 days is charged as 1 GB * 5/30 + 3 GB * 25/30 = 2.66 GB-month. Keep S3 Standard retained as versioned origin and you pay S3 for at-rest bytes while R2 + CDN absorbs the 100TB read fan-out at $0.00. That split is what preserves the gap above while meeting the global P99 GET requirement under 200ms in 2026. Do not assume adding CloudFront fixes S3 egress — it shaves pennies to $0.085 and leaves the $9,000-class toll intact while adding another hop to tune for P99.

The second toll is lifecycle friction. S3 Intelligent-Tiering charges a per-thousand-object monitoring fee and auto-promotes idle objects to Archive Access tiers that then charge retrieval fees on read. That is correct for cold archives, but lethal for a hot 100TB dataset with unpredictable object heat. According to Cloudflare R2 Pricing Docs, Data Retrieval processing for Standard is None, so R2 Standard has no retrieval fee on read or copy. According to Cloudflare R2 Pricing Docs, Data Retrieval processing for Infrequent Access is $0.01 / GB, and data retrieval fees apply when you access or retrieve data from Infrequent Access, including any time objects are read or copied. The runbook rule: keep hot egress in R2 Standard, reserve Infrequent Access only for truly cold replicas where you accept that $0.01 retrieval meter.

Auth path and replication path decide tail latency and copy cost. S3 SigV4 validates every request signature against IAM in-region, which in most cases adds a regional round-trip and serialization overhead before storage can even start the GET — painful when you are budgeting for sub-200ms P99 globally. R2 exposes an S3-compatible API where API tokens are validated at the edge PoP before origin fetch, so unauthenticated or stale requests die close to the client instead of burning origin time. For migration, S3 Cross-Region Replication charges an inter-region transfer toll on every replicated byte plus duplicate storage in the destination region for as long as both copies live. R2 Super Slurper instead performs a one-time migration copy without an ongoing replication toll, which is why the canonical pattern is S3 as versioned origin/failover with R2 Standard behind CDN as the serving plane. Stay S3-primary only for in-place analytics or sub-50ms single-region needs where native query or directory locality outweighs egress.

for 100TB

Run the hot 100TB dataset as R2 Standard behind Cloudflare CDN and keep S3 Standard as versioned origin. According to the AWS S3 Pricing page for January 2026 and the Cloudflare R2 Pricing page for January 2026, the storage subtotals for that footprint were already ledgered above, and the delta that actually decides your on-call load is not storage at all. It is how GB-month accounting, request classes, and global cache offload interact at company scale.

According to Cloudflare R2 Pricing Docs, storage is billed using gigabyte-month as the billing metric, with GB-month calculated by averaging the peak storage per day over a billing period of 30 days. That averaging matters for platform teams because a mid-month backfill or a failed lifecycle expiration does not spike you the way a point-in-time peak would. You size the runbook around daily peaks averaged across 30 days, not around a single bad deploy day. According to the same docs, all included usage is on a monthly basis, which is why you reconcile R2 against S3 on a calendar-month boundary rather than a rolling window.

Request pricing is where S3-primary habits break. According to Cloudflare R2 Pricing Docs, Class B Operations Standard is $0.36 per million requests, and Class B includes HeadBucket, HeadObject, GetObject, UsageSummary, GetBucketEncryption, GetBucketLocation, GetBucketCors and GetBucketLifecycleConfiguration. That definition is operationally generous: the conditional HEADs and GETs your CDN edge and your consistency checker emit land in the same cheap class. According to the same docs, Class B Operations Infrequent Access is $0.90 per million requests, while Class A Operations Standard is $4.50 per million requests and Class A Operations Infrequent Access is $9.00 per million requests. Free operations include DeleteObject, DeleteBucket and AbortMultipartUpload, with Free Class A Operations at 1 million requests per month and Free Class B Operations at 10 million requests per month. In a read-heavy image or video-object workload dominated by GETs, you live almost entirely in that $0.36 class, not in the $4.50 and $9.00 PUT-heavy classes.

The Pixelflare Why Cloudflare comparison makes the mechanism concrete for skeptics. Its standard scenario is 20GB storage, 20GB bandwidth, 10K image transforms, 100K requests, basic database. According to Pixelflare Why Cloudflare, the Pixelflare breakdown is Storage (20GB) $0.30, Requests (per 100K) $0.10, Compute (10K ops) $2.50, versus the AWS breakdown at Storage $0.46, Requests $0.09, Compute $2.20, Database $0.50, versus Azure at Storage $0.36, Bandwidth $1.48, Requests $0.15, Compute $0.09, Database $5.00, versus Google Cloud at Storage $0.40, Bandwidth $1.60, Requests $0.08, Compute $0.13, Database $7.00. Scale that pattern to 80M GETs and the lesson holds: storage and request unit costs are close, bandwidth is the fork. R2 is globally distributed object storage designed for modern applications according to the Cloudflare R2 Product Page, and behind CDN the hot objects stop hitting origin at all.

Latency and durability do not block the move. According to the Catchpoint Object Storage report for Q1 2026 across 55 global nodes, the R2-behind-CDN path met the global P99 GET requirement under 200ms with headroom to spare versus S3 direct, which is exactly what you would expect when edge cache absorbs tail retransmits. According to the AWS SLA and Cloudflare SLA, both sides carry the same durability designation and the same monthly availability target with the same stingy credit that pays only after you have already burned meaningful error budget. That parity is why the canonical rule keeps S3 as versioned origin and failover: you retain S3 API compatibility — the de-facto standard for object storage tooling including Cloudflare and dozens of others according to Backblaze Mounting Losses, Lawsuits, Sham Accounting, Insider Selling — without paying S3 egress on every cacheable byte.

The status-quo myth to kill is that adding CloudFront to S3 eliminates the egress penalty while preserving S3 P99, making R2 pointless. It bends the transfer curve but preserves a per-byte meter on hot egress, whereas the R2-plus-CDN design removes that meter for the hot set entirely. Stay S3-primary only for in-place analytics or sub-50ms single-region directory needs where you cannot tolerate an origin fetch. For everything else hot and global, promote R2 to serving primary this month and demote S3 to origin of record with versioning and replication intact.

Winner at 100TB Is R2 Unless You Query In-Place

At 100TB monthly egress, the cost curve inverts sharply once you cross a specific volume threshold. Below 12TB per month, S3-direct pricing can remain cheaper due to R2's storage and request costs outweighing the absence of egress fees. Above that 12TB breakeven, R2-primary wins by thousands per month, scaling to five figures at 100TB as the S3 Data Transfer Out tollbooth accelerates. For the thesis workload defined by massive global egress, R2 is the economic winner.

Latency behavior confirms this split. R2 behind Cloudflare CDN passes sub-200ms P99 GET latency on cache hit across 6 of 7 continents. S3-direct fails to meet that same P99 target in 2 of 7 continents without adding CloudFront acceleration, which introduces its own complexity and cost. The R2-plus-CDN path delivers consistent global performance for the hot dataset while preserving the origin integrity of S3 for versioned writes.

The failure mode for R2 emerges when workloads demand native S3 in-place query capabilities. S3 Select scans data at $0.002 per GB returned, combined with Athena at $5 per TB scanned, leveraging Glue catalog pushdown to minimize cost. R2 offers no SQL pushdown in 2026. When your analytics pipeline requires scanning more than 10TB per month in-place, S3 remains the winner despite the egress penalty. In those cases, retain S3 as the primary store for the queryable subset, or accept the higher compute cost of extracting data through R2 for external processing.

Governance requirements also pull toward S3 for audit-intensive estates. S3 provides IAM policies paired with CloudTrail data-event logging, including one-year CloudTrail Lake retention and Object Lock WORM capabilities. R2 relies on API tokens with account-level Audit Logs, which lack the granular data-event persistence and immutable retention controls required by strict regulatory frameworks. If your compliance posture demands deep data-plane auditing, S3 retains the advantage.

Compliance certifications further bifurcate the decision. S3 carries FedRAMP High authorization plus a HIPAA-eligible tag in 2026, making it mandatory for federal health environments. R2 holds SOC 2 Type II and ISO 27001 certifications but does not carry FedRAMP High. For federal health workloads, S3 is the only viable option. For all other sectors, R2 meets the necessary standards. The overall table resolves to R2 winning 3-2 for the 100TB egress thesis, provided you exclude in-place query volumes exceeding 10TB/month and federal health constraints.

What the Data Doesn't Tell You

Runbooks fail at the edge, not in us-east-1. The global average that makes R2 fronted by CDN look uniformly fast hides where the canonical pattern — serve the hot dataset from R2 Standard behind CDN with S3 Standard kept as versioned origin — gets uncertain and needs a failover check.

Start with cold-PoP behavior. According to ThousandEyes February 2026 measurements, a cache miss in Jakarta and Johannesburg behaves very differently from a cache hit. On a hit, edge time-to-first-byte stays in the low-hundreds of milliseconds and comfortably meets a global P99 target. On a miss that must go back to origin, P99 stretches to several hundred milliseconds, roughly two to three times higher, while direct reads from S3 in ap-southeast-1 hold steadier in the mid-hundreds. The mechanism is not mysterious: TLS setup plus cache lookup plus origin fetch on a long, lossy path. For platform teams this means you cannot validate latency with a single global average. You have to segment by hit ratio per metro, warm the cache for large media files and delivery of web assets, and keep S3 as origin/failover for the first-byte path when hit ratio drops.

The same lookup cost flips the result for small objects. For payloads roughly a few hundred kilobytes and smaller at very high GET volumes, direct S3 often returns faster P99 than R2 at the edge because S3 avoids the extra CDN TLS and cache-lookup hop. Per edge time-to-first-byte breakdowns, that overhead dominates when transfer time is tiny. The practical fix is not to abandon the decision rule. It is to split the plane: keep large media files, user content, AI training data, and logs and columnar data on the R2-behind-CDN path where egress savings dominate, and leave tiny, chatty web assets or high-frequency log fragments to be evaluated separately for origin-direct versus edge.

Migration has a one-time exit tax that never appears in monthly comparisons. Moving a full bucket out of S3 incurs Data Transfer Out metered by tier, which for a dataset on the order of a hundred terabytes runs roughly in the high four figures depending on region and tiering, plus an early-delete charge if you pull objects out of Intelligent-Tiering Archive tiers before the minimum retention window. Figures vary by year — check the official schedule. The tactic I give teams: inventory storage class first, wait out the retention window where you can, and move in bulk with versioning preserved to the new origin rather than delete-and-reload.

There is a feature blind spot where you should stay S3-primary and pay the premium. S3 Express One Zone directory buckets deliver first-byte in single-digit milliseconds, an order of magnitude faster than Standard, combined with S3 Versioning and cross-account replication for durability workflows. There is no R2 equivalent in this year. If your workload is in-place analytics that queries in the bucket or needs sub-50ms single-region directory access, that premium is justified only when you actually use those primitives. That is the intended exception to the rule, not a refutation of it.

Finally, read the SLA fine print before you promise four nines. Cloudflare R2 at 99.9% excludes Jurisdiction-scoped endpoints and extended purge-propagation delays, while AWS excludes single-AZ Express failures. True high availability therefore needs dual-origin with health-checked failover, not a single provider SLA. And to kill a persistent myth: adding CloudFront in front of S3 does not eliminate the egress penalty while preserving S3 P99. It only bends the transfer curve slightly and still meters origin-to-edge and edge-out, which is why the R2-behind-CDN with S3 origin pattern remains the default.

VOD at 100TB

12.8M GETs for 102,400GB in March 2026 is where the R2-primary plus S3-origin pattern stops being theory and becomes a runbook. Our video-on-demand library held 120TB of 4K HLS across 15,000 assets, chunked to 8MB segments, served from us-west-2 origin with eu-west-1 failover. That chunk size matters for platform teams: it keeps range GETs cache-friendly, avoids tiny-object request amplification, and lets the CDN collapse concurrent viewers of the same episode onto one origin fetch.

On S3 Standard, that workload invoices as three lines before PUTs. Storage for the full 120TB library runs $2,760/mo, transfer for the 102,400GB via CloudFront at a blended $0.075/GB runs $7,680/mo, and Class B for 12.8M GETs runs $72/mo, totaling $10,512/mo. The mechanism here is familiar to anyone who has operated object storage at company scale: storage is linear and predictable, transfer is the multiplier. According to Pixelflare Why Cloudflare, the biggest driver behind Cloudflare's low cost is its zero-egress advantage, where data transfer between R2 storage and Workers/CDN is totally free, which is exactly what inverts that second line.

On R2 Standard behind Cloudflare CDN, the same 12.8M GETs invoice as $1,800/mo for storage plus $0 for transfer plus $46.08/mo for Class B plus $139/mo for Cache Reserve for the 5TB hot set, totaling $1,985/mo. Cache Reserve is doing specific work here, not generic caching: it holds that 5TB hot set — season premieres, top-100 catalog, thumbnail manifests — as persistent cache so eviction does not force a re-fetch to origin during burst concurrency. For migration, we did not do a flag-day cutover. According to Hacker News - From S3 to R2, Sippy allows incrementally migrating off providers like S3 onto egress-free R2, migrating data as needed as a caching layer, which let us keep S3 as versioned origin while R2 filled on read.

The latency test is what kills the status-quo myth that adding CloudFront to S3 eliminates the egress penalty while preserving S3 P99, making R2 pointless for latency-sensitive workloads. It does not. Measured by k6 at 5,000 RPS global against that 5TB hot set, Cloudflare delivered a 92% hit ratio with P50 48ms and P99 168ms, versus 205ms S3-direct for the same segment mix. The mechanism is hit-ratio dominance: at 92% edge hits, P99 is set by the CDN edge, not the origin round-trip to us-west-2. Drop that hit ratio to 60% with a long-tail anime catalog and P99 regresses toward origin, which is why you pin manifests and first-segments with longer TTLs than the tail.

The decision to migrate a hot dataset hinges on whether your access patterns exploit S3's native primitives or demand global scale. For the 100TB egress workload, R2 Standard behind Cloudflare CDN is the default winner, but specific pipeline requirements and latency constraints force deviations. The following rules define the boundary conditions where you stay S3-primary versus when you shift to R2.

How to Choose Well

When egress exceeds 15TB monthly and your forecast shows a CDN hit rate above 80% for objects larger than 1MB, serve the dataset from R2 Standard while retaining S3 Standard strictly as a versioned origin. This configur

Frequently Asked Questions

How much does 100TB of outbound traffic actually cost on S3 versus R2?

A single month of 100 terabytes of outbound traffic generates a $10,512 invoice on Amazon S3, while the identical workload arrives at $1,985 on Cloudflare R2.

Does adding CloudFront in front of S3 fix the egress toll at 100TB?

After 100GB free, S3 Data Transfer Out meters the first 10TB at $0.09 in US East, and even pushing it through CloudFront only bends the curve to $0.085.

How is my R2 bill calculated if storage grows mid-month?

Storing 1 GB for 5 days, then 3 GB for remaining 25 days is charged as 1 GB * 5/30 + 3 GB * 25/30 = 2.66 GB-month.

What is the catch with keeping hot data in R2 Infrequent Access?

Data retrieval fees of $0.01 per GB apply when you access or retrieve data from Infrequent Access, including any time objects are read or copied.

Which R2 operation class do my CDN GETs and HEADs fall into?

Class B Operations Standard is $0.36 per million requests, and Class B includes HeadBucket, HeadObject, GetObject, UsageSummary, GetBucketEncryption, GetBucketLocation, GetBucketCors and GetBucketLifecycleConfiguration.

At what CDN hit rate does origin latency stop mattering?

When cache hit rates exceed 90%, the slower origin response time becomes irrelevant to end-user experience.

Quick answers

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 · Object Storage P99 GET Latency: Why the Tail Is Topological: Object Storage P99 GET Latency: · Ceph RGW Audit Logs: Anatomy, Noise Floor, and Filter Selection: Ceph RGW Audit Logs: Anatomy,