From Ever changing code
Jump to navigation Jump to search

This is being innovated by Microsoft quite often but basis should stay the same. Virtual Network Documentation covers most of the subject here

  • routing, service endpoints, security groups, more...

Azure Virtual Network



Virtual networks can be in the same, or different, supported Azure regions. The virtual networks can be in the same or different Azure subscriptions.

Naming conventions:

  • <vnet>_to_<vnet>_peerlink | _prl | _pl | _peer | _pelnk
  • sandbox_infra1_euw1_to_sandbox_client_euw1_peerlink


Peerlinks need to be created from both ends of Vnet unlike in AWS one connection requests acceptance from other side. In Azure 1st peerlink get status Iniciated then once 2nd peerlink gets created the status changes to Connected.

Options when creating peerlink:

Allow virtual network access
Select this option if you wish to allow communication between the two virtual networks. This allows the peer virtual network address space to be included as part of the Virtual_Network tag.
Allow Forwarded traffic
This setting allows the peer’s forwarded traffic (traffic not originating from inside the peer virtual network) into your virtual network.It does not create any user-defined routes or network virtual appliances. User-defined routes and network virtual appliances are created separately. You don't need to check this setting if traffic is forwarded between virtual networks through an Azure VPN Gateway.
Allow Gateway transit
Allows the peer virtual network to use your virtual network gateway. The peer virtual network cannot already have a gateway configured, and must select ‘use remote gateway’ in its peering settings. Check this box if you have a virtual network gateway attached to this virtual network and want to allow traffic from the peered virtual network to flow through the gateway.

VPN gateway

Connects a virtual network to your on-premises network using p2s, s2s or ExpressRoute.

Naming convention:

  • <project'sVnet>_<region>_vng | _vnetg | vngw
  • sandbox_euw1_vng
  • sandbox_infra1_euw1_vng
  • sandbox_client_euw1_vng

Client Download for p2s connection The Windows VPN connection name will be a name of VNet where Virtual Gateway resides, eg. sandbox_euw1_vng


VPN Gateway transit to and from peered networks

Azure/Point-to-Site VPN


Service endpoints

Virtual Network (VNet) service endpoints extend your virtual network private address space and the identity of your VNet to the Azure services, over a direct connection. Allow you to secure your Azure service resources to only your virtual networks. Traffic from your VNet to the Azure service always remains on backbone network.

When enabling a service endpoint for an existing subnet, ensure that no critical tasks are running on any resource in the subnet. Service endpoints switch routes on every network interface in the subnet from using the default route with the address prefix and next hop type of Internet, to using a new route with the address prefixes of the service, and a next hop type of VirtualNetworkServiceEndpoint. During the switch, any open TCP connections may be terminated. The service endpoint is not enabled until traffic flows to the service for all network interfaces are updated with the new route. To learn more about routing, see Routing overview.

Example service endpoint, these can be fount in Vnet blade > Service Endpoints, and additional added route in Nic > Effective routes

  • Microsoft.Sql

So the technique that is used with Service endpoints is basically done by creating a route that has “VirtualNetworkServiceEndpoint” as the next hop type.

Secondary note

A Virtual Network service endpoint is a subnet whose property values include one or more formal Azure service type names. VNet services endpoints use the service type name Microsoft.Sql, which refers to the Azure service named SQL Database. This service tag also applies to the Azure SQL Database, Azure Database for PostgreSQL and MySQL services. It is important to note when applying the Microsoft.Sql service tag to a VNet service endpoint it configures service endpoint traffic for all Azure Database services, including Azure SQL Database, Azure Database for PostgreSQL and Azure Database for MySQL servers on the subnet.

List Service endpoints in Subnet

When creating a subnet following service endpoints are available to enable:

  • Microsoft.AzureActiveDirectory
  • Microsoft.AzureCosmosDB
  • Microsoft.EventHub
  • Microsoft.KeyVault
  • Microsoft.ServiceBus
  • Microsoft.Sql
  • Microsoft.Storage

DNS Name Resolution

Resources in one Vnet cannot resolve the names of resources in a peered vnet using built-in DNS. To resolve names in a peered virtual network, requires

  • own DNS server
  • Azure DNS private domains

Resolving names between Vnet and on-premises networks requires

  • own DNS server

Private DNS zones

A DNS zone is used to host the DNS records for a particular domain. To start hosting your domain in Azure DNS, you need to create a DNS zone for that domain name. Each DNS record for your domain is then created inside this DNS zone. To publish a private DNS zone to your virtual network, you specify the list of virtual networks that are allowed to resolve records within the zone. These are called resolution virtual networks. You may also specify a virtual network for which Azure DNS maintains hostname records whenever a VM is created, changes IP, or is deleted. This is called a registration virtual network.

Create DNS private zone

# Private zone can be only created in empty Vnet
az network vnet create \
  --name myAzureVNet \
  --resource-group MyAzureResourceGroup \
  --location eastus \
  --address-prefix \
  --subnet-name backendSubnet \

az network dns zone create -g MyAzureResourceGroup \
   -n us.sandbox.local \
  --zone-type Private \
  --registration-vnets myAzureVNet

az network dns zone list --resource-group MyAzureResourceGroup

az network dns record-set a add-record \
  -g MyAzureResourceGroup \
  -z us.sandbox.local \
  -n db \

az network dns record-set list \
  -g MyAzureResourceGroup \
  -z us.contoso.local


# Created VM named switch-1

piotr@switch-1:~$ cat /etc/resolv.conf

piotr@switch-1:~$ cat /etc/hosts localhost

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff02::3 ip6-allhosts

piotr@switch-1:~$ nslookup switch-1
Non-authoritative answer:

# this is registered DNS record
piotr@switch-1:~$ nslookup

Non-authoritative answer:

If you wanted to create a zone just for name resolution (no automatic hostname creation), you could use the resolution-vnets parameter instead of the registration-vnets parameter.

Azure DNS Private Zone is in Public Preview since 22 March 2018


Availability Zones

Azure Virtual Networks (VNETs) and Subnets, are and will remain "regional" entities. Once you will define in a region, they will be visible and usable across all the AZ since Network Resource Manager in Azure is region-wide. There is no AZ specification for these objects, VNETs and Subnets can cross AZ.

Availability Zones and Availability Sets cannot be used together: when creating a Virtual Machine (VM), you will have to specify an AS, or AZ assignment, you cannot do both.

Services that support Availability Zones

The Azure services that support Availability Zones are:

  • Linux Virtual Machines
  • Windows Virtual Machines
  • Virtual Machine Scale Sets
  • Managed Disks
  • Load Balancer
  • Public IP address
  • Zone-redundant storage
  • SQL Database
  • Event Hubs
  • Service Bus
  • VPN Gateway
  • ExpressRoute
  • Application Gateway (preview)