Exposing Oracle Exadata hosted on ODB@AWS Using Amazon VPC Lattice

Overview

Joint AWS and Oracle customers often want to deploy Oracle Exadata on AWS while integrating it cleanly with existing application VPCs.

Today, when Exadata is deployed inside an Oracle Database@AWS (ODB) network, the applications typically connect to it using full end-to-end network connectivity, for example:

• ODB network peering
• AWS Transit Gateway
• AWS Cloud WAN

These approaches are fully supported and appropriate for many architectures - particularly where customers want explicit control over routing, segmentation, and traffic flow across their next gen firewall stacks.

However, some customers prefer a different operational model: one where Oracle Exadata appears to application teams as if it were hosted locally inside their VPC, without requiring those teams to reason about cross-network routing constructs.

This article explores how Amazon VPC Lattice can be used to support that model.

---

Prerequisites and Assumptions

This article assumes the reader already has a baseline understanding of Oracle Database@AWS and Amazon VPC Lattice. It focuses on connectivity architecture flow and high level implementation details, rather than initial service onboarding.

Required Knowledge

Before proceeding, you should be familiar with:

• Oracle Database@AWS (ODB) networking concepts, including:
  • ODB networks
  • Exadata SCAN listeners and database VM architecture
• Amazon VPC fundamentals, including:
  • VPC endpoints
  • Security Groups
  • Route 53 public and private hosted zones
• Amazon VPC Lattice, including:
  • Service networks
  • Resource configurations (FQDN-based vs IP-based)
  • Private DNS behavior

---

Environment Prerequisites

The following must already be in place:

• An Oracle Database@AWS ODB network has been provisioned
• Oracle Exadata VMs are running inside the ODB network
• You have sufficient permissions to:
  • Configure Amazon VPC Lattice, Route 53, and VPC endpoints in AWS
  • Modify Oracle Exadata listener configuration
• Client applications are deployed in an AWS VPC that will access Exadata through VPC Lattice

---

Architectural Distinction

The key difference between routed connectivity approaches and Amazon VPC Lattice is the level of abstraction they provide.

Routed Connectivity (ODB Peering, Transit Gateway, Cloud WAN)

• Provides full IP connectivity between networks
• Requires explicit routing configuration and awareness
• Well-suited for:
  • Network-centric architectures
  • Broad service-to-service communication
  • Centralized transit with next generation firewall inspection

Service-Level Connectivity (Amazon VPC Lattice)

• Exposes specific services or endpoints, rather than entire networks
• Abstracts underlying routing from application consumers
• Allows Exadata resources hosted in ODB@AWS to be presented into an application VPC as if they were local
• Preserves familiar patterns such as:
  • Private DNS
  • Security Group–based access control
  • Database access semantics similar to Amazon RDS

These approaches are complementary, not mutually exclusive. Each supports different architectural preferences and operational models.

---

Using Amazon VPC Lattice with Oracle Exadata

Amazon VPC Lattice provides managed, service-level connectivity that behaves similar to a transparent TCP proxy, allowing resources in different VPCs or environments to be exposed as endpoints inside a client VPC.

VPC Lattice already supports ODB networks and can be configured to forward TCP traffic (without TLS termination) between client VPCs and Exadata resources.

Note
As part of Oracle Database@AWS ODB network creation, some Amazon VPC Lattice components are provisioned automatically, including the Lattice service network associated with the ODB environment. This article focuses on how to extend and consume those components from an application VPC.

---

Oracle Client Connection Pattern

Oracle clients connecting to Exadata follow a two-step process:

1. Initial Connection: Client connects to the SCAN hostname, which load-balances across three SCAN listener VIPs
2. Redirection: The SCAN listener redirects the client to a specific database VM hostname where the actual database instance is running
3. Final Connection: Client establishes the working connection directly to the VM

This redirection pattern is why both SCAN and VM endpoints must be accessible through VPC Lattice.

---

