Oracle Exadata on AWS: What Oracle AI Database@AWS Really Means

On this page

1. 01 · Why Exadata Inside AWS Changes the Conversation
2. 02 · What Oracle AI Database@AWS Actually Is
3. 03 · The Architecture: Who Runs What, and Where
4. 04 · Latency: Why Placement Inside the Region Matters
5. 05 · Billing and Commercials Through AWS
6. 06 · Management: Consoles, APIs and AWS Integrations
7. 07 · Database@AWS vs Oracle on EC2 vs Amazon RDS for Oracle
8. 08 · Is It the Right Fit? A Decision Checklist
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · Why Exadata Inside AWS Changes the Conversation

Architecture brief · Oracle AI Database@AWS

"We are an AWS shop. Can we keep Exadata?"

For years the answer was awkward. Teams that standardised on AWS had three options for Oracle: run it themselves on EC2, accept the limits of Amazon RDS for Oracle, or keep the database on premises or in OCI and connect across a network link. Each choice gave something up: RAC, Smart Scan, operational simplicity, or latency between the application and the database.

Oracle Database@AWS, generally available since July 2025 and renamed Oracle AI Database@AWS in October 2025, removes that trade-off. Oracle installs Exadata racks inside AWS data centers, OCI operates them, and you provision and pay through AWS. The database sits a few network hops from your EC2 or EKS workloads, yet it is the same Exadata platform that runs on OCI and on premises.

02 · What Oracle AI Database@AWS Actually Is

Answer: Oracle AI Database@AWS is a jointly delivered service in which Oracle runs Exadata infrastructure and Oracle Database services inside AWS regions. You subscribe through AWS Marketplace, create resources from the AWS console or API, and connect your VPCs to the database over a private ODB network.

The key word is inside. This is not a hosted connection to OCI, and it is not an AWS rebuild of Oracle's software. The physical Exadata database servers and storage servers are installed in an AWS facility. Oracle treats that footprint as an OCI child site linked to an OCI parent region, which is where the control plane, fleet automation and support tooling live.

From the database team's point of view, the services are the same ones they already know from OCI:

03 · The Architecture: Who Runs What, and Where

Answer: Three domains meet in every deployment: your VPCs in the AWS region, the Oracle-operated Exadata site in the same AWS data center, and an OCI parent region that hosts the control plane. Application traffic stays inside AWS; management traffic flows from OCI.

The figure below is the reference topology. On the left, your VPC holds the application tier. In the middle, the Oracle-operated Exadata site contains an ODB network with a client subnet and a backup subnet, the VM cluster your databases run in, and the Exadata infrastructure underneath. Along the bottom are the AWS services Oracle and AWS have integrated. On the right, the OCI parent region provides the control plane and optional key and backup services. Read it from left to right to follow a SQL call, and from right to left to follow a patching run.

The blue "ODB peering" arrow is the only path your application uses, and it never leaves the AWS region. The dashed red "mgmt" arrow is the OCI control plane building and patching the VM cluster. Backups can land in Amazon S3 or, through the orange arrows, in OCI backup targets. Keys can stay in OCI Vault or be Oracle-managed.

The ODB network

The ODB network is the private network that the Exadata resources live in. You create it in the Oracle AI Database@AWS console (or with the aws odb CLI) in one Availability Zone, and you give it two CIDR ranges: a client subnet for SQL*Net traffic and a backup subnet for backup traffic. Neither range may overlap with each other, with any VPC you plan to peer, or with ranges OCI reserves.

aws odb create-odb-network \
    --display-name prod-odb-net \
    --availability-zone-id use1-az4 \
    --client-subnet-cidr 10.50.0.0/24 \
    --backup-subnet-cidr 10.50.1.0/24

Once the ODB network exists, you create the Exadata infrastructure (or choose Exascale), then a VM cluster inside that network. The database servers get VNICs in the client subnet, which is the address space your application connects to.

ODB peering

ODB peering connects the ODB network to a VPC. It works like VPC peering in that traffic stays on the AWS backbone, and you still add routes in the VPC route tables and allow port 1521 (or your listener port) in security groups. Applications in other VPCs reach the database through transit routing, for example AWS Transit Gateway or Cloud WAN, or through service networking with VPC Lattice. Confirm the supported pattern for your region before you design a hub-and-spoke layout around it.

04 · Latency: Why Placement Inside the Region Matters

Answer: Latency is the main reason to choose Database@AWS over a cross-cloud link. The VM cluster sits in the same Availability Zone as the ODB network, so an application in a peered VPC in that AZ gets the shortest possible path. Every extra hop, such as another AZ or a transit gateway, adds round-trip time to every SQL call.

OLTP applications are chatty. A single page view can issue dozens of SQL statements, and each one pays the network round trip. That is why the same application can feel fine against a local database and sluggish against one in another cloud, even when the bandwidth is identical. Database@AWS fixes the distance; your job is not to undo it with a poor network design.

