Oracle Database@Azure: Connecting Azure Applications with Exadata

On this page

1. 01 · Why Connectivity Is the Real Project
2. 02 · How Oracle Database@Azure Places Exadata in Your VNet
3. 03 · Designing the Network: Hub, Spokes, Peering and Routes
4. 04 · DNS: The Hop That Breaks Most Connections
5. 05 · Four Connection Paths, Hop by Hop
6. 06 · Identity and Security: Entra ID, Ports and Encryption
7. 07 · Connection Strings, Drivers and Resilience
8. 08 · Setup Sequence and Test Plan
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · Why Connectivity Is the Real Project

Integration brief · Azure applications to Exadata

"The cluster is up. Why can't the application connect?"

Most Oracle AI Database@Azure projects (the service launched as Oracle Database@Azure) hit the same moment. The Exadata VM cluster shows as available in the Azure portal, the DBA has created the container database and a pluggable database, and the first application deployment fails with a timeout. The database is fine. The problem is a DNS zone that is not linked, a peering without gateway transit, or a route that sends traffic to a firewall that drops it.

That is because the Database@ model puts Exadata inside your Azure network, not behind a public endpoint. The database gets private IP addresses in a subnet of your virtual network, and every Azure workload reaches it the same way it reaches any other private service: through VNet routing, peering, network security rules and private DNS. This post shows how to fit it into a hub-and-spoke landing zone.

02 · How Oracle Database@Azure Places Exadata in Your VNet

Answer: Oracle Database@Azure runs Exadata hardware in an Oracle-operated OCI child site inside the Azure data center. You delegate a subnet in your own VNet to the service, and the VM cluster's client network interfaces, SCAN addresses and node VIPs take IP addresses from that subnet.

From the application's point of view the Exadata VM cluster looks like any other private resource in Azure. It has addresses in a subnet you created, in a VNet you own, in a region you chose. Behind it, the Exadata servers sit in Oracle's racks in the same Azure data center, managed by OCI from a parent region. Delegating the subnet to Oracle.Database/networkAttachments lets the service attach interfaces into your VNet.

The topology below is the pattern most enterprises end up with. A hub VNet holds the ExpressRoute gateway, the central firewall and the DNS Private Resolver. The database has its own spoke with the delegated subnet and a private DNS zone, and applications live in a separate peered spoke. On-premises users arrive through ExpressRoute and the hub firewall.

Follow the blue path first: VMs, AKS and App Service traffic reaches the SCAN listener over VNet peering on TCP 1521, or 2484 if you enable TLS. The orange path is on-premises traffic, which enters through the ExpressRoute gateway and is forced through the firewall by a user-defined route (UDR). The grey dashed path is DNS, which must work before either of the others.

What lives where

03 · Designing the Network: Hub, Spokes, Peering and Routes

Answer: Put the delegated subnet in a dedicated database spoke, peer it to the hub and to application spokes, and decide early whether traffic between spokes goes direct over peering or through the hub firewall. Plan non-overlapping CIDRs for every VNet, the delegated subnet and the backup range before provisioning.

There are two common designs. In the first, application spokes peer directly with the database spoke. Latency is lowest and there are fewer moving parts, but east-west traffic bypasses your central firewall. In the second, every spoke peers only with the hub, and UDRs send spoke-to-spoke traffic through Azure Firewall or a network virtual appliance (NVA). That gives you inspection and central logging at the cost of an extra hop and firewall throughput limits.

Both are valid if chosen deliberately. Support for NSGs, UDRs and hub transit on delegated subnets has widened over time and depends on the service's advanced network features in your region, so confirm the current matrix in the Microsoft Learn documentation before you commit.

Address planning rules

Overlapping address space is the single most common reason a Database@Azure build stalls. Peering will not work between VNets with overlapping ranges, and the delegated subnet range is hard to change after the VM cluster is built. Reserve every range in your IPAM tool first and check it against on-premises ranges advertised over ExpressRoute.

04 · DNS: The Hop That Breaks Most Connections

Answer: Applications should connect to the SCAN host name, not to IP addresses, so DNS must resolve it from every client network. Link the private DNS zone that holds the database names to every VNet with clients, and point on-premises DNS at an Azure DNS Private Resolver inbound endpoint with a conditional forwarder.

When you create the VM cluster you choose how its host names are published: in an Oracle-managed default domain, or in a private DNS zone in your own subscription. Either way, the names only resolve from networks that can see that zone. A VM in the database spoke usually works on the first try. An AKS pod in another spoke, an App Service app and an on-premises laptop each need their own path to the same zone, and that is where most connection failures start.

For Azure workloads, link the zone to each client VNet (or to the hub, if spokes use a central DNS server or the Private Resolver). For on-premises clients, create an inbound endpoint on the DNS Private Resolver in the hub and add a conditional forwarder on your corporate DNS for the database domain. Then test from each network:

# From a VM, an AKS debug pod and an on-prem host
nslookup exa-clu1-scan.db.contoso.internal
# Expect three SCAN addresses from the delegated subnet range
tnsping exa-clu1-scan.db.contoso.internal:1521/app_svc.contoso.internal

AKS pods resolve through CoreDNS, which forwards to the node VNet's DNS server, so a custom DNS server there must forward the database domain. App Service resolves through its integrated VNet, so link the zone to that VNet too.

05 · Four Connection Paths, Hop by Hop