Current Limitation

At the time of writing, Amazon VPC Lattice supports TCP (resource) connectivity only to targets that are reachable via:

• Publicly resolvable DNS hostnames, or
• A single IP address

Oracle Exadata relies on a SCAN hostname for initial client connections. This hostname:

• Is only privately resolvable inside the ODB network
• Resolves to multiple IP addresses
• Cannot be directly used as a Lattice target

---

Workaround Based on Exadata Behavior

A viable workaround exists today, based on two Exadata properties:

1. SCAN VIPs Are Static

When resolved privately inside the ODB network, the SCAN hostname consistently returns the same three IP addresses, even during failover scenarios.

2. Oracle SCAN Redirection to VMs Can be configured to use Hostnames instead of IPs

After connecting to a SCAN listener, Exadata redirects the client to a database VM hostname, not to a VM virtual IP (VIP).

These characteristics allow Exadata to be exposed safely through Amazon VPC Lattice.

---

Architecture and Traffic Flow Overview

SCAN Hostname Access Flow

1. The client resolves the SCAN hostname and a Lattice-managed private hosted zone returns the VPC endpoint IP
2. The client connects to the VPC endpoint
3. VPC endpoint transports traffic to the SCAN resource configuration associated with the service network.
4. Lattice resolves a public DNS name that maps to the SCAN VIPs
5. Traffic is forwarded to the resource gateway in the ODB network
6. The resource gateway source NATs to it's own IP address and forwards traffic to the SCAN VIP

The public DNS record is used only for Lattice IP discovery and is not used by clients directly.

---

VM Redirection Flow

All the steps below happen after the client receives a VM hostname from the SCAN redirect.

1. The client resolves the VM hostname and a Lattice-managed private hosted zone returns and IP address on the same VPC Endpoint.
2. The client connects to the VPC endpoint.
3. VPC endpoint transports traffic to the SCAN resource configuration associated with the service network. Because this is an IP-based resource no DNS resolution is needed.
4. Traffic is forwarded to the resource gateway in the ODB network
5. The resource gateway source NATs to it's own IP address and forwards traffic to the VM VIP

No DNS lookup is required for VM targets at this stage.

---

Implementation Steps

The following steps assume that:

• The ODB network is already provisioned
• Exadata VMs are already running

Where steps are well documented, links to official AWS documentation are provided.
Where configuration is nuanced or non-obvious, additional explanation and console screenshots are included.

---

1. Oracle Exadata VM Configuration

On each Exadata VM, update the local listener to advertise the VM hostname, not the VIP.

Example (update the HOST and SID fields to match your environment):

SHOW PARAMETER local_listener;

ALTER SYSTEM SET local_listener =
  '(ADDRESS=(PROTOCOL=TCP)(HOST=vm1.client.def.oraclevcn.com)(PORT=1521))'
  SCOPE=BOTH SID='DEV';

ALTER SYSTEM REGISTER;

Additionally, update the OCI Network Security Group (NSG) associated with the Exadata VMs to allow inbound traffic from the ODB resource gateway. The source IPs need to be the IP addresses used by Resource Gateway: 129.224.0.0/20 and 192.43.176.0/22. Even though these don't fall under RFC1918 they are treated as private IP space for the Lattice use case and are not opening up public access.

This is required so that traffic forwarded by Amazon VPC Lattice through the ODB resource gateway can reach the database VMs.

---

2) DNS Configuration for SCAN Discovery

Amazon VPC Lattice requires targets to be reachable via publicly resolvable DNS. Because the Exadata SCAN hostname is private to the ODB network, a separate public DNS record is required solely for Lattice IP discovery.

Steps:

1. Resolve the SCAN hostname inside the ODB network and record the IP addresses returned.
2. Create a public DNS record (must be a publicly registered domain you own) mapping a custom hostname to those SCAN IPs. Refer to Route 53 documentation for detailed steps.

Example:

