Oracle Database@AWS network connectivity using Amazon VPC Lattice

As Oracle Database (ODB)@AWS becomes generally available, we’re introducing new network connectivity capabilities that streamline connectivity between Oracle Exadata infrastructure (managed by OCI) inside Amazon Web Services (AWS) data centers and users’ AWS and on-premises networks. These new features include Amazon VPC Lattice integrations for hybrid connectivity from ODB networks, and native secure access between zero-ETL, Amazon S3, and ODB networks.

In this post, we explore how the networking works for these features, with a focus on the VPC Lattice-powered capabilities that allow you to connect ODB networks to a variety of services.

These capabilities offer a more automated and streamlined integration experience, while also enabling secure access to user-managed resources—even in environments with overlapping IP address spaces. This helps reduce setup complexity and broadens the types of applications that can securely interact with Oracle Database@AWS.

Understanding the basics

If you’re new to ODB@AWS, you can find comprehensive information in the AWS documentation. Before diving into the new features, we can review the existing ways to connect your ODB network to Amazon Virtual Private Clouds (Amazon VPCs) without using VPC Lattice:

• ODB Peering: A direct, low-latency option for connecting one ODB to one VPC.
• AWS Transit Gateway: Enables streamlined connectivity at scale with multiple VPCs.
• AWS Cloud WAN: Provides scaled connectivity options with multiple VPCs.

Our new capabilities rely on VPC Lattice, thus you must understand its core components:

• Service network: A logical boundary for grouping resources
• Service network endpoint: Enables private and secure access to the service network
• Resource gateway: Allows the service network to reach provider-exposed resources
• Resource: Any TCP application made reachable through resource gateway

Architecture overview

When you create a new ODB@AWS deployment with a private network, AWS automatically provisions a default VPC Lattice service network in your account. Although this network is created for you, it behaves just like any standard VPC Lattice service network. You can add your own applications to it as resources or services, associate it with VPCs or endpoints, and enable access logs to gain visibility into application traffic.

The ODB service network comes pre-configured with a default service network endpoint (for outbound access from the ODB private network) and resource gateway (for inbound access to ODB private network resources). This VPC Lattice deployment works seamlessly alongside traditional connectivity options such as ODB peering, AWS Transit Gateway, or AWS Cloud WAN.

The following diagram shows all the available traffic flows between ODB private network and other AWS services and user managed resources.

Figure 1. Hight level architecture overview

Traffic flows between the ODB private network and other AWS services, and user-managed resources occur in the following ways:

1. Routed traffic between ODB private network and user-managed VPCs using traditional connectivity such as ODB peering, Transit Gateway, or AWS Cloud WAN.
2. Transport-layer traffic from the ODB private network to Amazon S3 or user-managed VPC Lattice resources.
3. Transport-layer traffic from user VPCs (or on-premises networks) to Oracle hosted virtual machines (VMs).
4. Transport-layer traffic from Amazon Zero-ETL to ODB private network (simplified).

Configuring managed service integrations

You can easily set up managed integrations for Amazon S3 and Zero-ETL with your ODB@AWS network. Simply select the appropriate checkboxes in the console during the ODB@AWS network creation process, as shown in Figure 2.

Figure 2. Enabling managed service integrations on ODB network

If you want to use the default ODB service network to connect to:

• Customer-managed applications
• Individual Oracle VMs

You must configure additional Amazon VPC Lattice settings, which we’ll explain in detail in the following sections.

Note: We won’t cover ODB Peering in this post since AWS documentation and other blog posts already address it thoroughly.

Connectivity from ODB network to Amazon S3

Access to Amazon S3 from your ODB private network supports two main use cases: access to Oracle-managed S3 buckets for automated backups, and access to your own user-managed S3 buckets.

To enable access to your own S3 buckets, define authorization policies that control permissions based on bucket names, AWS accounts, or AWS Organizations. These policies use standard Amazon S3 endpoint policy syntax.

The ODB private network connects to Amazon S3 through an automatically created service network endpoint. The Oracle-managed backup access to Amazon S3 works out of the box with no added configuration necessary.

The following diagram shows the Amazon S3 access example flows.

Figure 3. ODB network access to Amazon S3

1. To communicate with any S3 buckets the ODB private network sends traffic to the Service Network Endpoint that front ends the default ODB Lattice Service Network.
2. If traffic is destined to Oracle managed S3 buckets, then that communication is managed and controlled by Oracle.
3. For traffic to user owned buckets, you can apply an auth policy to limit the destination buckets that can be accessed (for example, allow access to buckets only in your specific AWS account).

Considerations:

• ODB network DNS automatically returns the service network endpoint IPs for regional Amazon S3 hostnames if you’re using the Oracle built-in Virtual Cloud Network (VCN) DNS resolver.
• Access to S3 buckets in different AWS Regions is currently not supported.
• The following conditions on your S3 bucket policies are not supported for traffic using this model: aws:SourceVpc, aws:SourceVpce, and aws:VpcSourceIp.

