Oracle Database@AWS — Architecture, Licensing and Pricing Guide 2026

Oracle Database@AWS was announced in September 2024 as the third major Oracle Database@Hyperscaler service alongside the existing Oracle Database@Azure and the subsequent Oracle Database@Google Cloud. The service places physical Oracle Exadata infrastructure inside AWS regions, operated by Oracle Cloud Infrastructure (OCI) staff, accessible to AWS workloads through low-latency private connectivity, and billed through one of three commercial routes (AWS Marketplace, Oracle Universal Credits, or direct Oracle invoicing).

For the enterprise customer running production Oracle workloads on AWS, the service materially changes the architecture and the licensing options. For the customer operating a hybrid Oracle-AWS estate, it introduces a third sourcing channel for Oracle Database consumption with distinct commercial economics. For both, the audit and compliance exposure is novel — Oracle LMS interpretation of the Database@AWS deployment, the BYOL transfer rules, and the support boundary between Oracle and AWS are all being established through the first wave of customer engagements.

This guide covers the architecture, the licensing rules, the commercial models, the buyer-side comparison against alternatives, and the audit defence framework. For the broader cloud licensing context, see the Oracle cloud licensing master guide. For the parallel Azure architecture, see Oracle Database@Azure pricing benchmarks 2026. For the variant decision framework across Exadata Cloud Service, ExaCC, and Oracle Database@Azure, see Exadata OCI vs ExaCC vs Database@Azure.

The architecture — Oracle Exadata in AWS regions

Oracle Database@AWS is delivered through dedicated Oracle Exadata X10M infrastructure installed in AWS data centres. The Exadata racks are physically located in selected AWS regions (initial 2025 availability: us-east-1, us-west-2, eu-central-1, eu-west-1, ap-southeast-2, with progressive regional expansion through 2026). The infrastructure is operated and managed by Oracle Cloud Infrastructure operations under an Oracle service framework; AWS provides the physical facility, power, cooling, and the high-bandwidth network connectivity to AWS native services.

From the customer's perspective, the Database@AWS environment appears as a standard OCI Exadata Database Service tenancy accessible through the OCI Console and OCI CLI, but provisioned inside AWS regions with private connectivity to AWS Virtual Private Clouds. The compute scaling, the storage allocation, the Database creation, the patching, and the operational support all flow through OCI. The AWS-native services (S3, Lambda, EKS, EMR, the AWS analytics stack) consume from the Oracle Database via low-latency private endpoints.

The four commercial models — pick the right one

Model 1 — Licence-Included Subscription

The customer pays an all-in subscription price covering the Database@AWS infrastructure consumption plus the Oracle Database licences (Enterprise Edition, RAC, Exadata-equivalent options) on a metered basis. The model suits customers without significant existing Oracle Database licence inventory or customers consolidating from a higher-cost on-premise position. Pricing is published by Oracle in the OCI pricing list per OCPU-hour and per storage-GB-month.

Model 2 — Bring Your Own Licence (BYOL)

The customer applies existing Oracle Database Enterprise Edition processor licences against the Database@AWS consumption. The compute rate is materially lower (typically 60 – 70% discount against the licence-included rate) because the licence component is supplied by the customer. The BYOL economics favour customers with significant existing licence inventory — a customer with surplus licences from a ULA exit or from right-sized on-premise consolidation captures the BYOL discount without the licence cash outlay.

BYOL eligibility requires Oracle Database Enterprise Edition licences with active Premier Support. Options (Partitioning, Diagnostics Pack, Tuning Pack, Real Application Clusters where applicable) must be separately licensed at the deployed footprint. The BYOL rules are documented in the Oracle Database@AWS BYOL guide and are essentially identical to the OCI BYOL framework. See multi-cloud BYOL rules.

Model 3 — Oracle Universal Credits

The customer commits to a multi-year Oracle Universal Credits consumption value and draws down Database@AWS consumption against the commitment. The Universal Credits route delivers contractual discount on the consumption rate (typically 8 – 22% against the on-demand rate depending on commitment size and term) plus Support Rewards eligibility (25 cents on each $1 of consumption applied against eligible on-premise Oracle support). This is the model most large Oracle Database@AWS deployments use.

Model 4 — AWS Marketplace

The customer procures Oracle Database@AWS through AWS Marketplace, billed on the AWS invoice and drawing against the customer's AWS Enterprise Discount Programme commitment. Suits customers with an existing AWS EDP commitment they want to consume against; the unit pricing is comparable to the OCI direct routes but the commercial structure folds into AWS-side commercial mechanics rather than Oracle-side. The model is most useful for customers whose internal procurement function prefers single-supplier consolidation onto AWS.

The pricing benchmark — what the unit economics actually look like

The unit prices above are indicative benchmarks from active 2026 customer engagements; actual published rates vary by region, configuration shape, and the customer's specific Universal Credits commitment level. The pricing list at the Oracle published rate is materially higher than the negotiated rate available through Universal Credits commitment structuring — the standard 8 – 22% Universal Credits discount range applies to Database@AWS consumption as it does to native OCI consumption. For the Universal Credits negotiation framework, see Oracle OCI negotiation strategy. The line item most often missing from the initial commercial proposal is the network egress cost — for the full forecasting framework, see egress costs in Oracle@Hyperscaler deals — the hidden bill.

The licensing rules — what BYOL covers and what it does not

BYOL coverage on Database@AWS

Covered with standard Oracle Database Enterprise Edition processor licences: Oracle Database Enterprise Edition core engine, deployed on Database@AWS OCPUs at standard processor-to-OCPU conversion (2 OCPUs = 1 Processor licence on the standard core-factor calculation, with Exadata-specific OCPU mapping).

Covered with the corresponding options licences: Partitioning, Diagnostics Pack, Tuning Pack, Advanced Compression, Advanced Security — each option must be licensed at the deployed OCPU footprint matching the underlying Database Enterprise Edition licence quantity. The BYOL discipline requires the same forensic right-sizing that applies to on-premise Database deployments. See the Oracle Database licensing master guide.

Covered with the corresponding RAC licence: Real Application Clusters — Database@AWS supports RAC across multiple OCPUs on the same Exadata infrastructure. The RAC licence quantity must match the deployed OCPU footprint running RAC.

BYOL does NOT cover

Exadata-specific features (Smart Scan, Storage Indexes, Hybrid Columnar Compression, Smart Flash Cache) are included in the Database@AWS Exadata infrastructure subscription and do not require separate Oracle Exadata Database Machine licences as they would on-premise. This is a material BYOL economic benefit — the Exadata feature licensing on-premise is non-trivial; on Database@AWS it is embedded in the infrastructure rate.

Database@AWS infrastructure components (the Exadata storage cells, the InfiniBand network, the platform management) are not BYOL-eligible — these are consumed at the published infrastructure rate regardless of the customer's licence model.

The audit and compliance position — what changes

Oracle audit liability on Database@AWS runs between the customer and Oracle Corporation under the Oracle Master Agreement, exactly as it does on any other Oracle deployment. The Database@AWS commercial structure does not transfer audit liability to AWS. What does change is the operational surface area Oracle LMS can inspect: the Database@AWS environment is managed by OCI operations, which removes some customer-managed infrastructure forensics from the audit perimeter.

Specifically: the underlying Exadata infrastructure (storage cells, hypervisor configuration, platform-level options usage) is not a customer-managed inspection target. The deployed OCPU count, the Database options usage, and the RAC deployment are still measurable by Oracle through the OCI tenancy reporting and are still subject to standard Oracle audit mechanics on the BYOL portion of the consumption.

The compliance gap risk on Database@AWS is materially lower than self-managed Oracle on AWS EC2 (where USMM script execution against customer-managed EC2 instances drives the LMS audit). It is not zero, and the standard audit defence framework still applies. For the broader audit context, see the Oracle audit defence master guide and audit risk in Oracle Database@Hyperscaler deployments.

The architecture decision — Database@AWS vs RDS for Oracle vs self-managed

Use Database@AWS when

• The workload requires Oracle Real Application Clusters (RAC) — RDS for Oracle does not support RAC.
• The workload requires Exadata performance features (Smart Scan, Storage Indexes, Hybrid Columnar Compression) — RDS for Oracle does not support Exadata.
• The workload requires Oracle Autonomous Database — not available on RDS or self-managed EC2.
• The customer has significant existing Oracle licence inventory (ULA exit, right-sized estate) that benefits from BYOL pricing on a managed service.
• The customer wants AWS-native consumption (S3, Lambda, the AWS analytics stack) over Oracle Database without operating the Database stack themselves.

Use RDS for Oracle when

• The workload tolerates RDS feature constraints (no RAC, no Exadata, limited HA options).
• The customer prefers AWS-managed operational tooling, AWS billing consolidation, and AWS-side support relationships.
• The deployment is sub-enterprise scale (small databases, dev/test environments, application-tier supporting databases).

Use self-managed Oracle on EC2 when

• The customer requires Oracle Database versions or configurations not supported by RDS or Database@AWS.
• The customer has bespoke infrastructure requirements (specific kernel modules, custom patching cycles, non-standard storage architectures).
• The customer accepts the materially higher audit exposure of self-managed Oracle on hyperscaler infrastructure.

"Oracle Database@AWS is the first major shift in Oracle's hyperscaler stance — physical Oracle infrastructure inside the AWS data centre, managed by Oracle, consumable by AWS workloads. The architecture is novel; the licensing rules are still being established. The customers in the first wave are writing the buyer-side defence framework in real time."

An anonymised case study — Fortune 500 retail Oracle modernisation on AWS

A North American retail enterprise carried a 240-processor Oracle Database Enterprise Edition deployment across on-premise data centres supporting the merchandising, supply chain, and finance application stack. The modernisation programme called for migration of the application tier to AWS-native services while retaining Oracle Database for the transactional workloads. Pre-engagement state: 240 processors of Oracle Database Enterprise Edition plus Partitioning, Diagnostics Pack, Tuning Pack, Real Application Clusters; $4.6M annual Oracle support spend.

