Vertex AI in the Tokyo Region: Seven Models You Can Call, Eight That Are Processed in Japan

Hello, this is Ryuta Hamamoto from TIMEWELL.

Last week I published a comparison of what the major cloud providers write in their own documentation about running an LLM inside Japan. The line that drew the most response was Google Cloud's, the one saying that endpoints guarantee neither data residency nor in-region ML processing. Several readers came back with the same follow-up. If that is true, what is the point of naming the Tokyo region at all?

Fair question, and I did not have a tidy answer. So this time I narrowed the scope to Google Cloud alone and went back to the primary documentation to settle two things. What can you actually call in Tokyo (asia-northeast1), and how far is processing inside Japan actually committed to?

The short version is that those two things do not match. The list of models you can call from the Tokyo endpoint and the list of models whose ML processing is committed to Japan sit on different pages, in different tables, and their contents diverge. Read only the first one, then tell your organisation "we are on Tokyo, so it is processed in Japan", and that sentence comes apart the first time an auditor or a client's vendor review team pulls on it. Below is the exact shape of the gap.

Everything here reflects official documentation retrieved on 6 September 2026. Model availability moves, so check the current version before you decide anything. If you would rather start by getting a read on where your own organisation stands, we have a free AI readiness check.

Only seven models answer at the Tokyo endpoint

One thing before the tables. If you went looking for this documentation recently and got lost, the product has been renamed. The old path /vertex-ai/generative-ai/docs/learn/locations now returns an HTTP 301 to /gemini-enterprise-agent-platform/resources/locations, and the page you land on is titled "Deployments and endpoints". The rename table lists "Vertex AI Platform" becoming "Gemini Enterprise Agent Platform", "Generative AI on Vertex AI" becoming "Generative AI on Gemini Enterprise Agent Platform", and "Vertex AI API" becoming "Gemini Enterprise Agent Platform API"¹. If your internal standards or architecture diagrams still carry the old names, you will be reading them against that table for a while. Worth doing the substitution once, deliberately, rather than every time someone opens the wiki.

Now the Asia Pacific table on that locations page. Seven columns: Mumbai (asia-south1), Singapore (asia-southeast1), Hong Kong (asia-east2), Taiwan (asia-east1), Tokyo (asia-northeast1), Sydney (australia-southeast1) and Seoul (asia-northeast3). There are 37 rows for Google models, and seven of them carry a mark in the Tokyo column².

Model marked for Tokyo	Kind
Gemini 3.5 Flash	Gemini text
Gemini 2.5 Pro	Gemini text
Gemini 2.5 Flash	Gemini text
Virtual Try-On	Image utility
gemini-embedding-001	Embeddings
Embeddings for Text	Embeddings
Embeddings for Multimodal	Embeddings

Three Gemini text models, three embedding rows, one image utility. That is the whole menu.

Turn it over and the other 30 rows are not offered in Tokyo³. The newer Gemini line is absent: 3.8 Flash, 3.7 Flash, 3.6 Flash, 3.5 Flash-Lite, 3.1 Flash-Lite, the 3.1 Pro preview, the 3 Flash preview and the Omni models. So is image generation, meaning 3 Pro Image, 3.1 Flash Image, 3.1 Flash-Lite Image and 2.5 Flash Image. Also 2.5 Flash-Lite and the Live API native audio. Every Veo 3 video row. Chirp 2 and Chirp 3 for speech recognition, and every TTS row. Gemini Embedding 2, the next generation of embeddings, is not there either.

Something worth noticing before anyone reaches for a conclusion: this is not a Tokyo story. Gemini 3.8 Flash is blank across all seven Asia Pacific regions. So are the five Veo 3 rows and the three TTS rows. The four Chirp 2 and Chirp 3 rows carry a mark in Singapore and nowhere else in the region. The pattern is not that Tokyo has been passed over. It is that newer models are being run from a smaller number of places.

That reads to me as a supply decision rather than a slight. GPU capacity is constrained and demand density differs by region. Running a frontier model from a few concentrated sites is more stable and faster to ship than spreading it thinly across every region on the map. As a provider call it makes sense, and part of why new models arrive as quickly as they do is precisely that concentration. From the customer's chair, though, the constraint is still there: name Tokyo and your menu drops to seven. Treating that as structural rather than as someone's negligence makes it much easier to plan around.

