Oracle Database@AWS: Connecting AWS Applications with Exadata

On this page

1. 01 · The Network Is the Integration
2. 02 · Building Blocks: ODB Network and ODB Peering
3. 03 · A Reference Topology
4. 04 · Connection Paths in Practice
5. 05 · DNS and Name Resolution
6. 06 · Security Controls on Each Layer
7. 07 · Choosing a Connectivity Pattern
8. 08 · Beyond SQL*Net: AWS Service Integrations
9. 09 · Key Takeaways
10. 10 · Frequently Asked Questions

01 · The Network Is the Integration

Integration brief · AWS applications talking to Exadata

"The database is provisioned. Why can't the app connect?"

It is the most common first-week ticket on Oracle AI Database@AWS (launched as Oracle Database@AWS, GA July 2025). The Exadata VM cluster is up, the DBA can log in from the OCI console, and the application team's EC2 instances time out on port 1521. Nothing is broken. The database simply lives in an ODB network, a dedicated network that belongs to the Database@AWS service, and nothing reaches it until you connect a VPC, add routes, open security groups and make the host names resolvable.

That design is deliberate. It keeps the Exadata client and backup networks isolated, lets Oracle operate the infrastructure without touching your VPCs, and gives you explicit control over which applications can reach which database. The price is that connectivity becomes a design task. Done well, AWS applications get same-data-center latency to Exadata; done badly, they get timeouts, asymmetric routes and DNS failures.

02 · Building Blocks: ODB Network and ODB Peering

Answer: An ODB network is the private network the Oracle Database@AWS service creates for Exadata, with a client subnet for SQL*Net traffic and a backup subnet for backups. ODB peering is the connection that links an ODB network to a customer VPC so that routed traffic can flow between them.

When you create an ODB network in the AWS console, CLI or CloudFormation, you choose the Availability Zone and two CIDR ranges: one for the client subnet, where the VM cluster's client VNICs, virtual IPs and SCAN listeners live, and one for the backup subnet. The Exadata infrastructure and the VM cluster are then created into that ODB network. None of these addresses are inside your VPC, so you cannot simply attach an EC2 instance to them.

ODB peering behaves much like VPC peering from the application's point of view. You create the peering between the ODB network and a VPC, add a route for the client CIDR in the VPC route tables, and open the database ports in security groups. Traffic stays on the AWS network inside the region. As with VPC peering, plan as if peering is not transitive: a VPC peered to the ODB network does not automatically give other VPCs or on-premises networks a path.

03 · A Reference Topology

Answer: A typical design peers the main application VPC directly to the ODB network for the lowest latency, connects other VPCs and on-premises networks through a transit hub, resolves database host names through Route 53 Resolver, and sends backups and telemetry to Amazon S3 and CloudWatch.

The topology below brings the pieces together in one AWS region. App VPC A holds EC2 and EKS workloads and is peered straight to the ODB network. App VPC B, which runs Lambda functions and batch jobs, reaches the database through a transit hub, as does the corporate data center over AWS Direct Connect. Route 53 Resolver answers queries for the database domain. On the right, the database writes backups to Amazon S3, feeds Amazon Redshift through zero-ETL and publishes metrics and events to CloudWatch and EventBridge.

Follow the blue arrows: only the peered VPC has a direct hop to the ODB network, while everything else goes through the transit hub. The yellow tag on VPC A is the security group rule teams forget most often: outbound access to the client CIDR on 1521 and 2484.

Sizing the address plan

04 · Connection Paths in Practice

Answer: EC2 in a peered VPC needs a route and a security group rule. EKS pods need routable pod IPs and pod or node security groups. Lambda needs VPC attachment, a route and connection pooling. On-premises clients need Direct Connect or VPN into a transit hub that routes to the ODB network, plus DNS forwarding.

The four examples below cover most AWS workloads. Each lane shows the hops a connection takes from the caller to the SCAN listener, and the box on the right lists what has to be in place for that path to work. Use it as a checklist when an application team asks for access.

Notice that the last hop is identical in every lane: the SCAN listener on 1521 or 2484 in the client subnet. Everything that differs sits on the AWS side, which is why most connectivity issues are solved by the cloud team rather than the DBA team.

A connect string that survives failover

Use the SCAN name, not node IPs, and include retry settings so that a RAC node restart or Data Guard role change does not surface as an application error. Port 2484 with TCPS adds TLS on the wire.

ORDERS_TP =
  (DESCRIPTION =
    (CONNECT_TIMEOUT=5)(TRANSPORT_CONNECT_TIMEOUT=3)(RETRY_COUNT=3)(RETRY_DELAY=2)
    (ADDRESS = (PROTOCOL = TCPS)(HOST = <scan-host-name>)(PORT = 2484))
    (CONNECT_DATA = (SERVICE_NAME = orders_tp.<db-domain>)))

