Networking for Database@Azure: Delegated Subnets Explained

Most Database@Azure projects stand or fall on a decision made in the first planning workshop: the delegated subnet. Oracle operates real Exadata infrastructure inside Azure data centers, and the service reaches your applications through a subnet in your own virtual network that you delegate to the service. The Exadata VM cluster receives addresses from that subnet, your applications connect to those addresses over ordinary private VNet routing, and from the application's point of view the database is simply another private endpoint in the Azure network. That elegance is exactly why the networking decisions deserve care, because the subnet you delegate is difficult to change once the cluster is alive on it.

This article is a deep dive within our multicloud database series. The pillar, Oracle Database@Azure, @AWS, and @Google Cloud: The Buyer Guide, frames the strategic choice across providers, and our complete guide to Database@Azure covers the service end to end. Here we focus on one layer: how the network attachment works, how to plan the delegated subnet, how traffic actually flows, and the mistakes that surface at cutover when it is most expensive to fix them.

How Database@Azure attaches to your network

The mechanism is subnet delegation. You create a subnet in a VNet you own and delegate it to the Oracle service, which hands Oracle the right to place the network interfaces of the Exadata VM cluster into that subnet. The cluster's listener addresses, SCAN addresses, and node addresses all come out of your address space. There is no public endpoint in the default design, no NAT in the data path, and no gateway hop between an Azure hosted application and the database: traffic moves over the VNet fabric as private east west traffic inside the region.

This is the architectural difference between Database@Azure and connecting Azure applications to a database in an OCI region over an interconnect. In the interconnect pattern, which we cover in OCI to Azure networking, traffic crosses a boundary between two clouds, and the design work is about that boundary. With Database@Azure the database is already inside the Azure region, so the design work moves inward: address planning, routing between VNets, DNS, and the controls around a subnet you own but do not fully control. How that compares to simply running the workload in OCI is a fair question, and we take it on directly in Database@Azure versus native OCI.

Planning the delegated subnet

Three planning rules cover most of what goes wrong. First, size the address space generously. The cluster consumes more addresses than people expect once node interfaces, SCAN addresses, and growth are counted, and resizing a delegated subnet later is not a quick edit: it can mean standing up a new subnet and moving the workload. Whatever minimum the portal accepts, plan well above it, and leave room for the cluster you will scale to, not the one you start with.

Second, the subnet must not overlap with anything it will ever need to talk to. That includes the on premises ranges reachable over ExpressRoute, every peered VNet in the hub and spoke, and any future acquisition or partner network you can reasonably foresee. Overlap is the classic silent failure: everything works in the lab, then a peering or a route is added months later and two networks that must communicate cannot. Treat the delegated subnet as a permanent reservation in the corporate address plan, recorded wherever your organization records such things.

Third, follow the one subnet per VM cluster pattern. Sharing a delegated subnet across clusters couples their lifecycles and their failure domains, and it makes security boundaries mushy. Separate clusters for production and non production, in separate delegated subnets, in clearly separated VNets or clearly separated address blocks, is the layout that stays legible as the estate grows.

How traffic flows

The common deployment is hub and spoke. Application tiers live in spoke VNets, the spokes peer with a hub, and the delegated subnet lives either in the hub or in a dedicated data VNet peered to it. An application in a spoke reaches the database over VNet peering, the traffic stays on the Azure backbone inside the region, and the round trip is short enough that latency sensitive Oracle workloads behave the way they would on a well built on premises network. Nothing in the data path between Azure applications and the database leaves the Azure region in this design.

Management is the part that involves OCI. Oracle operates the Exadata infrastructure through the OCI control plane, and the deployment is represented in OCI as a child site that hangs off an OCI region: you see the resources in an OCI tenancy, and Oracle's automation manages the platform over Oracle's own management path. That path is Oracle's responsibility and does not carry your application traffic, but it matters for two practical reasons. Operational identities and policies for the database layer live partly in OCI, so your access model spans both clouds, and certain service flows such as backups to OCI services or cross region Data Guard follow paths you should understand and bandwidth plan rather than discover. Which Azure regions offer the service, and which OCI region each one pairs with, changes over time; Oracle publishes the current region list, and we discuss how to read it in Database@ regions and availability.

Integrating with on premises