There is a practical consequence that catches teams late. If your group has standardised on a model family and your Japanese entity is expected to follow, the standardisation itself may be what puts you outside the Tokyo menu. That conversation is easier to have in month one of a project than in month six, when the architecture is already drawn.

The eight entries committed to processing in Japan sit in a different table

This is the part I most wanted to write down.

Separate from the "what can I call in Tokyo" table, there is a data residency document, and inside it a different table covering ML processing⁴. It states, for a given model in a given configuration, which jurisdiction the ML processing is committed to happen within. Thirteen columns including the US and EU multi-regions, 27 rows. One of those columns is Japan (asia-northeast1).

Eight entries carry a mark in the Japan column⁵.

Entry marked for Japan	Configuration as listed
Gemini 3.5 Flash
Gemini 2.5 Flash	128k context
Gemini 2.5 Pro	64k context
Chirp 3	Transcription
Chirp 3	HD Voices
Chirp 3	Instant Custom Voice
Embeddings for Text	text-embedding-004
Embeddings for Text	text-multilingual-embedding-002

Hold that against the seven models from the previous section. Different count, different contents.

The line is drawn at context length, not around the model

First thing that catches the eye is that the boundary runs through models rather than around them.

Model and configuration	Japan (asia-northeast1)
Gemini 2.5 Flash, 128k context	marked
Gemini 2.5 Flash, 1M context	not marked (US, EU, Brazil and Singapore only)
Gemini 2.5 Pro, 64k context	marked
Gemini 2.5 Pro, 1M context	not marked (US, EU and Brazil only)

That lands directly on implementation. Same model ID, same call, and the moment you switch to the long-context configuration you may fall outside the commitment that processing happens in Japan. Throwing an entire internal document set into one request is a natural performance choice, and often the right one. From a residency standpoint it is a separate decision that has to be made separately. Choosing the model does not finish the check. The context configuration has to be matched against the table too.

I find this detail useful rather than annoying, for what it is worth. A commitment stated at the level of a specific context configuration is a commitment someone has actually thought about. A vaguer promise would be easier to read and much harder to rely on.

Where exactly the two tables disagree

Put the two side by side and three groups fall out.

Group	Entries	Callable in Tokyo	Japan ML processing
Both	Gemini 3.5 Flash, Gemini 2.5 Flash (128k), Gemini 2.5 Pro (64k), text-embedding-004, text-multilingual-embedding-002	yes	yes
Callable only	gemini-embedding-001, Embeddings for Multimodal, Virtual Try-On	yes	no
Committed only	Chirp 3 Transcription, Chirp 3 HD Voices, Chirp 3 Instant Custom Voice	no	yes

The first group is the set you can honestly describe as finishing inside Tokyo. It is not large, and it is the only thing you can put in an internal document without a caveat.

The second group is the one that surprises people. gemini-embedding-001 and Embeddings for Multimodal carry marks only for the US and EU multi-regions in the ML processing table. Virtual Try-On does not appear in the data residency table at all, not even as a row. Embeddings are the foundation of search and RAG, and the content of internal documents passes through them intact. Having that particular step sit outside the commitment matters more to a design than it first looks, because it is rarely the step anyone thinks to check. Most residency reviews I have seen focus on the chat model and stop there.

The third group runs the other way. The three Chirp 3 entries are covered by the Japan commitment, but the Asia Pacific locations table gives them no mark in Tokyo, where Singapore is the only Asia Pacific region marked. Committed, and not callable from the Tokyo endpoint. Two tables maintained for two different purposes will do that.

Storage is simpler. The document says that data stored at rest in the customer selected location remains at rest in that location, independent of the Agent Platform endpoint called by that customer's request. Elsewhere it explains that stored artefacts such as custom model weights or metadata remain physically stored in the Google Cloud location you chose, and that this holds regardless of which endpoint you use to call the model⁶. Storage and processing are handled as two separate questions. Collapsing them into one is where a lot of the confusion starts.

Two ways to write an endpoint, and a note placed before the first heading

So how are the endpoints themselves distinguished? The locations document shows two forms⁷.

