[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-05 (世界標準時間)。"],[[["\u003cp\u003eData residency refers to the physical location of data and the local regulations governing its storage, encryption, and access.\u003c/p\u003e\n"],["\u003cp\u003eAlloyDB for PostgreSQL allows you to specify the location of your data, helping you meet data residency requirements by constraining which locations are available.\u003c/p\u003e\n"],["\u003cp\u003eYou can select specific regions for data storage when creating AlloyDB clusters, ensuring your data is stored at rest only within those designated areas.\u003c/p\u003e\n"],["\u003cp\u003eOrganizational policy constraints can be used to enforce data residency requirements at the organization, project, or folder level, limiting where users can create AlloyDB resources.\u003c/p\u003e\n"],["\u003cp\u003eThe Cloud Asset Inventory (CAI) service can help you view and monitor the locations of resources across different services, including AlloyDB, for compliance with data residency requirements.\u003c/p\u003e\n"]]],[],null,["# Enforce data residency requirements\n\nThis page explains how to configure AlloyDB for PostgreSQL to enforce data residency\nrequirements.\n\nOverview of data residency\n--------------------------\n\n*Data residency* refers to the physical location of data, and the local\nregulations that govern how you store, encrypt, and access that data. As\ncountries' data protections and privacy regulations evolve, it's increasingly\nimportant that you understand how to follow local data residency requirements\nand protect your users' data.\n\nIn a traditional on-premises environment, you configure various components to\nhandle data residency. For example, a company can host a tokenization gateway as\na cloud access security broker (CASB) to secure application data before it's\ntransmitted overseas.\n\nBecause a cloud computing service stores your data off-premises, cloud computing\nintroduces its own data residency issues and questions. These include the\nfollowing:\n\n- 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.\n- 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.\n- 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.\n\nData residency for AlloyDB\n--------------------------\n\nData residency involves storing personally identifiable information (PII) or\nother sensitive information within a particular region, in a way that meets that\nregion's laws and regulations.\n\nTo store data, you must meet a country's legal and regulatory demands, such as\ndata locality laws. For example, a country might mandate that any\ngovernment-related data be stored in that country. Or, a company might be\ncontractually obligated to store data for some of their customers in a different\ncountry. Therefore, a company has to meet the data residency requirements of the\ncountry where the data is stored.\n\nYou can use the [Cloud Asset Inventory (CAI)](/asset-inventory) service to view\nand monitor the locations of resources across [services supported by\nit](/asset-inventory/docs/supported-asset-types), which includes\nAlloyDB.\n\nAlloyDB helps you with your data residency requirements by\nletting you specify the location of your data, and constrain which locations\nthat AlloyDB makes available.\n\n### Location selection\n\nWith Google Cloud, you choose where your data is stored. This includes letting\nyou choose the [regions](/alloydb/docs/locations) where you store your data.\nWhen you configure AlloyDB resources in these regions, Google\nstores your data at rest only in these regions, according to our [Service\nSpecific Terms](/terms/service-terms). You can select the region when you create\nyour cluster. Any instances and backups created against a cluster is stored in\nthe same region as the cluster.\n\n### Resource locations constraint\n\nYou can use organizational policy constraints to enforce data residency\nrequirements at the organization, project, or folder level. These constraints\nlet you define the Google Cloud locations where users can create resources for\nsupported services. For data residency, you can use the [resource locations\nconstraint](/resource-manager/docs/organization-policy/defining-locations) to\nlimit the physical location of new [supported AlloyDB\nresources](/resource-manager/docs/organization-policy/defining-locations-supported-services#AlloyDB).\nYou can also fine-tune policies for a constraint to specify regions, such as\n`us-east1` or `europe-west1`, as allowed or denied locations. Existing location\nviolations can be [discovered using Security Health\nAnalytics](/resource-manager/docs/organization-policy/defining-locations#vulnerability_findings_and_remediation)\nand then remediated.\n\nWhat's next\n-----------\n\n- For more information about Google Cloud data location commitments, see the\n Google Cloud [Service Specific Terms](/terms/service-terms).\n\n- To learn more about data residency in Google Cloud, see [Understanding your\n options for data residency, operational transparency, and privacy controls\n on\n Google Cloud](/blog/products/identity-security/meet-data-residency-requirements-with-google-cloud).\n\n- To learn more about how Google Cloud protects customer data throughout its\n lifecycle, and how Google Cloud provides customers with transparency and\n control over their data, see [Trusting your data with\n Google Cloud](https://services.google.com/fh/files/misc/072022_google_cloud_trust_whitepaper.pdf).\n\n- Learn about best practices for [data residency](/architecture/framework/security/meet-regulatory-compliance-and-privacy-needs#control_data_residency)\n and [data sovereignty](/architecture/framework/security/meet-regulatory-compliance-and-privacy-needs#recommendations_to_manage_your_data_sovereignty)."]]