The walkthrough below traces four typical requests through the ODB network. Each example starts from a different source and takes a different path, so the destination tags show both where the traffic lands and what it costs in latency or design effort. Use it as a checklist when you place new workloads: the first example is the pattern to aim for, and the others are legitimate but need a deliberate decision.

Example 1 is the design target: an EC2 or EKS workload in a VPC peered directly with the ODB network, in the same AZ. Example 2 works but adds a transit hop. Examples 3 and 4 are not application traffic at all: backups use the separate backup subnet, and zero-ETL is a managed feed, so neither competes with SQL*Net.

05 · Billing and Commercials Through AWS

Answer: You buy Oracle AI Database@AWS through AWS Marketplace, usually as a private offer, and the charges appear on your AWS bill. That spend can count toward your AWS commitments. Oracle licensing works through license-included or Bring Your Own License options, and Oracle Support Rewards may apply.

This is a large part of the appeal for finance teams. Instead of a separate Oracle cloud contract, procurement adds Oracle database spend to an existing AWS agreement. The consumption is metered by Oracle and billed by AWS, so cost reports, tags and budgets live in the tools the cloud team already uses.

06 · Management: Consoles, APIs and AWS Integrations

Answer: Day-to-day resource management happens from AWS: the console, the aws odb CLI, CloudFormation and IAM policies. Database-level operations such as creating PDBs, patching Oracle homes and configuring Data Guard use Oracle tooling, reached from AWS or the OCI console. Metrics and events flow into CloudWatch and EventBridge.

The split is logical once you see the topology. AWS owns the request: who can create an ODB network, which VPC is peered, which tags apply. Oracle owns the platform: the hypervisor, the Exadata software, the storage servers and the infrastructure patching schedule. Your team owns the databases, exactly as it would on OCI.

What stays with the DBA

Oracle runs the infrastructure, but DBAs still own schema design, performance tuning, database patch timing within Oracle's windows, Data Guard configuration, user management and backup policy. In practice the runbooks look like OCI runbooks with an AWS front door. Teams that already run ExaDB-D on OCI usually find the learning curve is on the AWS side: IAM, peering and CloudWatch, not the database.

07 · Database@AWS vs Oracle on EC2 vs Amazon RDS for Oracle

Answer: Choose Oracle AI Database@AWS when you need Exadata performance, RAC or large consolidation inside AWS. Choose Oracle on EC2 when you need full OS control or unusual configurations. Choose Amazon RDS for Oracle for smaller, standard databases where a fully managed service matters more than Exadata features.

All three run the same Oracle Database engine, which is why the choice is easy to get wrong. The difference is the platform under the database and who operates it. The comparison below lines up the six questions that usually decide the matter in an architecture review. Green cells are strengths, amber cells are trade-offs to plan around and red cells are hard limits. Read down a column to see what a platform gives you, and across a row to see who wins on that question.

The rows that usually decide it are RAC and Smart Scan. If a workload depends on RAC for availability or on Exadata offload for performance, only the Database@AWS column keeps them. If neither matters and the database is small, RDS for Oracle removes the most operational work.

08 · Is It the Right Fit? A Decision Checklist

Database@AWS is not a default for every Oracle database on AWS. It is the right answer when Exadata capabilities, latency to AWS applications and AWS commercial alignment all matter. Work through these steps before committing:

1. List the workloads and their dependencies. Mark which databases use RAC, Exadata features, or need sub-millisecond latency to AWS-hosted applications. Those are your Database@AWS candidates.
2. Check region and service availability. Confirm that your AWS region offers Oracle AI Database@AWS (listed in more than 20 AWS regions in 2026) and that it offers the service you want: ExaDB-D, ExaDB-XS or Autonomous.
3. Design the ODB network early. Reserve non-overlapping CIDR ranges for the client and backup subnets, pick the Availability Zone that hosts your application tier, and decide how other VPCs will reach it.
4. Agree the commercial route. Work with AWS and Oracle on the Marketplace private offer, commitment credit and BYOL mapping before you size.
5. Write down the operating model. Who patches Oracle homes, who watches CloudWatch alarms, who owns backups in S3 versus OCI, and who calls Oracle Support.
6. Plan the migration path. Zero Downtime Migration with Data Guard for physical online moves, or GoldenGate and Data Pump for logical moves and version changes.

Database@AWS does not make Oracle an AWS-native database. It makes Exadata an AWS-adjacent platform, close enough that the application never notices the difference.

09 · Key Takeaways

1. Exadata really is inside AWS. Oracle installs and operates Exadata in AWS data centers as an OCI child site linked to an OCI parent region.
2. The ODB network is the front door. A client subnet and a backup subnet in one AZ, connected to your VPCs through ODB peering.
3. Placement decides latency. Keep latency-sensitive applications in the same AZ and in a directly peered VPC.
4. You pay through AWS. AWS Marketplace offers put Oracle spend on the AWS bill, where it can count toward commitments.
5. Pick the platform per workload. Database@AWS for Exadata, RAC and consolidation; EC2 for full control; RDS for Oracle for small standard databases.

10 · Frequently Asked Questions