Microsoft Hosted ADO Agent IP Details

Denny GLADWIN 0 Reputation points
2026-10-07T08:17:34.1733333+00:00

Hello Team,

We are working on an automation, whereas the end system requires to whitelist the Microsoft Hosted Agent's IPs in order to establish Network Connection. We would need your support in knowing below details

  1. The list of IPs to be whitelisted
  2. Will there be a change in this list, if yes how do we get those details?
  3. Is there a failover list of IPs to consider, just in-case if there is a high-availability scenario for the Agents?

We found below list of IPs from the official documentation. Shall we proceed with this list (Which intern covers the above)?

  • 150.171.22.0/24
  • 150.171.23.0/24
  • 150.171.73.0/24
  • 150.171.74.0/24
  • 150.171.75.0/24
  • 150.171.76.0/24

Thanks

Denny

+65 9466 4645

Azure DevOps
0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-10-07T08:17:50.18+00:00

    The IPs listed in the question should not be used as the Microsoft-hosted agent allowlist.

    For Microsoft-hosted Azure DevOps agents:

    1. There is not a single fixed IP list to whitelist.
    2. The IP ranges change over time.
    3. The correct approach is to allow the IP ranges for all Azure regions mapped to the organization’s geography, using the weekly Azure datacenter JSON file.
    4. For macOS hosted agents, the IP ranges are different because they run in GitHub’s macOS cloud.

    The ranges listed in the question are associated with Azure DevOps service connectivity guidance and are not the complete allowlist for Microsoft-hosted agents. The documentation explicitly states that the Azure DevOps service tag or previously mentioned inbound IP addresses don’t apply to Microsoft-hosted agents.

    To get the correct IP ranges:

    1. In Azure DevOps, open https://dev.azure.com/<your_organization>/_settings/organizationOverview and note the organization region.
    2. Find the matching geography for that region.
    3. Allow the IP ranges for every region in that geography, not only the organization’s home region.
    4. In the weekly file, use the entries named AzureCloud.<region> for each region.

    For high availability and failover:

    • Yes, a hosted agent can run in any region mapped to the organization’s geography.
    • Because of that, the effective “failover list” is the set of IP ranges for all regions in that geography.
    • If the organization is in the European Union, agents are always served from regions within the EU data residency boundary.
    • If using macOS hosted agents, they always run in the US.

    If maintaining the full geography-wide allowlist is too broad, the documented alternatives are:

    • Microsoft Managed DevOps Pools
    • Azure Virtual Machine Scale Set agents

    Also note:

    • Private connectivity such as ExpressRoute or VPN cannot be used to connect Microsoft-hosted agents to a corporate network.
    • Traffic from Microsoft-hosted agents to target systems is over the public network.
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. SHOUMIK CHAKRAVARTY 1,150 Reputation points
    2026-10-09T02:19:30.58+00:00

    Hello @Denny GLADWIN , No this list won’t work. Those 150.171.x.x ranges are the inbound addresses for reaching Azure DevOps itself, and the page they come from is explicit that they don’t cover hosted agents. From Allowed IP addresses and domain URLs: “The Service Tag or previously mentioned inbound IP addresses don’t apply to Microsoft Hosted agents. Customers are still required to allow the entire geography for the Microsoft Hosted agents.”

    On your three questions.

    There isn’t a fixed list. The ranges sit in a weekly JSON file Microsoft publishes, under AzureCloud.<region>, documented on Microsoft-hosted agents.

    It changes every week, and only the current file is downloadable, so you have to fetch it yourself and keep your own copies if you want history. New ranges take effect the week after they appear. If pipelines suddenly start failing, that file is the first thing to re-check.

    On failover, yes. Your agent isn’t pinned to your organization’s region: “While your agent might run in the same region as your organization, it isn’t guaranteed to do so.“ You need every region in your geography, not just your own.

    Worth mentioning that this is a lot of surface area to allowlist and it moves every week. Microsoft’s own suggestion if that’s a problem: “If allowing the entire geography is a concern, we recommend using the Microsoft Managed DevOps Pools. Alternatively, you can also use Azure Virtual Machine Scale Set agents.” Both put your agents on IPs you control, which is usually what the firewall team actually wants.

    Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.