When most organizations migrate to the cloud, they continue to have a significant amount of infrastructure on-premises and they need to connect those local resources with what they’ve deployed in the cloud. Microsoft provides several ways to do this.

The first decision to make is whether you’ll connect them over the internet. You might not want to do this if you’re concerned about the reliability, performance, or security of this method. If any or all of those concerns are deal-breakers for your organization, then you should choose ExpressRoute.

There are four ways to connect to Azure using ExpressRoute. If your infrastructure is colocated in a datacenter that has a cloud exchange, then you can get an Azure cross-connection through the colocation provider. If you’re not in that sort of facility, but you use a WAN provider, then they can make the Azure cloud look like one of your branch offices. The third option is to use a point-to-point ethernet provider.

All three of these methods use a service provider to connect your infrastructure to Azure. Alternatively, if your infrastructure is located in what Microsoft calls an ExpressRoute location, then you can use ExpressRoute Direct. With this method, you connect to Azure directly without going through a service provider. One advantage of ExpressRoute Direct is that it can support connections up to 100 gigabits per second, which is 10 times as much as you can get through a service provider.

Regardless of which of these methods you use, you’ll have a redundant layer 3 connection that doesn’t go over the internet. Routing is handled using BGP.

If you’re okay with using encrypted connections over the internet instead of taking on the expense of a direct connection, then you can put an Azure VPN Gateway in a virtual network. Once you’ve set that up, there are two ways to to create an encrypted connection to it.

For a site-to-site connection, you install a VPN device with a public IP address at your on-premises location. Then you deploy a VPN gateway in your Azure virtual network. It must be in a gateway subnet that doesn’t have any VMs in it. You also have to make sure that the IP address space of the virtual network doesn’t overlap with the address space of your on-premises network. When both sides are ready, you can set up an IPsec tunnel between the two networks.

If you want to connect multiple sites to the same virtual network, you can set up a VPN device at each location and connect them all to the same VPN gateway. You can only have one VPN gateway per virtual network. This is known as a multi-site configuration. All connections to the same VPN gateway share its available bandwidth.

The second way to connect is called point-to-site. With this method, you connect individual computers to the VPN gateway in your virtual network. You don’t have to use a VPN device, so this is suitable for remote workers and telecommuters. It uses the Secure Socket Tunneling Protocol (or SSTP) on Windows devices and IKEv2 VPN on Macs.

Point-to-site connections use certificate-based authentication. To set this up, first you need either a root certificate from a certificate authority or a self-signed root certificate that you create yourself. Next, you generate client certificates from the root certificate. Then you need to install a client certificate on each client device that will be using a point-to-site connection.

You can connect to the same VPN gateway with both site-to-site and point-to-site methods as long as you can use the same configuration for both. The main issue is what type of routing you configure the VPN gateway to use. Site-to-site connections can use either route-based or policy-based routing. For most scenarios, route-based is the best option, because it’s dynamic, requires less maintenance, and can tolerate failures in the network path. Policy-based routing is static, so you have to maintain all of the routes manually. You’d only want to choose this option is you require strict control of your routing.

Multi-site and point-to-site configurations have to use route-based routing, so they can’t share a VPN gateway with a site-to-site configuration that uses policy-based routing, because a VPN gateway can only be configured to support one type of routing.

Even when you’re using ExpressRoute to connect to your Azure virtual networks, there’s still a reason to use a VPN gateway. You can set up a site-to-site connection as a failover in case your ExpressRoute connection goes down. Traffic would only go through the VPN tunnel if the ExpressRoute connection is not available.

You can also use VPN gateways to connect two virtual networks, but it’s much easier to use virtual network peering, which is a newer feature. To do it, go into one of the virtual networks in the portal, select Peerings from the menu, and click Add. Give it a name. I’ll use the name of the first virtual network dash and the name of the second virtual network. To complete the connection, you also need to create a peering in the other direction in the second virtual network. Then choose the subscription where the second virtual network resides, and finally, choose the second VNet.

Okay, it’s done. The peering from vnet1 to vnet2 is showing a status of “Connected”. Let’s check the second peering as well. It’s connected, too. Once the status of both peerings is “Connected”, instances in the two VNets will be able to communicate with each other as if they were in the same VNet.

You can even do this with virtual networks that are in different regions, which is known as global vnet peering. Traffic between them still goes through the Microsoft backbone network rather than the internet, so the connection is private and has high bandwidth and low latency.

When you create a virtual network, Azure automatically creates a route table for each of the subnets. It then adds system default routes to each table. For example, it creates routes so all of the instances within the virtual network can connect to each other. It also creates a catch-all route that sends traffic to the internet if no other route is applicable. If you don’t want traffic to go to the internet, then you need to override it with a custom route, also known as a user-defined route.

Another example of when you’d use a custom route is if you set up a virtual appliance, such as a firewall, and you need to route traffic through it. In this case, in addition to adding a custom route to the table, you’d also need to enable IP forwarding on the network interface that’s attached to the virtual appliance. Otherwise, Azure would prevent it from forwarding traffic.

So far, I’ve been talking about connectivity for VM instances, but it’s also possible to get the same networking benefits with containers. When you create an Azure Kubernetes Service cluster, you can select the advanced networking option and specify a virtual network and subnet to put the cluster in. Then the nodes in the cluster will use the Azure Container Networking Interface plugin to connect to the virtual network. With this setup, Kubernetes pods can communicate with the rest of your network, including your on-premises network through ExpressRoute or a VPN gateway.

And that’s it for external connectivity.