--- title: "IaaS" canonical: "https://docs.aryaka.com/space/KNOW/1295188070/IaaS" format: markdown --- Aryaka offers customers a fully managed multi-cloud connectivity solution for connecting to the industry leading infrastructure as a service (IaaS) providers. To connect to an IaaS provider, refer to the following deployment topics: Alibaba Alibaba IPsec-VPN Alibaba Partner Express Connect AWS AWS connectivity with Aryaka AWS configuration for London POP AWS ECX configuration Azure Azure connectivity with Aryaka Azure ExpressRoute Portal Azure ExpressRoute Power Shell Azure VPN Azure site-to-site VPN Eagle Cloud Eagle Cloud Connect Equinix Fabric Equinix Fabric connectivity with Aryaka Cloud Services Extension with Equinix Fabric Google Interconnect Google Partner Interconnect IBM IBM Cloud Direct Link Connect 2.0 Oracle Oracle IPsec configuration Oracle FastConnect Based on the region of your instance, Aryaka provides the following options to connect to an IaaS provider:  Private Connect Secure VPN Internet These options are illustrated in the following graphic, then described in the sections that follow. Private Connect In Private Connect mode, Aryaka acts as a connectivity provider by establishing a direct, low latency, high performance private layer 2 connection with leading IaaS vendor solutions like Microsoft ExpressRoute, AWS Direct Connect, Google Interconnect, and so on. Aryaka leverages its high bandwidth, redundant layer 2 virtual circuits with Equinix Cloud Exchange (ECX) to connect to any IaaS vendor. This connection type reduces the deployment time as the connections are always active.  Depending on the region you want to connect to, there are two options available:  Local connection—Virtual private connection to a vendor that is present in the  same ECX geographic location. Refer to the linked topics above for the latest list of supported regions for each vendor. Remote connection—Virtual private connection to a service provider that is present in a  different  ECX geographic location. Contact Aryaka Support to understand available regions for remote connections. Private Connect supports both private and public peering. Private peering should be used when all resources within your region are private resources and are accessible only using internal IPs. Public peering should be used when there are publicly accessible resources available in your region. In either case, a BGP session is configured between the cloud instance and Aryaka to exchange the subnets dynamically to establish an end-to-end connection between your remote sites and the cloud instance. Secure VPN In Secure VPN mode, Aryaka connects to your cloud instance using an IPsec VPN over the internet. Secure VPN ensures that the traffic between the Aryaka POP and IaaS vendor is always encrypted.  This type of connection is typically used when the configured region is not supported by Aryaka for Private Connect or if layer 2 solutions are not available from the IaaS vendor. Internet In Internet mode, Aryaka connects to your cloud instance over the internet. This is useful when the cloud instance has publicly accessible resources like web servers.   Redundancy in Hosted Cloud services Most of the IaaS vendors—including, but not limited to AWS, GCP, and Azure—support redundant connections between the on-premises and the cloud instances, regardless of how they are connected. To create a resilient network setup, each Aryaka POP comprises multiple servers and routers interconnected to support redundant connections to any IaaS vendor using Direct Connect (private/public), IPsec VPN (private), and Virtual Office (public).  In general, the network is configured as follows: Aryaka configures two sites that represent two independent connections to the IaaS vendor. They are referred to as primary site and backup site in this document.   Each site is configured either on different POPs or on different servers on the same POP to support redundancy.  All servers are directly connected to redundant pairs of edge routers and core routers using cables. The two edge routers cross-connect with the ECX Fabric, providing a high availability and a low latency Direct Connect to the cloud resources. The core routers are configured with different ISP providers to connect to the cloud instance either using IPsec (private) or Virtual Office (public). Aryaka prefers configuring the sites on two different POPs that are geographically closest to the cloud instance to leverage POP redundancy. If this is not possible due to geographical limitations, the sites may get deployed on different servers of the same POP.  The sections that follow describe and illustrate the different redundancy types: Redundancy with Direct Connect Redundancy without Direct Connect IPsec VPN Virtual Office Redundancy with Direct Connect (private and public peering) Redundancy is achieved as follows:  Traffic from an ANAP or CPE in a branch office is received on the source POP from redundant pairs of IPsec connections.  Aryaka routes the traffic to the POP on which the primary site is configured (either destination POP A or destination POP). Aryaka configures the routing such that traffic is routed through the primary site to the cloud instance as follows: Server A > Edge Router A > ECX Fabric > Primary Virtual Circuit (VC). If either Server A or Edge Router A, or the entire destination POP A fails, or if the Primary VC goes down, the traffic is routed through the backup site using Server B > Edge Router B > ECX Fabric > Backup VC. Virtual circuit on two POPs Virtual circuit on a single POP Redundancy without Direct Connect When the cloud instance is in a region that is not covered by Aryaka Direct Connect, the POPs are capable of providing IPsec tunnels in a high availability (HA) configuration  and Virtual Office over the internet to access private and public resources respectively.   IPsec VPN (private) Redundancy is achieved either with a single POP or two POPs.  Aryaka routes the incoming traffic to the destination POP A that is hosting the primary site (or the destination POP on which both the primary and backup sites are configured). Traffic gets routed through Server A > Core Router A > Primary IPsec > VPN Gateway. The active ISP on the router is used to carry this traffic.  If Server A, Core Router A, or the destination POP A fails, the primary site is declared down. The traffic then switches to Backup Site that uses Server B > Core Router B > Secondary IPsec > VPN Gateway.   IPsec connections using two POPs IPsec connections using a single POP Virtual Office (public)  For publicly accessible resources, Aryaka recommends using a Virtual Office site type. Virtual Office sites do not support inbound traffic. All traffic is initiated by a branch device that is then connected to the Source POP (with or without an ANAP at the site). This traffic is carried to a primary site on destination POP A, which is then  source-natted  (SNAT) by the POP. This results in the traffic leaving the destination POP A having been assigned the public IP of the POP. Return traffic travels to the POP where is it destination-natted  (DNAT) back to the private IP of the branch. The two core routers in the POP work in active/passive mode. The active core router's ISP is used to send the traffic over the internet.   Redundancy, in this case, is achieved at the POP and ISP levels. Virtual Office redundancy using two POPs Virtual Office redundancy using a single POP In this topic