Most enterprises we have come across started their cloud adoption by deploying a handful of applications spanning a few Azure VNets in a specific Azure region. Over time, the business needs of these enterprises have evolved and changed and as a result their cloud deployments have evolved as well. What initially started as a few applications in a few VNets in one region have grown over time to become many applications spanning 100s of VNets in multiple cloud regions and in some cases multiple cloud providers. At the same time, networking architectures and designs within Azure have changed over the years. This is because of the newer features and the connectivity options made available to the customers. So as with any of these evolutions, customers end up having different architectures for different applications depending on the timelines when these applications were deployed and what options were available to them.
Many of these architectures are hosting applications which are mission critical or atleast important for the business. So whenever an enterprise tries to move to a different solution they have to make sure that the new solution can co-exist with their existing cloud networking solution.
But before getting into the details, let’s talk about WHY and WHEN enterprises will need to look for a different solution?
All the cloud native networking solutions like all the connectivity options within Azure are built for applications hosted within their own cloud. As soon as enterprises look to embrace other clouds they run into different challenges as every cloud provider has their own cloud-native constructs which in some cases are very specific to their own cloud networking options.
So when the customers are looking to expand their deployments to multiple cloud providers or to on-prem, they require a solution that can abstract the complexity at the same time scale dynamically, offer an on-demand consumption model, provide a standardized and a unified experience when connecting to different cloud service providers. Alkira’s solution provides all these benefits and at the same time provides the flexibility to integrate and co-exist with any of your current cloud networking designs and architectures.
Here in this blog, we will cover the flexibility that the Alkira solution offers and can integrate and co-exist with any of the connectivity options offered within Azure. We will also discuss customer requirements for each of these options and how Alkira helps tackle them seamlessly.
Site-to-site IPSec to VNets
One of the ways customers connect Azure VNet to on-prem and other environments is by building site-to-site IPSec tunnels to the VPN gateway. To connect Azure VNet to Alkira, IPSec tunnels are built from Alkira Cloud Exchange Point (CXP) to the VPN gateway inside the VNet. VNet subnets are advertised to the CXP to direct traffic from CXP to the VNet. For VNet to CXP routing, customers can choose to advertise a default or a custom prefix to the VNet. Default route can be used if the VNet is a greenfield and does not connect to any other networks. While a custom prefix option is recommended If it is a brownfield VNet and already connects to other networks. Figure 1 explains the topology for site-to-site IPSec between Alkira and the Azure VNet. To connect on-prem branches and users to CXP, you can use IPSec, SDWAN, direct connect, express route or secure connect (Alkira’s remote access solution).
Figure 1
By default, Alkira provides availability zone (az) level redundancy. If the application is mission critical, you also have an option to configure inter-region or inter-cloud redundancy by defining a failover CXP which can be in the same public cloud or in another cloud provider. This option is available in the workflow when you connect a VNet to the CXP.
Figure 2
Connect VNets using a peering connection
Instead of directly terminating VNets over a site-to-site IPSec connection, customers can choose to connect their VNets to Alkira over a VNet peering connection. In this option none of the host VNets will require a virtual network gateway. Alkira will automatically discover the VNets in your account and establish a peering connection to a transit VNet inside the Alkira account which then connects to Alkira CXP advertising spoke VNet subnets.
Extend connectivity from vWAN to Alkira
In this scenario enterprises are already using vWAN to connect their spoke VNets through vWAN vHub. Basic connectivity between VNet to VNet works well with this architecture however, they run into challenges when there is a need to extend the same architecture to other cloud providers and to on-prem over ExpressRoute or SDWAN. Also, introduction of security or other higher layer services becomes a complex do-it-yourself project. Mostly at this stage, enterprises realize that they will need a different solution which can help standardize and unify their connectivity and security architecture across all cloud service providers. But this migration can be painful if the new solution can not co-exist with their existing vWAN.
Customers can connect their VNets to Alkira for connectivity and security consolidation and simplification. During the migration to Alkira, enterprises can easily connect their vWAN to Alkira CXPs over IPSec. CXP will learn routes for all the host VNets and can advertise on-prem and other cloud prefixes back to vWAN. Enterprises can now gradually disconnect VNets attached to vWAN and onboard them to Alkira CXP and migrate one VNet at a time to minimize the downtime.
Figure 3
Integration with Transit VNet
Before Azure vWAN, transit VNet used to be the recommended solution from microsoft to aggregate connectivity from host VNets. In this case, all the host VNets peer with the transit VNet and use the remote gateway of the transit VNet to reach on-prem networks and other VNets. On-prem sites can be connected to this transit VNet over site-to-site IPSec or using Express Route (ER).
Like the Azure vWAN, this architecture also holds up pretty well If you are using it for basic VNet to VNet communication. But the solution becomes complex if you extend connectivity to multiple clouds or require security in line within the datapath.
Figure 4
With Alkira, all you need to do is to discover the transit VNet from the portal, onboard the transit VNet as a cloud connector on the CXP. Once transit VNet is onboarded, you will have connectivity with other cloud service providers instantly. For security, choose a firewall vendor of your choice from Alkira’s marketplace and deploy it. Finally, using Alkira’s policy framework, steer interesting traffic towards the firewall for traffic inspection. Figure 5 below shows the topology when the transit VNet is connected to Alkira CXP.
Figure 5
Even though the architecture is fully supported, customers will still be responsible to manage connectivity between host VNets and on-prem networks through transit VNet. So it is recommended that the customer should only leverage this integration for migration and eventually migrate all host VNets, and on-prem connections from transit VNet to the CXP so that all cloud and on-prem connectivity is standardized through CXP.
Connect Express Route (ER) to Alkira
Express route (ER) connector enables customers to extend high bandwidth private connectivity into Azure through Alkria CXP. You can connect host VNets and cloud services providers as a cloud connector to CXP and they can connect to applications inside the datacenter or collocations over express route connector.
Figure 6
ER configuration is difficult if you have to do it yourself from the Azure portal. Alkira simplifies the whole experience of ER onboarding by abstracting all the complexity involved. Customers just need to terminate the ER in their Azure account and set up underlay peering between the on-prem router and azure. After which they just need to add an ER connector from Alkira portal. Once the connector is provisioned, a configuration file for the on-prem router is generated so that you don’t have to figure out the configurations. You can also use the same ER circuit to CXP to extend connectivity to other cloud service providers as shown in Figure 6.
Conclusion
Simplicity, ease of use, and flexibility is the theme on which the Alkira solution is built upon. All the Azure integration options that I shared in the blog adhere to the same and still provide you an enterprise grade solution for all your cloud connectivity use cases. Hope you found the options discussed in the blog relevant to your environment. Please reach out to us at [email protected] if you like to schedule a demo or discuss the solution in more detail.
