Understanding networking options for OCI cloud database for Azure

Oracle’s new ODSA offering brings new options for organizations focusing on Azure as the primary cloud provider but who are still relying on Oracle databases. In this post, I look at common networking scenarios in OCI and Azure for running databases in OCI.

Scenarios

- Scenario a. An application running on an OCI Virtual Machine uses an Oracle Base Database hosted in OCI. By default, all traffic would stay within the OCI VCN.
- Scenario b. An application running on an Azure Virtual Machine uses an Oracle Base Database hosted in OCI. The easiest way to do this is to set up an internet gateway in OCI and route all traffic via the public internet. Even though traffic uses TLS, you do not get any SLAs on public internet traffic. This will be something your CISO, and most other IT staff will frown upon.
- Scenario c. An application running on an OCI Virtual Machine uses an Oracle Autonomous Database. The Autonomous DB would default be consumed as PaaS via exposed public IP. All traffic will stay within Oracle networks; still, some companies do not like the idea of having their data traversing networks not controlled by them.
- Scenario d. An application running on an Azure Virtual Machine uses an Oracle Autonomous Database. This scenario resembles scenario b so that traffic will be routed via the public internet. You do not need an internet gateway, as Autonomous DB endpoints are exposed via public IPs by default.

Remedy scenario b — ODSA and OCI-Azure interconnect

This is the use case for which Oracle Database Service for Azure (ODSA) and the OCI-Azure interconnect were introduced. I discussed both ODSA and OCI-Azure interconnect in depth in several previous posts.

A managed interconnect gets deployed by default when creating a Base Database using ODSA. This gets you a dedicated interconnect optimized for latency for your connection between applications running in Azure that use Oracle Base Database and dedicated Exadata infrastructure in OCI. There are SLAs for the connection, and there is tooling for setting up and managing the interconnect maintained by Oracle and Azure.

So with ODSA, the solution comes out of the box and is set up automagically for you.

Remedy scenario c — private endpoints and service gateway

To protect Autonomous databases within OCI, there are easy and straightforward methods.

If you deploy an Autonomous DB from OCI, you will get the option to deploy a private endpoint to one of your networks. Problem solved.

Alternatively, you can deploy a service gateway to your VCN that will provide access to services like object storage or Autonomous DB from within your VCN. It is not hard to set up and ticks all the checkmarks for having private access.

Remedy scenario d — service gateway and transit routing via interconnect

And then there is scenario d which requires a combination of service gateway and interconnect. You need to set up an interconnect, create a service gateway and set up transit routing as described in my previous posts.

Currently, most of this has to be done by yourself. If you create the Autonomous Database via ODSA, you will get the default routing via the public internet. There is no option to create a private endpoint and set up the interconnect. This makes the scenario of using ODSA Autonomous Database as a fast and easy PaaS alternative to Azure offerings, a little less attractive.