If You Pick Azure's Data Zone, How Much Actually Stays in Japan?

Hello, this is Ryuta Hamamoto from TIMEWELL.

Not long ago, an IT manager at a manufacturing company asked me to confirm something. "We selected Azure's data zone, so our data stays inside Japan. That's right, isn't it?" He had already written that sentence into an internal approval document and circulated it for signatures.

I could not say yes on the spot. Rather than answer from memory, I opened the official documentation and we read the screen together.

By the time we finished, he had decided to pull the document back. What was written there turned out to be a little different from what he had assumed.

What follows is that same set of pages, which I retrieved again on 6 September 2026 and worked through. Availability tables change within weeks, so please do not read this one without keeping the date attached to it.

Storage and processing are described as two separate things

The starting point is a Microsoft Learn page called "Deployment types for Microsoft Foundry Models". Open it and the very first thing you see is a note box that gathers the definitions of where data sits.¹ The original reads:

Data stored at rest remains in the designated Azure geography. However, inferencing data is processed as follows: Global types: May be processed in any Azure region Data Zone types: The service processes data only within the Microsoft-specified data zone (US, EU, or Asia Pacific (APAC)). Standard and Regional Provisioned types: Prompts and responses are processed within the customer-specified Azure geography and might be processed between regions within that geography for operational purposes.

The thing to notice is that the subject changes between the first sentence and the second. Sentence one is about "Data stored at rest", meaning data that is being kept. That remains in the designated Azure geography, stated flatly, with no conditions hanging off it. Sentence two switches its subject to "inferencing data", the data that flows through the service while it produces an answer, and from there the treatment splits by deployment type.

When people write internal documents in Japanese, those two normally collapse into a single word. Data. The moment they collapse, the explanation stops being accurate. Do not put the storage claim and the processing claim into the same sentence. That was the first fork in the road for us.

Read the rest of the box carefully and the Standard and Regional Provisioned row carries a clause that is easy to skim past. "Might be processed between regions within that geography for operational purposes." Processing can move between multiple regions inside the geography for operational reasons. Inside the geography, not pinned to a region. The same idea sits on the responsible AI data privacy page, which explains that processing may happen across regions within the geography in order to manage performance and capacity.²

So even if you pick the most domestic configuration on offer, writing "processing takes place in a Tokyo datacenter" is not accurate. The accurate version is "processing takes place within the Japan geography". That distinction earns its keep the moment somebody hands you a third-party risk assessment form with a free-text field for data location, because that field is read by a reviewer who did not sit in your architecture meetings and has no way to guess what you meant. If you want a sense of how precisely your own organization can answer that kind of question today, the free AI readiness check is a reasonable place to take stock before you read on.

The documentation says "any Asia Pacific nation"

So how far does processing actually reach when you choose a Data Zone deployment? This is the heart of the piece.

The region availability page has a heading called "Data Zone Standard", and the single sentence directly beneath it defines the scope.³

For Data Zone deployments, Microsoft processes prompts and responses anywhere within the specified data zone: United States (data processed anywhere within the US), European Union (data processed within any EU member nation), or Asia Pacific (data processed within any Asia Pacific nation).

Line up the three parentheses next to each other and the difference in drafting jumps out. The United States gets "anywhere within the US", which is one country. The European Union gets "any EU member nation", which has an institutional boundary behind it, since membership is a defined status. APAC alone gets "any Asia Pacific nation". Any nation in the Asia Pacific, and nothing more. There is no membership concept to lean on and no list of countries anywhere near it.

What most customers in Japan expect the sentence to say is Japan. The sentence does not say Japan. It says prompts and responses are processed somewhere in the Asia Pacific. That is the exact point at which "we chose the Data Zone, so we are domestic" slips off the source material.

There is a second passage about how movable that scope is. The deployment types page describes the APAC data zone this way.⁴

The APAC Data Zone covers multiple Asia Pacific regions. Microsoft can add regions to either data zone without prior notice to improve capacity and availability.

Regions can be added to either data zone without prior notice, in order to improve capacity and availability, and that is stated by the provider in its own words. The same paragraph carries a link reading "For the exact regions in each data zone, see Data Zone deployments." Looking at the HTML, that link is an anchor to a spot on the same page, and the destination does not enumerate countries or regions either.