Most estates adopting Database@Azure still have application tiers, batch schedulers, and integration platforms on premises, and those reach the database over the same ExpressRoute connectivity that serves the rest of the Azure estate. The route is unremarkable, which is the good news: ExpressRoute into the hub, hub to the delegated subnet, no special handling. The planning points are bandwidth and DNS. Bandwidth, because database traffic from on premises is often chattier than teams expect, and a circuit sized for office workloads can become the bottleneck for a migration wave or a nightly batch window.

DNS deserves its own paragraph because it is the most commonly deferred decision and the most disruptive one to defer. Applications connect to the database through names, SCAN names in particular, and those names must resolve correctly from Azure spokes, from on premises, and from anywhere else a client lives. That means deciding early how the database zones are hosted, how private DNS zones attach to which VNets, and how on premises resolvers forward queries for those zones into Azure. Teams that leave DNS until cutover weekend end up debugging connection storms at two in the morning that are really just resolution failures. Where backups or other service integrations use private endpoints, those endpoints need addresses and DNS entries planned with the same discipline.

Security controls on a delegated subnet

A delegated subnet is yours, but not entirely yours. You control the VNet, the peerings, and the routing around it. Oracle's automation controls the interfaces inside it. Network security groups can be associated with the delegated subnet, but they do not behave exactly like NSGs on an ordinary subnet: the service imposes rules it needs for the platform to function, some flows are managed by the service rather than by your rule set, and an NSG written as if this were a normal application subnet can either block something the platform requires or silently fail to constrain what you assumed it constrained. The honest model is layered: use NSGs and routing to govern who can reach the database listener from your side, and accept that the inside of the cluster is operated by Oracle under its own controls.

Route tables follow the same logic. Forcing database traffic through an inspection appliance in the hub is possible for client flows, but it must be designed deliberately, with the throughput of the appliance and the latency budget of the application both checked, and management flows must never be strangled by a well meaning default route. Document who in your organization can change the NSGs, the route tables, and the peerings around the delegated subnet, because the blast radius of a casual network change here is the production database.

Disaster recovery traffic

If the architecture includes DR, the network plan must include it from day one. Data Guard between a Database@Azure deployment in one region and a standby in another region, or between Database@Azure and an OCI region, generates sustained replication traffic that scales with redo volume, and the paths it takes are exactly the ones that carry charges and have bandwidth ceilings. Model the steady state redo rate, then model the catch up case after a network interruption, because the catch up case is the one that saturates links. The full design space, including where the standby should live and how failover is orchestrated, is covered in DR for the Database@ services.

Design decisions at a glance

Common mistakes

The failure patterns are remarkably consistent across projects, which at least makes them easy to list.

• Undersized subnets. A minimal block chosen to conserve address space, exhausted by the second VM cluster or the first scale out.
• Overlapping address space. The delegated subnet collides with an on premises range or a future spoke, discovered only when the peering goes in.
• Treating NSGs as ordinary. Security rules written without understanding service managed flows, blocking platform traffic or providing imaginary protection.
• DNS deferred to cutover. Name resolution designed during the migration weekend instead of before it.
• No bandwidth plan for backups and Data Guard. Replication and backup traffic landing on links sized for application chatter.
• Nobody owning the boundary. Network changes around the delegated subnet made by people who do not know a production database lives behind it.

A network design framework for Database@Azure

Here is the sequence we run when we design or review the network layer for a Database@Azure deployment.

Where we fit

The network layer is the part of a Database@Azure project where experience compounds fastest, because the decisions are made once, early, and under time pressure, and the cost of revisiting them is measured in migration weekends. This is core territory for our OCI networking practice, and it is usually delivered inside a wider engagement through our implementation service: address plan, topology, DNS design, security model, and the bandwidth math, reviewed before anything is delegated. We work as an independent firm on a fixed project fee for design and migration work, or a managed monthly retainer when we run the estate after go live, and the planning workshop that prevents an undersized subnet costs a small fraction of the project that fixes one.

The short version of this whole article: Database@Azure networking is not exotic, it is unforgiving. Plain VNet routing, plain peering, plain ExpressRoute, all of it familiar, attached to one subnet that you get to define exactly once. Spend the planning effort there, in proportion to how hard it is to change, and the rest of the network design is a calm exercise in patterns you already know.