When you have an internal network, you usually care about the network you plug your resources into. In Azure, that piece is abstracted out of your view in most scenarios. However, you might need to control how your resources interact or you may need to connect your own network to Azure.

I like to use VNet for the following reasons:

• Isolation and segmentation
• Communication between Azure resources

• Communication with o-premise resources
• Filtering network traffic
• Routing network traffic, using routing tables to move traffic between subnets and networks on-premise or via the internet
• Connecting virtual networks in different regions

Let’s take a quick look at a simplified VNet implementation that has a public frontend and a private backend:

As you can see, we are using a Network Security Group (NSG), to apply policies to the subnets. One of the policies on the backend subnet is limiting access to the internet.  We have an Azure front door service running in front of our app services to provide load balancing and SSL off-loading. In our backend subnet, we are using Key Vault to store our secrets and keys. This is just a simple way to show how to use a VNet in Azure.