In this post, Senior ADM Fidelis Ekezue shares insights into similarities and differences between Azure VNets and AWS VPC.

It’s important to note that in the cloud, features and capabilities are in a state of constant change to improve services and adapt to industry demands.  To the best of our knowledge, the information in this article is accurate at the time of the publication (September 2017).  This is not a marketing blog nor is it intended to be a competitive analysis, rather, to help end-users better understand similarities and differences in these services to make informed decisions based on our experience.  Constructive comments, clarifications, and perspective are welcomed in the post comments.  Be sure to include links to supporting information if you would like to contribute.  Both of these technologies are evolving rapidly so always consult the latest product documentation to confirm capabilities at any given time.

Cloud computing has changed what we know about software design and the role/functions of data centers. The journey to the cloud begins with choosing a cloud provider and provisioning private networks or extending their on-premise network. Customers looking to provision their resources in the cloud can choose from the different private networks offered by the various cloud providers. The two most deployed private networks are Virtual Network (VNet) and Virtual Private Cloud (VPC) from Microsoft and Amazon respectively. This blog looks at the similarities and differences between these two private network offerings with the goal of informing potential customers on what differentiates the two private networks and assist in their decision on which is suitable for their workload. In this first blog in the series, I will cover some basic components of every cloud network. This current blog will not compare the pricing due to its complexity, it may be covered in a future post.

Conceptually, both the Azure VNet and AWS VPC provide the bedrock for provisioning resources and service in the cloud. Both networks provide the same building blocks but with a degree of variability in implementation. Following is the summary of some of these building blocks:

