Before starting with the detailed analysis of the topic, in this section of the chapter, I would like to introduce you to the typical anatomy of a VNet infrastructure. You will get to know the individual components of a VNet and their respective relationships to each other or to the public space. By acquiring this basic knowledge, you will then easily understand the subsequent sections of the chapter. Let's take a look at the following diagram:

In the illustration, you can see a simple representation of an Azure VNet in the example of VNet support for Azure VMs.

Note that this example is generally valid, as the VNet support for most other Azure resources are also technologically based on the network capabilities of an Azure VM.

Let's look at the details. The mandatory elements of an Azure VNet architecture are the following:

• Resource group: A resource group is a container that holds all related resources. For our example, this means that the resource group contains all elements of the virtual network and the application (the VM).

A typical example of a solution distribution would be as follows:

• • One resource group for the application
  • One resource group for storage elements (optional)
  • One resource group for the infrastructure (these are the VNet elements)
  • One resource group for management elements (optional)

• VNet: An answer to the question, what is an Azure VNet? Is not so easy to find, because a VNet is not a service in the classical sense. Instead, a VNet is an individual collection of single components or services that are grouped together in a logical group (the VNet).

There is a second description, which we can consider as a fitting answer; a VNet is a representation of your own network in the cloud, or an extension of your on-premises network towards the cloud.

What do I need to know about VNets? A VNet is always run in isolation on the Azure platform. This allows you, on the one hand, to create multiple VNets using the same Classless Inter-Domain Routing (CIDR) address blocks (for example, to provide separate VNets for development, test, and production), or on the other hand, to create multiple VNets that access different CIDR address blocks, but which have the right to communicate with each other.

A VNet can be segmented into any number of VNet Subnets. When you create a VNet, you enter a custom IP address space that contains both public and private IP addresses. Azure allocates resources associated with the VNet to a private IP address from the address space that you assign.

Although communication can occur within a VNet or between multiple VNets over IP addresses, it is much easier to use names that are easy to remember and do not change. For the name resolution, the Azure platform uses an internal name service, or you have the ability to integrate your own DNS server. A VNet subnet is a logical unit (a segment) of the VNet, and is assigned with a part of the VNet address space.

• Network Interface (NIC): The NIC enables the resources to communicate with the virtual network. One NIC is provided automatically when the resource is created. Other NICs can be added at any time to meet your needs.

What do I need to know about NICs? You can link multiple public and/or private IPs with a NIC (dynamic or static). You can link a Virtual IP (VIP) for load balancing with a NIC (dynamic or static). You can get the MAC address of your NIC over the phase between stop and restart persistent.

Optional resources of an Azure VNet are the following:

• Public IP address: A public IP address is needed to communicate with the resource, for example, over the Remote Desktop Service (RDP).
• NSG: An NSG is used to allow or deny network traffic. You can associate an NSG with an individual NIC or with a VNet subnet. If you associate it with a VNet subnet, the NSG rules apply to all VMs in that subnet. (More information on this topic will follow in a later section of the chapter.)

Now, you've learned everything about a VNet for a single VM, but in real life, there are usually more than just one. What does this mean for us and our example? If you thought that you simply have to provide the same Azure resources, the answer is only partially correct. There are differences and I will introduce those now. Take a look at the following diagram:

We start with the most important innovation in this illustration, which is Azure availability sets.

The availability sets are an organizational component (resource) of the Azure platform and manage the operation of two or more instances of a VM. The availability sets ensure that the VM instances are always running on different fault and update domains of the Azure platform, so that at least one instance is always online.

Let's look at the next novelty in this illustration: if you look closely, you can see an instance of the Azure Load Balancer serving as a new entry point to the architecture. The load balancer has the task of forwarding incoming internet requests to the provided VMs.

The load balancer requires the following additional resources to perform its tasks:

• Public IP address: A public IP address is needed for the load balancer to receive internet traffic.
• Frontend configuration: This associates the public IP address with the load balancer.
• Backend address pool: This contains a list of the NICs for all resources that will receive the incoming traffic. The assignment to the NICs usually takes place via so-called VIPs, but can also be defined via public or private IPs.

Not shown in the picture are the following resources:

• Load balancer rules: Load balancer rules are used to distribute network traffic among all the resources in the backend address pool.
• Network address translation (NAT) rules: NAT rules are used to route traffic to a specific resource. But beware if you want to enable, for example, the RDP for your VMs, you must create a separate NAT rule for each VM.

Now, we know all of the basics, it is time to make a complex architecture (N-tier architecture) out of this. Let's take a look at the following diagram:

What is different here? The architecture is again based on the pattern for multiple resources, but this time, the design is repeated several times because the architecture is divided into, at least, the following three levels:

• Web Tier or frontend-application
• Business Tier or business logic
• Data Tier

The following levels are not required, but nevertheless often present:

• Management tier
• Active Directory

Actually, all existing levels within this architecture are also single subnets of the VNet.

The entry point for this architecture is, again, the Azure Load Balancer, which is only used to distribute incoming internet traffic to the web tier; the Azure Internal Load Balancer (ILB) is then used for all other levels.

Let's go back to distribution from incoming internet traffic. Not visible but still present, are the numerous NSGs that are respectively associated with the subnet. An NSG is used to regulate network traffic by allowing or denying network traffic. For our architecture, this means, for example, that you can use the help of an NSG to decide that the data from the web tier, can only be passed on to the business tier.

Now, I have some additional information about the optional architectural layers:

• Management tier (also known as jumpbox or bastion host): The management tier includes a secure VM on the network that administrators (or DevOps) use to connect to the other VMs. Note that most of the time, the management tier has an NSG that allows remote traffic only from public IP addresses on a safe list. The NSG should also permit the use of the RDP. The management tier is also a good place to install a monitoring solution, such as Nagios or Zabbix, that can give you an insight into response time, VM uptime, and the overall health of your system.
• Active Directory tier: This includes a VM with an installed Active Directory Domain Service (AD DS). An Active Directory tier is only required if you use an SQL Server AlwaysOn Availability Group as a Data Tier. Prior to Windows Server 2016, SQL Server AlwaysOn Availability Groups must be joined to a domain. This is because availability groups depend on the Windows Server Failover Cluster (WSFC) technology.

In conclusion, I would like to present you with a variant of N-tier architecture: N-Tier architecture – multi-regions. This variant is designed for high availability and as a disaster recovery infrastructure. Let's take a look at the following diagram:

What is different here? The architecture shown here is divided into three resource groups. Two resource groups (located in two Azure regions) are based on the already presented N-tier architecture and are thus identical.

One of these resource groups is called primary resource group and is for daily use. The other resource group (called secondary resource group) serves as a failover.

The third resource group only includes an instance of Azure Traffic Manager as a resource. Azure Traffic Manager is the new entry point for this architecture and routes incoming requests to one of the regions. During normal operations, it routes requests to the primary resource group. If that region becomes unavailable, the traffic manager fails over to the secondary resource group.

Not shown in the figure but still mostly available, is the VPN gateway connection between the Primary RG and Second RG. With this VNet-to-VNet connection, you can enable network traffic between the two VNets, and a type of synchronization.

Where do we go from here? In the last section of the chapter, I tried to introduce you to the basic architectures from the area of Azure networking. You now know the individual components of a VNet (or at least most of them) and have thus acquired a certain basic knowledge of the topic.

In the next sections of the chapter, we will now discuss some aspects of the topic again, this time, in detail. We will begin with the area of Connectivity.