Can not restrict IP addresses on both Translation Service and Azure Storage for Document Translation

For those with the same problem, here is what solved it. When there are IP restrictions on the Storage service, passing a SAS token to the Translator service no longer works. The documentation recommends using Managed Identity to let Translator talk to the Storage container, while still using SAS to talk to Storage directly and says you no longer need to include SAS URLs, but what it should say is if you do include it you will get an error, more specifically the status will change to "ValidationFailed". The code has to know that a managed identity is being used and not send the SAS token to the Translator service.

The other approaches, including VNET, service tags, trusted Azure services, etc, didn't work.

Hi Martin Laplante,

Welcome to Microsoft Q&A and Thank you for reaching out.

when you enable IP restrictions on both the Azure AI Translator (Translation Service) and your Azure Storage account, the Document Translation workflow breaks because the translation service can no longer fetch the documents from storage. That’s expected behavior when both services are locked down without trustable network paths.

Azure AI Translator needs network access to your storage account in order to read and write blobs during the translation batch job. When you enable IP restrictions on both resources independently, the Translator’s backend service endpoints are not automatically allowed through the Storage firewall unless explicitly permitted. Microsoft Learn

There are three main approaches you can consider:

1. Use Virtual Network + Private Endpoints Putting both the Translator service and the Storage account in the same VNet with private endpoints ensures they can communicate securely without exposing public IPs. This is typically the recommended pattern for secure document workflows and avoids reliance on public CIDR whitelisting.
2. Allow the Translator service to reach Storage via service tags or managed identity If using public endpoints, make sure you grant the Translator service’s outbound IP ranges or service tag access to the storage firewall. Azure Translator is included under the CognitiveServicesManagement service tag for network rules, so you can allow traffic from that tag instead of trying to list individual IPs.
3. Keep Storage locked down but allow trusted Azure services Some customers enable the Storage firewall while allowing trusted Microsoft services or specific Azure services to bypass it. This lets the translator service talk to Storage while still blocking untrusted traffic.

In short: you can’t enforce strict IP blocking on both sides without a trusted path either via private networking (VNet + private endpoints) or by explicitly allowing Azure Translator’s network identity to access your storage. If you restrict both independently to only a few IPs, the translation batching service can’t complete because the storage fetch calls are blocked.

Please let me know if there are any remaining questions or additional details, I can help with, I’ll be glad to provide further clarification or guidance.

Thankyou!