This page explains how to configure AlloyDB for PostgreSQL to enforce data residency requirements.
Overview of data residency
Data residency refers to the physical location of data, and the local regulations that govern how you store, encrypt, and access that data. As countries' data protections and privacy regulations evolve, it's increasingly important that you understand how to follow local data residency requirements and protect your users' data.
In a traditional on-premises environment, you configure various components to handle data residency. For example, a company can host a tokenization gateway as a cloud access security broker (CASB) to secure application data before it's transmitted overseas.
Because a cloud computing service stores your data off-premises, cloud computing introduces its own data residency issues and questions. These include the following:
- If a company's cloud administrators don't know the physical location of the data, then they don't know the local regulations. To research the data residency policies for each location, administrators need to know where the data centers are.
- A company's cloud administrators and providers might use service-level agreements (SLAs) that establish allowed locations, requiring restrictions on the range of regions that the cloud service can use for data storage.
- Users must ensure that their data, and all of the services and resources that they use in their cloud projects, follow the data residency regulations of the host country.
Data residency for AlloyDB
Data residency involves storing personally identifiable information (PII) or other sensitive information within a particular region, in a way that meets that region's laws and regulations.
To store data, you must meet a country's legal and regulatory demands, such as data locality laws. For example, a country might mandate that any government-related data be stored in that country. Or, a company might be contractually obligated to store data for some of their customers in a different country. Therefore, a company has to meet the data residency requirements of the country where the data is stored.
You can use the Cloud Asset Inventory (CAI) service to view and monitor the locations of resources across services supported by it, which includes AlloyDB.
AlloyDB helps you with your data residency requirements by letting you specify the location of your data, and constrain which locations that AlloyDB makes available.
Location selection
With Google Cloud, you choose where your data is stored. This includes letting you choose the regions where you store your data. When you configure AlloyDB resources in these regions, Google stores your data at rest only in these regions, according to our Service Specific Terms. You can select the region when you create your cluster. Any instances and backups created against a cluster is stored in the same region as the cluster.
Resource locations constraint
You can use organizational policy constraints to enforce data residency
requirements at the organization, project, or folder level. These constraints
let you define the Google Cloud locations where users can create resources for
supported services. For data residency, you can use the resource locations
constraint to
limit the physical location of new supported AlloyDB
resources.
You can also fine-tune policies for a constraint to specify regions, such as
us-east1
or europe-west1
, as allowed or denied locations. Existing location
violations can be discovered using Security Health
Analytics
and then remediated.
What's next
For more information about Google Cloud data location commitments, see the Google Cloud Service Specific Terms.
To learn more about data residency in Google Cloud, see Understanding your options for data residency, operational transparency, and privacy controls on Google Cloud.
To learn more about how Google Cloud protects customer data throughout its lifecycle, and how Google Cloud provides customers with transparency and control over their data, see Trusting your data with Google Cloud.
Learn best practices for implementing data residency and sovereignty requirements.