Azure Virtual Network (VNet) allows you to create private networking within Microsoft Azure. While VNet functions similarly to conventional networks, it inherits significant benefits from Azure, particularly scalability, isolation, and resiliency. VNet can be configured to allow your resources in Azure to communicate securely with each other, with resources on the internet or in other clouds, and with any on-premises networks that you have. As with conventional networks, you have options for filtering and routing traffic.
Communicate with the internet
The default settings allow outbound traffic but restrict inbound connections to resources with public IP addresses or run through public load balancers.
Communicate between Azure resources
VNet enables secure communication between Azure resources using a virtual network, a virtual network service endpoint, or VNet peering.
Communicate with resources in other clouds
For communication with your on-premises network, a site-to-site virtual private network (VPN) through an Azure VPN Gateway ensures that your data over the public internet remains secure.
Small network (4K IPs)
A small virtual network using the address range of 10.0.0.0/20 contains 4,000 usable IP addresses.
Large network (65K IPs)
A large virtual network using the address range of 10.0.0.0/16 contains 65,000 usable IP addresses.
Our bundle includes the following design choices to help simplify your deployment:
The virtual network will have a custom private IP address using public and private (RFC 1918) addresses so that Azure can assign resources within that address space. As noted above, the address range will depend on whether you want to deploy a small or large network.
Subnets in VNet function as conventional subnets. We give you the capability to segment your virtual network with subnets and secure them with network security groups to enforce security rules for traffic to and from the VNet.
Massdriver architecture for subnets
Assuming a 10.0.0.0/16 VNet (i.e., a large virtual network), the following subnets will be provisioned:
- Default subnet (10.0.0.0/17): The first half of the CIDR (10.0.0.0/17) will be allocated to the default subnet, which will be used by Massdriver to provision all resources that can share a subnet.
- Spare capacity (10.0.128.0/17): The second half of the range (10.0.128.0/17) will be spare capacity for deploying additional subnets either for customers or for Massdriver. Some Azure services, such as Azure Flexible Server for Postgres or MySQL, require a delegated subnet. This range will be used to create those subnets.
Since VNet cannot span regions, Virtual Network Peering can connect multiple virtual networks if you need to bridge multiple locations.
VNet cannot span subscriptions, but each subscriber can have multiple virtual networks.
Virtual network integration for Azure services
For secure communication between Azure resources, VNet provides you with three configurations: dedicated service instances within a VNet, private access over Microsoft’s backbone network through Azure Private Link, and public service endpoints. Massdriver uses Azure Private Link whenever possible for services hosted on Azure, in accordance with Microsoft’s recommendation for secure communication.
The bundle includes a number of best practices without needing any additional work on your part.
We create and manage a default subnet to deploy all resources that can share a subnet.
We reserve half of the subnet space for Azure services that require delegated subnets. This reserved space is also available for future expansion needs.
Azure Private Link
Whenever possible, Azure Private Link will be used to keep communication with Azure services within your private network.
With private networking, all services in your VNet will communicate internally.
Azure Private link
Whenever possible, services that are deployed into your VNet and that support Azure Private Link will use it to ensure private communication between your workloads and Azure’s services.
- The IPv6 address space is not supported.
- You cannot use the following:
- Azure Bastion service
- Azure DDoS Protection Standard
- Azure Firewall
|monitoring.mode||string||Enable and customize Function App metric alarms.|
|network.automatic||boolean||Enabling this will automatically select an available CIDR range for your database. Unchecking will require you to specify the CIDR.|
|network.region||string||Select the Azure region you’d like to provision your resources in. This cannot be changed after the resource is created.|