Summary

  • R2’s zero outbound-transfer rate coexists with storage and operation charges. Infrequent Access also carries a retrieval charge and a minimum storage duration, according to Cloudflare’s pricing documentation.
  • Cloudflare’s documented outward-copy procedure is a concrete starting point for an exit test. It is not evidence that a production application has moved successfully or that the entire transition costs nothing.

Cloudflare gives R2 customers two distinct things: a zero-priced outbound-transfer line item and a documented procedure for taking object data out. Neither is merely a promise to consider portability later. But neither supplies a measured cost or timetable for replacing a running workload. The distinction matters because a buyer can correctly identify a tariff benefit and still underestimate the cost of exercising the alternative it appears to offer.

The listed terms examined on 19 September 2026 put outbound transfer at US$0.00 per GB for both Standard and Infrequent Access storage. They also put Infrequent Access retrieval at US$0.01 per GB. These are separate billing categories in Cloudflare’s tariff, not contradictory descriptions of the same charge. Free outbound transfer can therefore accompany a bill for retrieving the data being transferred.

This is an examination of the documented terms, not a report of a newly effective price cut. No production migration was performed for this article. The available documentation supports a narrower, useful conclusion: customers can identify the charge that is zero, calculate how other listed rates interact and specify the evidence needed to establish a workable substitute. It does not establish realized customer savings, R2 profitability or a change in market-wide competitive power.

One zero, several meters

A storage purchase is not priced by a single measure. Capacity over time, operation counts and retrieved data can enter the calculation separately. Cloudflare’s listed rates make that separation explicit:

Listed component Standard Infrequent Access
Storage US$0.015 per GB-month US$0.01 per GB-month
Class A operations US$4.50 per million US$9.00 per million
Class B operations US$0.36 per million US$0.90 per million
Outbound transfer US$0.00 per GB US$0.00 per GB
Data retrieval charge No separate retrieval charge listed US$0.01 per GB
Minimum storage duration None 30 days

These figures come from Cloudflare’s pricing documentation. Class A broadly covers write, list and mutation operations; Class B broadly covers reads and metadata reads. Those descriptions do not tell a customer how many billable operations a particular transfer will generate. That requires an account of the actual workload, rather than an assumption that every object or every GB produces the same request pattern.

The rate comparison pulls in different directions. Infrequent Access’s storage rate is US$0.005 per GB-month below Standard’s, or one-third lower. Its Class A rate is twice Standard’s, while its Class B rate is 2.5 times as high. These are arithmetic comparisons between the listed classes, not price changes over time. Selecting the lower storage rate alone therefore does not establish the lower total cost.

The free allowance also matters. Cloudflare lists a monthly Standard-only allowance of 10 GB-month of storage, one million Class A operations and ten million Class B operations. Infrequent Access does not receive that free tier. The same documentation says usage is rounded up to the next billing unit. A calculation that simply multiplies every observed quantity by a unit rate is consequently not a complete invoice calculation, particularly where allowances and billing increments are material.

Nor should the 30-day minimum be converted into a precise early-exit charge without the applicable detailed billing treatment. It establishes that storage duration belongs in the comparison. It does not, by itself, establish the final adjustment for every deletion or class transition. Buyers need to distinguish the economic direction of a rule from a fully specified bill.

There is still a real advantage in a zero-priced line item. Under the listed tariff, increasing outbound volume does not create an R2 egress charge. That is more than a cosmetic feature for a workload where transfer volume matters. The mistake is not valuing it; the mistake is letting its value stand in for all the other costs. R2’s outbound-transfer rate also says nothing about the prices charged by the services receiving the data.

How US$5 of storage savings can disappear

Consider an illustrative comparison using 1,000 GB-month of storage. At the listed rates, the Standard storage component is US$15 and the Infrequent Access storage component is US$10. The gross difference is US$5. At Infrequent Access’s US$0.01-per-GB retrieval rate, 500 billable GB of retrieval adds US$5 and consumes that difference before considering the higher operation prices.

At 1,000 billable GB of retrieval, the Infrequent Access storage-plus-retrieval components reach US$20, against Standard’s US$15 storage component. The arithmetic is straightforward; its scope must be equally clear:

Hypothetical billable retrieval from Infrequent Access Standard storage component Infrequent Access storage component Infrequent Access retrieval component Infrequent Access components shown, combined
0 GB US$15 US$10 US$0 US$10
500 GB US$15 US$10 US$5 US$15
1,000 GB US$15 US$10 US$10 US$20

This is an illustrative calculation from the published unit rates, not a customer invoice or an observed saving. It excludes operation charges, free-tier allowances, billing-unit rounding, minimum-duration adjustments, taxes, negotiated terms, credits and discounts. It also excludes destination services, engineering, validation and parallel operation during a transition. The retrieval quantities are assumed billable quantities, not measurements of physical traffic or a claim that every access retrieves a whole stored object.

