The course is part of these learning pathsSee 2 more
Cloud-based virtual networks are software based, and they provide a standard way to organize and isolate Virtual Machines running in the cloud. A virtual network controls addressing, DNS settings, security policies, and routing tables.
Virtual Networks which are commonly referred to as “v-nets”, are isolated from one another. Due to the isolation, you can create networks for development, testing, and production that use the same address blocks.
To allow even further isolation, v-nets support subnets, which allow you to segment the network. Subnets will allow you to break out VMs by their purpose, which is common with tiered architectures. For example, if you have an application broken out into front-end and back-end tiers, then you might want to create two subnets, one for the front-end VMs, and another for the back-end tier.
If you're familiar with traditional networking components then you're going to feel right at home working with v-nets. So, if you're looking to learn more, then start in on the first lesson!
|Lecture||What you'll learn|
|Intro||What will be covered in this course|
|Overview||The componets of virtual networks|
|Creating a v-net||Creating a virtual network part 1|
|Completing the v-net||Creating a virtual network part 2|
|Application Gateway||The application load balancer|
|User defined routes||Using route tables|
|Traffic Manager||DNS based load balancing|
|Hybrid networking||VPNs and express route|
|Final thoughts||Wrapping up the course|
Welcome back! In this lesson we’ll cover hybrid networking options.
Cloud migration is a long-term process, not an immediate one. The bigger the company, the longer the process will take, and it can take years. To confuse matters, some assets may never be migrated for security or other reasons, so a complete migration will never happen.
Thus, hybrid solutions are required. Services will be migrated from on-premise to the cloud over time, and so they need to integrate seamlessly with on-premise services.
Confidentiality is an important requirement for a service used to connect to on premise datacenters with a Virtual Network of resources in Azure. Most of the time, the connection goes through the public Internet where it’s susceptible to attack.
Virtual Private Networking, commonly referred to as VPN, is a technology that allows reserved connections between nodes throughout the public Internet. It ensures communication are kept secret with encryption, ensuring the communicating parties are who they say they are and preventing “man in the middle” attacks.
VPNs are a scalable solution which can accomplish many goals. It is possible to connect to a cloud VPN from a single computer, to connect an on-premise network to the VPN, or to connect multiple virtual networks to each other.
Point-to-Site VPN technology is the easiest way to connect to a remote Virtual Network through the public Internet. To do this, you have to install software on the client PC that will connect with the VPN. This software guarantees a secure, encrypted connection to the cloud resources, as if they were on the same physical network as the PC.
This is a practical solution only when few users need to connect to the VPN. Typical scenarios would be remote administration or troubleshooting. Also, it is a good solution during development, for remote worker or debugging sessions.
It is not, however, the best solution when the number of connections start increasing, or when an entire network needs to reach the remote network. A remote P2P VPN gateway has limitations accepting more than a specific number of connections and can be difficult to manage, as every connection has to be defined independently.
Site-to-site VPN is a single private connection from an on-premise network to the remote Virtual Network, over the public Internet, that projects an entire on premise LAN to the remote Azure Virtual Network. The single connection is shared among all the on-premise nodes accessing the remote endpoints.
A hardware appliance can be used to build up a Site-to-Site VPN. Not all networking appliances, like consumer routers, supports S2S VPNs, so a network upgrade may be required. There is also the possibility of using a software appliance, installed on a server inside the LAN. For example, Windows Server has a routing service to connect the lan to the VPN.
There can be issues with the quality and reliability of the public Internet connection. In general it is not possible to guarantee Internet performance, especially if corporate demand increases. There are too many issues not under company control.
So instead, you can use ExpressRoute. ExpressRoute is a private connection for an on-premise datacenter to Azure datacenter. It’s a dedicated connection co-located in third-party connection providers all around the world. Traffic doesn’t travel in the public Internet, but is kept private to ensure reliability, faster speeds, lower latencies and security.
SLA is guaranteed by redundant connections to the Microsoft Edge network.
Different performances levels can guarantee from 50Mbps/s to 10Gbps/s throughout network service provider or exchange provider. The key factor here is that the connection is not public, and can reach high level of security and reliability.
Performances are ensured by layer 2 or layer 3 Ethernet connections between on-premises network node and the Microsoft Cloud endpoints. Connectivity can be from an any-to-any (IPVPN) network, a point-to-point Ethernet connection, or through a virtual cross-connection via an Ethernet exchange.
ExpressRoute is ideal for data storage access, backup, and disaster recovery. It is also preferred to connect to Office 365 or Dynamics CRM services solutions.
It’s not a service useful or cost effective for everyone. It can become convenient when you have frequent, big data transfers on a daily basis.
As the most expensive solution connection on-premise datacenter, it should be analyzed well, and tested, if S2S VPN connection is enough for company needs before approaching ExpressRoute.
There is the possibility of needing to create multiple Virtual Networks, for security or for performance reasons. In any case, two VNs, even in the same datacenter, should be considered as two VNs that need to establish reliable communications through the public Internet. In this case we require that two VPN gateways allow intra-region traffic among owned VNs. This is a scenario for vNet-to-vNet VPNs solutions.
This ensures multiregion availability of the cloud infrastructure. There are many different scenarios for this: such SQL Server AlwaysOn high availability deployed as Infrastructure as a Service. Or this can be useful for distributing geographically-distributed partitions in NoSQL solutions, deployed on VM connected to the different Virtual Networks.
If you need to access Virtual Networks from multiple on-premise sites, such as when a company has multiple geographically distributed physical locations, then you need to share a connection to the same Azure Virtual Network. This network configuration is commonly known as a hub-and-spoke topology.
Okay, that’s going to wrap up this lesson. In the next lesson we’ll wrap up the course with final thoughts. So, if you’re ready to wrap up this course, then let’s check out the next lesson!
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.