Imagine your entire enterprise application already runs on AWS. Web servers on Amazon EC2, APIs on ECS or EKS, files in Amazon S3, monitoring in CloudWatch. Then someone asks the question that stops every architecture review cold:
Where should our Oracle Database run?
For years the answer was constrained: lift-and-shift Oracle onto EC2, accept the limits of Amazon RDS for Oracle, or migrate everything to Oracle Cloud Infrastructure. Enterprise customers wanted something different — Exadata performance and OCI automation without leaving the AWS ecosystem they had already invested in.
Oracle's answer is Oracle Database@AWS. Oracle brings its database services into AWS data centers while continuing to manage the platform through OCI. Your applications stay in AWS. Your database runs on co-located Exadata. Let's walk through what actually happens behind the scenes.
01 · What Is Oracle Database@AWS?
Oracle Database@AWS is a strategic multi-cloud partnership that co-locates Oracle's specialized Exadata hardware directly inside AWS data centers — managed by the OCI control plane but accessed natively by AWS applications. It builds on similar partnerships with Microsoft Azure and Google Cloud, and it represents a major milestone in Oracle's broader multi-cloud strategy.
Historically, connecting AWS applications to OCI databases meant routing traffic across the public internet or custom carrier circuits. That introduced variable latency, fragmented identity models, and complicated support matrices. Database@AWS eliminates those friction points by installing physical Oracle Exadata infrastructure in the same availability zones as your AWS compute.
On EC2, your team owns installation, patching, HA, tuning, and EBS storage configuration. RDS for Oracle automates admin tasks but lacks RAC, Exadata Smart Scan, and Autonomous Database. Database@AWS combines OCI-managed automation with raw Exadata performance — all while your workloads remain inside AWS.
Procurement is straightforward: the service is available through the AWS Marketplace, so you can buy using existing AWS procurement channels and count spend toward Enterprise Discount Program commitments or reserved capacity agreements — no separate Oracle sales cycle required for initial provisioning.
02 · What Runs Inside AWS?
The design principle is simple: leave your application layer exactly where it is. The following native AWS components run inside your Virtual Private Cloud (VPC):
EC2, EKS, ECS, and Lambda run your application servers, business logic, Kubernetes pods, and serverless functions. They connect to the database via standard Oracle Net (SQL*Net) client drivers.
Amazon S3 holds media assets, processing files, and reporting outputs — accessible to AWS analytics pipelines without cross-cloud data movement.
Amazon CloudWatch aggregates application telemetry, metrics, and infrastructure alerts — keeping operators in a single pane of glass.
Application roles, execution policies, and engineer access limits to AWS resources are defined and enforced through AWS Identity and Access Management.
Under the shared responsibility model, AWS remains responsible for physical security, virtualization, networking, and availability of these application-side components.
03 · What Runs Inside Oracle Cloud Infrastructure?
While the database appears as a local resource to AWS applications, the underlying software, platform tooling, and physical infrastructure are delivered by OCI — the same hardware and automation that drives Oracle's native public cloud regions.
- Oracle Exadata Database Machine — dedicated database servers and intelligent storage cells with PCI Express NVMe flash and high-capacity drives optimized for Oracle workloads.
- Oracle Autonomous Database — fully automated operations including self-tuning, auto-patching, and autonomous scaling on co-located Exadata.
- OCI Control Plane — orchestrates provisioning, automated backups, rolling patches, and real-time database metrics.
- Exadata Storage Server software — executes Smart Scans, hybrid columnar compression, and storage-level encryption offloads separate from AWS compute.
Oracle retains full responsibility for maintaining, patching, and securing the Exadata hardware, OCI virtualization layer, database automation routines, and database engine software.
04 · Oracle Database@AWS Architecture
The split-stack model keeps applications in AWS and databases on co-located OCI infrastructure, connected by a private low-latency link inside the same physical facility.
Figure 1 · Split-stack architecture — AWS applications connect to co-located OCI Exadata via private link
05 · How Do AWS Applications Reach the Database?
The networking layer is the foundation of Database@AWS. If round-trip times between your application tier and the database exceeded a single millisecond, transactional throughput for enterprise OLTP workloads would collapse. Co-location exists specifically to prevent that.
Oracle and AWS bridge AWS Direct Connect and OCI FastConnect inside the co-located data center facilities. This dedicated private connection bypasses the public internet entirely. When an EC2 instance sends a query, the packet travels over an optimized VPN path directly to the Exadata database interface — typically achieving sub-millisecond latency.
AWS VPC Endpoints and Private DNS
Applications connect through native AWS VPC endpoints (interface endpoints) that route database traffic into the co-located Oracle infrastructure without exposing connection strings to the public internet. A private hosted zone in Amazon Route 53 resolves database TNS descriptors to OCI private endpoint addresses across the peering link. Traffic stays secure, isolated, and free of complex overlay networks or public IP schemes.
Direct Connect Patterns
For enterprise workloads, architects typically implement one of these patterns:
- Co-located fabric (default) — Direct Connect and FastConnect bridged inside the same facility; lowest latency, no internet transit.
- Extended Direct Connect — On-premises data centers connect via Direct Connect to AWS, then traverse the co-located link to Oracle databases for hybrid architectures.
- Virtual interface (VIF) configuration — Dedicated VIFs across the co-located cloud link for production traffic, separate from general AWS connectivity.
Deploy application compute (EC2, EKS) in the same availability zones as the co-located Exadata hardware. Cross-AZ hops add latency that co-location was designed to eliminate.
06 · Identity and Security
Multi-cloud architectures risk fragmented security policies and disjointed identity structures. Database@AWS addresses this through explicit identity federation and secure bridging across both environments.
Figure 2 · Identity federation and secure database connectivity across AWS and OCI
- Identity federation — Enterprise directories (Microsoft Entra ID, Okta) federate with both AWS IAM and OCI IAM. One login, uniform RBAC.
- Secrets management — Credentials and encryption keys live in AWS Secrets Manager or OCI Vault; applications retrieve them at runtime.
- Data encryption — Oracle Net encryption or TLS in transit; Transparent Data Encryption (TDE) at rest with enterprise-managed keys.
07 · Which Oracle Database Services Are Available?
Oracle does not offer cut-down versions. Database@AWS provides flagship enterprise services, fully optimized and OCI-managed:
Oracle Exadata Database Service
Run Oracle Enterprise Edition on dedicated Exadata inside AWS data centers — with all advanced options including Oracle Real Application Clusters (RAC) for active-active HA, Multitenant for containerized management, and Advanced Compression. RAC nodes span availability zones within the co-located ring, giving you the same clustering model you would expect on-premises or in native OCI.
Oracle Autonomous Database
A serverless, fully automated service that configures, tunes, secures, scales, and backs up without routine DBA intervention — ideal when your team wants to focus on application logic rather than patch weekends.
Both options include native Oracle Data Guard for automated standby configuration across availability zones or regions, delivering robust disaster recovery with defined RTO and RPO targets.
| Capability | Exadata Database Service | Autonomous Database |
|---|---|---|
| RAC support | Native active-active clustering | Managed internally by OCI automation |
| Admin model | Scheduled rolling patches via OCI | Fully autonomous — zero-touch patching |
| Ideal workload | Mission-critical OLTP, custom tuning | Elastic SaaS backends, rapid provisioning |
| Procurement | AWS Marketplace · BYOL or License Included | |
08 · Enterprise Deployment Scenarios
Four practical scenarios where Database@AWS delivers a distinct advantage over EC2-hosted Oracle or RDS for Oracle.
Example 1: Large E-Commerce Company
Challenge Storefront on Amazon EKS across multiple AZs; inventory backend requires high-throughput OLTP and sub-second response during peak events.
Solution EKS containers scale dynamically; inventory runs on Exadata Database Service with RAC via the Direct Connect/FastConnect link. Smart Scans and active-active availability keep page loads fast without migrating microservices out of AWS.
Example 2: Financial Services Organization
Challenge AWS for analytics and fraud detection; core ledger on Oracle must meet strict regulatory standards with cross-region DR.
Solution Ledger on Autonomous Database@AWS with TDE and automated point-in-time backups. EMR and QuickSight ingest data through secure private endpoints — no public internet exposure.
Example 3: Global Healthcare Provider
Challenge Clinical apps on EC2; EHR database must guarantee 99.999% uptime, HIPAA compliance, and zero RPO.
Solution Exadata Database Service with RAC nodes across two AWS AZs. Data Guard maintains a synchronized standby in a separate region. AZ outage triggers seamless failover without dropping active patient-care sessions.
Example 4: Global SaaS Company
Challenge Multi-tenant ERP on AWS-native framework; backend must scale CPU and storage with daily transaction swings.
Solution Autonomous Database@AWS with auto-scaling. Terraform scripts call both AWS and OCI providers simultaneously for unified infrastructure-as-code.
09 · Enterprise Reference Architecture
A production-grade layout spanning multiple AWS availability zones, shared AWS services, and a co-located OCI Exadata cluster with Data Guard DR.
Figure 3 · Multi-AZ AWS application tier connected to co-located Exadata RAC with Data Guard DR
10 · Database@AWS vs EC2 vs RDS for Oracle
Three primary methods for running Oracle Database workloads alongside AWS infrastructure — compared side by side.
| Attribute | Oracle on Amazon EC2 | Amazon RDS for Oracle | Oracle Database@AWS |
|---|---|---|---|
| Infrastructure | Customer-managed EC2 and EBS | AWS-managed infrastructure | Oracle-owned Exadata hardware, co-located |
| Management | Manual install, patch, backup — full DBA ownership | Automated patching, provisioning, local backups | OCI control plane automation (Exadata or Autonomous) |
| Oracle support | Standard support; customer resolves infra issues | Support via AWS; licensing limits apply | Direct Oracle collaborative engineering |
| Performance | Bounded by EBS IOPS and network limits | Standard RDS storage engine limits | Exadata Smart Scan, persistent memory, flash |
| Oracle RAC | Not native (complex third-party tools) | Not supported | Fully supported — active-active scalability |
| Autonomous DB | Not available | Not available | Native Autonomous Database support |
| High availability | Manual Data Guard or storage replication | Multi-AZ active/passive | Native RAC + automated Data Guard |
| Networking | Standard VPC; customer-configured | Standard VPC endpoint to RDS | VPC endpoints + Direct Connect/FastConnect fabric |
| Procurement | AWS compute billing + separate Oracle license | RDS hourly + Oracle license | AWS Marketplace · BYOL supported |
| Ideal workloads | Legacy apps needing OS-level DB access | Departmental apps, low-to-medium I/O | Mission-critical OLTP and large data warehouses |
11 · Common Misconceptions
"Database@AWS is just Oracle installed on EC2."
Reality: It runs on physical Exadata co-located inside the AWS footprint, managed via OCI automation — not standard AWS virtual compute.
"RDS for Oracle and Database@AWS are the same thing."
Reality: RDS lacks Exadata, RAC, and Autonomous Database. Database@AWS targets workloads that exceed RDS capabilities.
"OCI is no longer involved."
Reality: The OCI control plane provisions, patches, scales, and diagnoses databases — integrated into the AWS console experience.
"Public internet carries database traffic."
Reality: All traffic crosses the private Direct Connect/FastConnect bridge via VPC endpoints — never the public internet.
"AWS manages the Oracle database."
Reality: AWS handles data center space and application layers. Oracle owns the database engine and platform patching exclusively.
"Database@AWS replaces Aurora and DynamoDB."
Reality: It complements native AWS databases for enterprises with deep Oracle software investments — it sits alongside, not instead of, Aurora and DynamoDB.
12 · Enterprise Best Practices
- Keep applications close to the database — deploy EC2/EKS in the AZs matching co-located Exadata hardware.
- Design integrated networking early — plan CIDR blocks across AWS and OCI before provisioning to prevent IP overlaps.
- Use Direct Connect and FastConnect — establish dedicated VIF configurations; bypass public or intermediate transport.
- Configure VPC endpoints correctly — interface endpoints for database traffic; private Route 53 hosted zones for TNS resolution.
- Plan IAM federation early — SSO across AWS IAM and OCI IAM with linked audit logs from day one.
- Secure database connectivity — enforce TLS; centralize credentials in Secrets Manager or OCI Vault.
- Review Oracle licensing — leverage BYOL across the integrated architecture with your license management team.
- Design for disaster recovery — combine cross-AZ RAC with cross-region Data Guard replication.
- Monitor cross-cloud latency — automated synthetic tests between application subnets and OCI database endpoints.
- Follow co-authored reference architectures — validate against updated Oracle and AWS playbooks.
13 · Readiness Checklist
Evaluate your organization's preparation before adopting Oracle Database@AWS:
- AWS footprint: Are core enterprise applications already running on or migrating to AWS?
- Exadata / RAC requirements: Do workloads require Exadata capabilities or active-active RAC?
- Network architecture: Have architects mapped Direct Connect, FastConnect, and VPC endpoint integration paths?
- Identity federation: Is your enterprise IdP prepared to federate with both AWS IAM and OCI IAM?
- Security & compliance: Have you audited encryption key governance, TDE policies, and regulatory rules?
- Licensing: Are Oracle licenses reviewed and mapped for BYOL migration?
- Disaster recovery: Is cross-region DR documented with target RTO and RPO metrics?
- Performance baseline: Have you established a baseline of current on-premises database workloads for comparison?
- Procurement path: Is AWS Marketplace procurement approved for database services spend?
14 · Frequently Asked Questions
1. Does Oracle Database@AWS use the public internet to route application traffic?
No. All database connection traffic routes over a dedicated private connection bridging AWS Direct Connect and OCI FastConnect, with VPC endpoints keeping traffic inside your virtual network.
2. Can I run Oracle Real Application Clusters (RAC) using Oracle Database@AWS?
Yes. The Exadata Database Service tier fully supports active-active Oracle RAC configurations natively on co-located Exadata hardware.
3. How is database patching managed?
Patching is managed automatically via the OCI control plane. Autonomous Database handles it without intervention; Exadata Database Service uses scheduled rolling updates with minimal downtime.
4. Where do database backups live?
Backups can be stored in OCI object storage or transferred directly into Amazon S3 buckets, depending on compliance and retention requirements.
5. Can I use my existing Oracle licenses?
Yes. The service fully supports Oracle's Bring Your Own License (BYOL) model.
6. What network latency can we expect?
Because Exadata is co-located within the same facility footprint, applications typically experience sub-millisecond round-trip times.
7. Is Oracle Autonomous Database supported?
Yes — fully automated self-driving, self-securing, and self-repairing operations on co-located Exadata.
8. How do I monitor database metrics alongside AWS application metrics?
Monitor through the OCI console, or stream telemetry into Amazon CloudWatch and central SIEM systems via OCI logging integrations.
9. Does this service replace Amazon RDS for Oracle?
No. It is an alternative for mission-critical systems that exceed RDS performance, scaling, or structural capabilities — especially those requiring RAC or Exadata.
10. Can I purchase through the AWS Marketplace?
Yes. Oracle Database@AWS is available on the AWS Marketplace, allowing procurement through existing AWS channels and EDP commitment application.
11. How is support handled if an issue arises?
Oracle and AWS operate a co-designed collaborative support model. Open a ticket with either provider and engineering teams collaborate to resolve the issue.
15 · Key Takeaways
- Multi-cloud alignmentOracle Database@AWS lets AWS applications use Oracle-managed database services without forcing application migration to OCI.
- Functional separationEnterprise applications run inside AWS; Oracle databases are delivered through co-located OCI Exadata infrastructure.
- Exadata corePhysical Exadata powers Database@AWS — enterprise-grade performance, Smart Scan, and native RAC support.
- Autonomous integrationOracle Autonomous Database integrates into AWS-centric architectures for fully automated database operations.
- Private connectivityDirect Connect, FastConnect, and AWS VPC endpoints provide secure, sub-millisecond communication — no public internet transit.
- Federated securityAWS IAM and OCI IAM work together through identity federation, simplifying enterprise authentication.
- Coordinated operationsOracle manages the database platform; AWS manages the application platform — a unified multi-cloud experience.
- Investment protectionContinue investing in AWS while leveraging Oracle's optimized database infrastructure, BYOL licensing, and AWS Marketplace procurement.
Oracle Database@AWS isn't about replacing AWS — it's about extending AWS with Oracle's best database technologies. By combining AWS application services with co-located Exadata and OCI-managed databases, enterprises gain multi-cloud flexibility without sacrificing performance, security, or operational simplicity.