The regions where you can create a Data Zone Standard deployment are listed on the Asia Pacific tab of the region availability page: australiaeast, japaneast, koreacentral, southeastasia and southindia.⁵ Their physical locations, according to the Azure regions list, are New South Wales, Tokyo and Saitama, Seoul, Singapore, and Chennai.⁶ Seeing those five, it is very tempting to conclude that processing must happen in Australia, Japan, Korea, Singapore or India. Write that down and you have overstepped. Those five are the regions in which a deployment can be created, not a published fixed list of processing destinations. The provider has already said that regions can be added without notice.

To me the variability is the actual issue, not the current contents of the table. I understand the urge to screenshot five region names and paste them into an assessment pack, because a concrete list is so much easier to submit than a paragraph about scope. But that table breaks at the next update, and the person holding the problem when it breaks is the one who pasted it.

What the official documentation does not say about APAC

Everything so far has been about what the documentation says. What it does not say matters roughly as much.

When you need to explain data location to a legal team, the page that gets cited most often is "Data, privacy, and security" in the responsible AI section. It also has a section on processing location for Global and Data zone deployment types, and it explains that data at rest, including uploaded data and the data stores used for abuse monitoring, is stored in the geography the customer specified, and that what changes is the location of processing.² Up to that point it lines up with the deployment types page.

The examples used in that page's Data Zone explanation, though, were the United States and the European Union only. I ran a full-text search, and as of 6 September 2026 neither "APAC" nor "Asia Pacific" appears on it even once. The page metadata gives an update date of 5 June 2026, which is earlier than 9 July, the day the APAC data zone reached general availability.⁷ Chronologically, the page has not caught up yet.

This is not something to hold against anyone. Documentation gets updated in some order, and there are more pages than there are hours. But the practical conclusion is clear enough. The page you cite as authority for APAC data location is not this one. Cite the region availability page that carries "any Asia Pacific nation", and the deployment types page that carries the note box. If a footnote in a pack going to legal review points at a page that never mentions APAC, a careful reviewer will find it, and the finding will be fair.

One more phrase deserves care. "Doesn't offer data residency" is a strong, quotable line, and it does exist in the documentation. Where it sits is narrower than people assume. One occurrence is a note about Global training for fine-tuning, saying that the cost per training token is lower but data residency is not offered.⁸ Directly after it comes a list of available regions, and Japan East is in that list with "no vision support" in parentheses. The other occurrence is the description of the Developer deployment type, which is for evaluating fine-tuned models, has a fixed 24-hour lifetime with automatic deletion, and includes neither an SLA nor a data residency guarantee.⁹

Meanwhile, a sentence stating in the negative that Global inference "does not offer data residency" is not something I found in the body of the deployment types page. Global is described in the affirmative instead. "May be processed in any Azure region", plus a description of using global infrastructure to route traffic dynamically to available datacenters, the highest initial throughput limits, and the broadest model availability.¹⁰ My honest read is that this is not evasive drafting. It states where processing may happen, in a plain declarative sentence, near the top of a page anyone can reach. The misunderstanding arises because readers stop before that sentence, not because it is hidden.

What you can actually choose in japaneast, as of 6 September 2026

Now for availability, which is where the requirement meets its price. Once you write "processing must stay inside Japan" into a requirements document, it is worth knowing exactly what you are giving up. Everything below comes from tabs on the region availability page that I retrieved and counted on 6 September 2026.¹¹¹²¹³

Deployment type	SKU name	Processing scope	Available in japaneast
Global Standard	GlobalStandard	Any Azure region	37 rows in the Azure OpenAI models table
Data Zone Standard	DataZoneStandard	Within data zone	5 rows: gpt-5.2, gpt-5.3-codex, gpt-5.4, gpt-5.4-mini, gpt-5.6-sol
Standard (regional)	Standard	Within Azure geography	5 rows: gpt-4.1-mini, gpt-4o (2024-11-20), text-embedding-3-large, text-embedding-3-small, text-embedding-ada-002
Regional Provisioned Managed	ProvisionedManaged	Within Azure geography	15 rows including gpt-5, gpt-5-mini, gpt-5.1, gpt-5.2, gpt-5.4, gpt-5.4-mini, gpt-4.1, o1, o3-mini, o4-mini

Let me be explicit about what was counted. The 37 is the number of rows marked for japaneast out of all 55 rows on the Asia Pacific tab for Global Standard in the Azure OpenAI models table. The same page also has a differently structured tab titled "Availability for other Foundry Models sold by Azure", and including that one pushes the number higher. Publishing a count without saying what it counted is how two people end up with two numbers and a pointless argument three weeks later.

