Exadata on AWS vs Azure vs Google Cloud

On this page

1. 01 · Three Clouds, One Exadata
2. 02 · What Is Identical on All Three Clouds
3. 03 · Architecture Side by Side
4. 04 · Integration, Identity and Monitoring Compared
5. 05 · Availability, Regions and Exascale
6. 06 · Commercials and Operations
7. 07 · How to Choose the Hosting Cloud
8. 08 · Common Mistakes When Comparing
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · Three Clouds, One Exadata

Comparison brief · Exadata inside AWS, Azure and Google Cloud

"If it is the same Exadata everywhere, why does the cloud matter?"

Every architecture board that looks at the Oracle Database@ partnerships ends up asking this. Oracle has put Exadata racks inside the data centers of all three big hyperscalers. Oracle Database@Azure went GA in December 2023, Oracle Database@Google Cloud in September 2024 and Oracle Database@AWS in July 2025. In October 2025, with Oracle AI Database 26ai, all three were renamed Oracle AI Database@Azure, @Google Cloud and @AWS. The database layer is identical: same Exadata generation family, same Oracle Database releases, same Smart Scan, RAC and Data Guard.

So the choice is rarely about the database itself. It is about where your applications already run, which identity system your security team trusts, which monitoring console your operations team watches, where your committed spend sits, and whether the region you need has the service you designed for.

02 · What Is Identical on All Three Clouds

Answer: On AWS, Azure and Google Cloud the Exadata hardware sits in the hyperscaler's data center, is operated by OCI as a child site of an OCI parent region, and runs the same Oracle Database software. Provisioning, billing and the first layer of networking go through the hyperscaler's console and marketplace.

It helps to separate the stack into layers before comparing anything. At the bottom is the Exadata infrastructure: database servers, storage servers and the RDMA network fabric. Oracle owns and operates it, patches the firmware and the hypervisor, and replaces failed parts. Above it is the VM cluster, where your Oracle homes and databases live. You own those: you choose database versions, apply database release updates (through the cloud tooling) and run the workload. Around both is the OCI control plane, which actually builds and maintains the clusters, even when you start the request from the AWS, Azure or Google Cloud console.

Because all of this is shared, DBA skills carry across directly: dbaascli, Data Guard association, automatic backups and quarterly patching work the same in every Database@ partnership.

03 · Architecture Side by Side

Answer: Each hyperscaler attaches Exadata to your network differently. AWS uses an ODB network that you connect to VPCs with ODB peering, Azure places the VM cluster's interfaces in a delegated subnet of your VNet, and Google Cloud uses client and backup subnets associated with your VPC. All three keep the database in the same data center as the application.

The diagram below draws the three partnerships next to each other. Each column is one hyperscaler region with your application network at the top, the network construct the database plugs into in the middle and the Oracle-operated Exadata site at the bottom. Underneath, each site is tied to its own OCI parent region, which is where the control plane, backups to OCI Object Storage and fleet tooling live. Reading the columns from top to bottom shows that the data path is short and local in every case, while the management path always goes back to OCI.

The blue arrows are the SQL*Net path and they never leave the hyperscaler region. The dashed red arrows are the OCI control plane: build, patch and scale requests flow from the parent region into each site. The yellow tags show general availability dates, which explain why Azure tends to have the most mature runbooks today.

The network constructs in practice

04 · Integration, Identity and Monitoring Compared

Answer: AWS emphasises native data and event integrations (zero-ETL to Amazon Redshift, S3 backups, CloudWatch, EventBridge, CloudFormation). Azure emphasises Microsoft Entra ID, Azure Monitor and ARM or Terraform automation. Google Cloud emphasises analytics and AI through BigQuery and Vertex AI with Cloud Monitoring and Cloud Logging.

This is where the partnerships genuinely differ, because each hyperscaler wires Exadata into its own services. The panel compares four areas that come up in every evaluation: native integration, identity, monitoring and how mature Exascale is on that cloud.

Read the bottom row with care. Exascale maturity is the area most likely to change during your project. Azure has run Exascale since March 2025, Google Cloud added Exascale with ExaDB-D in August 2026, and AWS reached Exascale GA on 13 August 2026 in three launch regions. Check the specific region before you design around it.

Identity in more detail

Identity is the area most often underestimated. There are two separate layers. The first is who can create, scale and delete Exadata resources, which every partnership controls through its own access model: AWS IAM policies, Azure RBAC on Microsoft Entra ID, or Google Cloud IAM roles. The second is who can log in to the database. Oracle Database supports Microsoft Entra ID authentication for database users, which makes Azure the most natural fit for teams that want single sign-on into the database itself. On AWS and Google Cloud, database users are typically still managed in the database or through your existing directory integration, while the cloud IAM controls the resource layer.

Monitoring in more detail

Each partnership publishes Exadata and database metrics into the native monitoring service: Amazon CloudWatch with CloudTrail auditing and EventBridge events on AWS, Azure Monitor with Log Analytics on Azure, Cloud Monitoring and Cloud Logging on Google Cloud. For deeper database diagnostics, such as AWR, ASH and SQL-level performance, DBAs still use Oracle tooling, either in the database or through OCI Database Management and Ops Insights in the parent region. Decide which team watches which dashboard.