The general calculation shows why the storage headline can mislead. Let S represent storage in GB-month, A represent Class A operations in millions, B represent Class B operations in millions and R represent billable Infrequent Access retrieval in GB. Applying the listed rates linearly gives these illustrative dollar components:

  • Standard: 0.015 × S + 4.50 × A + 0.36 × B.
  • Infrequent Access: 0.010 × S + 9.00 × A + 0.90 × B + 0.010 × R.
  • Infrequent Access minus Standard: −0.005 × S + 4.50 × A + 0.54 × B + 0.010 × R.

The comparison assumes the same storage quantity and operation counts under both classes, with all the exclusions described above. The negative storage term favors Infrequent Access; the additional operation and retrieval terms work in the other direction. The formula isolates that mechanism. It is not a universal break-even rule, because actual billing treatment and actual request counts still have to be supplied.

This also explains why a migration estimate needs more than a data-volume figure. Equal stored volume does not necessarily imply equal operation counts. A useful estimate must retain both the quantities of data and the billable actions associated with handling them. Without those separate measurements, a team cannot tell whether a change in the expected bill comes from storage, retrieval or requests. The tariff does not supply a fixed request count for a particular migration, and none should be assumed here.

None of this establishes that Infrequent Access is generally the wrong choice. A workload with sufficiently little retrieval and a suitable operation pattern may benefit from its lower storage rate. A different workload may not. The right conclusion is conditional: compare the meters that the workload will actually use. A low storage rate is a component of that decision, not the decision itself.

The documented exit is real, but its scope is smaller than an application

Cloudflare’s Rclone documentation goes beyond describing how to bring data into R2. It gives an outward-copy example: rclone copy r2:user-uploads/dog.txt ., which copies an object from an R2 bucket to a local destination. The documented setup uses the S3-compatible storage backend and Cloudflare R2 selection, an access key ID, a secret access key and an S3 API endpoint. It also identifies the account ID and an appropriately scoped R2 API token as relevant configuration requirements.

That is a meaningful operational starting point. It identifies a procedure a customer can test, rather than merely a statement that departure is permitted. It would be inaccurate to portray R2 as having no documented outward path. But a command example does not measure the time needed to transfer a representative collection, the associated billable requests or the work needed to make a replacement application behave correctly.

Rclone’s own description of copy says it copies between source and destination while skipping identical files and does not delete files from the destination. When the source is a directory, it copies that directory’s contents rather than the directory itself. Those semantics matter when planning a trial. Not deleting destination files does not make an operation read-only, nor does it guarantee that every aspect of the destination remains unchanged.

The same documentation describes --dry-run for previewing a copy without performing it. A preview is useful for checking the intended action. It is not a throughput measurement, proof that the transfer completed or validation that an application can run against the result. These are different observations and should remain different entries in a migration record.

There is also a distinction between copy and sync. Cloudflare’s Rclone documentation warns that synchronization can delete destination files absent from the source. A customer should not treat the two commands as interchangeable evidence of a safe transition. Any decision to use destructive synchronization needs its own tested plan; it is not a necessary consequence of wanting an export path.

Compatibility creates a further boundary. Cloudflare says R2 implements the S3 API to facilitate migration, while noting differences in API features and tracking implementation status as work proceeds. Its compatibility documentation therefore supports an operation-by-operation check, not an inference of complete interchangeability from the S3 label. Equally, that statement does not establish that a particular application will fail.

For a buyer, the relevant questions are specific: which operations and parameters does this application require, and do they work at both ends? What metadata or other application state must be preserved or recreated? Which checks demonstrate that the destination behaves as intended? Those are questions for a representative test, not documented defects in R2. A copy of object bytes answers one part of the problem; the application’s dependence on those bytes determines the rest.

Three propositions that require three kinds of evidence

The first proposition is economic: outbound transfer is listed at zero. The tariff establishes that narrow claim. To extend it into an expected transition bill, the buyer needs workload quantities, applicable billing treatment and the costs of the other services and work involved. To extend it into realized savings, the buyer needs an observed comparison with a relevant alternative. Neither extension follows automatically from the first proposition.

The second proposition is operational: objects can be taken out through a documented procedure. Cloudflare’s example establishes a described outward path. To turn that into evidence for a specific workload, a customer would need to perform a representative transfer and record its results. Intended objects, completed objects, elapsed time, retries, validation and billable activity belong in that record. A successful preview belongs in a different column from a successful transfer.

The third proposition is substitutability: the destination can support the required service after cutover. That is broader than obtaining the data. It requires the customer to define the application behavior, performance and continuity conditions that matter, and then test them. It also requires checking for any unplanned continuing dependence on the original service. These are proposed tests; this article has not established that a customer has passed or failed them.

The distinction prevents errors in both directions. It prevents a zero-egress tariff from being sold analytically as zero switching cost. It also prevents ordinary migration work from being presented as proof of abusive lock-in. Integration can be useful, and workload complexity can create transition costs independently of any supplier-specific barrier. The amount of work is not, on its own, a finding about its cause.

The bounded commercial conclusion is therefore stronger than a slogan but narrower than a claim of liberated markets. R2 offers a documented zero-egress tariff and an outward-copy procedure. Infrequent Access shows especially clearly why transfer pricing and the total bill must remain separate. What would advance the analysis next is a representative transfer with measured costs, followed by application validation at the destination. Until then, an available export operation and an executable workload exit remain different achievements.