Answer: Every Azure client reaches Exadata through the same three hops: resolve the SCAN name, route to the delegated subnet, and pass the security rules on TCP 1521 or 2484. What changes between a VM, an AKS pod, an App Service app and an on-premises user is how each hop is configured.

The walkthrough below lines up the four client types most teams have. Read each row left to right: the yellow headers are the three questions every packet must answer, and the boxes show the setting that answers it for that client. When a team reports that "the database is down", walk this checklist one hop at a time.

The App Service row is the one most often missed. Without regional VNet integration and the route-all setting, outbound calls leave through the app's public outbound addresses and never reach the private SCAN IPs. The on-premises row depends on gateway transit on the peering and matching UDRs in both directions.

Client-side settings per workload

06 · Identity and Security: Entra ID, Ports and Encryption

Answer: Network rules decide who can reach the listener; database authentication decides who can log in. Oracle Database on Exadata in Azure supports Microsoft Entra ID token authentication, so users and applications can sign in with Entra identities instead of local database passwords, over a TLS connection.

Keep the two layers separate in your design. At the network layer, allow only known source ranges on the database ports. At the identity layer, map Entra ID users and app roles to database schemas or global roles. The database is registered with Entra ID as an application, and you set two initialisation parameters to trust it:

ALTER SYSTEM SET IDENTITY_PROVIDER_TYPE = AZURE_AD SCOPE=BOTH;
ALTER SYSTEM SET IDENTITY_PROVIDER_CONFIG =
  '{"application_id_uri":"https://contoso.onmicrosoft.com/exa-app",
    "tenant_id":"<tenant-guid>", "app_id":"<app-guid>"}' SCOPE=BOTH;

-- Map an Entra ID app role to a shared database schema
CREATE USER app_rw IDENTIFIED GLOBALLY AS 'AZURE_ROLE=ExaAppReadWrite';

Token authentication requires a TLS (TCPS) connection, which is another reason to enable the TCPS listener early. Applications that cannot use tokens yet can keep passwords, held in Azure Key Vault rather than in config files.

07 · Connection Strings, Drivers and Resilience

Answer: Use the SCAN name, a database service (never the default service), and Oracle's recommended retry and timeout settings in the connect descriptor. Enable FAN and Application Continuity on the service so that patching and node failures in the Exadata VM cluster are invisible to users.

Exadata in Azure is still a RAC cluster, and rolling patching restarts instances under the application regularly. Applications that connect to one node by IP, or ignore FAN events, see those windows as outages. A standard connect descriptor avoids that:

APP_SVC =
 (DESCRIPTION =
   (CONNECT_TIMEOUT=90)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
   (ADDRESS_LIST = (LOAD_BALANCE=on)
     (ADDRESS = (PROTOCOL=TCP)(HOST=exa-clu1-scan.db.contoso.internal)(PORT=1521)))
   (CONNECT_DATA = (SERVICE_NAME=app_svc.contoso.internal)))

On the database side, create a dedicated service per application with high availability attributes, for example srvctl add service -db CDB1 -pdb SALESPDB -service app_svc -preferred CDB11,CDB12 -failovertype TRANSACTION -commit_outcome TRUE -notification TRUE. That enables Transparent Application Continuity behaviour for drivers that support it and publishes FAN events on the ONS port.

If the application can resolve the SCAN name, reach every node VIP and receive FAN events, Exadata in Azure behaves exactly like Exadata in your own data center, only closer to the application.

08 · Setup Sequence and Test Plan

Answer: Build the network before the database: plan CIDRs, delegate the subnet, peer the VNets, wire DNS and open the ports, then provision the VM cluster and test each client type from its own network. Finish with a failover drill using the real application driver.

The timeline below is the order that avoids rework. The first four steps belong to the network and platform teams and can be finished before the VM cluster exists. The owner tags matter: in most delayed projects the DBA was waiting on a DNS link or firewall rule owned by another team.

Steps 1 and 4 cause most of the trouble. A CIDR overlap found after provisioning means rebuilding the cluster, and a private DNS zone that is not linked to one client VNet looks exactly like a database outage from that application. Treat both as gating checks.

1. Resolve from every client network. Run nslookup for the SCAN name from a VM, an AKS debug pod, the App Service console and an on-premises host. All four must return the same addresses.
2. Test the port, not just the ping. Use tnsping or a TCP check against the SCAN name and each node VIP.
3. Log in with the real identity. Connect with an Entra ID token or the vaulted application credential, not with SYSTEM, so you test the access path users will actually take.
4. Run a planned failover. Relocate the service or restart one instance with srvctl while a test load runs. Watch the application for errors.

09 · Key Takeaways

1. Exadata joins your VNet. The delegated subnet gives the VM cluster private client IPs, so Azure workloads connect over peering and private routing, not over the internet.
2. Three hops, every time. Resolve the SCAN name, route to the delegated subnet, allow 1521 or 2484 from the client range. Most failures are DNS.
3. Decide direct peering vs hub firewall early. Both work; mixing them by accident creates asymmetric routing that drops replies.
4. Entra ID handles who logs in. Token authentication over TLS replaces local passwords; network rules still decide who can reach the listener.
5. Design for RAC behaviour. SCAN name, a dedicated service, FAN and Application Continuity make rolling maintenance invisible to users.

10 · Frequently Asked Questions