Regional looks like https://{LOCATION}-aiplatform.googleapis.com/v1/projects/{PROJECT}/locations/{LOCATION}/publishers/google/models/{MODEL_ID}:generateContent, which for Tokyo means the host asia-northeast1-aiplatform.googleapis.com. Global looks like https://aiplatform.googleapis.com/v1/projects/{PROJECT}/locations/global/publishers/google/models/{MODEL_ID}:generateContent, with no regional prefix on the host. The documentation frames it as using this in place of a service endpoint prepended with https://${GOOGLE_CLOUD_LOCATION}-aiplatform.googleapis.com.

On what the global endpoint is for⁸:

Selecting a global endpoint for your requests can improve overall availability while reducing resource exhausted (429) errors. Don't use the global endpoint if you have ML processing requirements, because you can't control or know which region your ML processing requests are sent to when a request is made.

Availability goes up and 429s go down. Anyone who has run this in production knows how much of a nuisance 429s are, so that benefit is not small. Then the second half says plainly not to use it where you have ML processing requirements, and gives the reason: you can neither control nor know which region the request goes to.

The "or know" is the part I would underline. Not being able to control where processing happens is one problem. Not being able to know is a different and worse one, because it means there is no record to produce afterwards. An audit question you cannot answer with a log is an audit question you answer with an apology.

Then a note whose placement carries meaning. Looking at the structure of the locations page, the article opens with three introductory paragraphs, and immediately after them, before the first H2, sits this⁹:

Important: Endpoints don't guarantee data residency or in-region ML processing.

Given where it sits, this is not a caveat attached to one model or one region. Straight after the introduction and before the first heading reads as a general note governing every regional table that follows. Choosing an endpoint, by itself, guarantees neither data residency nor in-region ML processing, and the note sends readers to the data residency document for detail. Skip that line, read only the tables, and the misunderstanding I opened with goes straight into an internal deck with nobody noticing.

What the global endpoint cannot do

There are functional limits as well. The same document lists three capabilities unavailable on the global endpoint: tuning, batch prediction for Anthropic and OpenMaaS models, and RAG corpus¹⁰. RAG is split carefully there, since the corpus is what you lose while RAG requests themselves are supported. Use with Provisioned Throughput is limited to fifteen models, from Gemini 3.8 Flash down to Gemini 2.5 Flash-Lite, shown in a collapsed table.

Take the availability and you give those up. Build on tuning or a RAG corpus and the global endpoint was never on your menu to begin with. Availability, features and residency pull against one another, so a three-way tension is a closer description than any pairwise trade-off.

The only jurisdiction-pinned endpoints are the US and the EU

Wanting to hold processing inside a legal jurisdiction has a purpose-built mechanism. Multi-region endpoints. The documentation describes them as letting you ensure that machine learning processing of Customer Data by the service stays within a specific jurisdictional boundary, such as the United States or the European Union¹¹.

Read against a requirements list, that is exactly the feature you want. Then look at the table of hostnames and there are two rows. United States, us, https://aiplatform.us.rep.googleapis.com. European Union, eu, https://aiplatform.eu.rep.googleapis.com. That is the whole table. The REST sample carries a note that the location must be us or eu. No Japanese jurisdiction endpoint exists, and no Asian one either.

So the furthest a user in Japan can go is the Tokyo regional endpoint. The ML processing section explains that a locational endpoint keeps processing within the broader multi-region or country jurisdiction that the region belongs to, while the global endpoint offers neither regional isolation nor a data residency guarantee⁴. The same section adds a Note that the EU multi-region does not include the United Kingdom or Switzerland, and an Important stating that models not explicitly listed as supporting US multi-regions do not meet DoD IL5 commitments. The overall shape is that locational endpoints can satisfy standard requirements such as GDPR and HIPAA, while jurisdiction endpoints are recommended for DoD IL5 and ITAR.

One more line lands squarely on network design. Private Google Access is not supported for multi-region endpoints¹². Not merely unsupported, either: the documentation says that attempting to connect that way may produce connectivity issues, SSL/TLS handshake errors or certificate mismatch warnings. Establishing private connectivity requires configuring Private Service Connect endpoints for regional Google APIs. The more a company depends on a closed network design, the more a move to jurisdiction endpoints turns into a design change rather than a configuration change. Japan has no jurisdiction endpoint, so there is no direct effect for a Japan-only footprint. Any group running globally and planning to use them from a US or EU site should check this before the architecture is signed off.