The architecture decision evaluated three options: self-managed Oracle Database on AWS EC2 (rejected on audit exposure), AWS RDS for Oracle (rejected on absence of RAC support for the transactional workloads), and Oracle Database@AWS (selected on technical fit and BYOL economics). The Database@AWS deployment used the customer's existing 240 processor licences against the Database@AWS BYOL pricing, eliminating the licence-included subscription premium.

The Oracle commercial engagement structured a 36-month Universal Credits commitment of $6.0M ($2.0M per annum) covering the Database@AWS consumption plus adjacent OCI services for analytics workloads. The Universal Credits commitment delivered an 18% discount against the on-demand rate and generated Support Rewards capture of approximately $500k per annum against the on-premise residual support stream (Oracle EBS supporting financial close, retained on-premise during the modernisation).

The buyer-side defence prevented three Oracle attempts at scope expansion during the deal: the proposed conversion of Premier Support to Java SE Universal Subscription bundling (declined as out-of-scope), the proposed migration of Oracle E-Business Suite to Fusion Cloud as a Universal Credits add-on (declined pending separate evaluation), and the proposed audit-waiver only for the migrated Database scope rather than the full residual estate (re-scoped to cover both). The resulting commercial position carried $1.4M of annual savings against the pre-engagement support spend plus three years of contractual audit waiver across the Database scope.

The four buyer-side negotiation moves on Database@AWS

Move 1 — Benchmark all three commercial routes. The Licence-Included, BYOL, and Universal Credits routes deliver materially different economics depending on the customer's specific licence inventory and consumption profile. Request quotes for all three routes on identical workload scope; the cheapest route is rarely obvious from Oracle's account-team narrative.

Move 2 — Negotiate the Universal Credits discount independently from the AWS commercial structure. The Universal Credits discount is set by Oracle Deal Desk regardless of whether the consumption is delivered through Database@AWS or native OCI. Treat the Database@AWS deployment decision (architecture) separately from the Universal Credits commercial decision (Oracle commercial structure).

Move 3 — Lock the support-cost trajectory on the on-premise residual. Most Database@AWS deployments are partial migrations — a portion of the Oracle estate moves to Database@AWS, a portion remains on-premise. Lock the support uplift cap on the residual on-premise scope as part of the Database@AWS deal structuring. The combined cloud-and-on-premise commercial event compounds the negotiation surface area.

Move 4 — Negotiate audit-waiver years across the full Oracle scope. Use the Database@AWS commitment as the trigger for audit-waiver years covering both the migrated and the residual Oracle deployment. The waiver is granted by Deal Desk on customers materially expanding OCI consumption; Database@AWS commitment qualifies the customer for the waiver.

Frequently asked questions

What is Oracle Database@AWS?

Oracle Database@AWS is the dedicated managed Oracle Database service announced jointly by Oracle Corporation and Amazon Web Services in 2024, delivering Oracle Exadata Database Service and Oracle Autonomous Database inside AWS data centres with full Oracle Database functionality including Real Application Clusters. The service uses physical Oracle Exadata infrastructure deployed inside AWS regions, with the Oracle estate managed by Oracle Cloud Infrastructure operations and billed through Oracle Universal Credits, AWS Marketplace, or direct Oracle invoicing depending on the customer's commercial structure.

Can I bring my own Oracle Database licences to Database@AWS?

Yes — Oracle Database@AWS supports both Bring Your Own Licence (BYOL) and licence-included subscription models. BYOL allows the customer to apply existing Oracle Database Enterprise Edition processor licences against Database@AWS consumption at a discounted compute rate. The BYOL economics favour customers with significant existing licence inventory; the licence-included subscription favours customers without. The choice should be made through forensic comparison of the customer's specific licence position against the Database@AWS unit economics, not by default reseller preference.

Does Oracle Database@AWS reduce audit exposure?

Oracle Database@AWS is operationally managed by Oracle Cloud Infrastructure, which removes some forensic surface area Oracle LMS would otherwise inspect through USMM scripts on customer-managed infrastructure. The audit exposure does not disappear — it shifts. Oracle still measures the deployed footprint against the customer's licence position; the BYOL portion of the Database@AWS deployment is still subject to standard Oracle audit mechanics. The compliance gap risk on Database@AWS is materially lower than self-managed Oracle on AWS EC2 but not zero, and the standard audit defence framework still applies.

How does Oracle Database@AWS compare to RDS for Oracle?

Oracle Database@AWS runs full Oracle Database functionality including Real Application Clusters, Exadata performance features, and Oracle Autonomous Database on dedicated Oracle infrastructure inside AWS. Amazon RDS for Oracle runs Oracle Database Enterprise Edition on AWS-managed EC2 with feature restrictions (no RAC, no Exadata, limited high-availability options)