I understand the approach in the article "Step-by-Step: Automate Building Outbound Network Security Groups Rules via Azure Resource Manager (ARM) and PowerShell": Allow all internally used IP-subnets used by Azure and then block the outbound Internet traffic.

But I think this list of subnets is not static, today there are 437 subnets for West-Europe, which is near to the maximum of 500 NSG rules per NSG.

Resources like storage or Linux repositories use some of these subnets. They are not accessed with static IPs, there are Load Balancers deciding about the used service and its IP address. That's the reason to open all Azure subnets.

I have the requirement to block all traffic to "real Internet servers" and also make the needed internal services accessible.


  1. When there are new subnets added and a Load Balancer decides to
    assign a service in this new subnet to my request, I will not be able to access it? This could result in a service degradation of my application. Is that correct?
  2. Are the newly announced "Service Endpoints" a solution for this problem?
  3. Is it planned to introduce another Default Tag usable in NSG rules in addition to "VirtualNetwork","AzureLoadBalancer" and "Internet" to address "External Internet" or "Azure Internal"?

Thanks in advance!

Links mentioned:



2 Answers 2


As you mention, the problem with blocking all traffic to the "internet" tag is that it also blocks access to Azure PaaS services. Previously the only way to deal with this was to allow access to the Azure IP ranges, but as you noted there are lots of these and they change reguarly, which is a pain. If a service you wants to access get's an IP that is not in the range your NSGs are programmed to allow outbound then yes, you will not be able to access it.

MS have started to address this issue through the use of service tags. These are tags similar to "Internet" that you can configure on an NSG rule, rather than having to specify the whole address ranges. There are some issues here, firstly the service is in preview, secondly it only encompasses storage and Azure SQL at the moment.

If SQL and Storage is all you need then you can go ahead and use these service tags to block access to "internet" and allow to "storage" and "SQL"

  • Thank you for your answer! It confirms that my understanding of the current options for firewalls (NSG) is right. It's always possible to miss some options in Azure! For a productive environment a risk of network failures because of changes in the network structure is often not acceptable. As you mentioned the Service Endpoints or Tags will only address access to storage and Azure SQL, but e.g. not to the Linux update repositories
    – JBee42
    Dec 21, 2017 at 10:28
  • Indeed, there are going to be more tags coming along for other services, but these are going to be Azure only. For things like Linux update Services you are going to have to allow IP ranges, unless we get the ability to create our own tags one day.
    – Sam Cogan
    Dec 22, 2017 at 11:33
  • The Ubuntu links to update repositories ("sources") link to an Azure Traffic Manger which normally returns an Azure mirror of this repository. So technically the traffic stays inside the Azure network. As this connection is needed for all Ubuntu VMs, a convenient solution without allowing outbound internet traffic in general would be useful.
    – JBee42
    Jan 10, 2018 at 10:29

Recently encountered a similar situation by which all outbound access was blocked. To allow restricted access to the Azure services which we required (Azure Recovery Services etc). We setup a Azure Automation Runbook which runs on a nightly basis to retrieve the XML list from the link below, parse the local region and update the NSG's. With the recent release of Augmented security rules, we can also collapse all these subnets down to a single rule.

Link: Create an Azure Automation runbook

Link: Microsoft Azure Datacenter IP Ranges

Link: Augmented security rules

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .