Exadata Exascale on AWS: Architecture, Scaling & Pricing Model

On this page

1. 01 · Why Exascale on AWS Matters
2. 02 · What Changes With Exascale
3. 03 · Reference Architecture on AWS
4. 04 · The Exascale Stack, Layer by Layer
5. 05 · How Scaling Works
6. 06 · The Pricing Model Explained
7. 07 · When Exascale on AWS Is the Right Choice
8. 08 · Key Takeaways
9. 09 · Frequently Asked Questions

01 · Why Exascale on AWS Matters

Architecture brief · ExaDB-XS on Oracle AI Database@AWS

"We want Exadata for this app, but not a whole rack of it."

When Oracle AI Database@AWS launched, the entry point was Exadata Database Service on Dedicated Infrastructure. That suits a bank consolidating fifty databases, but it is a hard sell for a single 2 TB application database or a dev and test fleet. Teams in that position usually fell back to Amazon RDS for Oracle or self-managed Oracle on EC2 and gave up Exadata features to save money.

Exascale changes the maths. On 13 August 2026 Oracle made Exadata Database Service on Exascale Infrastructure (ExaDB-XS) generally available on Oracle AI Database@AWS, starting in US East (N. Virginia), US West (Oregon) and EU Central (Frankfurt). Instead of renting servers, you rent a VM cluster and a slice of storage from a shared Exadata pool, billed per ECPU and per gigabyte.

02 · What Changes With Exascale

Answer: Exascale replaces dedicated Exadata hardware with a multi-tenant pool. Your VM cluster draws ECPUs from shared database servers, and your data lives in an Exascale storage vault on shared storage servers. The Exadata software features stay: Smart Scan, storage indexes and RDMA-based data access.

On dedicated infrastructure you pick a rack shape, then carve VM clusters out of it. You pay for the infrastructure whether you use it or not, and storage is the fixed capacity of the storage servers you rented. Exascale removes that layer. Oracle owns and pools the hardware across many tenants, and you consume only the compute and storage your databases need.

Oracle's own positioning is that Exascale offers up to 95 percent lower minimum infrastructure cost than ExaDB-D. The important word is minimum: the saving is largest at small scale, where a dedicated rack would sit mostly idle. For very large, steady estates, dedicated infrastructure can still be the better fit.

03 · Reference Architecture on AWS

Answer: ExaDB-XS on AWS uses the same front door as dedicated Exadata: an ODB network in one Availability Zone, peered with your VPC. Behind it, the VM cluster runs on a shared pool of Exadata database servers and stores data in your Exascale storage vault on shared storage servers. OCI's control plane manages it from the parent region.

The topology below shows the full path. Your application tier sits in a customer VPC. The ODB network inside the Oracle-operated site holds the client subnet and the VMs of your ExaDB-XS cluster. Underneath, the shared Exascale pool contains the database servers your VMs run on, the storage servers that hold every tenant's data, and the vaults that separate one tenant's files from another. Backups and metrics go to Amazon S3 and CloudWatch. Notice that nothing in the picture is a rack that you own.

The black RDMA arrow is what keeps Exascale fast: database servers read from storage servers over the Exadata RDMA fabric, so Smart Scan and storage indexes still work. The dashed vault box labelled "Other tenants" is the multi-tenancy boundary. You share hardware, never data or VMs.

Storage vaults

An Exascale storage vault is your logical storage container in the pool. You size it in GB when you create the VM cluster and increase it later. Database files, redo and snapshots live in the vault as Exascale files rather than in ASM disk groups you manage. The vault is also the unit you are billed for on the storage side.

Isolation in a shared pool

Multi-tenancy is the part architects ask about first. Each tenant gets its own VMs, its own ODB network and its own vault. Data is encrypted with TDE, with keys held by Oracle or in OCI Vault as customer-managed keys. The pool shares physical servers and the RDMA network, and Exadata's I/O resource management keeps one tenant's scan from starving another's OLTP.

04 · The Exascale Stack, Layer by Layer

Answer: Think of ExaDB-XS on AWS as five layers: the VM cluster, the ECPU allocation, the storage vault, the shared Exadata pool and the AWS data center. You size and run the top three. Oracle operates the shared pool, and AWS runs the facility.

The layered view below is the simplest way to explain Exascale to a finance or procurement team. Each band is a layer of the service. The "Who runs it" column shows the operational owner, and the "How it is billed" column shows which layers appear on the AWS bill and how. It also answers the most common question from DBAs who come from on-premises Exadata: where did the rack, the cell disks and the grid disks go? They are still there, inside the shared pool, but they are no longer your problem.

The two yellow tags are the whole pricing model: ECPU-hours and GB-months. The green "No IOPS charge" tag on the shared pool is the line that most often surprises teams coming from EBS, where provisioned IOPS and throughput are separate line items.

05 · How Scaling Works

Answer: Exascale scales compute and storage separately. You raise or lower enabled ECPUs on the VM cluster online, increase vault capacity in GB as data grows, and create thin clones from snapshots for test and development. None of these steps requires buying or resizing infrastructure.

The timeline below follows one realistic cluster through its first year. It starts small for a new application, absorbs a month-end peak by raising ECPUs, grows its vault as data accumulates, and provides thin clones for testing. The bars under each phase show the relative shape of the monthly bill, split into ECPU-hours and storage. They are illustrative only, not a price list, but they show why consumption pricing tracks the workload instead of the hardware.

The key detail is month 2 to month 6: the blue ECPU bar falls back after the peak, while the yellow storage bar keeps growing. On dedicated infrastructure you would have sized for the peak all year. Thin clones in the last phase add only a small amount of storage because they share unchanged blocks with the source.

Scaling compute

Enabled ECPUs are set per VM cluster and can be changed from the AWS console, the OCI console or the API. The change is online: the databases keep running while capacity is added. For workloads with a predictable rhythm, such as month-end close, teams script the change with EventBridge schedules or OCI automation so the ECPUs come down again afterwards.

Scaling storage

Vault capacity grows in GB. Because Exascale does not charge for IOPS, you do not need to buy extra capacity to get extra performance, which is a common workaround on block storage. Plan headroom for snapshots and clones, since they also consume vault space as they diverge from the source.

Thin clones for test and development

Exascale snapshots let you create space-efficient copies of a pluggable database in seconds to minutes, depending on size. A typical refresh looks like this:

-- in the CDB root, with the source PDB open
CREATE PLUGGABLE DATABASE sales_test FROM sales_prod SNAPSHOT COPY;
ALTER PLUGGABLE DATABASE sales_test OPEN;

Run data masking on the clone before handing it to developers. Thin clones copy the data, including any sensitive columns, exactly as they are in production.

06 · The Pricing Model Explained

Answer: ExaDB-XS on AWS bills two meters: ECPUs per hour and Exascale storage per GB per month. There is no Exadata infrastructure charge and no separate IOPS charge. You buy through an AWS Marketplace offer, choose license included or BYOL, and the spend appears on your AWS bill.

The model is simple to describe and easy to underestimate. Compute is usually the larger line item for OLTP, while storage dominates for large, rarely queried archives. Because the meters are independent, you can tune each one to the workload instead of buying a balanced box.

A practical way to estimate

1. Measure today's CPU use. Take AWR peaks and averages from the current system and convert them to ECPUs with Oracle's sizing guidance.
2. Separate peak from baseline. Price the baseline for the whole month and the peak only for the hours it actually runs.
3. Size the vault. Current data plus 12 months of growth, plus space for the number of clones you expect to keep.
4. Add backups and licences. Choose backup retention per environment and decide between license included and BYOL.
5. Compare with the alternatives. Put the result next to an ExaDB-D quote and an RDS for Oracle or EC2 estimate for the same workload.

07 · When Exascale on AWS Is the Right Choice

Exascale is not a smaller version of dedicated Exadata. It is a different consumption model that happens to run the same software. The decision depends on the size, shape and growth of each workload, and on how much infrastructure you want to own.

Many estates end up with both: ExaDB-D for the consolidated production core and ExaDB-XS for new applications and non-production. Because both use the same ODB network model and the same Oracle Database releases, moving a database between them is a Data Guard or Data Pump exercise, not a re-platforming project.

Exascale turns Exadata from a capacity purchase into a consumption decision. On AWS, that finally puts it within reach of the workloads that used to end up on RDS by default.

08 · Key Takeaways

1. Exascale is live on AWS. ExaDB-XS has been generally available on Oracle AI Database@AWS since 13 August 2026, starting in N. Virginia, Oregon and Frankfurt.
2. Shared pools, private data. Your VM cluster and vault run on shared Exadata servers, with Smart Scan and RDMA intact and tenant isolation by VM, network and vault.
3. Two meters only. ECPU-hours and storage GB-months, with no infrastructure charge and no IOPS charge.
4. Scale each side separately. Raise ECPUs online for peaks, grow the vault for data, and use thin clones for test.
5. Pick per workload. ExaDB-XS for small, growing and non-production databases; ExaDB-D for large, steady, consolidated estates.

09 · Frequently Asked Questions