• Subnet – For effective design and control of resources deployed on the cloud, both Azure VNet and AWS VPC segregate the networks with subnets. An AWS VPC spans all the Availability Zones (AZs) in that region, hence, subnets in AWS VPC are mapped to Availability Zones (AZs). A subnet must only belong to one AZ and cannot span AZs. Azure VNet subnets are defined by the IP Address block assigned to it. Communications between all subnets in the AWS VPC are through the AWS backbone and are allowed by default. AWS VPC subnets can either be private or public. A subnet is public if it has an internet gateway (IGW) attached. AWS allows only one IGW per VPC and the public subnet allow resources deployed in them access to the internet. AWS creates a default VPC and subnets for each region. This default VPC has subnets for each region where the VPC resides, and any image (EC2 instance) deployed to this VPC will be assigned a public IP address and hence has internet connectivity. Azure VNet does not provide a default VNet and does not have private or public subnet as in AWS VPC. Resources connected to a VNet have access to the Internet, by default.
• IP Addresses – Both AWS VPC and Azure VNET use non-globally routable CIDR from the private IPv4 address ranges as specified in RFC 1918 – addresses from this RFC are not globally routable — but customers can still use other public IP addresses. Azure VNet assigns resources connected and deployed to the VNet a private IP address from the CIDR block specified. In Azure VNet, the smallest subnet supported is /29 and the largest is a /8. AWS also allows IP addresses from the same RFC 1918 or publicly routable IP blocks. Currently, AWS does not support direct access to the internet from publicly routable IP blocks, hence they are not reachable from the internet even through the Internet gateway (IGW). They are only reachable via the Virtual Private Gateway. Because of this, Windows instances cannot boot correctly if launched into a VPC with ranges from 224.0.0.0 to 255.255.255.255 (Class D and Class E IP address ranges). For the subnet, AWS recommends a minimum address block of /28 and maximum of /16. Microsoft Azure VNet support for IPv6 is limited at the time of writing this blog, however, AWS VPC supports IPv6 for all regions except China, as of January 2017. For IPv6, the VPC is a fixed size of /56 (in CIDR notation) and the subnet size is fixed to be a /64. In IPv6, every address is internet-routable and can talk to the Internet by default. AWS VPC provides Egress-Only Internet Gateway (EGW) for resources in the private subnet. It blocks incoming traffic while still allowing outbound traffic. AWS allows enabling IPv6 for existing resources, and for resources in the private subnet that require access to the internet, an Egress-only internet gateway is provided. The egress-only internet gateway will allow access to the internet but blocks any incoming traffic. Understanding how to allocate IP Addresses from these CIDR blocks is key to designing an AWS VPC network because changing subnet IP Addresses after design is not trivial. Azure VNet offers more flexibilities in this area – IP addresses of the subnet can be changed after the initial design. But resources in the current subnet will need to be migrated off the current subnet.
• Routing Table – AWS uses the route table to specify the allowed routes for outbound traffic from the subnet. All subnets created in a VPC is automatically associated with the main routing table, hence, all subnets in a VPC can allow traffic from other subnets unless explicitly denied by security rules. In Azure VNet, all resources in the VNet allow the flow of traffic by using the system route. You don’t have to configure and manage routes because by default, Azure VNet provides routing between subnets, VNets, and on-premises networks. The use of system routes facilitates traffic automatically but there are cases in which you want to control the routing of packets through a virtual appliance. Azure VNet uses the system route table to ensure that resources connected to any subnet in any VNet communicate with each other by default. However, there are scenarios when you might want to override the default routes. For such scenarios, you can implement the user-defined routes (UDR) — control where traffic is routed for each subnet — or/and BGP routes (your VNet to your on-premises network using an Azure VPN Gateway or ExpressRoute connection). The UDR applies to only traffic leaving the subnet and can provide a layer of security for Azure VNet deployment, if the goal of UDR is to send traffic to some kind of inspection NVA or the like. With UDR, packets sent to one subnet from another can be forced to go through a network virtual appliance on a set of routes. In a hybrid setup, Azure VNet may use any of the three route tables – UDR, BGP (if ExpressRoute is used) and System routing tables. In Azure VNet, the subnet relies on the system routes for its traffic until a route table is explicitly associated with a subnet. Once an association is established, i.e. a UDR and/or a BGP route exists, routing is done based on Longest Prefix Match (LPM). In cases where there is more than one route with the same prefix length, a route is selected based on its origin in the following order: User defined route, BGP route (when ExpressRoute is used) and System route. Whereas, in AWS VPC the routing tables may be more than one, but of the same type.
• Security – AWS VPC provides two levels of security for resources deployed to the network. The first is called Security Groups (SG). The Security Group is a stateful object that is applied at the EC2 instance level – technically, the rule is applied at the Elastic Network Interface (ENI) level. The response traffic is automatically allowed once a traffic is allowed. The second security mechanism is called Network Access Controls (NACLs). NACLs are stateless filtering rules that are applied at the subnet level and applies to every resource deployed to the subnet. It’s stateless because if an ingress traffic is allowed, the response is not automatically allowed unless explicitly allowed in the rule for the subnet. NACLs operates at the subnet level by examining the traffic entering and exiting the subnet. NACLs can be used to set both Allow and Deny rules. You can associate a NACL with multiple subnets; however, a subnet can be associated with only one NACL at a time. The NACL rules are numbered and evaluated in order, starting with the lowest numbered rule, to determine whether traffic is allowed in or out of any subnet associated with the network ACL. The highest number that you can use for a rule is 32766. The last rule numbered is always an asterisk, and denies traffic to the subnet. Note, you reach this rule only if no rules in the NACL list matches the traffic. Azure VNet provides Network Security Groups (NSGs) and it combines the functions of the AWS SGs and NACLs. NSGs are stateful and can be applied at the subnet or NIC level. Only one NSG can be applied to a NIC, but in AWS you can apply more than one Security Group (SG) to an Elastic Network Interface (ENI)
• Gateways – Both VNet and VPC offer different gateways for different connectivity purposes. AWS VPC uses mostly three gateways, four, if you add the NAT gateway. AWS allows one Internet Gateway (IGW) to provide connectivity to the internet via IPv4 and Egress-only Internet Gateway for internet connectivity to resources with IPv6. In AWS, any subnet without the IGW is regarded as private subnet and have no internet connectivity without NAT gateway or NAT instance (AWS recommends NAT Gateway for high availability and scalability). Another AWS gateway, Virtual Private Gateway (VPG) allows AWS to provide connectivity from AWS to other networks via VPN or Direct Connect. On the non-AWS network, AWS requires Customer Gateway (CGW) on the customer side to connect to AWS VPC. Azure VNet provides two types of gateway namely VPN Gateway and ExpressRoute Gateway. The VPN Gateway allows encrypted traffic for VNet to VNet or VNet to on-premises location across a public connection or across Microsoft’s backbone in the case of VNet to VNet VPN. However, the ExpressRoute and VPN Gateway also require a gateway subnet. The gateway subnet contains the IP addresses that the virtual network gateway services use. Azure VNET to VNET can connect natively via VPN but in AWS, such VPC to VPC requires a 3rd party NVA if the VPCs are in different regions.
• Hybrid Connectivity – Both AWS VPC and Azure VNet allow hybrid connections using VPN and/or Direct Connect and ExpressRoute respectively. With Direct Connect or ExpressRoute, connections of up to 10Gbps are available. An AWS DC connection consists of a single dedicated connection between ports on your router and an Amazon router. With one DC connection, you can create virtual interfaces directly to public AWS services (for example, to Amazon S3) or to Amazon VPC. Before using AWS DC, you must create a virtual interface. AWS allows 50 virtual interfaces per AWS Direct Connect connection, and this can be increased by contacting AWS. AWS DC connection is not redundant and a second connection is needed, if redundancy is required. AWS VPN creates two tunnels between AWS VPC and the on-premises network. To provide fault tolerance for Direct Connect, AWS recommends using one of the tunnels to connect to the on-premises data network via VPN and BGP. Azure ExpressRoute also provides two links and an SLA for connectivity — Azure guarantees a minimum of 99.95% ExpressRoute Dedicated Circuit availability — and hence predictable network performance.

Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality.  Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.