This article focuses on the access to the Oracle Analytics Cloud (OAC) that is hosted on in a private subnet from a VCN.
Customers wanted to be able to access OAC privately because most of the data-sources used by it are in a private enviroment from on-premises.
Before the private endpoint, the connectivity from OAC to the data sources looked like this:
This image shows a high-level diagram of the architecture for Data Gateway. Oracle Analytics Cloud communicates through a firewall with an on-premise database using HTTPS, with an agent installed in the on-premise environment that channels database queries between Oracle Analytics Cloud and the on-premise database. The call-outs are 1. Oracle Analytics Cloud issues and queues queries. 2. The agent looks for queries to process. 3. The agent executes the queries. 4. The agent sends the query results to Oracle Analytics Cloud.
Further details on connectivity can be found here.
In the article we will follow two scenarios, the first, where both the data sources and the clients connecting to OAC are on a private subnet on-premises, and the second scenario, where the data sources are on a private subnet on-premises and the customers connecting to OAC are in the Internet.
Access the Private OAC from on-premises
This section will focus on accessing the instance from on-premises via Fastconnect or VPN Connect. It is not on the scope of the article to setup the connectivity between OCI and on-premises.
Moving forward, we assume, both the clients and the data sources are on-premises.
For instructions on how to provision OAC, follow this blog.
Once the instance is provisioned, you will get the service URL and the IP addresses (in this example the private IP address of the OAC is 192.168.33.2):
The URL can be resolved only by the VCN DNS resolver.
If we try to resolve it from outside of the VCN you will not get the internal IP address.
If we want to access the Private OAC from outside the VCN, there are two solutions: editing the hosts file on each client, use the Vanity URL.
Editing the hosts file on each client
On each clients that are trying to access the service URL, edit the hosts file and create an entry for the OAC host to point to the private IP address.
After we save the file, we can access the OAC:
Use the Vanity URL
In the OAC there is a Vanity URL that can be configured in order to accept connection for other HTTP headers.
There are prerequisites for this configuration:
- A domain name that will be used in order to connect to OAC. In this blog i used a free domain name. In a production enviroment, the public domain of the customer should be used.
- A valid SSL certificate (not self-signed). In this blog i used a certificate issued by Comodoca.
Once we have the prerequisites the Vanity URL can be filled-in.
After the Vanity URL is completed, the OAC can be accessed.
Access the Private OAC from the Internet
This scenario is used by the customers that have the data sources on-premises and the clients are on the internet.
The clients are connecting to the private OAC via a public loadbalancer (depicted with blue). The access to the data-sources is done via a private connection (Fastconnect or VPN Connect and it is depicted with green).
The public LB it is a tcp LB and has a TCP listener on port 443 and the back-end server is the OAC instance.
Because there will be significant more connections from the clients from the Internet, and thinking of the complexity of changing theirs hosts file, the Vanity URL should be used for the Public connectivity.
The Vanity URL will have a DNS record that points to the LB public IP address:
In this post we explored the different options for connecting to a private OAC instance.