It’s been a while since I have posted in my series intended to help those coming from AWS to get to grips with Azure; however, I was reminded a few days ago about the post I planned to do on networking.
If you’ve not yet read them, parts 1 and 2 can be found here:
When moving from AWS to Azure networking can seem reasonably straightforward, as there are a lot of similar concepts, however, there are enough differences to trip you up along the way. In this article, we’ll have a look at some of the core networking features in Azure and how these line up against their AWS counterparts, along with links to resources if you want to look further. Most of what we are going to look at today relate to IaaS services, although there are some places where PaaS services can be joined in.
VPC and vNets
At the core of any networking in either platform is going to be the virtual network. In AWS this is referred to as “Virtual Private Cloud” or VPC, in Azure, this is a Virtual Network or vNet. Both of these are doing the same thing, providing you with a walled-off virtual network that is yours to do with as you please (within limits) and where everything else that needs to interact with a network sits.
When creating a vNet, you specify a location to place the vNet and an IP address range for the virtual network.
Further Reading: Virtual Networks Overview
As with VPC’s, inside a vNet sit subnets, which allow you to carve up your vNet address range into smaller chunks. Where this differs from AWS is that there is no concept of a private or public subnet, as there is with a VPC. In Azure, all subnets are the same, and whether they are private or public is determined by how you configure the Network Security Groups (more on this later) and virtual machines).
When creating virtual machine network cards, you select which subnet they should join.
In AWS, if you have machines in a private subnet that you need to access the internet, then you needed to add a NAT Gateway to your VPC which allowed this. This gateway had an additional cost. In Azure there is no NAT Gateway required, all machines have outbound access unless your Network Security Group configuration restricts this.
In an AWS VPC, you can configure whether the VPC supports DNS resolution. If enabled the VPC is configured to use the AWS DNS servers, if not it is disabled. In Azure, a vNet is by default configured to use the Azure DNS servers for name resolution, if you wish you can override these with other name servers, or no DNS servers at all.
Further Reading: Name resolution for resources in Azure virtual networks
ACL/Security Groups and Network Security Groups
In the AWS there are two different mechanisms for securing traffic entering or leaving the VPC - Security Groups which act at the virtual machine level, and ACL’s which act at the subnet level. In Azure, there is only a single mechanism, called a Network Security Group or NSG. NSG’s are applied at either the VM level or the subnet level (or both). NSGs can also apply to multiple VMs or Subnets.
As with ACL/Security Groups, NSGs allow you to define a list of inbound or outbound networking rules that limit what traffic can enter or exit the network. These rules are based on IP addresses and ports. A single rule can filter multiple IP ranges and ports, or just one depending on your preference. There are also a set of default rules which apply if none of your rules are met.
NSG’s also include additional features that allow you to filter access to what are called “service tags” which are broad ranges of services such as “Internet”, “Virtual Network” or Azure Services like Storage and SQL.
Further Reading: Security Groups
AWS offers two load balancer options, the Network Load Balancer, which is a layer 4 device, and Application Load Balancer, which is a layer 7 device. In Azure, there is a similar distinction
Azure Load Balancer
The Azure Load Balancer is the layer 4 device and is the default option when you need to load balance traffic. It comes in two variants, an internal or external load balancer, and as the name suggests these have either an internal or external IP. The configuration of these is limited to which ports to load balance over which machines and configuration of a health probe to identify good machines. The Azure Load balancer can also provide inbound NAT translation for exposing machines to the internet.
Confusingly, the Azure Load Balancer also now comes in two SKUs, basic and standard. The basic version is the one that has been around forever and is free to use. The standard SKU is a newer option that offers some more features but has an additional cost. These features include:
- Larger backend pool size, 1000 instances vs 100 on basic
- Backend endpoints can be any VM in the virtual network. With the Basic SKU, you are limited to machines in the same availability set
- Availability Zones - if you wish to take advantage of machines spanning the new availability zones option then you need to use standard
- HTTPS based probes
- Better Diagnostics
- Distinct SLA of 99.99%
My general recommendation would be to make use of the standard load balancer SKU for any production applications.
You do also have the option to utilise 3rd part load balancers via the Azure Marketplace.
Further Reading: What is Azure Load Balancer?
Azure Application Gateway
If you need a layer 7 load balancer, like the AWS Application Load Balancer, then you would look at using the Azure Application Gateway Service. Application Gateway provides a layer 7 load balancer with features such as URL-based routing, redirection, session affinity, SSL termination. For an additional cost, you can also enable a Web Application Firewall (WAF) on the App Gateway to protect your applications based on OWASP core rule sets.
Further Reading: What is Azure Application Gateway?
Route 53 and Azure DNS
AWS offers a DNS service called Route 53, in the Azure world there is a similar service called Azure DNS. As with Route 53, Azure DNS supports both public and private DNS zones and is a global service which now offers a 100% SLA.
Further Reading: What is Azure DNS?
AWS offers a DDoS protection service called AWS Shield, this has a standard tier that applies to all users and then an advanced, paid for, tier that can be enabled for service that requires higher levels of protection.
In Azure, there is a similar service, Azure DDoS protection. The basic tier is applied to all users; there is a paid for “standard” tier that offers higher level protection.
Further Reading: Azure DDoS Protection Standard overview
For outbound traffic filtering AWS does not offer a 1st party solution, instead offering the option to integrate 3rd party solutions such as Aviatrix, Check Point etc. into the clients VPC.
In Azure, it is also possible to integrate these 3rd party solutions, but additionally, Microsoft has also recently announced a preview of the new Azure Firewall product that offers a 1st party solution. Azure Firewall offers outbound FQDN filtering, network traffic filtering rules, outbound SNAT support and monitoring. This service is in preview and limited regions currently.
Further Reading: What is Azure Firewall?
If you need to connect your on-premises network to AWS, you can use the AWS Managed VPN connections service. You would create a VPN gateway in AWS and connect this to your on-premises VPN equipment. In Azure, there is a similar service called Azure VPN gateway. VPN Gateway offers both point to site and site to site connections into your Azure Virtual Network.
To use Azure VPN Gateway you would deploy a gateway device into a dedicated subnet in your vNet, and then configure this to connect to your on-premises resources.
Further Reading: What is VPN Gateway?
AWS Direct Connect and Azure Express Route
Instead of using a VPN, AWS offers their Direct Connection solution to establish a direct private connection between your on-premises network and AWS. Azure offers a similar service called Azure Express Route.
Both of these services require to work with a communications provider within your region to establish the connection between your data centre and AWS/Azure. Both services charge a fee based on the maximum throughput of the connection.
Further Reading: ExpressRoute overview