An Azure service to easily conduct machine translation with a simple REST API call.
Short answer: for a US resource, the public docs don't say. The current Region support for Azure Translator page only gives a processing location for the resource-specific endpoint in one case, Switzerland. For a West US resource on <resource-name>.cognitiveservices.azure.com, no processing location is written down, so I wouldn't put "US only" in a HIPAA review based on the docs alone.
What the page does document for standard NMT text translation:
| Endpoint | Request processing location (as documented) |
|---|---|
Global api.cognitive.microsofttranslator.com |
Closest available datacenter. During a datacenter failure the request might be processed outside the originating geography |
Americas api-nam.cognitive.microsofttranslator.com |
East US 2 or West US 2 |
| Switzerland, resource-specific endpoint | Switzerland North or Switzerland West |
The same page also says that "a resource location and a request processing location aren't always the same", and that Translator doesn't persist customer data submitted for text translation. That second point usually helps a residency review, but it's a separate question from where processing happens.
What I'd do:
- Get it in writing. Open a support request, or go through your Microsoft account team, and ask exactly this: "For an Azure Translator resource in West US called through its resource-specific endpoint, which datacenters process text translation requests, including during failover?" An auditor will want that answer, not a forum post.
- If the CAT plugin can't use api-nam, one option is a small proxy that you host in a US region. The plugin calls the proxy and the proxy calls
api-nam.cognitive.microsofttranslator.com. That gets you onto the endpoint with a documented US processing location. Keep in mind the proxy then sees the text and becomes part of your HIPAA scope. - Check the HIPAA side separately. Whether Translator is covered under your BAA is answered by Microsoft's compliance documentation and your agreement, not by the region page.
Limits of this answer: it covers standard NMT text translation only. LLM-based translation in Foundry follows the model deployment type (global, data zone or regional) instead, and Document Translation has its own table, where the resource region decides processing. I haven't traced the network path myself.