Know where cloud AI services process your prompts

Processing, storage and logging are separate questions

On all three clouds, the setting that decides where a prompt is processed is chosen per call or per deployment, and it can change without touching anything about storage. In Amazon Bedrock it is the model identifier you send: a foundation model ID, a geographic inference profile such as one starting eu. or us., or a global. profile. ^[1] In Microsoft Foundry it is the deployment type, recorded on each deployment as a SKU name such as Standard, DataZoneStandard or GlobalStandard. ^[7] In Google's Gemini Enterprise Agent Platform, the product formerly called Vertex AI, it is the endpoint hostname and location in the request: a regional endpoint, the us or eu multi-region, or the global endpoint. ^[11][13]

Each provider states its at-rest promise separately from its processing promise, and the at-rest promise does not widen when you pick a broader processing scope. Microsoft says data stored at rest remains in the designated Azure geography for every deployment type, while Global types may process inferencing data in any Azure region. ^[7] Google says data at rest stays in the customer-selected location independent of the endpoint called, and that the global endpoint gives no data residency guarantee. ^[12] AWS says that with a geographic profile your data remains stored only in the source Region by default, but prompts and outputs might move outside it during inference. ^[2] A storage commitment therefore tells a reviewer nothing about where the model ran.

The third question is copies. Retained abuse monitoring data, optional request logs, caches and stateful API features each carry their own location rule, and the rules differ in ways a residency review has to capture. Bedrock stores retained abuse detection data in the destination Region that processed the request. ^[5] Microsoft keeps its abuse monitoring store in the geography of the Foundry resource, even for Global and Data Zone deployments. ^[8] Google stores flagged prompt logs in the region or multi-region selected for the project. ^[14]

A review that asks only where data is stored will get a reassuring answer from every provider. Ask three things instead: where inference can run for this exact model and option, where anything persists, and which logs or retained copies exist and where they live. The sections below answer those for each cloud as documented on October 7, 2026. Network path is a fourth, separate matter: a private endpoint changes how traffic reaches the service, not which region processes the request.

Source. Conceptual diagram based on AWS cross-Region inference, Microsoft Foundry deployment types and Google data residency documentation. ^{[1][5][7][8][12][14]}

Method. Conceptual architecture that generalizes three providers; provider-specific rules are in the comparison matrix and section text.

Accessible table and figure data

Figure 1 accessible table

Component	Role	Location rule
Application	Sends the prompt	Your choice
Home endpoint	Source Region, resource or project location	Fixed by your configuration
Data at rest	Files, stored features, tuned models	Home location or geography
Customer logs	CloudTrail, invocation logs, request logs	Where you configure them; source Region on Bedrock
Routing scope	Profile ID, deployment SKU or endpoint	Decides where inference runs
Processing in a boundary	One region, zone or jurisdiction	Scoped options
Processing anywhere	Any supported region worldwide	Global options
Provider retained copy	Abuse monitoring data	Varies by provider

Figure 1 accessible table

Component	Role	Location rule
Application	Sends the prompt	Your choice
Home endpoint	Source Region, resource or project location	Fixed by your configuration
Data at rest	Files, stored features, tuned models	Home location or geography
Customer logs	CloudTrail, invocation logs, request logs	Where you configure them; source Region on Bedrock
Routing scope	Profile ID, deployment SKU or endpoint	Decides where inference runs
Processing in a boundary	One region, zone or jurisdiction	Scoped options
Processing anywhere	Any supported region worldwide	Global options
Provider retained copy	Abuse monitoring data	Varies by provider

Download imageDownload table CSV

Amazon Bedrock inference profiles

Bedrock offers three processing scopes for on-demand inference. AWS describes cross-Region routing only through inference profiles, which define a model and the Regions a request can be sent to, which implies that a call naming a foundation model in one Region, without a multi-Region profile, is processed in that Region. ^[1][4] A geographic profile keeps requests inside a geography such as the US, EU or APAC; AWS gives the example that a request made within the US is kept within US Regions. ^[2] A global profile can send the request to any supported commercial AWS Region, and AWS prices it at roughly 10 percent below the geographic profile for the same model. ^[1][3] Not every model offers every scope in every Region: each model card's Regional availability table shows whether In-Region, geographic and Global options exist for a given Region. ^[4]