Read the table straight and the shape of the trade is obvious. The tighter you close processing inside Japan, the fewer models you can choose. With pay-as-you-go Standard the practical set is five, and once you set the embedding models aside, you are left with gpt-4.1-mini and gpt-4o. Whisper is not offered in japaneast at all; on the Asia Pacific tab only southindia is marked for it. Whether a team can stand up in front of its executives and say "we have built our internal generative AI platform" on that basis is, honestly, a stretch.

The part that surprised me was Regional Provisioned Managed, the PTU option. In japaneast there were marks against gpt-5, gpt-5-mini, gpt-5.1, gpt-5.2, gpt-5.4 and gpt-5.4-mini, and against o1, o3-mini and o4-mini as well. Making domestic processing a hard requirement does not lock you out of the GPT-5 generation, which is not the impression most people carry into the conversation.

The ceiling is just as clear, though. gpt-5.3-codex, gpt-5.5 and the gpt-5.6 family were not present for Regional Provisioned Managed in japaneast. For reference, the Data Zone Provisioned Managed tab for Asia Pacific has exactly one row on it, gpt-5.2. So "buy PTU and you get the current generation domestically" does not generalize. If your team wants the newest coding model in particular, the question of where inference runs is not one you get to skip.

There is one more wrinkle. The Azure geography called "Japan" is made up of two regions, Japan East (Tokyo and Saitama) and Japan West (Osaka).⁶ Apply the earlier clause about moving between regions within a geography to Japan, and it means processing can move between Tokyo and Osaka. It is still inside the country, so the practical impact is small, and I have never seen a reviewer object to it. But if your documentation says "pinned to Tokyo", that sentence is not true, and a sentence that is not true is a liability whether or not anyone minds the underlying fact.

I looked at this across cloud providers in a separate piece on running an LLM inside Japan. Each provider words it differently, but the underlying structure repeats: choosing a region and pinning where processing happens are tied together far more loosely than the intuition suggests. Our own product ZEROCK runs on a domestic AWS region, and even so, for every engagement we write out which model gets called through which path and check it line by line. "The platform is in Japan, therefore we are fine" is not a form of reasoning I am willing to rely on.

Do not promise it in prose. Enforce it in configuration.

So what does this look like in practice?

What I would push for is to stop writing the rule into an operating policy and start enforcing it in configuration. Azure deployment types surface directly as the sku.name attribute. GlobalStandard, DataZoneStandard, Standard, ProvisionedManaged, and so on. The deployment types page includes an Azure Policy sample targeting Microsoft.CognitiveServices/accounts/deployments/sku.name, which shows that restricting by SKU name is available to you.¹⁴

Rather than circulating a rule, deny the SKU name. That is roughly the whole recommendation. An agreement that says "production uses Data Zone" breaks the first time someone stands up a single deployment under quarter-end pressure, and nobody notices, because nothing about the moment feels like a violation. Discovery usually comes months later during an inventory, when it is too late to be a small conversation. With sku.name denial in place, the deployment never gets created, and the person in a hurry finds out immediately, from a tool rather than from an auditor.

The second thing I would change is the wording in assessment forms and vendor questionnaires. Instead of one line saying "we use Azure's data zone, so we are domestic", split it into three. Data at rest sits in the Azure geography the customer specifies, which is Japan. The scope of inference processing is determined by the SKU name of the deployment type you chose. And if the APAC data zone is selected, processing is not confined to Japan. Those three lines do not contradict the source documentation anywhere, which means they survive contact with a reviewer who goes and reads the source.

General availability of the APAC data zone was announced on 9 July 2026 on the official Azure blog, alongside general availability of GPT-5.6. The post is signed by Tina Schuchman, Corporate Vice President, Microsoft Foundry.⁷ The relevant sentence reads:

Today we're also announcing the general availability of the Asia-Pacific (APAC) Data Zone for Microsoft Foundry, enabling APAC customers to run frontier OpenAI models while keeping data processing within the Asia-Pacific regions, with no separate environment to stitch together and no waiting for capability to catch up.

