Oracle Exadata Multi-Cloud Networking: Designing Connectivity Across AWS, Azure & Google Cloud

On this page

1. 01 · Why Networking Decides Multi-Cloud Exadata
2. 02 · The Network Building Blocks in Each Database@ Cloud
3. 03 · The Reference Topology
4. 04 · Walking Through the Four Traffic Paths
5. 05 · Choosing the Interconnect
6. 06 · DNS, Security and Routing Details
7. 07 · A Practical Build Sequence
8. 08 · Key Takeaways
9. 09 · Frequently Asked Questions

01 · Why Networking Decides Multi-Cloud Exadata

Design brief · Connectivity for Exadata across three hyperscalers

"The database is fast. Why is the application slow?"

Most performance escalations in a new Database@ deployment are not database problems. A query that runs in a millisecond on the Exadata VM cluster takes forty milliseconds end to end because the application server sits in a different region, or because traffic hairpins through a firewall appliance in a hub network two hops away. On a chatty OLTP workload that turns a healthy system into an unhappy one, and no amount of Smart Scan will fix it.

Multi-cloud makes this harder, because there is no single network. Your AWS team thinks in VPCs, Transit Gateway and Direct Connect. Your Azure team thinks in VNets, hub and spoke and ExpressRoute. Your Google Cloud team thinks in shared VPCs and Cloud Interconnect. Oracle adds the OCI child site, the OCI parent region and FastConnect. The design job is to make these fit together.

02 · The Network Building Blocks in Each Database@ Cloud

Answer: Each partnership attaches Exadata to your network in its own way. Oracle AI Database@AWS uses an ODB network connected to your VPCs by ODB peering. Oracle AI Database@Azure uses a delegated subnet inside your VNet. Oracle AI Database@Google Cloud uses client and backup subnets associated with your VPC.

The Exadata hardware is physically in the hyperscaler data center, operated by OCI as a child site of an OCI parent region. What you see in your own cloud account is a network attachment point: a place where the database's client and backup interfaces receive IP addresses that your applications can route to. The constructs differ by cloud, and so do the knobs you can turn.

The older names, Oracle Database@AWS, @Azure and @Google Cloud, still appear in many network diagrams and Terraform modules. They describe the same services. Whatever the name, the Exadata client network carries SQL*Net traffic, the SCAN listeners and the node VIPs, while the backup network carries RMAN and other bulk transfers.

Address planning comes first

Every VM in the cluster needs client and backup addresses, plus node VIPs and three SCAN addresses on the client side. Both ranges must not overlap with any VPC or VNet you will peer to, with your on-premises ranges, or with the other clouds you plan to connect. In a three-cloud estate, keep a single IP address management register and allocate Exadata ranges from a reserved block, so the AWS and Azure database networks never collide when you later route replication between them.

03 · The Reference Topology

Answer: A sound multi-cloud Exadata topology has three layers: each Database@ cluster placed next to its application tier, private hyperscaler circuits (Direct Connect, ExpressRoute, Cloud Interconnect) that join on-premises and OCI through FastConnect, and explicit replication paths between clouds that never use the public internet.

The figure below shows one estate that uses all three hyperscalers. The primary database runs on Oracle AI Database@AWS, a Data Guard standby runs on Oracle AI Database@Azure, and a GoldenGate replica feeds an analytics team on Google Cloud. On the left, the on-premises data center reaches OCI through FastConnect, and OCI fans out to each hyperscaler's private edge. Read it as a pattern rather than a recommendation: most estates use one or two of these clouds, not all three.

The orange connectors are the hybrid backbone: FastConnect from the data center into OCI, then the hyperscaler's own private link into each region. The purple dashed lines are logical replication paths. Physically they ride those same private circuits, so redo and trail traffic shares bandwidth with migration and on-premises users. Size the circuits for all of it, not just for one.

04 · Walking Through the Four Traffic Paths

Answer: Design each traffic path separately: application to local database stays inside one data center, cross-cloud replication uses a private interconnect, on-premises users arrive through the hyperscaler's private circuit, and backups use the dedicated backup subnet to object storage. Each path has a different latency budget and failure mode.

The figure below follows four flows that every estate has and colours each by the link it uses. Notice that only one of the four, application to local database, is truly latency critical. The others are throughput or reachability problems, which changes how you design and monitor them.

Path 1 is the reason the Database@ model exists: an application server talks to the SCAN listener on port 1521 inside the same data center. Path 2 crosses clouds and is sized by redo volume, not by latency. Path 3 usually fails on DNS, not on routing. Path 4 should never compete with client traffic, which is why it has its own subnet.

Path 1: application to local database

Keep application servers in the same region and, where the cloud exposes it, the same availability zone as the Exadata cluster. Allow ports 1521 (or 2484 for TCPS) to the SCAN and node VIPs, and port 6200 if you use Fast Application Notification so connection pools learn about node failures quickly. Do not put a load balancer in front of SCAN; SCAN already balances connections across RAC nodes.

Path 2: database to database across clouds

Data Guard redo transport and GoldenGate trail traffic run over SQL*Net or GoldenGate's own transport between the two clusters. Asynchronous transport (ASYNC) is the normal choice across clouds because the round-trip time is too high for synchronous commit. Tune the session data unit and socket buffers for the bandwidth-delay product of the link.

# tnsnames.ora entry on the primary for the cross-cloud standby
STBY_AZ =
  (DESCRIPTION =
    (SDU = 65535)
    (SEND_BUF_SIZE = 10485760) (RECV_BUF_SIZE = 10485760)
    (ADDRESS = (PROTOCOL = TCP)(HOST = stby-scan.example.internal)(PORT = 1521))
    (CONNECT_DATA = (SERVICE_NAME = sales_stby)))

