Member-only story
Implementing a basic Azure Virtual Network with Bicep
Using Bicep, we can create Azure Virtual Networks (and subnets) for our private networking needs in Azure.
Azure Virtual Networks (or VNETs) are the fundamental building block for private networks in Azure. We can built Azure VNETs that are similar to on-prem networks, with the benefit of Azure infrastructure.
We can create VNETs with their own CIDR block, and link them to other Azure VNETs and on-prem networks (providing that there’s no overlap with CIDR blocks). We can also control DNS server settings, segmentation of VNETs into subnets, and more.
In this article, I’ll talk about what Azure VNETs can do, how we can design our Azure VNETs, and implement VNETs using Bicep.
What can Azure VNETs do?
Azure VNETs essentially enable Azure resources to securely communicate with each other, with the internet, or our on-prem networks.
All resources integrated with our VNET can communicate outbound to the internet by default. We can communicate with resources inbound by assigning public IP addresses or using a public Load balancer. We can also use these for outbound connections.
Virtual Machines, AKS, App Services etc. can connect to VNETs. We can use service endpoints to connect to other Azure resources such as storage accounts, and when we create a VNET, we provide a mechanism for our services within our VNET to communicate with each other in a direct and secure manner.
With connections to on-prem resources, we can use either Point-to-site virtual networks (VPNs), site-to-site VPNs, or ExpressRoute.
We can also use Azure VNETs to filter and route our network traffic. Using Network Security Groups (NSGs) and Network Virtual Appliances (NVAs), we can filter network traffic between subnets. By default, Azure routes traffic between subnets, connected VNETs, and the internet by default. To override this, we can implement route tables or border gateway protocol (BGP) routes.