Zero-ETL connectivity to ODB network

Zero-ETL integration is a fully managed solution that makes transactional and operational data available in data warehouses such as Amazon Redshift from multiple operational and transactional sources. This solution allows you to configure an integration from your Oracle Database VMs to an Amazon Redshift data warehouse. This results in more accurate and timely insights for use cases such as business dashboards, optimized gaming experience, data quality monitoring, and user behavior analysis.

The Zero-ETL use case needs inbound connectivity from AWS managed services to the ODB network. The following diagram shows the flow of traffic for this use case.

Figure 4. Zero-ETL connectivity to the ODB network

The Zero-ETL use case is relying on a custom network implementation fully managed by AWS and not visible on the default ODB VPC Lattice service network.

Considerations:

• Zero-ETL connectivity is supported only in the same Region as the ODB network.
• Zero-ETL is an opt-in feature. Refer to the AWS documentation for implementation details as well as pricing. Other charges apply for initial seeding and resync of data and for change data capture.

ODB network access to customer managed resources

The default ODB Lattice service network extends beyond Amazon S3 connectivity to support custom resources in your network. Unlike ODB peering, Transit Gateway, or AWS Cloud WAN, this approach doesn’t need end-to-end routing reachability. VPC Lattice handles connections between networks with overlapping IP spaces or different address families (IPv4/IPv6).

The following diagrams shows the traffic flow.

Figure 5. Exposing custom resources through default ODB VPC Lattice service network

1. The ODB network connects to the resources or services exposed through the service network endpoint.
2. The VPC Lattice service network is using the resource gateway to reach user managed resources.
3. The VPC Lattice service network has direct reachability to VPC Lattice services with which it is associated.

Setting up VPC Lattice Services (HTTP, HTTPS, TLS Passthrough)

1. Create a VPC Lattice service for your application
2. Share your VPC Lattice service with the AWS account that owns the ODB service network (if using cross-account setup)
3. Associate the service with the ODB service network
4. Identify your service’s auto-generated hostname:
   • Navigate to the ODB network’s service network endpoint
   • Review the Associations section

Setting up VPC Lattice Resources (TCP)

1. Create a resource gateway in your VPC where your TCP application resides
2. Create a resource configuration. An example could be a publicly resolvable hostname of your application.
3. Share your resource configuration with the AWS account that owns the ODB service network (if using cross-account setup)
4. Associate the resource configuration with the ODB service network
5. Identify your resource’s auto-generated hostname:
   • Navigate to the ODB network’s service network endpoint
   • Review the Associations section

Considerations:

• To use custom hostnames to connect to your applications from Oracle VMs, you need to update the DNS in your OCI environment. Create a private hosted zone and associate it with your Oracle VCN, then create CNAME mapping from your custom hostname to the AWS-generated hostnames.
• The resource gateway must be deployed in the same Availability Zone (AZ) as the ODB network.

Customer network access to Oracle VMs

VPC Lattice enables direct connectivity from your VPC to individual VMs in the ODB network. To access these resources, you must establish either a VPC association or service network endpoint association with your service network.

Each VM in your ODB private network appears as a distinct hostname and IP address from your VPC’s perspective.

To find out the details of the IPs and hostnames assigned to your VMs, review the associations under the service network endpoint configuration.

Figure 6. Exposing Oracle VMs through the VPC Lattice service network

1. The client in your VPC connects to an IP address from the local VPC representing a VM in the ODB Network.
2. Traffic is source NATed on the resource gateway to an IP address from the ODB network range before being forwarded to the target VM.

Setting up Oracle VMs as VPC Lattice Resources (TCP)

1. Configure resources for your Oracle VMs:
   • Create a resource configuration for each VM
   • Specify the VM’s IP address as the target
   • Use the default resource gateway in the ODB network
2. Share the ODB service network with your client AWS account (if using cross-account setup)
3. In your client AWS account, establish connectivity by either:
   • Creating a service network endpoint association
   • Setting up a service network VPC association
4. Access your VM’s auto-generated hostnames by:
   • Navigate to your newly created service network endpoint
   • Review the Associations section

Considerations:

• Connecting to Oracle Single Client Access Name (SCAN) is not supported. You can only access individual VMs.
• IP address based resource configurations support only the following ranges: 10.0.0.0/8, 100.64.0.0/10, 172.16.0.0/12, 192.168.0.0/16. For IPv6, specify an IP from the VPC. Public IPs aren’t supported.
• To configure custom DNS names on the user VPC side, you must setup private hosted zones in your VPC. To get details on this process, follow the guidance in this Amazon networking post.
• The example diagram shows access using service network endpoint. VPC association is also supported.
• Make sure that your Oracle Network Security Groups allow inbound traffic from the IP range of the resource gateway.

Conclusion

Amazon VPC Lattice enables seamless connectivity between your ODB private network and Amazon S3, Zero-ETL, and user-managed resources. For detailed implementation steps, consult the AWS documentation.

About the authors