# Cloudflare R2 adds a US-only data residency jurisdiction Cloudflare R2 can now guarantee that bucket data is stored and processed within the United States, giving builders a hard residency control rather than a best-effort location hint—but the choice is fixed when the bucket is created. R2’s new `us` jurisdiction gives object-storage users an explicit US data-residency guarantee, with jurisdiction-specific S3 endpoints and Workers bindings. Existing unrestricted buckets cannot simply be flipped into the new jurisdiction because jurisdiction is immutable after creation. - Status: Active - Published: 2026-08-21T21:56:11+12:00 - Updated: 2026-08-21T21:56:11+12:00 - Categories: Cloud & Infrastructure, Cloud Platforms, Databases & Storage - Tags: Cloudflare, Cloudflare R2, data residency, object storage - Canonical HTML: https://beyondthe.news/dossiers/cloudflare-r2-us-jurisdiction-data-residency ## What changed On August 17, 2026, Cloudflare added a `us` jurisdiction to R2. Buckets created with it are guaranteed to have their data stored and processed within the United States. Access uses a jurisdiction-specific S3 endpoint or a Workers R2 binding configured with `jurisdiction: "us"`. ## Why it matters R2 previously offered location hints that influence placement but do not guarantee residency. A jurisdictional restriction changes the compliance story for SaaS products and data workloads that must keep object data inside the US. Because jurisdiction is selected at bucket creation and cannot be changed later, adopting it can require a migration rather than a configuration toggle. ## A hard residency boundary, not a placement hint Cloudflare distinguishes R2 location hints from jurisdictional restrictions. Hints are best-effort placement controls intended mainly for latency; jurisdictions are guarantees about where data is stored and processed. The new US option joins Cloudflare’s existing jurisdiction mechanisms for workloads that need explicit geographic constraints. ## The operational cost is migration Jurisdiction is immutable after bucket creation. Teams with existing unrestricted or differently constrained buckets must create a new US-jurisdiction bucket and move or rehydrate data if they need the guarantee. Applications also need to use the US-specific S3 endpoint, and Workers bindings must identify the jurisdiction explicitly. ## What the guarantee does—and does not—cover The R2 documentation describes the restriction in terms of bucket data being stored and processed within the selected jurisdiction. Builders should still map the rest of their architecture separately: application compute, logs, analytics, databases, third-party processors and client traffic may have different residency properties. ## Key details - Added August 17, 2026. - The `us` jurisdiction guarantees R2 bucket data is stored and processed within the United States. - US-jurisdiction S3 endpoint format is account-specific under `.us.r2.cloudflarestorage.com`. - Workers R2 bindings can set `jurisdiction` to `us`. - A bucket’s jurisdiction cannot be changed after creation. - Location hints remain best-effort and are not equivalent to jurisdictional restrictions. ## Builder takeaways - If US data residency is a contractual or regulatory requirement, use a jurisdictional bucket rather than relying on an R2 location hint. - Plan the decision before bucket creation. Existing buckets that need the new guarantee require a data-migration path because jurisdiction cannot be changed in place. - Audit the full data path: an R2 jurisdiction does not automatically make application compute, logs, databases or third-party services US-only. - For S3-compatible clients and Workers, test endpoint/binding configuration in staging before migration so jurisdiction-specific addressing does not become a production cutover surprise. ## What to watch - Whether Cloudflare adds more country-level R2 jurisdictions beyond the current set. - Migration tooling for moving existing buckets between unrestricted and jurisdiction-constrained storage. - Clarification or certification around how the US jurisdiction maps to specific compliance regimes and service commitments. - Whether related R2 features such as Data Catalog and R2 SQL expose equivalent jurisdiction guarantees across their full processing paths. ## Uncertainties - Cloudflare documents the storage-and-processing guarantee for R2 bucket data, but builders must evaluate separate Cloudflare and third-party services independently for end-to-end residency. - The changelog does not provide an in-place conversion mechanism for existing buckets; current documentation says jurisdiction is immutable after creation. ## Sources - [R2 Changelog: New `us` jurisdiction for R2](https://developers.cloudflare.com/changelog/product/r2/) — Cloudflare · official changelog · 2026-08-17T00:00:00+12:00. Primary announcement of the US jurisdiction, endpoint/binding configuration and immutable-jurisdiction behavior. - [Data location](https://developers.cloudflare.com/r2/reference/data-location/) — Cloudflare R2 Docs · official documentation · 2026-07-28T00:00:00+12:00. Explains the distinction between best-effort location hints and jurisdictional restrictions that guarantee storage and processing location. - [Snowflake regions for R2](https://developers.cloudflare.com/r2/reference/partners/snowflake-regions/) — Cloudflare R2 Docs · official documentation · 2026-08-18T00:00:00+12:00. Current integration guidance reiterating that jurisdictions enforce where data is stored and processed, including US, EU and FedRAMP contexts.