Oracle Database@Azure Reference Architecture
Oracle Database@Azure Reference Architecture
Article Overview
The other guides on this blog each go deep on one topic — networking, security, high availability, backup, monitoring, and so on. This one does the opposite. It steps back to show how all those pieces fit together into one complete design for Oracle Database@Azure. Think of it as the big picture: a single drawing that shows every layer at once, and how the layers connect and support each other. It makes a clear choice for each layer instead of listing every option, and then points you to the deep-dive that explains the details. If you are setting up a Database@Azure environment and want one place that shows the whole thing — the hub-and-spoke network, the database subnet, the identity and security model, the storage and HA design, the backup and monitoring layers, and how a request moves through all of them — this is it. The diagrams do most of the work.
1.What a Reference Architecture Is For
A reference architecture is not a tutorial, and it is not a list of every option. It is a proven, ready-to-use design — a known-good way to arrange the parts that you can start from and then adjust to your own needs, instead of building from scratch and hoping the pieces fit. Its value is that the big decisions are already made, and it shows how the layers fit together. So you get one design that works as a whole, instead of a pile of parts that are each fine on their own but do not quite line up.
That fit is the whole point. Any good engineer can design a solid network, or a solid backup plan, on its own. The hard part — the part this design solves — is making them all work together: the network's segments matching the security model, the identity design supporting both, the monitoring able to see across everything, and the HA and backup layers agreeing on what "recovered" means. This article lays out one such complete design for Oracle Database@Azure, layer by layer, and shows how the layers connect.
Designing each layer well is the easy part. The real value of a reference architecture is making the layers work together — so the whole design holds up, not just the pieces.
How to read this article
Each layer below is covered the same way: the recommended choice, a diagram or table to make it clear, and a link to the deep-dive on this blog that explains the details. The master diagram in the next section is the map; the layer sections are the detail. If you read only one thing, read the master diagram — everything else just explains it.
2.The Master Architecture
Here is the whole design on one page. It is built as an Azure environment using the hub-and-spoke pattern. The Oracle database sits in its own subnet and is reached over a private link, and the shared concerns — identity, security, monitoring, backup — run across all of it. Read it top to bottom: users and identity at the top, the Azure network in the middle, and the Oracle database on Exadata at the base. Security wraps around everything, and monitoring and backup run down the side.
Adopt the shape, adapt the details
Use this master drawing as the shape to copy, and treat the details as yours to adjust. The hub-and-spoke layout, the database subnet, the security wrapper, and the monitoring and backup rails are the parts that stay the same. The exact sizes, regions, zone choices, and product options inside each box are where you fit it to your own needs. Starting from a design that already works and adjusting it is much safer than gluing parts together and hoping they fit.
3.The Networking Layer
Recommended choice: a hub-and-spoke network, with the database in its own subnet reached over a private link, and a central firewall that all traffic between zones passes through. This is the backbone that the rest of the design attaches to.
| Element | Canonical choice |
|---|---|
| Topology | Hub-and-spoke; shared services in the hub, workloads in spokes |
| Database placement | Delegated subnet, private endpoint, no public exposure |
| On-prem connectivity | ExpressRoute (private circuit), VPN as backup path |
| Cross-cloud | The private Azure–OCI interconnect provided with the platform |
| DNS | Central private resolver, conditional forwarding both directions |
| Inspection | Central firewall; cross-boundary traffic routed through it |
Deep-dive on this blog
The hybrid-architecture and beginner's-guide posts cover the networking details in full — ExpressRoute setup, the interconnect, address planning, and DNS forwarding. For this design, the key point is where things sit: the hub is the center, the database sits in its own subnet reached over a private link, and the address ranges for on-premises, Azure, and the database subnet must never overlap.
4.The Identity Layer
Recommended choice: use Microsoft Entra ID as the single place for identity — controlling who can manage the Azure resources and, through federated login, who can sign in to the database itself. One identity source, applied the same way everywhere, instead of a separate set of database-only accounts.
Azure resource access
Entra ID with role-based access control decides who can manage the Database@Azure resources, the network, and the related services. Give each person the least access they need, and keep admin roles tightly held.
Database authentication
Federated login lets database sign-ins be controlled by Entra ID users and rules, so access to the data follows the same directory that controls everything else.
Conditional access & MFA
Multi-factor authentication and conditional-access rules are set in one place, so the conditions for granting access are the same across the whole environment.
One identity plane is a security control, not just convenience
Putting everything on Entra ID is not just tidier — it makes you safer. One identity source means one place to require MFA, one place to cut off access everywhere at once, and one clear record of who can do what. Separate database-only accounts are the opposite: hard to manage, easy to forget, and a common source of old admin access that no one removed. This design treats one identity source as a foundation, because every layer above it is only as strong as the identity below it.
5.The Security Layer
Recommended choice: defense in depth — several independent layers of protection, so that no single failure exposes the data. In the master diagram, security is drawn as a wrapper around every other layer, because that is how it should work: present at every layer, not added to just one.
| Layer | Canonical control |
|---|---|
| Identity | Entra ID, MFA, least privilege, controlled break-glass |
| Network | Private-only access, least-privilege NSGs, central firewall, segmentation |
| Encryption in transit | Encrypted SQL*Net / TLS on every path |
| Encryption at rest | Transparent Data Encryption, with keys you control |
| Privileged-user control | Database Vault; separation of duties enforced in the database |
| Detection | Unified auditing streamed to Sentinel; alerting on real threats |
| Recovery from attack | Immutable, retention-locked backups — ransomware cannot destroy the recovery path |
Deep-dive on this blog
The security best-practices post covers each of these controls in depth — TDE and key management (rotate the master key from the Oracle/OCI side, never the Azure side), Entra ID, Database Vault, and sending audit data to Sentinel. For this design, the main idea is simple: security belongs in every layer at once. It is drawn around the whole thing because protecting only one point is not really security at all.
Security is not one layer in the stack — it wraps around every layer. Drawn any other way, the design is showing you where the gap will be.
6.The Storage Layer
Recommended choice: rely on Exadata's built-in storage instead of designing storage yourself. The Oracle database runs on Exadata, and its smart storage — offloading, storage indexes, ASM-managed redundancy, and the fast link between compute and storage — comes with the platform. You do not build it.
So the storage part of this design is mostly about what you do not have to do: you are not sizing disks, setting up RAID, or tuning a storage array, because the platform gives you storage built for Oracle. What is left for you are the higher-level choices — planning capacity from real usage data, turning on the compression that suits your workload, and making sure encryption at rest is on. The performance-tuning post covers how the storage speeds up queries; here the point is that good storage comes built in.
| Storage concern | Reference-architecture stance |
|---|---|
| Redundancy / RAID | Handled by ASM and the engineered platform — not yours to configure |
| Performance acceleration | Exadata offload and storage indexes — inherited, not assembled |
| Encryption at rest | TDE on, keys controlled from the Oracle/OCI side |
| Capacity | Plan from measured data; use compression where it fits the workload |
| Growth | Elastic scaling of the platform rather than array re-provisioning |
The best storage design here is mostly configuration, not construction
Coming from on-premises, the habit is to design storage in detail. On this platform, that habit mostly goes away: the storage is already built, so your effort goes into using it well — right capacity, right compression, encryption on — rather than building it. That is a good thing. It removes a whole set of work and lets storage be something you set up, not something you have to construct.
7.The HA and DR Layer
Recommended choice: use RAC for local high availability, and Active Data Guard for disaster recovery to a standby in another zone or region — picking the level that matches how critical the workload is. This is Oracle's Maximum Availability Architecture applied to the platform.
| MAA tier | Design | For |
|---|---|---|
| Bronze | Single instance + backups | Standard systems |
| Silver | RAC (local HA) | Important systems |
| Gold | RAC + Active Data Guard standby | Business- and mission-critical |
| Platinum | Gold + the most advanced zero-loss features | The most demanding systems |
Deep-dive on this blog
The HA/DR best-practices and mission-critical posts cover the methods and the tiering choice in full. For this design, the recommended level is Gold for anything that matters — RAC for local resilience, a standby in a second zone, and a standby in a second region for disasters — with the app tier and DNS set up to fail over together with the database, not after it.
8.The Backup and Recovery Layer
Recommended choice: back up the database with the Autonomous Recovery Service — real-time protection, locked backups that cannot be changed or deleted, and tested recovery — not the tools that back up the surrounding VMs. This is the layer people misunderstand most, so this design is clear about it.
⚠️ Azure Backup does not protect the Exadata database engine
One key point this design makes clear: Azure's own backup tools back up the surrounding virtual machines, not the Exadata database itself. The database is protected by Oracle's tools — the Autonomous Recovery Service (recommended) or OCI Object Storage — which use RMAN underneath. Planning the database backup as if Azure Backup covered it leaves a gap that only shows up when you try to recover, which is the worst possible time to find out.
| Concern | Canonical choice |
|---|---|
| Primary DB backup | Autonomous Recovery Service — real-time, immutable, retention-locked |
| Alternative | OCI Object Storage backups where ARS is not used |
| Ransomware defense | Retention-lock immutability so backups cannot be deleted or altered |
| Point-in-time recovery | Real-time redo protection enables near-zero-data-loss restore |
| Validation | Regular test restores — an untested backup is only a hope |
📊 Deep-dive on this blog
The backup-and-recovery post covers the Autonomous Recovery Service, Object Storage backups, retention periods, and recovery scenarios in depth. For this design, the recommended choice is ARS for the database with locked backups that cannot be changed, kept clearly separate from any VM backup of the app tier — and recovery proven by test runs, not just assumed.
9.The Monitoring Layer
Recommended choice: a three-layer monitoring model — infrastructure, database detail, and a single combined view on top — with the built-in Azure Monitor link sending Exadata metrics, logs, and events into Azure, and Oracle's own tools kept for deep database checks. One screen to watch, with easy drill-down when it points you somewhere.
Correlation layer
Azure Monitor, Workbooks, Log Analytics, and Sentinel — where you watch day to day, seeing across every layer of the design in one place.
Database depth
Oracle Enterprise Manager and OCI Database Management for the deep SQL and wait-event detail that the built-in Azure link does not try to cover.
Infrastructure
Exadata metrics and events in Azure Monitor, plus Azure Arc for the operating-system layer — the health of everything beneath the database.
Monitoring is drawn as a rail running alongside every layer in the master diagram because it has to see all of them. A slow request might be the app tier, the network, the database, or the storage, and only a view that covers the whole stack can tell you which. The built-in link — which sends Exadata metrics, logs, and events into Azure Monitor, set up through diagnostic settings to a Log Analytics workspace — is what makes that full view possible without joining two clouds together by hand.
Deep-dive on this blog
The monitoring post covers the three-layer model, the built-in Azure Monitor link, diagnostic settings and the four log types, KQL queries, and combined dashboards in full. For this design, the recommended choice is: watch from the single Azure view, keep Oracle's own tools for drill-down, and connect it all to a small set of trusted, useful alerts rather than a wall of noise.
10.How a Request Flows Through It
The best test of a design like this is to follow one request through it and watch every layer do its job. Follow a user's query from click to result, and the whole thing works as one system rather than eight separate parts.
Here it is in words: the user signs in through Entra ID with MFA; the app in the spoke builds a query and opens a connection that the network allows only because the NSG permits SQL*Net from that spoke and the firewall and DNS route it correctly; the connection crosses the private interconnect into the database subnet; the RAC database on Exadata runs the query against encrypted storage and sends the result back along the same private path. The whole way, security is applied at every step, monitoring watches the entire trip in one combined view, and backup has already made every saved change recoverable. Five layers in a row, three shared concerns running across them — all working as one.
A good design is one where a single request quietly uses every layer and every shared concern at once — and you cannot tell where one ends and the next begins.
11.Reference Bill of Materials
Putting the recommended choices together, here is the whole design as one build list — the layers, the recommended choice for each, and where to read the details.
| Layer | Canonical choice | Deep-dive |
|---|---|---|
| Network | Hub-and-spoke; delegated DB subnet; ExpressRoute + interconnect; central firewall & DNS | Hybrid architecture |
| Identity | Entra ID single plane; RBAC; MFA; federated DB authentication | Security best practices |
| Security | Defense-in-depth; TDE; Database Vault; auditing to Sentinel | Security best practices |
| Storage | Engineered Exadata storage; ASM; TDE at rest; compression | Performance tuning |
| HA / DR | Gold MAA — RAC + Active Data Guard (zone + region) | HA/DR best practices |
| Backup | Autonomous Recovery Service; retention-lock immutability | Backup & recovery |
| Monitoring | Three-layer model; native Azure Monitor integration; OEM depth | Monitoring |
Start from this list, then justify every deviation
A practical way to use this build list: make it the default, then require a clear reason for any change. If a system does not use Gold HA, or skips locked backups, or leaves out the combined monitoring, that should be a deliberate, written-down decision tied to a real reason — not something that was simply forgotten. Starting from the recommended setup and explaining any changes is how you keep a growing environment consistent.
12.Frequently Asked Questions
Is this the only correct architecture?
No — it is a solid, recommended starting point, not the only valid design. Its value is that the big shared decisions are already made and work together. Copy the shape (hub-and-spoke, database subnet, security wrapper, monitoring and backup rails) and adjust the details to your needs, explaining any changes rather than starting from a blank page.
Why is the database in a delegated subnet rather than a spoke I fully control?
Because that is how the platform puts the Oracle database privately into your Azure network — it is reached over the private interconnect and controlled by an NSG you own, without being exposed to the public internet. In this design the app spoke connects to it over SQL*Net, allowed only by tight least-privilege rules.
Where does security actually live?
Everywhere — which is why it is drawn as a wrapper, not a layer. Identity controls access, the network keeps paths private and tightly limited, encryption protects data in transit and at rest, Database Vault limits what admin users can do, and audit data feeds detection. Protecting only one point would leave a gap; defense in depth spreads the controls across every layer.
What is the most common architectural mistake this prevents?
Assuming Azure Backup protects the database. It does not — it covers the surrounding VMs, while the database is protected by the Autonomous Recovery Service or OCI Object Storage. Building that difference into the design stops teams from finding the gap when they try to recover.
How does monitoring see across two clouds?
Through the built-in Azure Monitor link, which sends Exadata metrics, logs, and events into Azure Monitor through diagnostic settings, together with Oracle's own tools for deep database checks. That is what lets the single combined view watch every layer of the design from one place while still allowing deep drill-down.
Can I adopt this incrementally?
Yes. The network, identity, and security layers are the foundation and come first; the HA level, backup, and monitoring can be brought up to the recommended standard over time. The build list is a target to work toward, and a system can start at a lower HA level and be moved up as its importance — and budget — allow.
13.Key Takeaways
The short version
• One design that works together. A reference architecture is worth it because it makes the layers fit each other — not because it designs each one on its own.
• Hub-and-spoke with a delegated subnet. The network is the backbone: central firewall, connectivity, and DNS in the hub; the database reached privately in a delegated subnet.
• Identity is one source; security wraps everything. Entra ID controls access everywhere, and defense in depth wraps every layer rather than being just one of them.
• Storage comes built in; you pick the HA level. Exadata's storage is a strength you just set up; Gold MAA — RAC plus Active Data Guard — is the recommended shape for anything that matters.
• Protect the database the right way. The Autonomous Recovery Service with retention-lock immutability — not Azure Backup, which covers only the surrounding VMs.
• Watch from one pane. The three-layer observability model, fed by native Azure Monitor integration, sees across every layer while keeping Oracle-native depth for drill-down.
In the end, a reference architecture is a way of turning a dozen good decisions into one system that works together. The separate layers of an Oracle Database@Azure setup — the network, identity, security, storage, HA design, backup plan, and monitoring — are each covered in depth elsewhere on this blog. What this article adds is how they fit: the master drawing that shows how they stack up, the shared concerns that run through all of them, and the single request that uses every layer at once and shows the whole thing holds together.
Use it as a starting point, not a fixed rule. Copy the shape — the hub-and-spoke backbone, the database subnet, the security wrapper, the monitoring and backup rails, and Gold HA as the default — and adjust the details to your own workloads, with a clear reason for each change. Designs that stay consistent as they grow are almost always the ones that started from a whole that already worked and changed on purpose, rather than being pieced together one part at a time. That is what a reference architecture is for: to give you a working whole on day one, so every good decision you make afterward has something solid to build on.
Platform capabilities, native integrations, supported services, and architectural options reflect Oracle and Microsoft documentation available at the time of writing and change frequently — verify current features, supported configurations, and design guidance against Oracle and Microsoft documentation before implementing. This reference architecture is a general, recommended design shown for illustration and must be adapted to your own requirements, constraints, and current platform capabilities. The diagrams are conceptual, not deployment templates. This article is independent commentary and is not affiliated with, endorsed by, or sponsored by Oracle or Microsoft.
Comments