• Domain: example.com
• Record: scan.example.com
• Values: <SCAN VIP 1>, <SCAN VIP 2>, <SCAN VIP 3>

Important characteristics of this DNS record:

• Publicly resolvable
• Used only by Amazon VPC Lattice
• Not referenced by clients
• Does not need to match the real SCAN hostname
• Not used for TLS termination

This hostname exists purely to allow Lattice to resolve the SCAN VIPs.

---

3) Amazon VPC Lattice Configuration

Some Amazon VPC Lattice components are provisioned automatically as part of ODB network creation, including the Lattice service network associated with the ODB environment as well as a Resource Gateway that can reach ODB network VMs. The steps below focus on configuring the additional resources required to expose Exadata into an application VPC.

First identify the IDs of resource gateway and service network associated with the ODB environment. You can see the details in the console or by running describe API calls on the ODB network.

---

3.1 Create Resource Configurations

Create the following Amazon VPC Lattice resource configurations:

• SCAN resource configuration
  • Type: FQDN-based
  • Hostname: the public DNS name created in Step 2 (for example, scan.example.com)
  • Custom domain name: use the real SCAN hostname (for example, abc-scan.client.def.oraclevcn.com)
  • 
• Database VM resource configurations
  • Type: IP-based
  • One resource configuration per Exadata VM
  • Target IP: the private IP of the VM inside the ODB network
  • Custom domain name: use the real hostname of the VM (for example, vm1.client.def.oraclevcn.com)
  • 

These resource configurations represent the Exadata entry points that will be exposed via Lattice. For detailed steps on how to create resource configuration refer to Lattice documentation.

---

3.2 Associate Resource Configurations with the Service Network

Associate all resource configurations created in the previous step with the Lattice service network attached to the ODB network:

• SCAN resource configuration
• All Exadata VM resource configurations

The service network ID can be obtained by describing the ODB network.

This association allows traffic entering through Lattice to be forwarded through the ODB resource gateway to the appropriate Exadata resources. For more information see the Manage associations for a VPC Lattice resource configuration

---

3.3 Create a VPC Endpoint in the Application VPC

In the client (application) VPC, create an Amazon VPC Lattice VPC endpoint that connects to the ODB service network.

When creating the endpoint:

• Select the ODB-associated service network
• Enable Private DNS for all domains

Enabling Private DNS ensures that:

• SCAN and VM hostnames resolve to the VPC endpoint IP
• Clients are unaware of the underlying ODB network topology

Warning
At least one Availability Zone where the VPC endpoint is deployed must match an Availability Zone of the ODB network. Ensure your endpoint subnet selection includes a subnet in a matching AZ, otherwise connectivity will fail.

For detailed steps on creating service network endpoints refer to AWS documentation.

---

Resulting Behavior

With this configuration in place:

• Oracle Exadata appears local to the application VPC
• Clients connect using standard SCAN semantics
• VM redirection functions normally using hostnames
• No explicit routed connectivity (peering, TGW, Cloud WAN) is required for application access
• Security controls remain aligned with existing AWS patterns

From the perspective of the application, the database behaves similarly to a service hosted natively inside the VPC.

---

Notes and Considerations

• For multi-account deployments use AWS Resource Access Manager to share Lattice Service Network or Resource Configurations
• This pattern relies on the assumption that SCAN VIPs remain static within the ODB network.
• This pattern assumes Exadata redirects clients to VM hostnames, not VIPs.
• The public SCAN DNS record must be maintained if SCAN IPs ever change.
• Routed connectivity options (ODB peering, Transit Gateway, Cloud WAN) remain valid and appropriate for architectures that require full network reachability.

---

Summary

Amazon VPC Lattice enables a service-level connectivity model that complements existing routed networking approaches for Oracle Database@AWS.

For customers who want to present Oracle Exadata resources hosted on ODB@AWS directly into their application VPCs as if they were local, VPC Lattice provides a clean and predictable solution using capabilities available today.