15 · Oracle Autonomous AI Database on Azure
The provisioning lessons in this module create an Exadata Database Service — infrastructure, then a VM cluster, then a database that you operate. Autonomous AI Database is the other main way to run Oracle under Oracle Database@Azure: a self-driving database that Oracle operates for you, provisioned in a single step from the Azure portal.
Core message
Autonomous AI Database is Oracle's self-driving database, offered as a first-class service under Oracle Database@Azure. Where Exadata Database Service asks you to provision infrastructure, then a VM cluster, then a database — and then tune and patch it yourself — Autonomous is created in one step from the Oracle Autonomous AI Database@Azure pane in the Azure portal, and Oracle automates provisioning, scaling, tuning, patching (with no downtime), and backups. It runs on shared Exadata infrastructure (serverless) or on dedicated Exadata, stays inside your Azure virtual network through a delegated subnet, and accepts logical migration only. You manage a small set of functions from the Azure pane and reach the rest through a Go to OCI link.
Exadata Database Service versus Autonomous AI Database
| Aspect | Exadata Database Service | Autonomous AI Database |
|---|---|---|
| Provisioning | Infrastructure → VM cluster → database (multi-step) | One step from the Azure portal |
| Tuning and patching | You, on your own schedule | Oracle, automatically and without downtime |
| Scaling | You scale the VM cluster | Elastic and automatic (serverless) |
| Backups | You set schedule and retention to OCI Object Storage | Automated by Oracle |
| Infrastructure | Dedicated Exadata | Shared (serverless) or dedicated |
| Migration inputs | Physical or logical | Logical only |
| Best fit | Full control for mission-critical workloads | Minimal administration for variable workloads |
How you provision it
You create an Autonomous database from the Oracle Autonomous AI Database@Azure pane — either the Create an Oracle Autonomous AI Database button on the application home, or + Create on the blade. There is no infrastructure or VM cluster to build first. The Create flow is a short set of tabs:
- Basics — subscription, resource group, a name unique within the subscription, and the region.
- Configuration — the database configuration for the workload.
- Network access — how the database is reachable (see below).
- Maintenance — the patch level is read-only because Oracle patches the database on a regular, unobtrusive schedule; you can add up to 10 email addresses for notification of unplanned maintenance.
- Consent — review and accept the Oracle terms of service.
- Tags — optional tags for management and tracking.
Select Create, and the database provisions while you watch its status on the blade. For deeper administration, use the Go to OCI link on the instance.
Network access options
On the Network access tab you choose how clients reach the database:
- Managed private virtual network IP only — the database is reachable on a private IP inside a virtual network and subnet you select. Mutual TLS (mTLS) is optional.
- Secure access from allowed IPs — you list the permitted individual IP addresses, ranges, or CIDR blocks in an access-control rule. Mutual TLS (mTLS) is optional.
As with the Exadata services, Oracle Database@Azure reserves 13 IP addresses for the client subnet (versus 3 for a comparable OCI deployment), so size the delegated subnet accordingly.
What Oracle automates
The point of Autonomous is that day-to-day database administration is handled for you:
- Provisioning and configuration — the database is pre-configured and provisioned in one step.
- Scaling — compute and storage scale elastically with demand; the serverless option scales up and down automatically, so you pay for what you use.
- Tuning — self-tuning based on the workload.
- Patching — applied automatically with no downtime.
- Backups — automated by the service.
That leaves you to focus on the data and the application rather than infrastructure and maintenance.
Serverless or dedicated
- Autonomous AI Database (Serverless) — runs on shared Exadata infrastructure with automatic, elastic scaling. Best for variable or cloud-native workloads that want minimal administration and pay-per-use economics.
- Autonomous AI Database on Dedicated Exadata — the same Autonomous automation on dedicated Exadata infrastructure, for customers who need isolation as well as automation.
Migrating into Autonomous
Because Oracle manages the platform, an Autonomous target accepts logical migration only — you cannot use a physical RMAN restore or Data Guard into Autonomous. Move data with Data Pump, a database link, or GoldenGate. See Module 4 · Migrate to Oracle Database@Azure for the methods and how to choose one.
Customer value
- Less to operate — Oracle handles tuning, patching, scaling, and backups, which reduces the database administration burden.
- Pay for what you use — serverless scaling means cost follows demand rather than a fixed peak.
- Same Azure operating model — the database sits in the customer's Azure VNet, on the Azure bill (counting toward MACC), and is created and monitored from the Azure portal.
- A faster path to a database — one Create flow with no infrastructure to stand up first.
Risks and considerations
- Logical migration only — plan a Data Pump, database-link, or GoldenGate move; a physical method cannot target Autonomous.
- Less low-level control — Oracle manages the platform, so workloads that require specific patch timing or deep OS-level control may fit Exadata Database Service better.
- Delegated subnet sizing — the service reserves 13 client-subnet IPs; size the subnet before provisioning.
- Some management lives in OCI — the Azure pane covers a limited set of functions; deeper administration is via the Go to OCI link, so teams still need OCI familiarity.
Terms to remember
- Autonomous AI Database — Oracle's self-driving database; Oracle automates provisioning, scaling, tuning, patching, and backups.
- Serverless — Autonomous on shared Exadata infrastructure with automatic, elastic scaling.
- Dedicated — Autonomous on isolated, dedicated Exadata infrastructure.
- Managed private virtual network IP — private-IP access to the database from a selected VNet and subnet, with optional mTLS.
- Go to OCI — the link from the Azure pane to the OCI console for management functions not exposed in Azure.
"If a customer likes the idea of Oracle Database@Azure but does not want to run a database, I point them at Autonomous. The contrast with Exadata Database Service is the story: with Exadata we stand up infrastructure, a VM cluster, and a database, and then the customer's DBAs tune and patch it. With Autonomous, they open the Azure portal, hit Create, fill in a few tabs — name, region, how it is reached on the network, a maintenance contact — and Oracle runs it from there: scaling, tuning, patching with no downtime, backups, all automatic. Serverless is the default I reach for when the workload is variable, because it scales up and down and they pay for what they use. Two things I always flag: moving into Autonomous is logical only — Data Pump, a database link, or GoldenGate, never a physical restore — and some of the deeper management still happens through the Go to OCI link, so the team keeps a little OCI familiarity."