VDC requires the Microsoft.Storage.Global service configured on the azure vnet subnet, but this causes issues in our environment.
Being able to nominate a dedicated vnet, or subnet, for VDC to use for backups would be a solution to this issue.
From case #07953313:
Per case notes would like to clarify "A virtual network service endpoint (routing) for the Microsoft.Storage.Global service must be configured for virtual networks to which worker instances will be connected — you can either configure the endpoint manually in Microsoft Azure beforehand or let Veeam Backup for Microsoft Azure do it for you automatically while deploying the worker instances."
For vdc Azure the worker instances config is handled in the backend maintaining the components required for the VM backups to be taken and traffic needs to be routed through this service endpoint. At this stage there is no way to separate the VDC traffic from the internet traffic and would be a feature request for the VDC Azure team if you would like to raise.
We have scripts that run each night that connect to other Azure hosted file shares. These file shares have IP whitelisting requirements.
When the Microsoft.Storage.Global service is enabled on the subnet, it causes the traffic to route via the MS routed service instead of via the internet. This results in the connection coming from a random Microsoft IP that is not whitelisted and the connection fails.
There are some ways to get around this, but it involves reworking scripts and network routes. Was hoping to avoid that