Partner models and open models have nothing in Tokyo

Everything so far has been Google's own models. Part of what makes this platform attractive is calling other companies' models from the same place. Anthropic, Mistral and xAI as partner models, plus a set of open models, all sitting under one API.

The Asia Pacific partner model table has 26 rows, made up of 16 for Anthropic Claude, 6 for Mistral and 4 for Grok. All 26 have an empty Tokyo column¹³. The marks in that table come to ten cells in total, eight rows in Singapore and two in Taiwan. Singapore covers Claude Sonnet 5, Claude Opus 5, Claude Fable 5, Claude Opus 4.6, Claude Opus 4.5, Claude Sonnet 4.6, Claude Sonnet 4.5 and Claude 3 Haiku. Taiwan covers Claude Haiku 4.5 and Claude Sonnet 4. Mistral and Grok have no marks anywhere in Asia Pacific.

Asia Pacific table	Rows	Rows marked for Tokyo
Google models	37	7
Partner models	26	0
Open models	15	0

A small correction while I am here. The open model table carries a "Deepseek models" heading row with no model rows beneath it. Rather than "listed but unavailable in Tokyo", the accurate description is that the Asia Pacific table shows no models under that heading. Minor, but exactly the kind of detail that gets miscopied when someone transcribes a table into an internal document, and the kind of error that is hard to walk back once it has been circulated.

Underneath the availability question there is a structural one. The partner model and open model tables in the data residency document have no Japan column at all⁵.

Data residency table	Japan column	Columns it does have
Google models	yes (asia-northeast1)	US and EU multi-regions among 13 columns
Partner models	no	US and EU multi-regions, Belgium, Netherlands, Singapore, Taiwan, Global
Open models	no	US and EU multi-regions, Singapore, Global

Google's own model table has a Japan column. These two do not. For Claude, Mistral, Grok and the open weights, a commitment to ML processing in Japan is not currently on offer as a structure. This is not a case of waiting for Tokyo to catch up on a rollout. The commitment framework itself is built on different lines.

That constrains model choice directly. Make domestic processing a requirement and what remains is a subset of Google's own models. Prioritise model variety and you need another way to explain where processing happens. When we design enterprise configurations on ZEROCK, settling that fork is the first thing we do, before anyone opens a model benchmark. Neither answer is wrong on its own. Deciding it late means rebuilding.

What to verify, and what to block with organisation policy

Last, how to handle this in practice.

If you want to stop people reaching the global endpoint, organisation policy gives you a lever. The constraint ID is constraints/gcp.restrictEndpointUsage¹⁴. It works as a denylist, so requests to API endpoints of any supported service that are not explicitly denied are allowed. The list of covered services includes "Generative AI on Gemini Enterprise Agent Platform", with aiplatform.googleapis.com shown as the global API endpoint and asia-northeast1-aiplatform.googleapis.com among the locational ones. Denying global while permitting only the Tokyo locational endpoint is therefore technically possible.

The same page carries a sentence you cannot afford to skip past. Organisation policies containing the Restrict Endpoint Usage constraint are not data residency commitments. On global endpoints generally, it says these endpoints do not provide any regional isolation or data residency compliance. Organisation policy stops unintended calls. It does not promise where processing happens.

That distinction bites in an audit. Offer the policy as evidence that a residency requirement is satisfied and you have handed the reviewer the thread to pull. Offer it as what it is, a control that prevents a specific class of mistake, and it holds up fine.

With that in mind, here is the order I work in.

1. Open the locations table and check whether the model you want is offered in Tokyo at all.
2. Open the ML processing table in the data residency document and check whether that model carries a Japan mark.
3. Confirm your context configuration is on the marked side of the line.
4. Read the hostname in the implementation code and confirm the SDK default is not quietly sending traffic to global.
5. Block global with organisation policy.
6. Write down the assumptions and limits that still remain, and who accepted them.