05 · Availability, Regions and Exascale

Answer: Azure has the longest track record (GA December 2023) and the earliest Exascale (March 2025). Google Cloud followed in September 2024. AWS is the newest (GA July 2025), but by 2026 Oracle AI Database@AWS was listed in more than 20 AWS regions. Region and service coverage changes often, so always verify the exact region.

A comparison of three expanding services is only useful with dates, so here is the timeline as it stood at the time of writing (late 2026). Exascale, sold as Exadata Database Service on Exascale Infrastructure (ExaDB-XS), is the small-entry option. Dedicated infrastructure (ExaDB-D) and Autonomous AI Database on Dedicated Exadata Infrastructure are the larger-footprint options.

Two practical points follow from this. First, the age of a partnership is a good proxy for how many questions have already been answered in documentation, community posts and support cases. Second, region lists are kept separately for the Database@ service and for each Exadata offering inside it. A region can run ExaDB-D long before it offers Exascale, so a "yes" for the cloud is not a "yes" for your design.

06 · Commercials and Operations

Answer: In all three partnerships you buy through the hyperscaler marketplace, receive one bill from that hyperscaler, and the spend can count toward your cloud commitment there. Licence-included and bring-your-own-licence options exist, and Oracle runs the infrastructure while your team runs the databases.

Commercially, the partnerships are built the same way, which is the point: Oracle wanted Exadata to look like any other first-party service to a customer's cloud finance team. You accept a public or private offer in the hyperscaler marketplace, usage is metered by Oracle and billed by the hyperscaler, and the spend can count toward an existing commitment, for example a Microsoft Azure Consumption Commitment. Confirm BYOL and Oracle Support Rewards treatment in your offer, because private offers vary.

Operationally, the split of responsibilities is also the same on every cloud. The table below is the one to agree with your operations team before go-live.

07 · How to Choose the Hosting Cloud

Answer: Start from where the applications that query the database run, because that keeps the data path inside one data center. Then confirm that the region satisfies data residency, including the DR region, and check which cloud commitment the spend should land in. Only fall back to another cloud or OCI with interconnect when those gates fail.

The decision flow below captures how ExaGuru architects run this conversation. It deliberately puts application placement first, because moving Exadata away from its applications to chase a feature or a discount trades a permanent latency and egress cost for a temporary benefit. Residency and commitments act as gates: either can push you to a different region or a different construct, but they rarely justify splitting an application from its database.

Note the right-hand exits. When residency fails, the answer is a compliant region or OCI with an interconnect such as Oracle Interconnect for Azure or Google Cloud, or AWS Direct Connect to OCI FastConnect. When the commitment gate fails, you still co-locate with the applications and fix the commercial side separately.

A short evaluation routine

1. Map the callers. List every application, ETL job and reporting tool that connects to the database, with the cloud and region it runs in today. The majority by traffic, not by count, decides the primary cloud.
2. Verify the service in that region. Confirm Database@ coverage and the exact Exadata offering (ExaDB-D, ExaDB-XS or Autonomous) in the primary and DR regions.
3. Check residency. Make sure both regions and the backup destination sit inside the required jurisdiction.
4. Map the money. Decide which marketplace offer, which commitment and which licence model apply.
5. Prototype the network. Build the construct (ODB network, delegated subnet or client and backup subnets) with real CIDRs and measure latency from a real app subnet.

08 · Common Mistakes When Comparing

Most failed comparisons share a few patterns. Avoid them and the choice usually becomes obvious.

1. Comparing list prices only. The Exadata meters are similar across clouds. The real cost differences are egress, cross-region traffic and whether spend counts toward a commitment you have already signed.
2. Ignoring identity. If your security team mandates Microsoft Entra ID for database login, that requirement weighs heavily toward Azure, whatever the infrastructure comparison says.
3. Treating Exascale as universal. It is on all three clouds, but not in every region. Design for the offering that exists in your region today.
4. Splitting app and database across clouds. Cross-cloud SQL*Net works, but every round trip pays for it. Keep chatty OLTP applications in the same cloud as the database.

Pick the cloud your applications already live in. The Exadata will be the same; the integration work will not.

09 · Key Takeaways

1. The database layer is the same everywhere. Exadata hardware, Oracle Database releases and OCI operations are identical on AWS, Azure and Google Cloud.
2. The network construct differs. ODB network with ODB peering on AWS, delegated subnet on Azure, client and backup subnets on Google Cloud.
3. Native integrations are the real differentiator. Redshift zero-ETL and CloudWatch on AWS, Entra ID and Azure Monitor on Azure, BigQuery and Vertex AI on Google Cloud.
4. Maturity and regions vary. Azure is the longest running, AWS the newest; Exascale coverage differs by region on every cloud.
5. Choose by application placement first. Then pass the residency and commitment gates; only then consider another cloud or OCI with interconnect.

10 · Frequently Asked Questions