"Within the Asia-Pacific regions." Within the regions of the Asia Pacific. It does not say inside Japan. The sentence is accurate and the author is not writing anything misleading. The benefits are stated candidly too, that there is no separate environment to assemble and no waiting for capability to catch up, and both of those are real advantages. The APAC data zone is a genuinely useful option, and I would not want this piece read as an argument against choosing it. The problem for readers in Japan happens one step later, when that English sentence gets summarized internally into Japanese and "Asia-Pacific" quietly falls out of it.

So how much of it stays in Japan?

Back to the question at the top. Reading the official documentation as it stood on 6 September 2026, the answer comes in three parts, and they do not have the same shape as each other.

Data at rest stays in the Japan geography no matter which deployment type you choose. The note box states that without hedging, so there is nothing to agonize over. It is not pinned to Tokyo, though, since processing can move within the geography, which for Japan means between Tokyo and Osaka. Inference processing, when you choose a Data Zone deployment, covers any Asia Pacific nation and is not limited to Japan. If you want processing closed inside the country, the options are Standard or Regional Provisioned Managed. And the harder you push toward domestic, the more visibly the model choices thin out.

Whether you can write those three separately is what decides how your approval and your vendor assessment go. Put the other way around, if you can write them separately, choosing the Data Zone is a perfectly sound decision and nobody has grounds to send it back. What gives me trouble is never the choice itself. It is a document whose stated reason contradicts the source it claims to rest on, and rejections land on that contradiction rather than on the architecture.

The IT manager I mentioned at the start rewrote his approval document and got it through with the Data Zone intact. What he changed was not the configuration, only the three lines of explanation. I think that was the right way to land it, and I would rather more of these conversations ended there than in a redesign nobody needed. If you are unsure whether your own documents need the same rewrite, get in touch and bring the pack you already have. A surprising amount of this gets settled just by reading the source together.

---

Footnotes

1. Microsoft Learn, "Deployment types for Microsoft Foundry Models", the note box at the top of the page (Data residency for all deployment types). Retrieved 6 September 2026; last updated on the page as displayed, 12 August 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types ↩

2. Microsoft Learn, "Data, privacy, and security for Azure OpenAI in Microsoft Foundry Models", section on understanding location of processing for "Global" and "Data zone" deployment types. Retrieved 6 September 2026; page metadata gives an update date of 5 June 2026. https://learn.microsoft.com/en-us/azure/foundry/responsible-ai/openai/data-privacy ↩ ↩²

3. Microsoft Learn, "Region availability for models sold directly by Azure", Data Zone Standard section. Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-region-availability ↩

4. Microsoft Learn, "Deployment types for Microsoft Foundry Models", Data Zone deployments section (from "The APAC Data Zone covers multiple Asia Pacific regions."). Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types ↩

5. Same region availability page, Data Zone Standard section, Asia Pacific tab. Column headings are australiaeast, japaneast, koreacentral, southeastasia and southindia. Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-region-availability ↩

6. Microsoft Learn, "Azure regions list". Japan East (paired region Japan West, physical location Tokyo, Saitama), Japan West (paired region Japan East, Osaka), and the physical locations of australiaeast, koreacentral, southeastasia and southindia. Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/reliability/regions-list ↩ ↩²

7. Microsoft Azure official blog, "GPT-5.6 now available in Microsoft Foundry" (Tina Schuchman, Corporate Vice President, Microsoft Foundry), published 9 July 2026. Retrieved 6 September 2026. https://azure.microsoft.com/en-us/blog/gpt-5-6-now-available-in-microsoft-foundry/ ↩ ↩²

8. Microsoft Learn, "Models sold directly by Azure", fine-tuning section (the note on Global training and the list of available regions). Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure ↩

9. Microsoft Learn, "Deployment types for Microsoft Foundry Models", Developer section. Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types ↩

10. Same page. Description of Global deployments (May be processed in any Azure region, and the passage on dynamic traffic routing). Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types ↩

11. Same region availability page, Standard/Regional section, all 6 rows of the Asia Pacific tab counted directly. Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-region-availability ↩

12. Same region availability page, Regional Provisioned Managed section, all 16 rows of the Asia Pacific tab counted directly (15 of them marked for japaneast). Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-region-availability ↩

13. Same region availability page, Global Standard section, all 55 rows of the Asia Pacific tab for Azure OpenAI models counted directly (37 of them marked for japaneast). Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-region-availability ↩

14. Microsoft Learn, "Deployment types for Microsoft Foundry Models", Azure Policy section (the sample targeting Microsoft.CognitiveServices/accounts/deployments/sku.name). Retrieved 6 September 2026. https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types ↩