Last updated: March 30, 2024
Some frequent questions that A-team encounters from customers are about connectivity to Oracle SaaS. With the flexibility and options that Oracle Cloud Infrastructure (OCI) brings to customers, there are several alternatives for network connectivity. In this post, I'll address the most common of these alternatives, in the context of Oracle Cloud Applications, aka. Fusion cloud applications, HCM, ERP, SCM, and Sales to be specific. The patterns explained here can generally be applied to other Oracle SaaS applications.
This post will address the connectivity architecture at a high level. I'll delegate to other Oracle blogs and documentation for detailed instructions for tasks such as setting up VPN Connect or FastConnect connections. The suitable audience for this post is cloud architects and engineers with a foundational understanding of networking with OCI.
Here are the four alternatives in my view to connect with Oracle Applications Cloud, starting with the most common ones.
While it is technically feasible to bypass CDN in ways other than what's listed above, they are not recommended.
The CDN for Fusion cloud applications is Akamai, which also provides edge-protection services.
Let's take a closer look at each pattern.
NOTE: CDN is automatically bypassed for all traffic originating from OCI for most OCI customers (Pattern #3). Customers can verify CDN bypass for their instance either themselves from an OCI compute instance, or by opening a request to Oracle support. Please refer to this blog for verifying bypass.
This is the connectivity pattern for Fusion SaaS customers who do not choose to customize connectivity. All connections originating from customer premises and the Internet are made over the public internet, through the CDN. There are a couple of key points to note.
A high-level visual of this pattern is shown below.
All Fusion SaaS clients, including the clients inside the customer's OCI tenancy, connect through the CDN. This pattern works well for most customers.
Many Fusion SaaS customers want to connect over encrypted tunnels, or over dedicated circuits to the application from the customer's premises. OCI VPN connect or OCI FastConnect provides this capability. Before I discuss this pattern, let me provide a quick introduction to OCI VPN Connect and FastConnect.
VPN connects is IPSec VPN from customer's premises (including customer's other 3rd party cloud provider accounts) to OCI. VPN provides an encrypted tunnel for all connections. However, note that all connections to and from Fusion SaaS are encrypted already. VPN can provide an additional measure of protection, for customers who see the benefit in it. VPN connections typically have a ceiling to the bandwidth, estimated to be around 250 Mbits. OCI VPN Connect is a fully self-service option for customers. VPN allows customers to extend their on-premises networks into OCI, for seamless connectivity between on-premises services and cloud services over private IP networks.
FastConnect provides a quick way to enable dedicated connections from customer's premises (again, including customer's other 3rd party cloud provider accounts) to OCI. FastConnect is easier enabled through one of Oracle's partners, such as Equinix or Megaport, among others. It is possible to enable direct circuits from customer premises to OCI where a partner is not available, but this is done as a last resort, with consultation from OCI networking support.
Fastconnect provides two types of peering. Private peering allows customers to extend their on-premises networks into OCI. This enables the customer to connect over private IP addresses. Public peering permits accessing Oracle public IP addresses advertised over FastConnect, which includes Fusion SaaS applications. Customers can choose to enable both private and public peering over the same FastConnect. FastConnect is also mostly self-service configuration, through OCI-console and Partner's console. There are, however, a few last steps that need to be performed by OCI network support before FastConnect becomes active. Consult OCI documentation or OCI networking support for more information.
Here is a visual of this pattern.
To ensure that all connections are only between customer premises and Oracle cloud services, and no 3rd parties are in-between, the CDN is disabled in this pattern. To ensure that connections can only originate from customer premises, the customer configures Location-Based Access control (LBAC) in the Fusion SaaS instances. Any clients outside the customer's premises, such as users on Mobile devices will have to be routed through the customer's premises using technologies such as VPN. If the mobile device's IP addresses can reliably fit into a few trusted-CIDR ranges that can be specified with LBAC, then the mobile clients might be able to connect directly. A solution for this is something within the customer's control, and the customer's network engineers must determine an appropriate design. Blocking all clients originating from outside customer premises is also a possibility.
NOTE: PaaS services hosted by Oracle Cloud, such as OIC, are located in Oracle Service Network (OSN), even though they are created by customers and administratively located inside a compartment. As a result, these products can not take the same connectivity route as other components such as services deployed on OKE or Compute.
NOTE: This pattern is the default for most customers today. Customers can verify CDN bypass for their instance either themselves from an OCI compute instance, or by opening a request to Oracle support. Please refer to this blog for verifying bypass.
This is a variation of the first pattern. In pattern #1, clients located within customer's OCI tenancy, such as Oracle Integration Cloud (OIC) or Oracle Kubernetes Engine (and, many other PaaS or IaaS services) connect over the CDN.
While pattern #1 works for most customers, it might not, for some customers have very high-volume integration needs who look to shave off milliseconds to improve the overall user experience. Those customers can request a by-pass of CDN, for services in their OCI tenancy, by working with Oracle field engineers engaged with customers or by submitting a request to Oracle Fusion SaaS support. Note that at the time of publishing this post, this procedure is approved on a per-customer basis, so the requests are not processed immediately. I'll not dive into details of how this is achieved by Oracle cloud support. The result would that any requests originating from the customer's OCI tenancy to Fusion SaaS API or web services will directly connect to Fusion SaaS, by-passing CDN, thus eliminating an additional network hop. This change will be transparent to customers and no code or configuration changes are required by customers.
Please remember that this might not be a preferred approach for every customer.
NOTE: PaaS services hosted by Oracle Cloud, such as OIC, are located in Oracle Service Network (OSN). The CDN bypass applies to those services as well, if they are hosted in OCI. All PaaS services are hosted in OCI unless a customer is still using OCI-Classic, in which case their services are on classic infrastructure.
This scenario is addressed as it can be a part of discussion around connectivity architectures. Despite its potential technical feasibility, we discourage custom solutions for multitude of reasons. Some of the reasons are:
At the time of this post, many customers still have their Fusion SaaS instances hosted in Gen1 infrastructure. Let's address the applicability of these patterns for those customers.
Securely Accessing Fusion Applications: https://docs.oracle.com/en-us/iaas/Content/fusion-applications/network-setup.htm
Interconnectivity within OCI Regions: https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/fastconnectpublicpeeringaddressranges.htm
OCI FastConnect: https://www.oracle.com/cloud/networking/fastconnect/
OCI VPN Connect: https://www.oracle.com/cloud/networking/vpn-connect.html
Previous Post