Network interconnectivity is one of the top three multicloud cloud challenges, according to S&P Global multicloud report. Enterprise multicloud strategies require reliable, cost-effective, dedicated intercloud connections. A common idea for addressing this challenge is connecting clouds indirectly peered through an intermediate cloud hop, commonly referred to as transitive cloud routing. The problem is that public clouds typically don’t support transitive routing natively.
This blog shares the transitive cloud routing options and considerations for multicloud network architectures.
The following table provides a comparison of various options to address the multicloud transitive routing limitations:
NFV router | Cloud network firewall | NFV firewall | Multicloud SD-WAN | Cloud networking platform | |
Routing | Advanced | Supported | Supported | Advanced | Advanced |
Tunneling | Supported | Not supported | Supported | Advanced | Supported |
Security inspection | Not supported | Advanced | Advanced | Advanced | Advanced |
High availability | Manual setup: Load balancer or API calls | Simple: Provided by service | Manual setup: Load balancer or API calls | Automated by SD-WAN controller | Automated by controller |
A routing service in the hub offers a simple option for addressing this limitation. This service can be a basic Compute instance with routing capabilities, or a network functions virtualization (NFV) router. Encapsulation tunnels like IPSEC or GRE are the most common option for connecting the cloud spokes to the routing service in the cloud hub. The following diagram depicts this scenario:
If encryption isn’t a requirement, you can also tweak the public cloud services and routing tables to establish the connectivity. The Oracle Cloud Infrastructure (OCI) documentation, Using a DRG to route traffic through a centralized network virtual appliance, explains how to achieve connectivity in a scenario where the hub is deployed in OCI. In this Oracle official guide, on-premises can be interchangeable with a different public cloud.
The blog, A routing scenario, transit traffic on OCI, provides a scenario where OCI acts as a transit network between a customer’s two on-premises sites.
In addition to providing connectivity between spokes, hub networks act as security enforcement points. So, deploying a firewall in the hub is a best practice when security is a requirement.
Firewalls can be NFVs or cloud network firewalls that the cloud provider offers. Like in the routing services section, the native firewall can facilitate high availability but might be limited in creating tunnels to the spokes.
Certain SD-WAN solution are specifically designed to cover the multicloud needs. These multicloud SD-WAN solutions are based in NFVs and successfully cover the routing, tunneling, and security requirements. SD-WAN also provides advanced capabilities for intelligent forwarding traffic through different underlays. So, it offers a good fit for architectures with more than one WAN Network. Maximizing the internet as underlay is common within SD-WAN deployments.
New niche players are also offering solutions that addresses the routing, tunneling and security requirement. Aviatrix offers a service that addresses transitive routing, while providing advanced capabilities that simplify multicloud deployment.
You can also achieve multicloud transitive connections by implementing the routing just before reaching the public cloud. This method was traditionally done at cloud exchange or colocation facilities. The offering ranges from deploying physical network appliances to more advanced services based on SDN solutions. Oracle works with strategic partners that provide the dedicated connectivity to OCI and offer advanced routing and security services.
The following diagram depicts this scenario.
This scenario is common when the connections are based on dedicated leased lines and encryption isn’t a requirement. It might also be suitable for architectures that require connection to multiple clouds because it centralizes the routing and security service in the cloud exchange instead of deploying it in each public cloud.
Public clouds have also started offering these types of services. Azure Global Reach and Amazon Web Services (AWS) Direct Connect SiteLink provide connectivity between on-premises sites by using their internal backbones. These services might also fulfill multicloud connectivity, according to the requirements shown in the following diagram.
In the Oracle multicloud strategy, we have released a set of services that address connectivity between clouds. Oracle offers the Oracle Database service for Azure (ODSA) and Oracle Interconnect for Azure as database services for Azure. Both services provide optimal latency levels to the directly connected public cloud. But you can use them for multicloud transitive architectures when the application supports this latency added by the extra cloud hop.
ODSA provides reachability from Azure to the Oracle Database service in OCI by either showing the OCI subnet as a VNet peering network or by creating a private endpoint in an Azure VNet. Either implementation allows the OCI subnet to be seen as an Azure network, solving the multicloud transitive routing problem.
The ODSA multicloud link must be used exclusively for Database traffic. Finally, the ODSA multicloud link is part of a fully managed service. So, it doesn’t permit custom configurations like ExpressRoute Global Reach. For architectures with global reach, the OCI-Azure Interconnect and FastConnect partners are better options.
The reference architecture, Deploying multicloud Oracle Database Service for Microsoft Azure in a hub and spoke topology, provides the solution when a VNet hub with Fortigate Firewall needs to connect to ODSA.
Transitive routing is a common challenge in multicloud architectures. The options for addressing these challenges include cloud native routers, NFV router, cloud native firewalls, NFV firewalls, cloud networking platforms, and cloud exchange solutions, among others. Multicloud transitive routing can optimize cost and deployment time, but it can also add latency that can affect application performance. Ensuring that cloud-to-cloud network (bandwidth and latency) is fully tested to ensure that the application performance meets the defined business requirements is the customer’s responsibility.
Finally, the OCI multicloud products and services used can influence multicloud transitive routing decisions. So, it’s important to do a proper assessment at the early design stage. The final decision should take into consideration, the specific connectivity, security, latency, and data residency requirements, along with your multicloud longer-term strategy and cost optimization.
Learn more about multicloud use cases at Oracle Cloud Infrastructure multicloud solutions.
Next Post