Today we are excited to announce that Azure DevOps is now available over Azure ExpressRoute.
Customers who typically operate in the government and financial services sectors have requested this support because they want private connections that don’t go over the public Internet for security reasons. ExpressRoute also typically offers them more reliability, faster speeds, and lower latencies than typical Internet connections.
Connectivity to Microsoft online services like Azure Storage, Azure SQL, Dynamics 365 and now Azure DevOps is through the Microsoft peering configuration of ExpressRoute circuits.
Route filters are a way to consume a subset of supported services through Microsoft peering. Using route filters, you can enable services you want to consume through your circuit’s Microsoft peering. Azure DevOps is included in the new Azure Global Services route filter with a BGP community value of 12076:5050.
ExpressRoute is available for all Azure DevOps services, including:
- Organizations using the new
https://dev.azure.com/
URL, - Organizations using the legacy
https://{organization}.visualstudio.com/
URL, - Self-hosted Azure Pipelines agents,
- Self-hosted Cloud Load Test agents,
- Visual Studio Marketplace (
https://marketplace.visualstudio.com/
), - Visual Studio Subscriber Portal (
https://my.visualstudio.com
), and - Visual Studio Subscriptions Administration Portal (
https://manage.visualstudio.com
).
ExpressRoute is not available for Azure DevOps static content that is delivered via Azure Content Delivery Network (CDN), which includes:
- Scripts, images, fonts and stylesheets, from the
cdn.vsassets.io
URL, and - Web extensions from the
{publishername}.gallerycdn.vsassets.io
URL.
ExpressRoute is available for use with Azure Artifacts. However, you will need to configure route filters for the Microsoft Azure region that your organization is located in.
For more information, see the ExpressRoute documentation for Configuring route filters for Microsoft peering.
Is Azure DevOps via Express Route the only way to lock down alternative credentials like PAT if our outbound IP addresses are neither segmented between networks nor static? Being able to lock down the security perimeter of Azure DevOps to match our current on premise perimeter is all that’s keeping us from migrating to Azure DevOps Services at this point and I can’t seem to find a clear answer to this problem. Thanks!