Only when steps one and two both hold can you say the work finishes in Tokyo. Reverse the order and it usually falls over. Policy goes in first, everyone relaxes, the model table gets read afterwards, and it turns out the model was never offered in Tokyo to begin with. I have watched that sequence run more than once, and it always costs more than the check would have.

The question is not "can I call it in Tokyo" but "can I call it in Tokyo, and is processing in Japan committed to". Two checks, not one. As long as those two lists do not line up, deciding on the strength of one of them will produce a mismatch somewhere. Google has not made this hard to find, either. Both facts are written down in the official documentation. It comes down to whether the reader is willing to open two tables and compare them line by line.

Personally I do not read this structure pessimistically. Publishing the scope of a commitment down to the model and the context configuration is more detail than you usually get anywhere. The problem was never missing information. It is information that exists and goes unread, while the sentence "we set it to Tokyo, so we are fine" travels through an organisation unchallenged until the day someone asks for evidence.

So: what does your requirement actually demand, and does the configuration running in production today sit inside it? Line those two up once and the next decision tends to make itself. If you want to talk through a specific setup, get in touch.

Footnotes

1. Google Cloud, "Vertex AI name changes", Gemini Enterprise Agent Platform documentation (page shows Last updated 2026-09-02 UTC). Source of "With the introduction of Gemini Enterprise Agent Platform, some Vertex AI products and features have been renamed. The following table lists the previous and new names." and the rows of the rename table. The HTTP 301 redirect from the old path /vertex-ai/generative-ai/docs/learn/locations to /gemini-enterprise-agent-platform/resources/locations was verified directly on 6 September 2026. https://docs.cloud.google.com/gemini-enterprise-agent-platform/vertex-ai-name-changes ↩

2. Google Cloud, "Deployments and endpoints", Gemini Enterprise Agent Platform documentation, Asia Pacific table (page shows Last updated 2026-09-03 UTC). The seven of 37 Google model rows carrying a mark in the Tokyo (asia-northeast1) column were established by retrieving the page HTML on 6 September 2026 and checking every row. The table headers are Mumbai (asia-south1), Singapore (asia-southeast1), Hong Kong (asia-east2), Taiwan (asia-east1), Tokyo (asia-northeast1), Sydney (australia-southeast1) and Seoul (asia-northeast3). https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#asia-pacific ↩

3. Same page, Asia Pacific table. The 30 rows with an empty Tokyo column, the fact that Gemini 3.8 Flash is empty across all seven Asia Pacific regions, that the five Veo 3 rows and three TTS rows are empty across the same seven regions, and that the four Chirp 2 and Chirp 3 rows are marked for Singapore only, were all established cell by cell from the version retrieved on 6 September 2026. https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#asia-pacific ↩

4. Google Cloud, "Data residency", Gemini Enterprise Agent Platform documentation, section "2. ML processing (in-use)" (page shows Last updated 2026-09-02 UTC). Source of "The geographic location of this processing is determined by your choice of endpoint" and the descriptions of locational and global endpoints that follow it, the Note that the EU multi-region does not include the United Kingdom or Switzerland, the Important stating "Models not explicitly listed as supporting US multi-regions don't meet DoD IL5 commitments", and the treatment of locational endpoints in relation to GDPR, HIPAA, DoD IL5 and ITAR. https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/data-residency#ml-processing ↩ ↩²

5. Same "Data residency" page, ML processing table for Google models. The eight entries marked in the Japan (asia-northeast1) column out of 27 rows and 13 columns, the difference between the 128k and 1M configurations of Gemini 2.5 Flash (1M marked for US, EU, Brazil and Singapore only), the difference between the 64k and 1M configurations of Gemini 2.5 Pro (1M marked for US, EU and Brazil only), and the absence of a Japan column from the partner model and open model tables were all established cell by cell from the version retrieved on 6 September 2026. The partner model table's columns are the US and EU multi-regions, Belgium, Netherlands, Singapore, Taiwan and Global. The open model table's columns are the US and EU multi-regions, Singapore and Global. https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/data-residency#ml-processing-google-models ↩ ↩²

6. Same "Data residency" page. Source of "Data stored at rest in the customer selected location remains at rest in that location, independent of the Agent Platform endpoint called by that customer's request." (introduction) and "When you store data on Agent Platform (such as custom model weights or metadata), it remains physically stored in the specific Google Cloud location you chose. This residency is maintained regardless of which endpoint you use to call the model." (section "1. Data-at-rest (storage)"). https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/data-residency ↩

