In order to meet the needs of compliance like GDPR in Europe, etc. - I had these questions about durable objects:
Can I create a durable object in a specific, prescribed country or region? Data at rest, in this case is then guaranteed to be geographically located in that area.
Can I ensure that auto-migration of a durable object instance is impossible outside a defined set of countries?
This level of location-control is critically important, as we want this capability to be a selling point for our SaaS product - Tallyfy.
While I donāt see any way to dictate where Durable Objects are stored, I do wonder if its nature of auto-migration can be leveraged by limiting the worker itself to a specific region. In theory, this would force the durable object to migrate close to where the worker is running. Still no guarantees, though.
I hope they consider it! This would make it much more powerful, and instead of just being storage, there would a level of geographical control that no other solution appears to have, in the face of compliance and data privacy laws popping up everywhere.
I believe āprivacy and complianceā was one of the key business drivers for creating workers, etc. so ensuring that storage-at-rest, and later - compute as well (Workers) is guaranteed to be in a certain locale is a very strong reason to adopt this.
Otherwise - Iām back to setting up an AWS stack in every region in the world (very expensive), which removes all the benefits of this worldwide edge storage/compute stack.
What Iād really like is region-locked compute and storage with both workers and KV-store + durable objects. For example - if my SaaS could guarantee that data from a company in Switzerland is going to live in Switzerland, thatās a strong selling point to adopt this.
I havenāt seen that, but I may have overlooked it.
One of Cloudflareās key features is being globally distributed. Not just for putting resources closer to users, but to better absorb the blow of high usage and attacks.
To layer geographic limits on services makes their services less efficient, though their high-end plans do allow for such restrictions.
As an example - Privacy Shield was invalidated recently, so any company relying on that has to change how they adopt model clauses for personal data held about EU citizens.
The answer is simply - to store data in the EU, I guess? Thatās why this would work - because governments and even states (California) are creating regulations around data held about/for residents.
When it comes to GDPR, there is a common misunderstanding that it relates to where the data is located, thatās false - the question is always - who has access to the data and what protections and compliance are in place to protect it when the data moves, Cloudflare has a DPA (Data Processing Agreement) just like Amazon does they donāt differ much, even the costs associated with an audit are the same (You pay).
In essence, they treat data the same within the EU as they do outside the EU.
Data protection is one of the most important GDPR points and Workers have advantages:
KV Data is encrypted in transit and at rest by default.
Workers run in isolates and works as an extra layer of security on top of the operating system.
Lambdas has a bigger area of vulnerability since itās apps are several times bigger.
This helps a lot - thank you! The reason I thought about the location was seeing this:
I then assumed that the āspiritā of GDPR was localization of data. In addition, isnāt this rule broken @thomas4 - because Privacy Shield has proven that the EU rules and US rules are not the same?
The entity to whom you pass the data to happens to be in a country that has data protection laws that are just as strong as GDPR (as determined by the EU Commission).
The EU Cloud is built for the primary reason of having a central location for all countries municipals and sensitive data in a single place, right now itās spread on US Clouds such as Amazon and mainly Microsoft Office 365 which has been adopted very broadly in Europe.
Iām hoping that this step will force US companies to split their companies into EU businesses that are isolated from the US laws which gives access to the US government when they request it.
Youāre right that the Privacy Shield was deemed ānot enoughā, the same will apply to the DPA agreements between Cloudflare, Amazon, Microsoft and Google on a case-by-case basis. Such cases will probably take quite a while, since the incurred cost of such an audit will just force the targeted business to shut down, so the business need to be large enough to make sense.
Until then, the DPAs are the only viable option that exist.
I think if you take a step back here and look at what you might be asking of Cloudflare becomes very difficult (if not impossible) to implement. Their whole system of routing traffic is based on anycast. Anyone could be routed to any data centre in the world, there is no guarantee youāll be routed to a data centre in-country and itās not something Cloudflare have total control over. So any implementation has to be global.
(note Iām in Australia and get routed out of country for some Cloudflare traffic even though Cloudflare has several local data centres, it actually depends on your ISP and believe it or not whether I use IPv4 or IPv6).
The origin country is already known, and you can already write workers that take a country code of the original request (if available) and do whatever you like with it.
I understand routing is going to go everywhere. This is a question focused on where persistent storage, at-rest happens - which is what Durable Objects offers.
This crossed my mind as well, but Origin Country, as detected by Cloudflare, doesnāt dictate which data center to use. As simon pointed out, heās in Australia, but sometimes is routed out of country. This happens more for some people than others.
I still stand by my original response. You canāt control where Durable Objects are stored unless Cloudflare adds this feature.
This happened to me too. Sometimes my traffic will be routed to Hong Kong or Japan, when the status of my nearest data center (Kuala Lumpur) is stated as āRe-routedā in cloudflarestatus.com
Noted - but there is a HUGE thing I want to clarify here.
We operate a SaaS app for identified users i.e. people using our API already present a bearer token - we know exactly who they are, and where they said they want to store their data.
Therefore, programmatically - all I need is the ability to guarantee object creation in a given country, and auto-migration needs to stay within that country too.
The request itself is irrelevant, as our Worker processes calls from authenticated, known users with known preferences - not anonymous traffic (where IP-based decisions are unreliable).
Iām the PM for Durable Objects - I can say this is definitely an interesting idea. Stay tuned to the blog in the next few weeks! Mind reaching out to gmckeon@cloudflare so I can chat with you a bit more about your use case?