Hybrid Cloud Architecture with Oracle Database@Azure
Hybrid Cloud Architecture with Oracle Database@Azure
Article Overview
Very few enterprises move to Oracle Database@Azure in a single leap. For months or years, the reality is hybrid: some databases still on-premises, some on the new platform, and traffic flowing between them, Azure, and the Oracle Cloud Infrastructure that Database@Azure runs on. Getting that connectivity right — secure, private, low-latency, and sanely routed — is what makes a hybrid estate feel like one system rather than three that happen to exchange packets. This guide works through the hybrid network architecture end to end: the three-way topology of on-premises, Azure, and OCI; how ExpressRoute connects your datacenter to Azure and how the Azure–OCI interconnect links Azure to OCI; the routing and DNS that make names resolve and packets flow the right way; the security model; and the hybrid patterns — migration, DR, and split-workload — that this connectivity enables. It is a networking article at heart, with the diagrams and configuration to match.
1.Why Hybrid Is the Normal Case
It is tempting to talk about cloud migration as a destination — you were on-premises, now you are in the cloud. In practice, for any enterprise with a serious Oracle estate, the interesting state is the long middle: the hybrid period where on-premises systems and Oracle Database@Azure run side by side and have to work together. That period is rarely short, and for many organizations it never fully ends, because some workloads have good reasons to stay close to home.
Hybrid is therefore not a transitional inconvenience to rush through — it is an architecture to design deliberately. During a migration, the source on-premises database and the target on Database@Azure must replicate to each other across the network. In steady state, an application on-premises may query a database on Database@Azure, or vice versa. For disaster recovery, an on-premises or Database@Azure primary may protect to a standby in the other environment. Every one of these depends on secure, reliable, well-routed connectivity between the environments.
Hybrid is not the awkward gap between on-premises and cloud. For most enterprises it is the operating model for years — so the network that joins the environments deserves to be designed, not improvised.
Three environments, not two
The mental model that trips people up is thinking in twos — on-premises and "the cloud." With Oracle Database@Azure there are three environments in play: your on-premises datacenter, your Azure estate, and the OCI on which the Oracle database physically runs. The connectivity story is about linking all three coherently, and keeping that triangle clear in your head is the first step to designing it well.
2.The Three-Way Topology
Start with the map. Three environments, two primary links between them, and one crucial fact that simplifies everything: from your point of view, the OCI where the database runs is reached through Azure, over a high-bandwidth interconnect that Oracle and Microsoft operate between the two clouds.
| Link | Connects | Provided by |
|---|---|---|
| ExpressRoute | On-premises datacenter ↔ Azure | Microsoft (with a connectivity provider) |
| Azure–OCI interconnect | Azure ↔ OCI | Microsoft and Oracle jointly |
| Chained path | On-premises ↔ database in OCI | The two links together, via Azure as hub |
Azure is the hub — design it that way
Because on-premises reaches OCI through Azure, your Azure network is the hub of the whole hybrid estate, not just one of three peers. Treat it as such: a well-designed Azure hub — clean address space, a central firewall, controlled routing — is what keeps the three-way topology manageable. Get the Azure hub right and both links plug into it cleanly; get it wrong and every hybrid flow inherits the mess.
3.ExpressRoute to Azure
The first leg of the hybrid path is ExpressRoute — Microsoft's private connectivity between your on-premises datacenter and Azure. Rather than crossing the public internet, an ExpressRoute circuit gives you a dedicated, private connection through a connectivity provider, with the bandwidth, low latency, and consistency that database replication and steady-state application traffic demand.
3.1 Why not just a VPN?
A site-to-site VPN over the internet is cheaper and faster to stand up, and it has a place — for a small migration, a proof of concept, or as a backup path. But for production Oracle traffic, ExpressRoute is usually the right answer: it avoids the public internet entirely, offers far more predictable latency and throughput, and scales to the bandwidth a large database replication or a busy cross-environment application actually needs. The two are not mutually exclusive; many designs use ExpressRoute as the primary and a VPN as a lower-cost failover.
| Aspect | ExpressRoute | Site-to-site VPN |
|---|---|---|
| Path | Private circuit via a provider | Encrypted tunnel over the public internet |
| Latency / consistency | Low and predictable | Variable — depends on the internet |
| Bandwidth | High, up to large circuit sizes | Limited by the tunnel and internet path |
| Best role | Production replication and app traffic | Backup path, PoC, or smaller workloads |
3.2 The building blocks
An ExpressRoute deployment has a few standard parts: the circuit (the logical connection you order, at a chosen bandwidth), the peering (private peering carries your VNet traffic), the ExpressRoute gateway in your VNet that terminates it, and a connection that binds circuit to gateway. Here is the shape in the Azure CLI.
# 1. Create the ExpressRoute circuit (ordered via a connectivity provider)
az network express-route create \
--name "er-onprem-to-azure" \
--resource-group "$RG" \
--location "eastus" \
--bandwidth 1000 \
--provider "Equinix" \
--peering-location "Silicon Valley" \
--sku-family MeteredData --sku-tier Standard
# 2. Configure Azure private peering on the circuit
az network express-route peering create \
--circuit-name "er-onprem-to-azure" --resource-group "$RG" \
--peering-type AzurePrivatePeering \
--peer-asn 65010 --vlan-id 100 \
--primary-peer-subnet "10.250.0.0/30" \
--secondary-peer-subnet "10.250.0.4/30"
# 3. Create the ExpressRoute gateway in the hub VNet's GatewaySubnet
az network vnet-gateway create \
--name "ergw-hub" --resource-group "$RG" \
--vnet "vnet-hub" --gateway-type ExpressRoute \
--sku ErGw1AZ --location "eastus"
# 4. Connect the gateway to the circuit
az network vpn-connection create 2>/dev/null || \
az network express-route gateway connection ... # bind circuit ↔ gateway🔧 ExpressRoute is a lead-time item — start early
Unlike most cloud resources, an ExpressRoute circuit is not instant: it involves a connectivity provider and physical cross-connects, and provisioning can take real calendar time. If your hybrid project has a deadline, order the circuit early — it is one of the few things in a cloud migration that you genuinely cannot spin up on the day you need it. Plan around the lead time rather than being surprised by it.
4.The Azure–OCI Interconnect
The second leg is the one unique to this platform: the connection between Azure and OCI. Oracle Database@Azure runs on OCI infrastructure sitting inside the Azure datacenter, and Microsoft and Oracle jointly operate a high-bandwidth, low-latency interconnect between the two clouds. For the core Oracle Database@Azure experience, this cross-cloud connectivity is part of the platform — the database in OCI is reachable privately from your Azure VNet without you building an internet path.
4.1 What the interconnect gives you
The interconnect is what makes the database feel local to Azure. Traffic between your Azure VNet and the Oracle database in OCI travels over this private, high-throughput link rather than the public internet — which is why the application-to-database latency is low enough for demanding workloads and why the connection is private by default. From your application's perspective, it connects to the database over a private address as though the database were just another endpoint in your network.
Private by default
The database is reached over private addressing from your Azure VNet, not a public endpoint — traffic stays on the private interconnect between the clouds.
Low latency, high bandwidth
The joint Oracle–Microsoft link is engineered for the demands of database traffic, keeping the app-to-database round trip short.
Part of the platform
For the core experience the cross-cloud connectivity is provided as part of Oracle Database@Azure — you consume it, you do not build it from scratch.
4.2 How it reaches your VNet
On the Azure side, the database is presented into a delegated subnet within your virtual network — the same VNet your application VMs live in or peer with. That is what lets an Azure application resolve and connect to the database privately, and it is the join point where the OCI side of the platform meets the Azure network you control. The practical consequence: your address planning and routing (next sections) must account for the database's subnet just as they would any other.
You consume the cross-cloud link, but you own the Azure side
The interconnect between the clouds is provided, but everything on the Azure side of it — the VNet, the delegated subnet, routing, DNS, firewall rules — is yours to design. The division of responsibility is clean once you see it: Oracle and Microsoft give you a private, fast pipe to the database; you make sure your Azure network routes to it correctly, resolves its name, and permits the right traffic. Focus your design effort on the Azure side, because that is the part you control.
5.The End-to-End Path
Now chain the two legs together and follow a packet from an on-premises application all the way to the database in OCI. Seeing the whole path makes the routing and DNS decisions that follow obvious.
The application does not know it is cross-cloud
The elegance of this path is that the application is oblivious to it. An on-premises or Azure application connects to the database over a private address and a standard Oracle service name; it neither knows nor cares that the packets cross ExpressRoute and a cross-cloud interconnect to reach a database physically running in OCI. That transparency is the goal — the network complexity is real, but it is hidden beneath a connection that looks entirely ordinary to the application.
6.Routing and Address Planning
The single most common cause of hybrid networking pain is address space that was never planned across all three environments. When on-premises, Azure, and the OCI-side database subnet all have to route to each other, overlapping ranges are fatal — you cannot route to a destination whose address also exists somewhere else in the topology. This is a decision to make once, carefully, before anything is provisioned.
6.1 Non-overlapping address space is non-negotiable
Give each environment its own distinct, non-overlapping CIDR range, planned centrally. On-premises, the Azure VNets, and the subnet the database is delegated into must never share address space. Once ranges overlap, the fixes are ugly (NAT, re-addressing) and expensive; planning clean ranges up front costs nothing but a spreadsheet and an afternoon.
| Environment | Example distinct range (illustrative) |
|---|---|
| On-premises datacenter | 10.0.0.0/8 blocks already in use — document them |
| Azure hub VNet | 10.100.0.0/16 — gateway, firewall, shared services |
| Azure spoke / app VNet | 10.101.0.0/16 — application tier |
| Database delegated subnet | 10.102.0.0/24 — distinct from all of the above |
6.2 Route so the right traffic takes the right path
With clean addressing, routing is about making each environment know how to reach the others. On-premises learns the Azure and database ranges over ExpressRoute (via BGP); Azure knows how to reach the database subnet over the interconnect; and route tables plus a central firewall steer traffic through the inspection point you want. A user-defined route sending database-bound traffic through the hub firewall is a typical control.
# Force app-subnet traffic bound for the database through the hub firewall
az network route-table create --name "rt-app-to-db" --resource-group "$RG"
az network route-table route create \
--route-table-name "rt-app-to-db" --resource-group "$RG" \
--name "db-via-firewall" \
--address-prefix "10.102.0.0/24" \
--next-hop-type VirtualAppliance \
--next-hop-ip-address "10.100.1.4" # hub firewall private IP
# Associate the route table with the application subnet
az network vnet subnet update \
--vnet-name "vnet-spoke-app" --name "snet-app" --resource-group "$RG" \
--route-table "rt-app-to-db"
# On-prem ranges are advertised into Azure via ExpressRoute BGP;
# confirm the gateway is learning them:
az network vnet-gateway list-learned-routes \
--name "ergw-hub" --resource-group "$RG" -o table⚠️ Overlapping IP ranges are the mistake you cannot easily undo
Almost every other hybrid networking problem has a clean fix; overlapping address space does not. Once two environments that must talk share a CIDR range, you are into network address translation or a painful re-addressing project, either of which can stall a migration for weeks. Plan the whole address space — on-premises, Azure, and the database subnet — before you provision anything, and treat the plan as sacred.
7.DNS Across Three Environments
Connectivity gets packets to an address; DNS is what lets an application find that address from a name. In a three-environment hybrid estate, DNS resolution is the second most common source of pain after addressing — an application that cannot resolve the database's name is just as stuck as one that cannot route to it, and the symptoms are more confusing.
7.1 The resolution problem
Names have to resolve consistently in all directions: an on-premises app resolving a database name, an Azure app resolving both on-premises and database names, and so on. The goal is a DNS design where any workload, in any of the three environments, resolves the names it needs to their correct private addresses — without leaking to public resolvers that would return the wrong answer or nothing at all.
7.2 Conditional forwarding ties it together
The usual pattern is conditional forwarding through a set of DNS resolvers in the Azure hub. On-premises DNS forwards queries for the cloud zones to Azure resolvers; Azure resolvers handle the Azure private zones and forward database and on-premises names appropriately; and the result is consistent private resolution across the estate. Azure's private DNS resolver in the hub is the natural place to centralise this.
# In the Azure hub: a Private DNS Resolver with inbound + outbound endpoints
az dns-resolver create --name "dnsr-hub" --resource-group "$RG" \
--location "eastus" --id "$HUB_VNET_ID"
# Inbound endpoint: lets on-prem forward cloud-zone queries into Azure
az dns-resolver inbound-endpoint create \
--dns-resolver-name "dnsr-hub" --name "inbound" --resource-group "$RG" \
--ip-configurations '[{"privateIpAllocationMethod":"Dynamic","subnet":{"id":"'$INBOUND_SUBNET_ID'"}}]'
# Outbound + forwarding ruleset: send specific zones to the right resolver
az dns-resolver forwarding-ruleset create \
--name "fwd-ruleset" --resource-group "$RG" --location "eastus" \
--outbound-endpoints '[{"id":"'$OUTBOUND_EP_ID'"}]'
# Example rule: forward the on-prem corporate zone to on-prem DNS
az dns-resolver forwarding-rule create \
--ruleset-name "fwd-ruleset" --name "to-onprem" --resource-group "$RG" \
--domain-name "corp.example.com." \
--forwarding-rule-state Enabled \
--target-dns-servers '[{"ipAddress":"10.0.0.53","port":53}]'
# On-prem DNS, in turn, conditionally forwards the cloud zones to the
# resolver's inbound endpoint IP — closing the loop in both directions.Solve DNS as deliberately as routing
Teams often nail the routing and then lose days to DNS, because resolution failures masquerade as connectivity problems — the packet could get there, but the name never resolved to the right address. Design DNS as a first-class part of the hybrid architecture: decide where each zone is authoritative, set up conditional forwarding in both directions through the hub, and test resolution from every environment. Name resolution that "just works" everywhere is the quiet mark of a well-built hybrid network.
8.Securing the Hybrid Network
A hybrid network widens the blast radius of a mistake — three environments joined together means a misconfiguration in one can expose the others. The good news is that the private links already remove the biggest risk (the public internet), and the rest is disciplined application of controls you already know, at the boundaries between environments.
| Control | What it does in the hybrid context |
|---|---|
| Private links only | ExpressRoute and the interconnect keep all cross-environment traffic off the public internet |
| Central hub firewall | A single inspection and policy point that cross-environment traffic is routed through |
| Network security groups | Least-privilege rules — open only the database port from only the subnets that need it |
| Encryption in transit | Encrypt Oracle traffic (native network encryption / TLS) so data is protected on the wire |
| Segmentation | Hub-and-spoke isolates workloads; a compromised spoke does not reach everything |
| Identity | Microsoft Entra ID governs access consistently across the Azure side of the estate |
8.1 Least-privilege at the database boundary
The database subnet should accept traffic only on the Oracle listener port, and only from the specific subnets that legitimately connect — the application tiers and the replication sources. Everything else is denied. A network security group on the database's delegated subnet is where you enforce this.
# Allow SQL*Net to the database ONLY from the app and on-prem ranges
az network nsg rule create \
--nsg-name "nsg-database" --resource-group "$RG" \
--name "allow-sqlnet-from-app" --priority 100 \
--direction Inbound --access Allow --protocol Tcp \
--source-address-prefixes "10.101.0.0/16" "10.0.0.0/8" \
--destination-address-prefixes "10.102.0.0/24" \
--destination-port-ranges 1521
# Deny everything else inbound to the database subnet
az network nsg rule create \
--nsg-name "nsg-database" --resource-group "$RG" \
--name "deny-all-inbound" --priority 4096 \
--direction Inbound --access Deny --protocol "*" \
--source-address-prefixes "*" --destination-address-prefixes "*" \
--destination-port-ranges "*"The private link is the floor, not the ceiling, of security
It is easy to assume that because the traffic is on a private circuit, it is secure and the job is done. Private connectivity removes internet exposure, but it does not encrypt the payload, segment your workloads, or enforce least privilege — those are still yours to add. Treat the private links as the foundation, then layer encryption in transit, tight network security groups, a central firewall, and identity on top. Private plus those controls is secure; private alone is merely not-public.
9.Hybrid Patterns
The connectivity exists to enable something. Three patterns cover the great majority of why enterprises build a hybrid network to Oracle Database@Azure, and each leans on the topology in a slightly different way.
9.1 Migration replication
During a migration, the hybrid link carries replication from the on-premises source to the target on Database@Azure — a Data Guard physical standby syncing, or GoldenGate streaming changes — until you cut over. The network requirement here is sustained bandwidth for the initial sync and steady change flow, which is exactly what ExpressRoute plus the interconnect provides. This pattern is temporary but bandwidth-hungry.
9.2 Cross-environment disaster recovery
A powerful use of the topology is DR across environments: an on-premises primary protecting to a standby on Database@Azure, or a Database@Azure primary protecting to a standby elsewhere. Redo ships continuously across the private link, so a regional or datacenter loss in one environment can be ridden out in the other. The network requirement is reliable, low-latency continuous flow — and, for the failover to be useful, the DNS and routing that let applications find the new primary.
9.3 Split workloads
In steady state, many enterprises run applications in one environment and their database in another — an on-premises application against a Database@Azure database during a phased move, or an Azure application against a database that will later consolidate. This is the most latency-sensitive pattern, because every query crosses the link, which is why the low latency of the private path matters so much and why keeping chatty tiers as close as the design allows is worth the effort.
One network, three jobs
The reassuring thing is that these patterns are not three separate builds. They all ride the same on-premises↔Azure↔OCI private path; what differs is the direction, volume, and latency-sensitivity of the traffic. Design the connectivity once, well, and it serves migration today, DR tomorrow, and split workloads in between — which is why the network investment pays back across the whole lifecycle rather than just the migration.
10.Resilience and Redundancy
When your hybrid estate depends on the network, the network cannot be a single point of failure. A link outage that severs on-premises from the database is an outage of everything that spans the two — so the connectivity itself needs redundancy proportionate to what rides on it.
| Resilience measure | What it protects against |
|---|---|
| Redundant ExpressRoute circuits | Loss of a single circuit or provider path — use diverse peering locations |
| Zone-redundant gateways | An availability-zone failure taking down the gateway |
| VPN as backup path | A cheaper failover if ExpressRoute is unavailable — degraded but connected |
| Diverse physical routes | A single fibre cut severing both circuits — ensure genuine physical path diversity |
| Monitored BGP sessions | Silent route withdrawal — alert on peering and learned-route changes |
Match connectivity resilience to what depends on it
If a production application in one environment depends on a database in another, the link between them is now production infrastructure and deserves production-grade redundancy — dual circuits over diverse paths, zone-redundant gateways, and a tested backup path. If the link only carries a one-off migration, a simpler setup may suffice. Size the redundancy to the consequence of an outage, and be honest about how much now rides on that connection.
⚠️ "Redundant" circuits that share one fibre are not redundant
A classic and costly illusion is two ExpressRoute circuits that, unknown to you, traverse the same physical fibre or the same building — so a single backhoe severs both. Redundancy on paper is not redundancy in the ground. When resilience matters, verify genuine physical path diversity with your connectivity provider, not just two logical circuits. The whole point of the second circuit is defeated if it fails at the same moment as the first.
11.Hybrid Networking Pitfalls
| Pitfall | Why it bites, and the fix |
|---|---|
| Overlapping IP address ranges | Cannot route between environments that share a CIDR — plan non-overlapping space up front |
| Thinking in two environments, not three | Forgetting the OCI database subnet in planning — design for on-prem, Azure, and OCI |
| Treating DNS as an afterthought | Resolution failures look like connectivity failures — design conditional forwarding deliberately |
| Ordering ExpressRoute late | It has real lead time — order the circuit early in the project |
| Assuming private means secure | Private links remove internet exposure only — add encryption, NSGs, firewall, identity |
| Ignoring cross-tier latency in split workloads | Every query crosses the link — keep chatty tiers close, measure the round trip |
| No link redundancy for production dependencies | A link outage becomes an application outage — dual circuits, diverse paths, backup VPN |
| "Redundant" circuits sharing one fibre | A single cut severs both — verify genuine physical path diversity |
| Not monitoring the links and BGP | Silent failures found during incidents — alert on peering, learned routes, latency |
| No firewall inspection of cross-env traffic | Unwatched lateral movement — route cross-environment traffic through a central firewall |
Hybrid networking rewards planning and punishes improvisation. The address plan, the DNS design, and the link redundancy are decided best on a whiteboard before provisioning — not rediscovered during an incident.
12.Frequently Asked Questions
How does on-premises reach the Oracle Database@Azure database?
Through Azure. On-premises connects to Azure over ExpressRoute, and Azure connects to the database in OCI over the Azure–OCI interconnect. The two private links chain together, with your Azure network as the hub, so on-premises reaches the database over an entirely private path.
Do I have to build the connection between Azure and OCI?
For the core Oracle Database@Azure experience, the cross-cloud interconnect is provided as part of the platform — the database is presented privately into a delegated subnet in your VNet. You consume that connectivity; what you design and own is everything on the Azure side: the VNet, routing, DNS, and security.
ExpressRoute or a VPN?
For production Oracle traffic, ExpressRoute — it avoids the public internet and gives predictable low latency and high bandwidth for replication and application traffic. A site-to-site VPN suits proofs of concept, smaller workloads, or a lower-cost backup path behind ExpressRoute. Many designs use both, ExpressRoute primary and VPN failover.
What is the most common hybrid networking mistake?
Overlapping IP address ranges. When environments that must communicate share a CIDR range, you cannot route between them cleanly, and the fixes (NAT or re-addressing) are painful. Plan distinct, non-overlapping address space across on-premises, Azure, and the database subnet before provisioning anything.
Why is DNS such a common source of trouble?
Because a name that will not resolve looks like a connectivity failure but is not — the packet could reach the address, but the application never learned it. Across three environments you need consistent resolution in every direction, usually via conditional forwarding through resolvers in the Azure hub. Design it as deliberately as routing.
Can I run disaster recovery across environments?
Yes — a primary in one environment can protect to a standby in another over the hybrid link, with redo shipping continuously. An on-premises primary can protect to a Database@Azure standby, or vice versa. Make sure the DNS and routing let applications find the new primary after a failover, or the DR is only half-built.
Does the application need to know it is talking across clouds?
No, and that is the point. The application connects to the database over a private address and a standard Oracle service name; the fact that packets cross ExpressRoute and the cross-cloud interconnect to a database in OCI is invisible to it. The network complexity is hidden beneath an ordinary-looking connection.
How much redundancy does the connectivity need?
As much as what depends on it. If production spans the link, treat it as production infrastructure: dual ExpressRoute circuits over genuinely diverse physical paths, zone-redundant gateways, and a tested backup path. If it only carries a one-off migration, simpler is fine. Size redundancy to the cost of an outage.
13.Key Takeaways
The short version
• Think in three environments. On-premises, Azure, and the OCI where the database runs — with Azure as the hub the other two connect through.
• Two private links chain through Azure. ExpressRoute joins on-premises to Azure; the Azure–OCI interconnect joins Azure to the database — one private path, no public internet.
• You own the Azure side. The cross-cloud link is provided; the VNet, routing, DNS, and security on the Azure side are yours to design well.
• Plan addressing and DNS first. Non-overlapping CIDR ranges and deliberate conditional forwarding prevent the two most common and most painful hybrid failures.
• Private is the floor of security, not the ceiling. Add encryption in transit, least-privilege NSGs, a central firewall, and identity on top of the private links.
• One network, three patterns. Migration, cross-environment DR, and split workloads all ride the same path — and it needs redundancy proportionate to what depends on it.
Hybrid cloud architecture with Oracle Database@Azure comes down to a triangle: on-premises, Azure, and the OCI where the database lives, joined by two private links that chain through Azure as the hub. Once that shape is clear, the rest of the design falls into place — ExpressRoute for the on-premises leg, the provided interconnect for the cloud-to-cloud leg, and your careful work on the Azure side to route, resolve, and secure the traffic that flows across both.
The enterprises that do this well treat the network as a first-class part of the architecture rather than plumbing to be sorted out later. They plan non-overlapping address space before provisioning, design DNS resolution as deliberately as routing, secure the private links with the full set of controls rather than trusting privacy alone, and give the connectivity redundancy that matches what depends on it. Do that, and the hybrid period — however long it lasts — stops being a source of fragility and becomes what it should be: one coherent estate that happens to span a datacenter and two clouds, working together as though they were always meant to.
Connectivity capabilities, the Azure–OCI interconnect, ExpressRoute behaviour, and platform networking details reflect Oracle and Microsoft documentation available at the time of writing and change frequently — verify current connectivity options, supported configurations, and setup steps against Oracle and Microsoft documentation before designing a hybrid network. All commands are illustrative, use placeholder names, addresses, and values, and must be validated against your own environment and current documentation before use. Example IP ranges are illustrative only. This article is independent commentary and is not affiliated with, endorsed by, or sponsored by Oracle or Microsoft.
Comments