Configuring Azure VNet Integration
The course is part of this learning path
This course will focus on how to configure Azure Kubernetes Service and Azure App Service so that they are accessible within an Azure Virtual Network. In addition to the how of configuring these services, it is also important to understand the requirements for making the configuration possible as well as what features and functions are possible once active. This course will help to put all of this information into perspective.
- Configure App Services for regional VNet integration
- Learn how Azure Kubernetes service can be configured for VNet integration as well as the different networking models that it supports
- Configure App Service environments so that your clients can access them
- Solution architects
- Cloud administrators
- Security engineers
- Application developers
- Anyone involved in the planning, implementation, and maintenance of Azure network solutions
To get the most out of this course, you should have a strong understanding of the Azure portal, networking experience, and experience with Azure network solutions, including routing and private access.
In this last video, we're going to cover App Service environments and specifically how your clients will access them.
App Service environments are slightly different from a standard public-facing App Service which we talked about in the first few videos. Let's start by really asking what actually is an application service environment or an ASE is.
First of all, it is still an App Service, and it has all of the same capabilities and features that a standard App Service does, meaning that it is a PaaS service and Microsoft is in fact going to be managing it. However, it gets deployed into an Isolated Tier based App Plan and as such when it does get created, Microsoft is going to ask you for a Virtual Network that it can be placed into and it exists solely within that virtual network.
All of the other features and capabilities of the App Service still apply, but now instead of it having a public IP address and a public name, it is going to exist inside of your virtual network, and it will have a CNAME that Microsoft applies, but it will only be accessible from within that Virtual Network until you define otherwise. It can have both internal and external endpoints, but most customers that I have worked with have used it strictly for internal purposes or they have created a public endpoint using another device such as a network virtual appliance, Azure Application Gateway or the like and it can allow for both inbound and outbound traffic.
Now, if you'll remember correctly from the App Service VNet integration we talked about in the first few videos, the App Service only had the ability to talk into services inside of the virtual network, not the reverse. Services inside of the virtual network could not talk to the App Service or could not instigate traffic with the App Service. Only the App Service could instigate traffic with services in the VNet.
With an Application Service Environment, the traffic can be instigated in both ways. Both internal services and the Application Service Environment can see one another.
From a client access perspective, you're going to access the application service environment in much the same way that you do with any infrastructure as a service-based solution.
You can allow for port forwarding from a jump box or Azure Bastion for example.
You can allow for traffic through an internal or external load balancer. Remember, App Services have a load balancer attached to them by default to allow for scalability. You can define whether that load balancer will have a private endpoint or a public endpoint, and Microsoft does supply different CNAMEs for each specific solution.
You can use User Defined Routes for any traffic coming in and out of that App Service. So if you want the traffic to go through an intrusion detection/prevention device or a web application firewall, you can absolutely force that.
The one key factor that a lot of my customers have done over the years is they have created these App Services to reduce the amount of administration overhead and allowed their internal users on their internal networks On-Premises to be able to access these App Services via an ExpressRoute.
So, there's any number of different options for accessing the App Service, but the key factor here is that the App Service is still in App Service. It's just now isolated, and network secured like an infrastructure as a service-based solution would be.
With that, we'll wrap up the course with a conclusion video. Hope you've enjoyed this and I hope to see you soon.
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.