The storage wording is precise and worth quoting in a review. For geographic profiles AWS says data remains stored only in the source Region by default, while input prompts and output results might move outside the source Region during cross-Region inference. ^[2] The exception is abuse detection. Bedrock describes itself as zero data retention by default, but for a named list of models, currently including several OpenAI GPT models and Anthropic's Claude Fable 5 and 5.1, it may retain flagged or all traffic for up to 30 days, and with cross-Region inference those retained inputs and outputs are stored in the destination Region. ^[5] Profiles can also include opt-in Regions your account never enabled, and AWS notes that prompts and outputs may be stored there for abuse detection. ^[4]

Two details change how a profile should be verified. Destination Regions depend on the source Region you call from: AWS's example us. profile routes to three Regions when called from US East (Ohio) and two when called from US West (Oregon). ^[4] AWS also states that a geography-tied profile's destination list will never change, whereas a global profile gains Regions as AWS adds them. ^[4] For data residency requirements, AWS's instruction is to call GetInferenceProfile from every source Region you plan to use, read the destination Regions from the model ARNs in the models field, and not rely on the prefix in the profile ID. ^[4]

Customer-side records stay at home. CloudTrail logs every cross-Region inference request in the source Region, and the additionalEventData.inferenceRegion field identifies where it was processed. ^[1] Model invocation logging is off by default; once enabled it writes full request and response bodies to CloudWatch Logs or S3 destinations that must be in the same account and Region, with bodies over 100 KB and binary data going to S3. ^[6] For global profiles, CloudWatch and CloudTrail entries are also recorded in the source Region. ^[3] Invocation logging only captures calls through the bedrock-runtime endpoint; the same APIs on bedrock-mantle are not currently captured. ^[6]

Region-deny service control policies interact with profiles in ways that catch teams out. A geographic profile fails if any of its destination Regions is blocked, unless the SCP carries an exception keyed on the bedrock:InferenceProfileArn condition key. ^[2] Global profiles are authorized against a Region-agnostic foundation model ARN for which aws:RequestedRegion is unspecified, so a Region allowlist without that value blocks them, and an explicit deny on it combined with a global.* profile ARN turns global routing off. ^[3] The fragment below follows AWS's documented SCP for organizations that must not use global routing.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyBedrockGlobalCrossRegionInference",
      "Effect": "Deny",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "unspecified"
        },
        "ArnLike": {
          "bedrock:InferenceProfileArn": "arn:aws:bedrock:*:*:inference-profile/global.*"
        }
      }
    }
  ]
}

Microsoft Foundry deployment types

Azure OpenAI models now sit inside Microsoft Foundry, which groups them with other Foundry Models sold by Azure, and the deployment types apply to the Serverless API deployment option; models running on managed compute do not use them. ^[7][8] Global types may process prompts in any Azure region. Data Zone types process only within a Microsoft-defined US, EU or Asia Pacific zone. Standard and Regional Provisioned process within the customer-specified Azure geography and might move between regions inside it for operational purposes. ^[7] Microsoft recommends starting with Global Standard, which gets new models first at the lowest price, and says new deployment types arrive in the order Global, Data Zone, then geography-based, with no guaranteed date for the last. ^[7]

Storage stays with the resource whatever the type. For Global and DataZone types, Microsoft says any data stored at rest, including uploaded data and the abuse monitoring data store, sits in the customer-designated geography, and only the location of processing changes. ^[8] Features that persist content, such as the Responses API, Assistants threads, stored completions and files uploaded for batch, store it in the Foundry resource within the same geography. ^[8] Global Batch shows the split clearly: input waits at rest in the designated geography until capacity is available, then processing may happen in any geography where the model is deployed. ^[8]

Abuse monitoring changes who can see content, not where it is kept. Flagged samples are reviewed by automated means, including LLMs, and by authorized Microsoft employees when needed; for models deployed in the European Economic Area those employees are located in the EEA. ^[8] Customers who meet Limited Access criteria can apply for modified abuse monitoring, which stops storage for human review, and an approved resource shows a ContentLogging capability set to false in its JSON view or in az cognitiveservices account show output. ^[8]