7. Same "Deployments and endpoints" page, REST tab of the "Specify an endpoint" section. Source of the URL forms for regional and global endpoints and of the note "When using the global endpoint, use https://aiplatform.googleapis.com/v1/projects/${GOOGLE_CLOUD_PROJECT}/locations/global/publishers/google/models/${MODEL_ID}:generateContent instead of a service endpoint prepended with https://${GOOGLE_CLOUD_LOCATION}-aiplatform.googleapis.com." https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#specify_an_endpoint ↩

8. Same "Deployments and endpoints" page, "Global endpoint" section. Source of "Selecting a global endpoint for your requests can improve overall availability while reducing resource exhausted (429) errors. Don't use the global endpoint if you have ML processing requirements, because you can't control or know which region your ML processing requests are sent to when a request is made." https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#global-endpoint ↩

9. Same "Deployments and endpoints" page. The note "Important: Endpoints don't guarantee data residency or in-region ML processing. For information about data residency, see Data residency." is placed immediately after the three introductory paragraphs of the article body and before the first H2 heading, "Specify an endpoint". Its position was confirmed against the page DOM structure on 6 September 2026. https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations ↩

10. Same "Deployments and endpoints" page, "Limitations" section. Source of "The following capabilities are not available when using the global endpoint: Tuning / Batch prediction for Anthropic and OpenMaaS models / Retrieval-augmented generation (RAG) corpus (RAG requests are supported)" and of "Usage of the global endpoint with Provisioned Throughput is available only for the following models", followed by a collapsed table of fifteen models running from Gemini 3.8 Flash to Gemini 2.5 Flash-Lite. https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#limitations ↩

11. Same "Deployments and endpoints" page, "Multi-region endpoints" section. Source of "Multi-region endpoints allow you to ensure that machine learning processing of Customer Data by the service stays within a specific jurisdictional boundary, such as the United States or the European Union.", the two rows of the hostname table (United States / us / https://aiplatform.us.rep.googleapis.com and European Union / eu / https://aiplatform.eu.rep.googleapis.com), and the line in the REST sample reading GOOGLE_CLOUD_LOCATION="..." # Must be 'us' or 'eu'. https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#multi-region_endpoints ↩

12. Same "Deployments and endpoints" page, "Private connectivity to multi-region endpoints" section. Source of "Private Google Access isn't supported for multi-region endpoints. If you attempt to connect to a multi-region endpoint using Private Google Access, you might experience connectivity issues, SSL/TLS handshake errors, or certificate mismatch warnings. To establish private connectivity to multi-region endpoints, you must configure Private Service Connect endpoints for regional Google APIs." https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#multi-region_endpoints ↩

13. Same "Deployments and endpoints" page, Asia Pacific partner model and open model tables. That all 26 partner model rows (16 Anthropic Claude, 6 Mistral, 4 Grok) and all 15 open model rows have an empty Tokyo column, that the marks amount to ten cells across eight Singapore rows and two Taiwan rows, and that the "Deepseek models" entry in the open model table is a heading row with no model rows beneath it, were all established cell by cell from the version retrieved on 6 September 2026. https://docs.cloud.google.com/gemini-enterprise-agent-platform/resources/locations#genai-partner-models ↩

14. Google Cloud, "Restrict Endpoint Usage" (retrieved 6 September 2026; no update date was visible on the page). Source of the constraint ID constraints/gcp.restrictEndpointUsage, of "The Restrict Endpoint Usage constraint is set using a denylist, allowing requests to any supported services' API endpoints that are not explicitly denied.", of "Organization policies that contain the Restrict Endpoint Usage constraint are not data residency commitments.", of the inclusion of "Generative AI on Gemini Enterprise Agent Platform" among the covered services, of the listing of aiplatform.googleapis.com as a global API endpoint and asia-northeast1-aiplatform.googleapis.com among the locational API endpoints, and of the statement about global endpoints generally that "these endpoints don't provide any regional isolation or data residency compliance". https://docs.cloud.google.com/docs/security/compliance/restrict-endpoint-usage ↩