Data location
Learn how the location of data stored in R2 is determined and about the different available inputs that control the physical location where objects in your buckets are stored.
Automatic (recommended)
When you create a new bucket, the data location is set to Automatic by default. Currently, this option chooses a bucket location in the closest available region to the create bucket request based on the location of the caller.
Location Hints
Location Hints are optional parameters you can provide during bucket creation to indicate the primary geographical location you expect data will be accessed from.
Using Location Hints can be a good choice when you expect the majority of access to data in a bucket to come from a different location than where the create bucket request originates. Keep in mind Location Hints are a best effort and not a guarantee, and they should only be used as a way to optimize performance by placing regularly updated content closer to users.
Set hints via the Cloudflare dashboard
You can choose to automatically create your bucket in the closest available region based on your location or choose a specific location from the list.
- Log in to the Cloudflare dashboard ↗ and select R2.
- Select Create bucket.
- Enter a name for the bucket.
- Under Location, leave None selected for automatic selection or choose a region from the list.
- Select Create bucket to complete the bucket creation process.
Set hints via the S3 API
You can set the Location Hint via the LocationConstraint
parameter using the S3 API:
Refer to Examples for additional examples from other S3 SDKs.
Available hints
The following hint locations are supported:
Hint | Hint description |
---|---|
wnam | Western North America |
enam | Eastern North America |
weur | Western Europe |
eeur | Eastern Europe |
apac | Asia-Pacific |
Additional considerations
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.
Jurisdictional Restrictions
Jurisdictional Restrictions guarantee objects in a bucket are stored within a specific jurisdiction.
Use Jurisdictional Restrictions when you need to ensure data is stored and processed within a jurisdiction to meet data residency requirements, including local regulations such as the GDPR ↗ or FedRAMP ↗.
Set jurisdiction via the Cloudflare dashboard
- Log in to the Cloudflare dashboard ↗ and select R2.
- Select Create bucket.
- Enter a name for the bucket.
- Under Location, select Specify jurisdiction and choose a jurisdiction from the list.
- Select Create bucket to complete the bucket creation process.
Using jurisdictions from Workers
To access R2 buckets that belong to a jurisdiction from Workers, you will need to specify the jurisdiction as well as the bucket name as part of your bindings in your wrangler.toml
:
For more information on getting started, refer to Use R2 from Workers.
Using jurisdictions with the S3 API
When interacting with R2 resources that belong to a defined jurisdiction with the S3 API or existing S3-compatible SDKs, you must specify the jurisdiction in your S3 endpoint:
https://<ACCOUNT_ID>.<JURISDICTION>.r2.cloudflarestorage.com
You can use your jurisdiction-specific endpoint for any supported S3 API operations. When using a jurisdiction endpoint, you will not be able to access R2 resources outside of that jurisdiction.
The example below shows how to create an R2 bucket in the eu
jurisdiction using the @aws-sdk/client-s3
↗ package for JavaScript.
Refer to Examples for additional examples from other S3 SDKs.
Available jurisdictions
The following jurisdictions are supported:
Jurisdiction | Jurisdiction description |
---|---|
eu | European Union |
fedramp | FedRAMP |
Limitations
The following services do not interact with R2 resources with assigned jurisdictions:
- Super Slurper (coming soon)
- Logpush
Additional considerations
Once an R2 bucket is created, the jurisdiction cannot be changed.