The EU zone needs a careful read. The deployment types page says the EU Data Zone follows the EU Data Boundary, which can include EFTA countries such as Norway and Switzerland, and that Microsoft can add regions to a data zone without prior notice. ^[7] The data privacy page describes an EU DataZone deployment as processing in that or any other EU Member Nation. ^[8] If an obligation names EU member states specifically, raise the difference with Microsoft and record its answer before relying on the zone.

Three options sit outside that scheme. DeveloperTier, meant for evaluating fine-tuned models for 24 hours, carries no data residency guarantee. ^[7] Claude models are sold and operated by Anthropic even inside Foundry: the Hosted on Azure option keeps data at rest in the selected geography and supports Global Standard and Data Zone Standard (US), while the Hosted on Anthropic infrastructure option may process data outside Azure and outside the selected region and offers Global Standard only. ^[9] Instant access, a preview that lets a West US 3 project call a model by name without a deployment, draws on a global quota pool, and Microsoft directs workloads that need data residency to create a deployment instead. ^[10]

Because the deployment type is a property of a resource, Azure Policy can enforce it when deployments are created. Microsoft documents a rule on the Microsoft.CognitiveServices/accounts/deployments/sku.name field; the example below inverts it into an allowlist so that any type not explicitly approved is denied. ^[7]

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.CognitiveServices/accounts/deployments"
        },
        {
          "field": "Microsoft.CognitiveServices/accounts/deployments/sku.name",
          "notIn": [
            "DataZoneStandard",
            "DataZoneProvisionedManaged",
            "DataZoneBatch",
            "Standard",
            "ProvisionedManaged"
          ]
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  }
}

Gemini Enterprise Agent Platform endpoints

Google renamed Vertex AI to Gemini Enterprise Agent Platform, and its documentation now uses that name, but requests still go to aiplatform hostnames. ^[11][13] Three endpoint families decide the ML processing location. Regional endpoints, which Google also calls locational, such as https://europe-west1-aiplatform.googleapis.com, keep ML processing within the broader multi-regional or country jurisdiction of that region, so a request to us-central1 is processed in the United States. ^[12] Multi-region endpoints at https://aiplatform.us.rep.googleapis.com and https://aiplatform.eu.rep.googleapis.com keep processing inside the US or the EU. ^[13] The global endpoint, https://aiplatform.googleapis.com with location global, may process a request in any Google Cloud location and provides no data residency guarantee. ^[12][13]

Google's EU boundary is narrower than Microsoft's. The eu multi-region covers EU member states only and excludes the United Kingdom and Switzerland. ^[12] Inside Europe, in-country processing depends on the model: Google says some models process locally in France or Germany while others are processed within the broader EU boundary, and it publishes per-model tables showing which locations carry an ML processing commitment. ^[12] The endpoints page adds that endpoints by themselves don't guarantee data residency or in-region ML processing, which is why the per-model table, not the hostname, is the document a review should cite. ^[13]

Counting the rows in Google's first-party model table shows how uneven that coverage is. Of 27 model entries listed on October 7, 2026, 26 carry both the US and EU multi-region commitments, yet no single country location covers more than 8, and Brazil, the Netherlands and South Korea cover one each. ^[12] A requirement for processing inside one specific country therefore narrows the model choice sharply, and it belongs at the start of model selection rather than at deployment.

Retained copies follow the project's location. When classifiers flag suspicious activity, Google may log prompts for up to 90 days in the region or multi-region selected for the project; these logs are not encrypted with customer-managed keys, and customers on a Google Cloud Master Agreement are exempt from this logging by default. ^[14] Models designated Advanced AI, including all versions of Claude Fable and Claude Mythos, have every prompt and response logged for up to 30 days in that same region or multi-region. ^[14] Gemini models also cache inputs and outputs in memory with a 24-hour TTL that Google says respects the selected location's residency, and caching can be turned off per project. Request-response logging to BigQuery is off unless you enable it per model and project. ^[15]

Grounding is where the documentation goes quiet about location. With Grounding with Google Search, Google stores logs of queries derived from prompts for up to three days for debugging, and that storage cannot be disabled; Grounding with Google Maps stores prompts, context and output for 30 days. ^[15] Neither entry says where those logs are kept. Until Google states a location for them in writing, a residency review should treat grounded requests as outside the boundary.

