Configure Access to Service Endpoints
Start course

This course will focus on how to create and configure Azure service endpoints so that PaaS services can be made available from within your virtual network. The course will also discuss service tags, their association with service endpoints, and how to use them within the scope of your Network Security Groups and Azure Firewalls to allow/deny traffic to Azure PaaS services. The course will help to put all of this information into perspective.

Learning Objectives 

  • Create service endpoints
  • Configure service endpoint policies
  • Configure service tags
  • Configure access to service endpoints

Intended Audience

  • Azure Network Engineers who will be recommending networking solutions and managing them for performance, resiliency, scale, and security
  • Azure Network Engineers who will be working with solution architects, cloud administrators, security engineers, and application developers to deliver Azure solutions


  • Subject matter expertise in planning, implementing, and maintaining Azure networking solutions, including hybrid networking, connectivity, routing, security, and private access to Azure services
  • Azure administration skills
  • Experience and knowledge of networking, hybrid connections, and network security

Hi there. In this last video, we're going to focus on how to access the services that are sitting behind a specific service endpoint. Now, it was kind of hard for me to not touch on this during the previous videos, but we're actually going to focus on just that particular topic. When limiting access there's a number of different ways that it can be done. Let's talk first about how to use the service tags. We touched on it a little bit, but within the scope of a network security group or an Azure Firewall, you can actually use service tags to either allow or deny access to specific Azure past services within the scope of your particular subnet that the NSG has been applied to or even all the way down to a specific NIC card. You can use current point-in-time list of IP ranges that those service tags are associated with in your on-prem environment as well, and therefore use them in your own on-prem firewall rules such as the Cisco device, Barracuda, or so on.

You can leverage service endpoint policies which granted, right now, are storage account only, but they do provide the ability for you to limit access to specific storage accounts based off of individual names, resource groups, or subscription IDs. And then there are also specific path services that are associated with service endpoints that have their own access control list features. A couple of examples are storage accounts have additional control list actions such as shared access signatures, where you can actually define the availability of the data within the scope of a storage account container. For example, you can control it based off of incoming IP addresses, you can specify time windows, things along those lines. There's also the ability to control access to storage accounts via role-based access control inside of Azure, there's a number of different features related to storage accounts that are inherent to the storage accounts themselves. And then within the scope of key vault, for example, Key Vault has its own firewall as well as access policies, thereby allowing you to limit access to not just Key Vault itself but also to what data is inside of Key Vault.

And one of the things that you're going to find from a limiting access perspective is that Microsoft has provided an additional capability within the scope of any service that is data-oriented. Key Vault, storage accounts both store data, the database is all stored data. So, they all have additional access capabilities within those services to make sure that data is secured and the customer is happy with that security. Now, just as a quick example, we touched on it a little bit during the last video of service tags, but let's actually create a deny rule inside of a network security group and deny access to a specific past service that a service endpoint has been set up for. We are back in the portal and we have gone directly into the network security group that I created called endpoints. And what we're going to do is we're going to create a quick deny rule that will prevent access to any storage account within a specific region. And then we're going to apply that network security group to the subnet that we created the service endpoints for.

So, we go into inbound rules, and we create a new one. We want the Source to be anything because we want to block all traffic. The Destination on the other hand is going to be a specific 'Service Tag' and we are going to, remember we actually turned on both Key Vault and storage accounts. So, let's lockdown storage accounts that exist inside of GermanyNorth. We are going to deny all traffic to all storage accounts that sit inside of the GermanyNorth region. And in this case, we're going to, Destination ports ranges will be all, Protocol, 'Any'. We're going to do a 'Deny'. The priority number just needs to be higher than 65,500 so that it will take effect first. And then we're just going to give it a name, and we're done. Now, before this can actually work and prevent traffic from flowing into a storage account that sits in GermanyNorth, we have to apply it to the subnet.

So, let's go back to our resource group and specifically the vnet. And go to the 'Subnets' and go to the subnet endpoints. We're going to make sure that the network security group that we just modified has been applied to this subnet. So, in this instance now, we actually have dual layers of accessibility to storage accounts within the scope of this subnet. We turned on Microsoft.Storage as a service endpoint. However, we have a network security group that's blocking all traffic to storage accounts in GermanyNorth. And of course, we could add additional rules if we wanted to limit it even further. But then we also have a storage account endpoint policy that is also allowing two specific storage accounts. So, it allows you to create that multilayered approach of accessibility from a security perspective with respect to service endpoints. And of course, this can be leveraged here in network security groups. 

We can also create deny rules or allow rules inside of the Azure Firewall as well. And then as I mentioned, there are a number of other capabilities, especially within storage accounts that you can take advantage of to even layer your security or your accessibility to the data within those storage accounts even further. That's going to do it for this course. I hope that you've enjoyed all of the content. We'll wrap things up in a conclusion video next.


About the Author

Brian has been working in the Cloud space for more than a decade as both a Cloud Architect and Cloud Engineer. He has experience building Application Development, Infrastructure, and AI-based architectures using many different OSS and Non-OSS based technologies. In addition to his work at Cloud Academy, he is always trying to educate customers about how to get started in the cloud with his many blogs and videos. He is currently working as a Lead Azure Engineer in the Public Sector space.