Designing Azure Network

Creating a virtual network to experiment with is easy enough, but chances are, you will deploy multiple virtual networks over time to support the production needs of your organization. With some planning, you will be able to deploy virtual networks and connect the resources you need more effectively.

Your network design will have a significant impact on the Invoice , so it’s very important to choose the right model for your cloud infra.

Managing the network in Azure or any other cloud solutions are entirely different from your on prem network. If you look this from the OSI view the Physical layer and data link layer is managed by Azure , At layer 3 (network layer), we get the protocol IP. Protocols like TCP, UDP and ICMP are implemented on top of IP. When we create a network on Azure , it is created by Microsoft at layer 3 ;the network (IP) layer.

One question that may come into mind is, whether we can create VLANS on Azure or not? on Azure, we don’t have access to layer 2 so we cannot create VLANS. vNets are created using a technique called overlay network. Overlay Network is built on top of other networks and it allows creating multiple networks (with conflicting address space) on top of same underlying shared network. Its done using technology similar to hyper-v network Virtualization

Let’s see look at some basic considerations while planning the network on Azure .

Naming

All Azure resources have a name. The name must be unique within a scope, that may vary for each resource type.

Regions

All Azure resources are created in an Azure region and subscription. A resource can only be created in a virtual network that exists in the same region and subscription as the resource.

Network latency

When deciding which region(s) to deploy resources in, consider where consumers of the resources are physically located.
You can use https://www.azurespeed.com/ to identify the latency from your location but you also needs to consider the consumers location to choose the right region.

Data residency, sovereignty and compliance

If you have data residency, sovereignty, compliance, or resiliency requirements? If so, choosing the region that aligns to the requirements is also critical.
https://azure.microsoft.com/en-us/global-infrastructure/geographies/

Resiliency across Azure Availability Zones

Availability Zoness is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region.
You can deploy resources, such as virtual machines (VM) to different availability zones within the same virtual network. Not all Azure regions support availability zones however.

Subscriptions

You can deploy as many virtual networks as required within each subscription, up to the limit. Some organizations have different subscriptions for different departments, for example.

             We also needs to consider network Security and connectivity requirements wile deploying the network.

Designing our network. 

We need to Design the network for best performance and security, some of the organizations will give more importance for the security where others needs the best performance.
Here is the some consideration for planning your workloads in Azure, we are only looking at the network requirements.

1.Catalog your software and workloads to deployed in Azure
2.Plan the destination(s) for each of your workloads
3.Plan the security requirements for workloads

Network Topology 

Lets us look at some commonly used network typologies in Azure .

1.Hub-Spoke Network Topology

                                  The hub is a virtual network in Azure that acts as a central point of connectivity to your on-premises network. The spokes are virtual networks that peer with the hub, and can be used to isolate workloads. Traffic flows between the on-premises datacenter and the hub through an ExpressRoute or VPN gateway connection.

Typical uses for this architecture include:

• Workloads deployed in different environments, such as development, testing, and production, that require shared services such as DNS, IDS, NTP, or AD DS. Shared services are placed in the hub virtual network, while each environment is deployed to a spoke to maintain isolation.
• Workloads that do not require connectivity to each other, but require access to shared services.
• Enterprises that require central control over security aspects, such as a firewall in the hub as a DMZ, and segregated management for the workloads in each spoke.

2.Hybrid Network

The architecture implements a DMZ, also called a perimeter network, between the on-premises network and an Azure virtual network. All inbound and outbound traffic passes through Azure Firewall.

This architecture requires a connection to your on-premises datacenter, using either a VPN gateway or an ExpressRoute connection. Typical uses for this architecture include:

• Hybrid applications where workloads run partly on-premises and partly in Azure.
• Infrastructure that requires granular control over traffic entering an Azure virtual network from an on-premises datacenter.
• Applications that must audit outgoing traffic. This is often a regulatory requirement of many commercial systems and can help to prevent public disclosure of private information.