The global endpoint can be blocked with an organization policy. The constraints/gcp.restrictEndpointUsage list constraint is a denylist of API hostnames that applies at runtime to every resource in scope, and Generative AI on Gemini Enterprise Agent Platform is a supported service whose global endpoint is aiplatform.googleapis.com. ^[16] Google tells customers with DoD IL5 obligations to use this kind of policy to block global endpoint traffic for models not listed for the US multi-region. ^[12]

constraint: constraints/gcp.restrictEndpointUsage
listPolicy:
  deniedValues:
  - aiplatform.googleapis.com

Source. Calculated from the Google models table on Google's Gemini Enterprise Agent Platform data residency page, reviewed October 7, 2026. ^[12]

Method. Count of the 27 rows in the Google models table marked Supported in each location column. Rows include tuning, embedding and speech entries. Partner and open model tables are excluded.

Accessible table and figure data

Figure 2 accessible table

Location	Model entries
US multi-region	26
EU multi-region	26
Japan	8
Canada	7
Singapore	7
United Kingdom	4
France	3
Australia	3
India	3
Germany	2
Brazil	1
Netherlands	1
South Korea	1

Figure 2 accessible table

Location	Model entries
US multi-region	26
EU multi-region	26
Japan	8
Canada	7
Singapore	7
United Kingdom	4
France	3
Australia	3
India	3
Germany	2
Brazil	1
Netherlands	1
South Korea	1

Download imageDownload table CSV

Comparing the options

Side by side, the three clouds offer the same three tiers: one place, a provider-defined group of places, and anywhere. The differences sit in the fine print of each tier, and those are what an assessment should record.

Boundaries differ in how stable they are. AWS commits that a geography-tied profile's destination list never changes and creates new profiles when it adds Regions. ^[4] Microsoft reserves the right to add regions to a data zone without notice. ^[7] Google's per-model commitments live in a table that changes as models are added; the page was updated on the day this guide was reviewed. ^[12] A review record should name the page it relied on and the date it was read.

The EU is not one definition. Google excludes the UK and Switzerland from eu. Microsoft's EU zone follows the EU Data Boundary, which can include EFTA countries. AWS does not define the geography in prose so much as publish it: the destination Regions for each profile and source Region, which is the most checkable of the three forms. ^[12][7][4]

Retained copies land in different places. On Bedrock, a retained abuse detection copy is stored in whichever Region processed the request, so a global profile can leave a copy in any supported commercial Region for models that require retention. ^[5][3] Microsoft keeps the abuse monitoring store in the resource's geography regardless of deployment type. ^[8] Google keeps abuse logs in the project's selected region or multi-region. ^[14]

Per-request evidence differs as well. AWS records the processing Region of each cross-Region request in CloudTrail's additionalEventData.inferenceRegion. ^[1] The Microsoft and Google pages cited here describe processing scope as a property of the deployment type or endpoint and document no equivalent per-request field, so the evidence on those clouds is configuration evidence: the SKU on every deployment and the hostnames your code and policies allow. ^[7][13]

Source. Compiled from AWS, Microsoft and Google documentation reviewed October 7, 2026. ^{[2][3][4][5][7][8][12][13][14]}

Method. Source-derived summary of stated commitments. Retained copies apply only where a model or policy requires retention. Cells paraphrase the cited pages.

Accessible table and figure data

Figure 3 accessible table

Option	Where inference can run	Data at rest	Retained safety copies
Bedrock model in one Region	That Region	Source Region	That Region
Bedrock geographic profile	Destination Regions in the profile	Source Region by default	Destination Region
Bedrock global profile	Any supported commercial Region	Logs in source Region	Destination Region
Foundry Standard or Regional Provisioned	Resource's Azure geography	Resource geography	Resource geography
Foundry Data Zone types	US, EU or APAC data zone	Resource geography	Resource geography
Foundry Global types	Any Azure region with the model	Resource geography	Resource geography
Agent Platform regional endpoint	Region's jurisdiction; in-country varies by model	Selected location	Project region or multi-region
Agent Platform us or eu endpoint	Inside the US or the EU	Selected location	Project region or multi-region
Agent Platform global endpoint	Any Google Cloud location	Selected location	Project region or multi-region

Figure 3 accessible table

Option	Where inference can run	Data at rest	Retained safety copies
Bedrock model in one Region	That Region	Source Region	That Region
Bedrock geographic profile	Destination Regions in the profile	Source Region by default	Destination Region
Bedrock global profile	Any supported commercial Region	Logs in source Region	Destination Region
Foundry Standard or Regional Provisioned	Resource's Azure geography	Resource geography	Resource geography
Foundry Data Zone types	US, EU or APAC data zone	Resource geography	Resource geography
Foundry Global types	Any Azure region with the model	Resource geography	Resource geography
Agent Platform regional endpoint	Region's jurisdiction; in-country varies by model	Selected location	Project region or multi-region
Agent Platform us or eu endpoint	Inside the US or the EU	Selected location	Project region or multi-region
Agent Platform global endpoint	Any Google Cloud location	Selected location	Project region or multi-region

Download imageDownload table CSV

Choosing a configuration and proving it

Work from the obligation to the configuration. Write the boundary down as the contract or regulation states it, whether a country, the EU or a named list of regions, then choose the model, then the option, then the preventive control, then the evidence. Model choice comes before deployment choice because scoped options can arrive later than global ones, or not at all, for a given model. ^[7][12]

Take a hypothetical EU team that wants a current Claude model with processing inside the EU. On Bedrock it would choose an eu. profile and confirm the destination Regions with GetInferenceProfile from each source Region it calls. ^[4] On Agent Platform, Claude Opus 5.5 is listed with an EU multi-region commitment, so the team would call the eu endpoint and deny the global one. ^[12][16] On Microsoft Foundry the same requirement fails as of the review date: Claude Hosted on Azure offers Data Zone Standard only for the US, and the Anthropic-hosted option may process outside Azure. ^[9] The model, not each cloud's general residency story, decided the outcome.

Keep the evidence next to the decision so the next reviewer does not have to rebuild it.

• Bedrock: profile IDs in code, GetInferenceProfile output for each source Region, the SCP text, and a CloudTrail sample showing inferenceRegion. ^[1][4]
• Foundry: an export of every deployment with its SKU name, the Azure Policy assignment, and the hosting option for any Claude deployment. ^[7][9]
• Agent Platform: the hostnames and locations in code, the gcp.restrictEndpointUsage policy, and a dated copy of the data residency table row for each model used. ^[12][16]
• All three: the retention and abuse monitoring terms for each model, any exemption granted, and the location of every log your own team writes. ^[5][8][14]

Source. Conceptual decision aid based on AWS, Microsoft and Google residency documentation. ^{[3][4][7][12][16]}

Method. Conceptual ordering of documented options. It does not replace legal review of the obligation itself.

Accessible table and figure data

Figure 4 accessible table

Question	Yes	No
Does a contract or law limit where prompts may be processed?	Write the boundary as stated, then continue	Global options are acceptable; still review retention
Is the boundary a single country?	Use a single-region option the model lists there	Ask whether it is a provider zone
Is it the US, the EU or another provider-defined zone?	Use a geographic profile, Data Zone type or multi-region endpoint	Use single-region options inside the boundary
Does the model you need offer that option?	Deploy it and record the source page and date	Choose another model or provider
Can policy block global options for this workload?	Apply the SCP, Azure Policy or endpoint constraint	Move the workload to an account or project where it can

Figure 4 accessible table

Question	Yes	No
Does a contract or law limit where prompts may be processed?	Write the boundary as stated, then continue	Global options are acceptable; still review retention
Is the boundary a single country?	Use a single-region option the model lists there	Ask whether it is a provider zone
Is it the US, the EU or another provider-defined zone?	Use a geographic profile, Data Zone type or multi-region endpoint	Use single-region options inside the boundary
Does the model you need offer that option?	Deploy it and record the source page and date	Choose another model or provider
Can policy block global options for this workload?	Apply the SCP, Azure Policy or endpoint constraint	Move the workload to an account or project where it can

Download imageDownload table CSV