Azure Service Endpoints
The course is part of this learning path
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.
- Create service endpoints
- Configure service endpoint policies
- Configure service tags
- Configure access to service endpoints
- 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. Let's start our discussion around service endpoints by talking about how to create them. But even before we talk about that, let's make sure that we understand what service endpoints are and what the key features are for them. So, with respect to a service endpoint, you are going to get secure direct connectivity to Azure PaaS services. Okay, that's great. But Azure PaaS services already have secure connectivity options because they are almost all SSL-based. But they allow secure connections to those Azure PaaS services from within your virtual network. Well, that's also already available as long as you allow outbound connectivity from your virtual network, then any virtual machine or Azure Kubernetes service could access those PaaS services from within the virtual network, the traffic would of course just go out to the Internet.
The last piece of the puzzle, it allows Azure private IP addresses from within the virtual network to reach the endpoint of the Azure service without needing a Public IP and without needing outbound Internet connectivity. The traffic will stay inside of the Azure region if both services are in the same region, or it will stay on the Azure backbone if the services are in two different regions. Now there are a lot of Azure PaaS services that are available. Not all of them are currently supported with respect to service endpoints. Here is the current list. Everything from Azure Storage, different databases, data analytics services, event messaging services, app services, cognitive services, and currently in public preview Azure container registry, I definitely will see that becoming generally available here very soon. Now, what are the key features with respect to our service endpoints? The first is improved security, absolutely.
You no longer have to worry about traffic going out to the Internet and therefore potentially being sniffed, or grabbed, or any of those kinds of things. All of the traffic stays inside of Microsoft's regions, inside of Microsoft's backbone. You can provide optimal routing for your Azure service traffic from your virtual network, therefore getting better performance. You can also control the routing of the traffic and use any base routing that you currently already have in place for other services. So, all traffic will travel to the service on the Azure backbone, I've mentioned this already. All Internet traffic forcing routes will work as expected. So, for example, should you have a route, user-defined route within your virtual network that forces all traffic to go through an intrusion detection, intrusion prevention device, or through a web application firewall, for example,
you can still leverage those routes to have that be the first endpoint for all traffic before going to the Azure service, thereby making sure that that traffic is both secure and clean. It is very simple to set up with much less required overhead than would be required if you were to allow for traffic to go out to the Internet and then to the Azure PaaS service, you would have to require many more network security group rules, maybe in that gateway, things along those lines. Whereas, these are not required if you're going to be using service endpoints.
No Public IP addresses are required as I mentioned earlier. And as I just talked about, no NAT or Gateway devices are required because the traffic stays in the Azure backbone, you no longer have to worry about this outbound Internet traffic requirement. Now, the last thing to make sure that we understand is what are the permissions required for someone who is going to configure service endpoints for your virtual network?
The first is, for existing virtual networks, with existing subnets, just write access. That's all that the user will need in order to be able to make the necessary configuration changes. However, if they are creating a new subnet, and in creating that new subnet they are also going to be adding a service endpoint capability, then they will also need the joinViaServiceEndpoint/action permission for any of those new additional subnets. Now, in the next video, let's take a look at an actual demonstration of how to create or configure your service endpoints for an existing virtual network.
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.