azure-virtual-network

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.

Use Cases

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.

Configuration Presets

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.

Design

Our bundle includes the following design choices to help simplify your deployment:

Address space

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

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.

Regions

Since VNet cannot span regions, Virtual Network Peering can connect multiple virtual networks if you need to bridge multiple locations.

Subscription

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.

Best Practices

The bundle includes a number of best practices without needing any additional work on your part.

Default subnet

We create and manage a default subnet to deploy all resources that can share a subnet.

Spare capacity

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.

Security

Private networking

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.

Trade-offs

• The IPv6 address space is not supported.
• You cannot use the following:
• Azure Bastion service
• Azure DDoS Protection Standard
• Azure Firewall