This document explains when data residency is enforced in each location where Model Armor is available. Data residency lets you specify a geographic region where your data is stored and processed, which helps ensure that your data remains in that location. Model Armor helps provide control over where your data is handled, supporting compliance with various regulations.
Model Armor processes the following types of data:
Core data: The primary data that Model Armor processes, most relevant to data residency, which includes prompts, responses, and input files. Model Armor processes core data but doesn't store it at rest. For more information, see Data handling and storage.
Configuration data: Template and floor setting configurations such as rules, filters, and thresholds that Model Armor uses to scan prompts and responses. Model Armor processes and stores configuration data at rest.
How and when data residency is enforced
When you enable data residency for Model Armor, it helps ensure that data remains within a specified location while in at least one of the following states:
At rest: Data is at rest when it is committed to persistent storage.
In use: Data is in use when it is in memory.
In transit: Data is in transit when the data is entering or exiting Google's network perimeter—for example, at the Google Front End (GFE)—and is encrypted with Transport Layer Security (TLS).
The following table indicates when data residency controls are enforced for each region and multi-region.
| Region/multi-region | At rest | In use | In transit |
|---|---|---|---|
asia-northeast1 |
Yes | No | No |
asia-northeast3 |
Yes | No | No |
asia-south1 |
Yes | No | No |
asia-southeast1 |
Yes | No | No |
australia-southeast2 |
Yes | No | No |
eu |
Yes | Yes | Yes |
europe-southwest1 |
Yes | No | No |
europe-west1 |
Yes | Yes | Yes |
europe-west2 |
Yes | No | No |
europe-west3 |
Yes | Yes | Yes |
europe-west4 |
Yes | Yes | Yes |
europe-west9 |
Yes | Yes | Yes |
northamerica-northeast2 |
Yes | No | No |
us |
Yes | Yes | Yes |
us-central1 |
Yes | Yes | Yes |
us-east1 |
Yes | Yes | Yes |
us-east4 |
Yes | Yes | Yes |
us-west1 |
Yes | Yes | Yes |
Regional endpoints
Regional endpoints provide access to resources in a specific location. When you use a regional endpoint, your request is routed directly to the endpoint's location. You can't use a regional endpoint to access resources in other locations.
Using a regional endpoint helps you enforce data residency controls for your resources when they're at rest, in use, and in transit. Each regional endpoint uses the following format:
modelarmor.LOCATION.rep.googleapis.com
Replace LOCATION with a supported location. For
supported locations, see Locations.
To access Model Armor regional endpoints from within a VPC network, you must create a Private Service Connect endpoint to the Model Armor APIs. This is required to prevent certificate errors when regional endpoints are accessed using Private Google Access or VPC Service Controls. For more information, see Troubleshoot Model Armor issues and About accessing regional endpoints through Private Service Connect endpoints.
Impact of data residency on MCP traffic
Jurisdiction defines the geographic region and legal boundary where your data is processed and stored. This is critical for data residency—ensuring data stays within a chosen location to meet regulatory compliance. Model Armor is a regionalized service, but it's not available in every Google Cloud region where Google and Google Cloud MCP servers-supported services operate. If you enable Model Armor for an MCP-supported service in a jurisdiction where Model Armor isn't present, your data might be sent to a Model Armor endpoint in a different jurisdiction for security screening. These cross-jurisdiction calls might impact data residency requirements for the MCP-supported service. For information about how cross-jurisdiction calls impact data residency for the specific services you use, refer to the documentation for each MCP-supported service.