--- title: "Azure connectivity with Aryaka" canonical: "https://docs.aryaka.com/space/KNOW/1292107963/Azure%20connectivity%20with%20Aryaka" format: markdown --- Modern technologies including cloud, virtualization, and Internet of Things (IoT) are revolutionizing Information Technology (IT) departments and entire enterprises. As technologies and workloads move to the cloud, enterprises must decide how best to upgrade their wide area networks (WAN). Many enterprises still deploy MPLS routers for their WAN, a technology that dates back to the 1990s. Legacy MPLS networks are typically inadequate for handling the volume and variety of traffic on modern corporate networks. An outdated or inappropriate WAN can negatively impact the performance of cloud-based applications and, ultimately, the end user experience. Traditional cloud connections use either IPSec over the Internet, or private MPLS links, neither of which address the current cloud connectivity challenge. Microsoft Azure is an internet-scale computing and services platform hosted in data centers managed and supported by Microsoft. Microsoft's Azure ExpressRoute service allows customers to extend their on-premises networks into the Microsoft cloud over a high-speed L2 private connection directly or indirectly with the help of a third-party connectivity provider. In addition, Aryaka subscribers can establish ExpressRoute connections to Microsoft cloud services (for example, Azure and Office 365) that do not go over the public Internet. Compared to Internet-based connections, ExpressRoute connections offer faster speeds, greater reliability, consistent latencies, and higher security. For more information on connecting your network to the Microsoft cloud using ExpressRoute, see the following documents at microsoft.com:  ExpressRoute introduction ExpressRoute connectivity models Azure ExpressRoute peering types ExpressRoute supports the following peering types: Private peering Microsoft peering These peering types are described in the sections that follow. Private peering In general, private peering enables you to directly connect virtual machines and cloud services on their private IP addresses. This peering uses ExpressRoute BGP sessions between Azure and the external termination points on Aryaka POPs over which the Azure private subnets are learned. Customers decide which private IP addresses are exposed to peering. The private peering that connects Azure virtual machines (IaaS) and cloud services (PaaS) that are deployed in virtual networks is considered a trusted extension of an on-premises network that connects into the Microsoft Azure Network. At time of publication of this document, Microsoft listed the  ExpressRoute route prefix limits  (at microsoft.com) as follows: Up to 4000 IPv4 prefixes and 100 IPv6 prefixes advertised to Azure private peering. This can be increased up to 10,000 IPv4 prefixes if the ExpressRoute premium add-on is enabled. Up to 200 prefixes per BGP session for Azure public and Microsoft peering. Microsoft peering This peering is basically ExpressRoute BGP sessions between Azure and the external termination points on Aryaka POPs over which all routes for Microsoft services and applications are learned. The following services are supported by Microsoft peering: Microsoft 365 Power BI Azure Active Directory Azure DevOps (Azure Global Services community) Azure Public IP addresses for IaaS (virtual machines, virtual network gateways, load balancers, and so on) This list excludes Office 365. Microsoft has documented their Office 365 connectivity preferences in  Azure ExpressRoute for Office 365 (at microsoft.com). Aryaka's multi-cloud connectivity solution Aryaka’s fully managed multi-cloud connectivity solution provides a fast and cost-effective means for connecting to the most widely used IaaS or SaaS platforms. Aryaka’s SD-WAN solution includes the following four components: Aryaka Network Access Point (ANAP) Global private network of more than 40 points of presence (POPs) MyAryaka monitoring and configuration portal Direct connectivity to leading IaaS and SaaS providers Direct and indirect connectivity (using partner peering) to leading IaaS and SaaS providers Aryaka’s cloud solution provides connectivity for both IaaS and SaaS platforms: IaaS connectivity is provided by private connections or IPSec tunnels and SaaS connectivity and application performance is addressed provided using a virtual office (VO). Instead of an office being a physical site, the VO is a virtualized office that hands off traffic from the Aryaka POP to the nearest SaaS entry point. The SaaS traffic travels over the Aryaka backbone from the edge to a SaaS colocation point, ensuring application performance. The following graphic shows the high-level architecture of Aryaka Global Core's multi-cloud (IaaS and SaaS) connectivity. Aryaka is a managed service provider that offers optimized access to your Azure resources by providing a redundant, low latency, and dedicated connection from the Aryaka POPs. This allows customers to establish a highly available end-to-end path between the remote sites and Microsoft Azure using Aryaka’s global, secured private network. Key Aryaka benefits Aryaka helps you bypass the complexity of having to deal with expensive MPLS connections with multiple service providers, interconnections, ports, cloud gateways, and appliances. Aryaka offers SD-WAN as a service that operates on six continents over a global L2 private network with more that 40 points of presence (POPs). A number of the POPs are colocated in the same IaaS data centers used by Azure.  Aryaka offers the following connection options when accessing your resources within different VNets in the Microsoft Azure cloud: ExpressRoute IPSec VPN over Internet Aryaka provides connectivity for your enterprise headquarters, branch and remote offices, and branch and remote users as follows: Enterprise to cloud—Access to Azure resources for users at headquarters, branch offices, and remote locations through a software-defined, application optimized, global private network with a choice of ExpressRoute or IPSec VPN options. Cloud to cloud—Enterprise-wide access to multiple ExpressRoute virtual networks (VNets). Multi-cloud—Enterprise-wide access to applications hosted simultaneously on Azure and other IaaS, PaaS, or SaaS platforms. ExpressRoute is available from Aryaka for the following geographic regions: Azure Location Aryaka POP Location Virginia - East US Ashburn or New Jersey Tokyo - Japan East Tokyo Texas - South Central US Dallas Singapore - Southeast Asia Singapore Seattle Seattle Netherlands - West Europe Amsterdam London - UK South London Hong Kong - East Asia Hong Kong Chicago - North Central US Chicago California - West US San Jose Brazil - Brazil South Sao Paulo Frankfurt - Germany West/Central Frankfurt Dublin Dublin Sydney - Australia Southeast Asia Sydney All the Azure geographic locations are included in an associated geopolitical region. For example, if a resource location is defined as Chicago - Central US, the customer also has connectivity to all other Azure regions in that same geopolitical region (that is, the US) automatically.  Prerequisites and requirements On-premises SD-WAN ANAP device to establish VPN connection to Aryaka POP. Verify that local, on-premises site network subnets do not overlap with the virtual network subnets in Azure VNets. A VNet in Azure cloud must have at least one workload and cannot contain Azure VPN or ExpressRoute gateways. If this gateway exists, it must be deleted. The ExpressRoute circuit must be enabled in a country with direct connectivity to a location listed in the previous table. Customer’s subscription must be registered for ExpressRoute Preview. The following graphic shows customer sites connected to the Azure cloud over the Aryaka Core and using two private ExpressRoute L2 links (primary and secondary). Private access without ExpressRoute  For Azure ExpressRoute locations not listed in the table, the Aryaka POP must connect to the Azure cloud over a VPN. Microsoft Azure supports the following two types of VPNs: Policy based VPNs—Supported on IKEv1 only Route based VPNs—Supported on IKEv1 and v2 For large subnets, policy-based VPNs are not recommended, because it is complicated to manage the large policy tables required for IPSec VPNs.  Aryaka terminates the VPN connection on an external router on the nearest Aryaka POP to the ExpressRoute location, and then continues the connection over an internal network using GRE and BGP protocols. Aryaka provides the following VPN options: An IKEv2 route-based VPN with BGP that is terminated on the Aryaka POP's external routers.  An IKEv1 tunnel with static routing that terminates on the Aryaka POP. The following graphic shows customer sites connected to the Azure cloud over Aryaka (L2/L3) and Internet IPSec VPN (primary and secondary). Public access without ExpressRoute  Customers can connect to their Azure public resources in locations where Aryaka does not have ExpressRoute circuits. Some of the resources are publicly accessible over the Internet, and do not require a VPN (which is also over the Internet) to connect to the Aryaka POP. The public access connectivity is achieved using the Aryaka L2 network and a virtual office (VO) on external routers over the Internet to the Azure cloud. The VO is a virtual instance of a router provisioned by Aryaka for each customer with specific route advertisement to the Azure cloud. The following graphic shows customer sites connected to the Azure cloud over Aryaka (L2/L3) using a VO over Internet for each link (primary and secondary). Azure Virtual WAN Azure Virtual WAN (vWAN) a networking service from Microsoft that provides connectivity to customers' VNets in Azure geographical regions with single point of connectivity. The design also incorporates networking, security, and routing features in one operational interface. It uses a spoke-hub-spoke topology to provide branch connectivity for the following technologies and scenarios: SD-WAN CPE devices (on-premises to Azure) Site-to-site VPN Remote user VPN (point-to-site) Private L2 (ExpressRoute) connectivity Intra-cloud regional connectivity VPN ExpressRoute inter-connectivity vWAN resources The virtual WAN represents the entire customer network in Microsoft Azure. It comprises multiple virtual hubs which are themselves a collection of multiple interconnected resources. This multi-hub architecture ensures vWAN resources remain isolated from each other because they can not contain a common hub. The following resources are available for the virtual WAN: Hub—Represents a common connection point for your Azure services. The hub's endpoints enable connectivity from your on-premises network. Connectivity is achieved using a VPN gateway inside either a site-to-site (S2S) or ExpressRoute circuit. Note that multiple hubs can be created in the same region. Hub virtual network connection—Connects the hub to your virtual network. Note that a virtual network can only be connected to one virtual hub. Hub-to-hub connection—Virtual hubs in a vWAN are typically connected using a full mesh topology. Full mesh connectivity gives flexibility for a branch, user, or VNet connected to a local hub to seamlessly communicate with another hub in the full mesh architecture. Additionally, you can create a full mesh hub-to-hub connected framework that connect VNets within a hub (transiting through the virtual hub), or VNets across a hub. Site—Facilitates a site-to-site connection known as vpnsite . It has a VPN device for example, a SD_WAN appliance that originates and terminates a VPN connection to and from the Azure cloud. Branch—An on-premises SD-WAN appliance, which is located in the customer's physical office location. The connection originates from within the branch and terminates at the destination in the Azure VNets. Aryaka connectivity to Azure vWAN The Aryaka ANAP device is located on-premises at a customer site. It connects directly to the Azure hub gateway —which is subset of the Azure virtual WAN—using two IPSec VPN tunnels (primary and secondary). Note that the hub gateway differs from a virtual network gateway used by ExpressRoute and VPN Gateway. You must create a site-to-site VPN connection to the virtual hub's VPN Gateway deployed in the virtual hub. The VPN traffic terminates on the hub gateway and traverses to the VNets attached to virtual hub deployed in the virtual WAN. This improves the scalability factor by allowing companies to virtually connect their Azure resources geographically. The overall architecture is simplified by the spoke-hub-spoke topology for connecting branches, sites, and Azure instances. The following graphic shows customer sites connected to Azure virtual hubs (in the Azure Virtual WAN) using direct site-to-site VPN and ExpressRoute over Aryaka Global Core.                                                         Related topics Azure ExpressRoute Portal Azure ExpressRoute Power Shell Azure VPN Azure site-to-site VPN At microsoft.com: Azure vWAN introduction ExpressRoute for Office 365 ExpressRoute routing requirements ExpressRoute documentation