# Quick checks from an application host
nc -vz <scan-host-name> 1521
sqlplus app_user@ORDERS_TP

For Lambda, the main risk is connection storms: hundreds of concurrent invocations each opening a session. Keep a pool per execution environment, set a low maximum, and consider Database Resident Connection Pooling (DRCP) on the database side. The python-oracledb driver in thin mode needs no Oracle Client libraries, which keeps Lambda packages small.

05 · DNS and Name Resolution

Answer: Applications should connect by SCAN host name, so the VPCs and on-premises networks that reach the database must be able to resolve the ODB network's DNS domain. In AWS this is typically done with Route 53 Resolver rules or private hosted zone associations, and on premises with conditional forwarding to a Route 53 Resolver inbound endpoint.

The VM cluster registers its SCAN and VIP names in a private DNS domain that belongs to the ODB network. Peering gives you a network path but not necessarily name resolution. Check how your ODB network's DNS is exposed, then make sure every caller resolves it:

1. Find the names. Read the SCAN DNS name and domain from the VM cluster details in the AWS or OCI console.
2. Resolve from the peered VPC. From an EC2 instance, run dig <scan-host-name>. It should return the SCAN IPs in the client CIDR.
3. Extend to other VPCs. Share the resolution through Route 53 Resolver rules or private hosted zone associations, ideally centrally from a shared services account.
4. Extend to on premises. Create a Route 53 Resolver inbound endpoint and a conditional forwarder for the database domain on your corporate DNS servers.
5. Test from Kubernetes. EKS pods use CoreDNS, which forwards to the VPC resolver. Confirm resolution from inside a pod, not only from the node.

06 · Security Controls on Each Layer

Answer: Control access in layers: AWS IAM decides who can create and change Database@AWS resources, VPC route tables and security groups decide which workloads have a network path, the database's own network rules and listener decide what reaches the VM cluster, and database users, roles and TLS protect the session.

Because the ODB network is separate from your VPCs, you have two sides to secure. On the AWS side you use familiar tools. On the database side, the VM cluster's network access rules are managed through the service, and Oracle Database security works exactly as it does anywhere else.

07 · Choosing a Connectivity Pattern

Answer: Use direct ODB peering for one or a few application VPCs in the same region. Use a transit hub (AWS Transit Gateway or Cloud WAN, where supported) for many VPCs, multiple accounts and on-premises access. For other regions, prefer a local replica over long-haul SQL*Net, and for pure analytics prefer zero-ETL to Amazon Redshift.

The decision diagram puts the caller in the centre and shows the six situations that come up most often, each with the pattern that fits it. Start from where the caller runs and how many networks are involved, then follow the matching spoke.

The patterns are not exclusive. Many estates peer the main application VPC directly for the lowest latency and add a transit hub for everything else. The important rule is to avoid accidental paths: every route to the client CIDR should be one that someone designed and approved.

08 · Beyond SQL*Net: AWS Service Integrations

Connectivity is not only about applications sending SQL. Oracle and AWS name several native integrations for Oracle AI Database@AWS that reduce the custom plumbing you would otherwise build:

1. Zero-ETL to Amazon Redshift. Replicate operational data into Redshift for analytics without building and running your own pipelines.
2. Amazon S3 for backups. Send automatic database backups to S3 through the backup subnet.
3. Amazon CloudWatch and AWS CloudTrail. Metrics and logs for the database service in CloudWatch, and an audit trail of API calls in CloudTrail.
4. Amazon EventBridge. React to lifecycle events, such as maintenance or scaling, with rules and automation.
5. AWS CloudFormation and IAM. Define ODB networks, peering and clusters as code, and control who may change them.
6. Amazon VPC Lattice. Listed among the integrations for service-to-service connectivity; check the current documentation for supported directions and services in your region.

Oracle AI Database@AWS was listed in more than 20 AWS regions in 2026, and features arrive region by region. Confirm each integration in your region before you build on it.

On Database@AWS the database is never in your VPC. Design the path to it as carefully as the schema inside it.

09 · Key Takeaways

1. Exadata lives in an ODB network, not your VPC. Client and backup CIDRs in one Availability Zone, reached only through paths you build.
2. ODB peering is the low-latency default. Peer the main application VPC directly; treat peering as non-transitive.
3. Use a transit hub for scale. Transit Gateway or Cloud WAN, where supported, for many VPCs, accounts and Direct Connect from on premises.
4. Routes, security groups, DNS, connect string. Every path needs all four; DNS and missing egress rules cause most first-week failures.
5. Use the native integrations. Zero-ETL to Redshift, S3 backups, CloudWatch, EventBridge and CloudFormation reduce custom plumbing.

10 · Frequently Asked Questions