On this page · 12 sections
- What Cloudflare shipped, and the wording that matters
- Break 1: one S3 client cannot span two jurisdictions
- Break 2: your existing tokens have default baked into them
- Break 3: the choice is permanent, per bucket
- Break 4: the surrounding docs have not caught up
- What this costs
- India-specific considerations
- How to tell whether this affects you
- What is still unknown
- FAQ
- How eCorpIT can help
- References
Summary. Cloudflare added a us jurisdiction to R2 on 17 August 2026, joining eu and fedramp and bringing the total to 3. Buckets created in it are guaranteed to be stored and processed inside the United States, reachable only at https://<ACCOUNT_ID>.us.r2.cloudflarestorage.com. The R2 data location page, updated 19 August 2026, lists exactly one limitation: Logpush. That single line is the part of this launch teams will read. The four that cost real time are not on it. The jurisdiction cannot be changed after bucket creation. Every bucket-scoped API token you already issued encodes the literal string default in its permission key and will not resolve a us bucket. Super Slurper's documentation, last updated 21 April 2026, never mentions jurisdictions at all, while Sippy's, updated 30 July 2026, requires a cf-r2-jurisdiction header. And Cloudflare's own Data Localization Suite page for R2, last updated 1 July 2026, still tells compliance readers that EU is the option. Pricing is unchanged: $0.015 per GB-month for Standard storage and $4.50 per million Class A operations, with no jurisdiction premium anywhere in the published rate card.
What Cloudflare shipped, and the wording that matters
The changelog entry is four sentences long. R2 "now supports a us jurisdiction, which guarantees that bucket data is stored and processed within the United States."
Read "and processed" carefully, because it is the claim that separates a jurisdiction from a location hint. R2 has offered 6 location hints for years: wnam, enam, weur, eeur, apac and oc. The data location reference describes those as "a best effort and not a guarantee", useful only "as a way to optimize performance". Jurisdictional Restrictions are the enforceable version. A compliance questionnaire that asks where data rests and where it is handled can be answered with a jurisdiction. It cannot honestly be answered with a hint.
That page also carries a detail most teams miss on first read. Location Hints "are only honored the first time a bucket with a given name is created. If you delete and recreate a bucket with the same name, the original bucket's location will be used." Naming is sticky in R2 in a way it is not in Amazon S3.
| Placement control | What it guarantees | How you set it |
|---|---|---|
| Automatic (default) | Closest available region to the create request | Nothing; it is the default |
| Location hint | Best effort only, explicitly not a guarantee | LocationConstraint in CreateBucket, or --location in Wrangler |
eu jurisdiction |
Storage and processing inside the European Union | Jurisdiction endpoint or --jurisdiction eu |
us jurisdiction |
Storage and processing inside the United States | Jurisdiction endpoint or --jurisdiction us |
fedramp jurisdiction |
FedRAMP boundary; Enterprise only, by request | Contact your Cloudflare account team or Support |
FedRAMP is the outlier. The docs state that "Cloudflare Enterprise customers may contact their account team or Cloudflare Support to get access to the FedRAMP jurisdiction." No such gate is documented for eu or us, which any R2 subscription can create.
Break 1: one S3 client cannot span two jurisdictions
The jurisdiction lives in the hostname, not in a request parameter. Cloudflare's R2 tokens documentation is blunt about the consequence: "Jurisdictional buckets can only be accessed via the corresponding jurisdictional endpoint. Most S3 clients will not let you configure multiple endpoints, so you'll generally have to initialize one client per jurisdiction."
The data location page says the same thing from the other direction: "When using a jurisdiction endpoint, you will not be able to access R2 resources outside of that jurisdiction."
If your service holds a single S3Client singleton, as most Node.js and Python services do, adding a us bucket means adding a second client, a second configuration path and a second set of connection settings. A ListBuckets call against the default endpoint will not enumerate jurisdictional buckets, so any inventory job, cost report or backup sweeper that discovers buckets dynamically goes quietly blind to the new ones. Nothing errors. The list simply comes back short.
Break 2: your existing tokens have default baked into them
This is the one that surfaces at 2am. R2 bucket-scoped API tokens carry a permission key of this shape:
"com.cloudflare.edge.r2.bucket.<ACCOUNT_ID>_<JURISDICTION>_<BUCKET_NAME>": "*"
The documentation then states plainly: "For buckets not created in a specific jurisdiction this value will be default."
Every bucket-scoped token issued before 17 August 2026 therefore encodes default in its scope. It is not a token that happens to lack a jurisdiction. It is a token scoped to a jurisdiction named default, and a us bucket is not in it. Re-scoping is a token rotation, not a settings change, which means the usual sequence applies: mint the new token, deploy it, drain the old one, revoke it.
Break 3: the choice is permanent, per bucket
"Once an R2 bucket is created, the jurisdiction cannot be changed."
There is no migration path in the R2 API for moving a bucket between jurisdictions, because the jurisdiction is part of the bucket's address. Moving means creating a second bucket at the other endpoint and copying every object across, paying Class A operations on the write side at $4.50 per million for Standard storage or $9.00 per million for Infrequent Access. R2 charges no egress bandwidth on any storage class, so the read side of a same-account copy is Class B at $0.36 per million, but the operation count is what bites on a bucket holding tens of millions of small objects.
Cloudflare applied the same rule to Artifacts on 13 August 2026: jurisdiction is picked at namespace creation and "cannot be changed after namespace creation." Two product launches, 4 days apart, both making residency a create-time decision. Treat that as the pattern rather than a quirk of R2.
Break 4: the surrounding docs have not caught up
The data location page lists one limitation, Logpush, with a documented workaround: run the Logpush job against an S3-compatible endpoint instead. Fine. The harder problem is silence. Several R2 surfaces a production bucket depends on never use the word jurisdiction on their documentation pages at all, so there is no stated behaviour to design against.
| R2 surface | Jurisdiction handling in its own docs | Page last updated |
|---|---|---|
| Logpush destination | Named as unsupported, with an S3-endpoint workaround | 19 Aug 2026 (data location page) |
| Sippy incremental migration | Requires a cf-r2-jurisdiction request header |
30 Jul 2026 |
| Super Slurper bulk migration | Not mentioned anywhere on the page | 21 Apr 2026 |
| Event notifications | Not mentioned anywhere on the page | 21 Apr 2026 |
| R2 Data Catalog (public beta) | Not mentioned anywhere on the page | 7 Aug 2026 |
| R2 SQL | Not mentioned anywhere on the page | Not stated on page |
| Data Localization Suite R2 guide | Names EU jurisdiction only | 1 Jul 2026 |
The Sippy and Super Slurper split is the sharpest example. Both are R2 migration tools. Sippy's page tells you exactly what to send: "If your bucket is setup with jurisdictional restrictions, you will need to pass a cf-r2-jurisdiction request header with that jurisdiction." Super Slurper's page, three months older, says nothing. A team planning a bulk migration into a us bucket has no documented answer and should test with a small prefix before committing a multi-terabyte job.
The Data Localization Suite page is the one that will reach the wrong reader. That is the page a privacy officer or an auditor opens, and on 23 August 2026 it still reads: "customers can create R2 buckets with jurisdictional restrictions set to EU." A US-headquartered customer reading Cloudflare's residency documentation would conclude the us option does not exist.
"No business should have to choose between compliance with local data regulation and a superior experience for their customers," said Matthew Prince, co-founder and CEO, Cloudflare, when the Data Localization Suite expanded into Asia. The engineering is now there for the United States. The documentation that a compliance team actually reads is more than 7 weeks behind it.
What this costs
Nothing extra, as published. The R2 pricing page never mentions jurisdictions, and the rate card is flat across them.
| Line item | Standard storage | Infrequent Access storage |
|---|---|---|
| Storage | $0.015 per GB-month | $0.01 per GB-month |
| Class A operations (writes) | $4.50 per million | $9.00 per million |
| Class B operations (reads) | $0.36 per million | $0.90 per million |
| Data retrieval | None | $0.01 per GB |
| Egress bandwidth | None | None |
| Minimum storage duration | None | 30 days |
The free tier of 10 GB-month of Standard storage, 1 million Class A and 10 million Class B operations per month applies to Standard storage only. If your residency migration also moves objects into Infrequent Access to save on the $0.015 rate, remember the 30-day minimum duration bills even for objects deleted or replaced sooner. The real cost of a residency move is almost always the operation count, not the stored bytes.
Teams comparing this against hyperscaler object storage will find the arithmetic differs mostly on egress, which is covered in our breakdown of cloud storage pricing across AWS S3, Azure and GCP.
India-specific considerations
There is no in jurisdiction. The published list is eu, fedramp and us, so an Indian team with a data localisation obligation cannot satisfy it with an R2 jurisdiction today.
That matters differently depending on the regulation. Section 16 of the Digital Personal Data Protection Act 2023 reads: "The Central Government may, by notification, restrict the transfer of personal data by a Data Fiduciary for processing to such country or territory outside India as may be so notified." That is a blocklist, not a blanket in-country storage rule, and the same section preserves any Indian law that imposes a stricter transfer restriction. The Reserve Bank of India's payment data directions are stricter and are the ones that usually decide the architecture. A us jurisdiction bucket is a clean answer to a US customer's residency clause and to a US-facing SOC questionnaire. It is not an answer to an RBI payment-data question.
The practical pattern for Indian teams selling into both markets is a split: jurisdictional R2 buckets for the customer data covered by a residency clause, and a separate store for anything under Indian sectoral rules. Getting that boundary right at design time is the whole job, and it is the same decision covered in our DPDP Act engineering playbook.
How to tell whether this affects you
Four checks, in order of how expensive the surprise is.
Search your Wrangler configuration for r2_buckets entries without a jurisdiction field. Those are default buckets, and adding the field to an existing binding does not move the data.
Grep your infrastructure code for r2.cloudflarestorage.com. Any hardcoded endpoint without a jurisdiction segment is a client that cannot see jurisdictional buckets.
List your bucket-scoped API tokens and read the permission keys. If they contain _default_, they are scoped to the unrestricted namespace.
Check whether anything downstream discovers buckets by calling ListBuckets rather than reading a configured list. Those jobs will under-report the moment a jurisdictional bucket exists.
Wrangler exposes --jurisdiction, aliased to -J, on r2 bucket create and on the list, info and other bucket subcommands, so the CLI path is available even where a doc page is silent.
What is still unknown
Cloudflare has not published whether Super Slurper accepts a jurisdiction target, whether R2 event notifications fire for jurisdictional buckets, or whether R2 Data Catalog and R2 SQL, both newer surfaces, honour the boundary. Those are not documented as unsupported. They are simply not documented. Until Cloudflare says otherwise, treat each as untested rather than working, and prove it with a throwaway bucket before it is in a compliance narrative.
FAQ
How eCorpIT can help
Residency decisions that are permanent at create time deserve more review than a settings toggle usually gets. Our senior engineering teams map which datasets carry a residency clause, which carry an Indian sectoral obligation, and which carry neither, then design the storage boundary and the token rotation around that split. eCorpIT is ISO 27001:2022 certified and builds applications aligned with DPDP Act requirements. If you are choosing between an R2 jurisdiction and a hyperscaler region, book a data residency architecture review and we will work through your object inventory with you. Our data residency and DPDP cloud architecture service covers the full design, and the wider cost picture sits in our cloud FinOps guide for Indian teams.
References
Last updated 23 August 2026.