-- On the primary
ALTER SYSTEM SET log_archive_dest_2 =
  'SERVICE=STBY_AZ ASYNC NOAFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
   DB_UNIQUE_NAME=sales_stby' SCOPE=BOTH;

Path 3: on-premises users and tools

Users and batch jobs in your data center reach the database through the hyperscaler's private circuit: Direct Connect into AWS, ExpressRoute into Azure, Cloud Interconnect into Google Cloud. The routing is usually straightforward. Name resolution is not: the SCAN name lives in a private DNS zone, so your corporate DNS needs a conditional forwarder to the cloud's resolver (Route 53 Resolver, Azure DNS Private Resolver or Cloud DNS).

Path 4: backups

Automatic backups go from the backup subnet to object storage: Amazon S3, Azure Blob Storage, Google Cloud Storage, or OCI Object Storage and Autonomous Recovery Service in the parent region. These are large, scheduled flows. Keep them on the backup network so a full backup never shares a path with client sessions.

05 · Choosing the Interconnect

Answer: Use same-region Database@ placement for application traffic, OCI FastConnect with Oracle Interconnect for Azure, Oracle Interconnect for Google Cloud or AWS Direct Connect for traffic that must reach OCI, a partner cloud exchange for hyperscaler-to-hyperscaler private links, and IPsec VPN only as a backup or for small, non-critical flows.

There are really four ways to move database traffic between two places in this estate. The comparison below rates them qualitatively, because the actual numbers depend on the regions, the metro distance between data centers and the circuit sizes you buy. Treat it as a starting point for a design review, then measure your own links.

The first column is not really an interconnect at all, and that is the point: the cheapest and fastest link is the one you do not need, because the application and database share a data center. The OCI interconnect is the default for anything that reaches OCI. A partner exchange is what you use to join two hyperscalers privately when neither side is OCI.

06 · DNS, Security and Routing Details

Answer: Resolve SCAN and VIP names through conditional forwarding between each cloud's private resolver and your corporate DNS, restrict database ports to known application ranges at every hop, encrypt cross-cloud traffic with native network encryption or TLS, and keep routing symmetric so firewalls do not drop return traffic.

Once the links exist, most problems come from three places: names that do not resolve from the right network, firewalls that see only half a conversation, and routes that send traffic the long way round.

Name resolution

Each Exadata cluster registers its hostnames, VIPs and SCAN name in a private zone. Applications inside the same cloud resolve them natively. Everything else, including on-premises tools, the standby in another cloud and your monitoring servers, needs a forwarding rule. Write these rules down per cloud and test them from every source network before go-live.

Security controls along the path

Apply least privilege at every hop: the application security group or NSG, the hub firewall if traffic passes one, and the database network's own rules. Encrypt anything that leaves a data center. Oracle Native Network Encryption or TLS on SQL*Net protects redo in transit even when the circuit itself is private. Transparent Data Encryption protects the data at rest and in backups, with keys held in OCI Vault or the cloud's key service where supported.

Routing symmetry

Hub-and-spoke designs often route outbound traffic through a firewall but let return traffic take a direct path. Stateful firewalls then drop the replies. Before you insert an appliance between applications and the Exadata cluster, confirm the cloud supports the necessary routes on the database network, and measure the latency it adds. On a chatty workload, an extra hop can cost more than the database itself.

07 · A Practical Build Sequence

Answer: Build the network in this order: allocate address ranges, create the database network and peering, configure DNS forwarding, open ports, provision the cluster, then test every traffic path with real tools before any data moves.

Teams that follow a fixed order rarely have surprises on cutover weekend. The sequence below works on all three clouds; only the console names change.

1. Reserve address ranges. Allocate non-overlapping client and backup CIDRs for every Database@ cluster, including future DR regions, from one IP register.
2. Create the database network. ODB network and ODB peering on AWS, delegated subnet on Azure, client and backup subnets on Google Cloud.
3. Connect the private circuits. Direct Connect, ExpressRoute or Cloud Interconnect to on-premises, and FastConnect or a partner exchange for OCI and cross-cloud paths.
4. Configure DNS forwarding. Conditional forwarders between corporate DNS and each cloud's private resolver for the Exadata zones.
5. Open only the required ports. 1521 or 2484 for SQL*Net, 6200 for FAN, 22 for administration from a bastion, and GoldenGate ports if used.
6. Provision and test. Resolve the SCAN name, connect with SQL*Plus, measure round-trip time and throughput on each path, and record the results as your baseline.

# From an application host: name, port and latency checks
nslookup sales-scan.example.internal
nc -zv sales-scan.example.internal 1521
ping -c 20 stby-scan.example.internal    # cross-cloud RTT for redo planning

# From SQL*Plus: confirm which instance and service you landed on
SELECT instance_name, host_name FROM v$instance;

Design the four paths on paper first: app to database, database to database, users to database, database to backup. If you cannot draw the link each one uses, you are not ready to provision.

08 · Key Takeaways

1. Co-locate app and database. The Database@ model's main benefit is same-data-center latency. Do not give it away by splitting tiers across regions.
2. Each cloud attaches differently. ODB network and ODB peering on AWS, a delegated subnet on Azure, client and backup subnets on Google Cloud.
3. Cross-cloud traffic stays private. Use FastConnect-based interconnects, Direct Connect, ExpressRoute, Cloud Interconnect or a partner exchange, not the internet.
4. Plan addresses and DNS first. Overlapping CIDRs and missing DNS forwarders cause more failed go-lives than bandwidth.
5. Test every path with real tools. Measure round-trip time and throughput for replication and record a baseline before any data moves.

09 · Frequently Asked Questions