Azure VNets and VNet Connectivity

Free AWS Course for AWS Certified Cloud Practitioner (CLF-C01) Start Now!!

FREE Online Courses: Enroll Now, Thank us Later!

Azure VNet Connectivity is one of the most popular services which is used by organizations. Administrators rely on this service for seamless development. So, in today’s article, we will cover all the information about Azure VNets and VNet Connectivity. Let us begin.

What is Azure VNet?

In a typical IT environment, we have multiple virtual networks, and the workloads in these virtual networks must communicate with one another.

As a result, we will go over some connectivity scenarios that can be used to enable communication between workloads in different virtual networks.

about azure vnet

The virtual networks can be from different subscriptions and in different regions. When you connect VNets from different subscriptions, they do not have to be associated with the same Active Directory tenant.

This configuration establishes a link between two virtual network gateways. This article is not about VNet peering.

Depending on the deployment model of your VNet, you can create this configuration using a variety of tools.

The steps in this article are applicable to the Azure Resource Manager deployment model as well as the Azure portal. Use the dropdown to select a different deployment model or deployment method article.

Azure deployment model

Azure VNet-to-VNet

A VNet-to-VNet connection is a quick and easy way to connect VNets. When you use a VNet-to-VNet connection type (VNet2VNet) to connect one virtual network to another, it’s similar to creating a Site-to-Site IPsec connection to an on-premises location.

Both connection types use a VPN gateway to provide a secure tunnel with IPsec/IKE and communicate in the same way. They differ, however, in how the local network gateway is configured.

When one creates a VNet-to-VNet connection, the local network gateway address space is created and populated automatically. When one VNet’s address space is updated, the other VNet automatically routes to the updated address space.

A VNet-to-VNet connection is typically faster and easier to establish than a Site-to-Site connection. The local network gateway, on the other hand, is not visible in this configuration.

If you know you want to specify additional address spaces for the local network gateway, or if you plan to add additional connections later and need to adjust the local network gateway, use the Site-to-Site steps to create the configuration.

Point-to-Site client pool address space is not included in the VNet-to-VNet connection. Create a Site-to-Site connection between the virtual network gateways or use VNet peering if you need transitive routing for Point-to-Site clients.

Site-to-Site (IPsec)

If an organization has a complicated network configuration, then you might choose to connect your VNets via a Site-to-Site connection.

When you follow the Site-to-Site IPsec steps, you must manually create and configure the local network gateways.

Each VNet’s local network gateway treats the other VNet as a local site.

These steps allow you to specify additional address spaces for traffic routing by the local network gateway. If the address space for VNet changes, the corresponding local network gateway must be manually updated.

Azure VNets Peering

We can connect two VNets in the same or different regions using virtual network peering in Azure.

Peering can be used if both virtual networks are in Azure and also in the same region. As a result, the workloads in those virtual machines can communicate with one another.

Traffic between virtual machines in peer virtual networks is routed directly from the Microsoft backbone infrastructure, rather than via a gateway or the public Internet.

We can set up hub-and-spoke networks, with the virtual hub network hosting infrastructure components like a virtual network appliance or a VPN gateway. Each spoke virtual network could then communicate with the hub virtual network. Traffic in the virtual hub network can pass through virtual network appliances or VPN gateways.

When virtual networks have peered, the gateway in the peered virtual network can also be configured as a transit point to an on-premises network.

Points to Remember

  • Traffic between virtual machines in peer virtual networks is routed directly from the Microsoft backbone infrastructure, rather than via a gateway or the public Internet.
  • We can set up hub-and-spoke networks, with the virtual hub network hosting infrastructure components like a virtual network appliance or a VPN gateway.
  • Each spoke virtual network could then communicate with the hub virtual network. Traffic in the virtual hub network can pass through virtual network appliances or VPN gateways.
  • When virtual networks have peered, the gateway in the peered virtual network can also be configured as a transit point to an on-premises network.

Azure Global Peering

We can use Global peering if we have a virtual network in Azure that spans multiple regions. VNet peering and Global VNet Peering both support gateway transit.

Site-to-Site VPN: If we have an on-premises virtual network and additional virtual networks in other cloud providers. We can use Site to site VPN to connect our virtual network in Azure to the network in an on-premises data center.

Express Route: If we have a business requirement that this connection between our on-premises data center and virtual network be on a private channel of communication, we can use Express Route.

Points to Remember

  • Peering between VNets is only permitted within the same subscription.
  • It is permitted between VNets in different subscriptions under the same AD tenant.
  • It is also permitted between VNets in different subscriptions located in different AD tenants.

Azure VPN Gateway

A VPN gateway is a type of virtual network gateway that is used to send encrypted traffic over the public internet between an Azure virtual network and an on-premises location.

VPN gateways serve as a go-between for both sides of virtual networks. If the workloads in those virtual networks need to communicate with one another, they will do so through this encrypted channel of communication between the VPN gateways of both virtual networks.

When we plan to deploy a VPN gateway into Azure, we can configure a number of related settings:

1. Gateway SKUs: We must choose the SKU that best meets our needs based on the types of workloads, throughputs, features, and SLAs.

2, Zone-Redundant Gateways: When we use zone-redundant gateways, we can benefit from zone-resiliency to access your mission-critical, scalable service on Azure.

3. Connection Types: Connection types include IPsec, Vnet2Vnet, ExpressRoute, and VPNClient.

4. VPN Types: The VPN type that we select is determined by the connection topology that we want to establish as well as the VPN Device” It can be either a policy-based or a route-based VPN.

5. Gateway Subnet: Before you create a VPN gateway, you must first create a gateway subnet called ‘GatewaySubnet,’ and you must not deploy anything else into that subnet.

6. Local Network Gateway: A local network gateway is a device that represents your on-premises location, such as VPN devices and addresses prefixes.

7. Connection Topologies: Site-to-site, multi-site, point-to-site, Vnet-to-Vnet, and express route are the connection topologies.

8. Monitoring and Alerts: Tracks key metrics and sets alerts.

Why use Azure VNets?

1. Cross-region geo-redundancy and geo-presence

  • Without using internet-facing endpoints, you can set up your own geo-replication or synchronization with secure connectivity.
  • You can set up highly available workloads with geo-redundancy across multiple Azure regions using Azure Traffic Manager and Azure Load Balancer. You can, for example, configure SQL Server Always On availability groups across multiple Azure regions.

2. Regional multi-tier applications with isolation or administrative boundaries

You can set up multi-tier applications with multiple virtual networks that are connected together within the same region for isolation or administrative reasons.

Multi-site configurations can be combined with VNet-to-VNet communication. These configurations enable you to create network topologies that combine cross-premises connectivity with inter-virtual network connectivity, as illustrated in the diagram below:

why use azure vnet

Conclusion

Thus, we are at the final section of this article. We have learnt about Azure VNets and Vnet Connectivity which is one of the most popular services used by organizations. Thus, we hope you enjoyed the article and Happy Learning.

Did we exceed your expectations?
If Yes, share your valuable feedback on Google

follow dataflair on YouTube

Leave a Reply

Your email address will not be published. Required fields are marked *