Advanced Connectivity Patterns for ODB@AWS

Introduction

In this blog, we examine the advanced network topologies supported by Oracle Database@AWS. We highlight the key design considerations, benefits, and trade-offs of each approach to help you select the topology that best aligns with your application and connectivity requirements. Detailed implementation procedures are outside the scope of this blog.

Agenda

This blog covers the following advanced connectivity patterns:

• Transit Gateway hub-and-spoke connectivity for multi-VPC to ODB@AWS access
• On-premises connectivity using Direct Connect and Transit Gateway
• Site-to-Site VPN with Transit Gateway
• Centralized inspection VPC for ODB@AWS traffic
• Cross-AZ disaster recovery over the OCI backbone
• Cross-Region disaster recovery over the OCI backbone
• Multi-Region connectivity using Transit Gateway peering
• AWS Cloud WAN for global enterprise connectivity

Transit Gateway hub-and-spoke for multi-VPC ODB@AWS access

This topology is the primary enterprise pattern for connecting multiple AWS application VPCs to ODB@AWS. An AWS Transit Gateway acts as the network hub between workload VPCs, shared services, hybrid connectivity, and the ODB peering path toward the ODB network.

AWS describes Transit Gateway as a network hub used to interconnect VPCs and on-premises networks. Transit Gateway supports VPC, Direct Connect gateway, VPN, peering, and network function attachments.

Figure: Transit Gateway hub-and-spoke connectivity for multi-VPC to ODB@AWS access.

Routing

1. Attach approved application VPCs to the Transit Gateway.
2. Associate application attachments with the application route table.
3. Statically configure the ODB@AWS reachable prefixes toward the required application and the Transit Gateway route tables.
4. Use a dedicated database access route table to control which attachments can reach the ODB peering path.
5. Keep production, non-production, shared services, and database access domains separated where required.

Use cases

1. Multi-account AWS environments where several application VPCs require ODB@AWS access.
2. Centralized routing designs owned by a shared network account.
3. Enterprise landing zones where database access must be explicitly governed.
4. Environments that need segmentation between production, non-production, shared services, and database access.

Advantages

1. Scales better than many point-to-point connections.
2. Centralizes route-table control for ODB@AWS access.
3. Supports integration with Direct Connect, VPN, inspection VPCs, and cross-Region designs.
4. Allows cleaner operational ownership between application, network, and database teams.

Trade-offs

1. Requires careful Transit Gateway route-table design.
2. Adds cost for Transit Gateway attachments and data processing.
3. Misconfigured route propagation can expose unintended connectivity.
4. Troubleshooting requires visibility across VPC route tables, Transit Gateway route tables, and ODB peering paths.

On-premises connectivity using Direct Connect and Transit Gateway

This topology supports hybrid ODB@AWS deployments where applications, administrators, monitoring platforms, or batch processes remain on-premises. AWS Direct Connect provides the private connectivity into AWS, while Transit Gateway distributes the traffic toward the ODB@AWS network path.

AWS Direct Connect links an internal network to an AWS Direct Connect location over standard Ethernet fiber and allows virtual interfaces to AWS services or Amazon VPC while bypassing internet service providers in the network path.

Figure: On-premises connectivity using Direct Connect and Transit Gateway.

Routing

1. Connect the on-premises network to AWS through Direct Connect.
2. Use Direct Connect Gateway and Transit Gateway when multiple VPCs or centralized routing are required.
3. Advertise approved on-premises prefixes into AWS using BGP.
4. Advertise only the required AWS and ODB@AWS reachable prefixes back to the on-premises network.
5. Optionally route hybrid traffic through centralized inspection before it reaches the ODB peering path.

Use cases

1. On-premises applications require private access to ODB@AWS.
2. Database administrators connect from corporate networks or jump-host environments.
3. Migration, batch processing, monitoring, or backup tooling remains on-premises.
4. A customer already uses Direct Connect as part of the AWS landing zone.

Advantages

1. Provides private and predictable hybrid connectivity.
2. Integrates with centralized AWS routing through Transit Gateway.
3. Supports route governance using BGP advertisements and allowed prefixes.
4. Can be combined with VPN for backup connectivity.

Trade-offs

1. Requires coordination between network, cloud, and data center teams.
2. Increases design complexity around BGP, prefixes, redundancy, MTU, and failover.
3. Direct Connect circuits, locations, and data transfer introduce additional cost.
4. DNS and firewall policy must be designed for both AWS and on-premises clients.

Site-to-Site VPN with Transit Gateway

This topology is used when Direct Connect is not yet available, when a temporary hybrid path is required, or when VPN is needed as a backup path. The Site-to-Site VPN terminates on Transit Gateway, and Transit Gateway routes approved traffic toward the ODB@AWS path.

AWS Site-to-Site VPN supports IPsec VPN connections between an on-premises network and AWS. Each VPN connection includes two VPN tunnels that can be used for high availability.

Figure: Site-to-Site VPN with Transit Gateway.

Routing

1. Create a Site-to-Site VPN connection from the customer gateway to Transit Gateway.
2. Enable both VPN tunnels and configure dynamic routing where possible.
3. Associate the VPN attachment with the correct Transit Gateway route table.
4. Propagate or statically configure on-premises prefixes into the required route tables.
5. Set route preference so VPN behaves as temporary, backup, or lower-throughput connectivity according to the design.

Use cases

1. Direct Connect is not yet provisioned but project work must start.
2. VPN is required as a backup path to Direct Connect.
3. Non-production environments need private hybrid access.
4. Lower-throughput administrative or migration activities require a temporary connection.

Advantages

1. Can be deployed faster than Direct Connect in many environments.
2. Provides encrypted IPsec connectivity.
3. Integrates with Transit Gateway hub-and-spoke routing.
4. Works well as a backup or bootstrap path.

Trade-offs

1. Less predictable than Direct Connect for latency-sensitive database traffic.
2. Throughput, MTU, and tunnel failover behavior must be validated.
3. Not ideal as the only production path for high-volume database workloads unless tested and approved.
4. Requires careful routing preference when used together with Direct Connect.

Centralized inspection VPC for ODB@AWS traffic

This topology forces selected application or on-premises traffic through a centralized inspection VPC before it reaches ODB@AWS. It is relevant for regulated environments and enterprises that require firewall enforcement between application, database, and hybrid network zones.

AWS Network Firewall is a managed, stateful network firewall and intrusion detection and prevention service for Amazon VPC. It can filter traffic entering or leaving a VPC, including traffic through VPN and Direct Connect paths.

Figure: Centralized inspection VPC for ODB@AWS traffic.

Routing

1. Attach application VPCs, hybrid connectivity, and the inspection VPC to Transit Gateway.
2. Use Transit Gateway route tables to direct database-bound traffic to the inspection VPC.
3. Forward inspected traffic from the inspection VPC back through Transit Gateway toward the ODB peering path.
4. Ensure return traffic follows the same inspection path to preserve stateful firewall symmetry.
5. Allow only approved source CIDRs, Oracle listener ports, and administrative paths.

Use cases

1. Security teams require inspection between application tiers and ODB@AWS.
2. On-premises traffic to ODB@AWS must pass through centralized firewall controls.
3. Database traffic must be logged or controlled centrally.
4. AWS Network Firewall or third-party firewalls are part of the landing zone standard.

Advantages

1. Centralizes security policy enforcement.
2. Supports consistent inspection for AWS-to-database and on-premises-to-database traffic.
3. Improves auditability of database network flows.
4. Aligns ODB@AWS connectivity with enterprise security controls.

Trade-offs

1. Requires symmetric routing for stateful inspection.
2. Adds routing and operational complexity.
3. This introduces additional latency and data processing cost.
4. Availability Zone alignment and return-path design must be carefully validated.

Cross-AZ disaster recovery over the OCI backbone

This topology covers cross-AZ disaster recovery for ODB@AWS when the primary and standby Oracle Exadata Database Service deployments are placed in different AWS Availability Zones in the same AWS Region, and Oracle Data Guard replication traffic is routed through the OCI network. Oracle documentation describes the Multi-AZ setup as a network configuration used to establish data replication by using either an OCI network or an AWS network across AWS availability zones. In the OCI network variant, primary-to-standby network traffic is directed through the OCI network, and the Oracle-side VCNs are automatically created after the Oracle AI Database@AWS primary and standby deployments are created. Source: Oracle HADR prerequisites for Oracle AI Database@AWS.

The reference architecture uses two ODB networks in different Availability Zones within the same AWS Region. The application or transit VPC is peered with both ODB networks through ODB peering. On the OCI side, the primary and standby Exadata VM Cluster VCNs are connected through local peering gateways, allowing Data Guard replication traffic to use the OCI backbone between zones while application traffic remains on the AWS-to-ODB peering path.

Figure: Cross-AZ disaster recovery over the OCI backbone.

Routing

1. Deploy the primary ODB@AWS database infrastructure in Availability Zone 1 and the standby ODB@AWS database infrastructure in Availability Zone 2 within the same AWS Region.
2. Use ODB peering so the application or transit VPC can reach both ODB Network 1 and ODB Network 2 where client access is required.
3. Use the OCI-created VCN 1 and VCN 2 that are associated with the primary and standby Exadata VM clusters.
4. Create a local peering gateway in the primary VCN and a local peering gateway in the standby VCN.
5. Establish local peering between the standby LPG and the primary LPG so the primary and standby client subnets can communicate through the OCI network.
6. Update the OCI network security groups for the primary and standby VM cluster networks to allow the required Oracle Data Guard and database listener traffic between the client subnet CIDRs.
7. Add route rules so the primary VCN routes the standby client subnet CIDR to the primary LPG, and the standby VCN routes the primary client subnet CIDR to the standby LPG.
8. After network connectivity is configured, proceed with Oracle Data Guard configuration and test connectivity in both directions.

Use cases

1. Same-Region disaster recovery for ODB@AWS deployments that require protection against Availability Zone failure.
2. Architectures where Data Guard replication traffic should use the OCI network path between primary and standby database environments.
3. Designs that keep application connectivity through ODB peering separate from database replication connectivity through OCI networking.
4. Enterprise HADR architectures where cross-AZ protection is required but cross-Region latency and complexity are not required.

Advantages

1. Aligns with the Oracle-published Multi-AZ HADR reference architecture for Oracle AI Database@AWS.
2. Keeps Data Guard replication traffic on the OCI network path between the primary and standby database environments.
3. Provides Availability Zone-level resilience while avoiding the additional latency and network complexity of cross-Region replication.
4. Separates AWS application access from Oracle database replication routing, which simplifies the connectivity model.

Trade-offs

1. Protects against Availability Zone-level failures, but it does not replace a cross-Region disaster recovery design for regional outage scenarios.
2. Requires careful route-table and network security group configuration in both the primary and standby OCI VCNs.
3. Requires non-overlapping client subnet CIDRs between the primary and standby environments.
4. Adds OCI networking components such as local peering gateways and route rules to the ODB@AWS design.
5. Requires application and operational runbooks to account for database role transitions and client failover behavior.

Cross-Region disaster recovery over the OCI backbone

This topology covers cross-Region disaster recovery for ODB@AWS when the primary and standby Oracle Exadata Database Service deployments are placed in different regions and Oracle Data Guard replication traffic is routed through the OCI network. Oracle documentation describes the cross-Region setup as a network configuration used to establish data replication by using either an OCI network or an AWS network across regions. In the OCI network variant, primary-to-standby traffic is directed through the OCI network, and the Oracle-side VCNs are created after the Oracle AI Database@AWS primary and standby deployments are created.

The reference architecture uses a primary ODB network in the primary AWS Region and a standby ODB network in the standby AWS Region. On the OCI side, the design introduces primary and standby hub VCNs, local peering gateways, dynamic routing gateways, and remote peering between the DRGs. This allows Data Guard replication traffic to use the OCI network path between regions while application VPCs continue to connect to the ODB networks through ODB peering.

Figure: Cross-Region disaster recovery over the OCI backbone.

Routing

1. Deploy the primary ODB@AWS database infrastructure in the primary AWS Region and the standby ODB@AWS database infrastructure in the standby AWS Region.
2. Use ODB peering so application VPCs can reach the ODB networks in the regions where client access is required.
3. On the OCI side, use the primary and standby VCNs associated with the Exadata VM clusters and create primary and standby hub VCNs for cross-Region transit.
4. Peer the primary VM cluster VCN with the primary hub VCN by using local peering gateways. Repeat the same pattern between the standby VM cluster VCN and the standby hub VCN.
5. Attach a DRG to each hub VCN and establish remote peering between the primary and standby DRGs so inter-Region database replication traffic can cross the OCI network.
6. Update route tables so the primary client subnet can reach the standby client subnet through the primary LPG, primary hub VCN, primary DRG, remote peering connection, standby DRG, standby hub VCN, and standby LPG path. Configure the reverse path symmetrically.
7. Update the network security groups for the primary and standby VM cluster networks to allow the required Oracle Data Guard and database listener traffic between the primary and standby client subnet CIDRs.

Use cases

1. Cross-Region disaster recovery for ODB@AWS deployments that use Oracle Data Guard.
2. Architectures where database replication traffic should use the Oracle-managed OCI network path instead of an AWS Transit Gateway inter-Region path.
3. Designs that separate application connectivity through ODB peering from database replication connectivity through OCI networking.
4. Enterprise HADR architectures that require a documented primary-region and standby-region network foundation before Data Guard configuration.

Advantages

1. Aligns with the Oracle-published cross-Region business continuity and HADR reference architecture for Oracle AI Database@AWS.
2. Keeps Data Guard replication traffic on the OCI network path between the primary and standby database environments.
3. Separates AWS application access from Oracle database replication routing, which makes the architecture easier to reason about.
4. Supports a clean regional DR model with explicit primary VCN, standby VCN, hub VCN, LPG, DRG, and remote peering components.

Trade-offs

1. Adds OCI networking components such as hub VCNs, local peering gateways, DRGs, and remote peering connections to the ODB@AWS design.
2. Requires careful route-table configuration in both primary and standby regions, including symmetric return routing.
3. Requires non-overlapping CIDR planning for primary, standby, and hub VCNs CIDR blocks.
4. Remote peering connection service limits and routing scale must be reviewed before implementation.
5. Requires coordination between AWS networking, OCI networking, and database teams during design and DR testing.

Multi-Region connectivity using Transit Gateway peering

This topology supports designs where applications, shared services, or disaster recovery components in one AWS Region need controlled access to ODB@AWS in another Region. Transit Gateway inter-Region peering connects regional Transit Gateways over AWS Global Infrastructure.

AWS documentation states that inter-Region peering connects Transit Gateways together using AWS Global Infrastructure, and that traffic between AWS data centers is automatically encrypted at the physical layer.

Figure: Multi-Region connectivity using Transit Gateway peering.

Routing

1. Create or use a Transit Gateway in each Region.
2. Attach regional application VPCs and ODB@AWS access paths to the appropriate regional Transit Gateway.
3. Create Transit Gateway inter-Region peering between the Regions.
4. Add the required static routes for the peering attachment and ODB@AWS reachable prefixes.
5. Define DNS behavior for regional access and failover scenarios.

Use cases

1. Applications in one Region need to access ODB@AWS in another Region.
2. Shared services or administration tools are centralized in a different Region.
3. Disaster recovery connectivity must exist before a failover event.
4. The customer is not using Cloud WAN but still needs cross-Region routing.

Advantages

1. Provides controlled cross-Region connectivity using Transit Gateway.
2. Fits existing regional hub-and-spoke designs.
3. Can support disaster recovery and shared-services access patterns.
4. Keeps route control at the Transit Gateway level.

Trade-offs

1. Cross-Region latency may affect database client behavior.
2. Cross-Region data transfer cost must be considered.
3. Transit Gateway peering requires explicit route configuration.
4. Security inspection and DNS failover can become more complex across Regions.

AWS Cloud WAN for global enterprise connectivity

This topology is suitable for large global organizations that need centralized policy-based routing and segmentation across AWS Regions, VPCs, and on-premises environments. ODB@AWS access can be placed into a controlled database access segment.

AWS Cloud WAN is a managed wide-area networking service used to build, manage, and monitor a unified global network across cloud and on-premises environments. Cloud WAN supports segments, which are dedicated routing domains with policy-controlled route sharing.

Figure: A

Routing

1. Define a Cloud WAN core network across the required AWS Regions.
2. Create segments for production, non-production, shared services, on-premises, and database access.
3. Attach approved VPCs, Transit Gateway route tables, or hybrid connections to the appropriate segments.
4. Use route-sharing policy to control which segments can reach the ODB@AWS database access segment.
5. Apply inspection requirements between segments where required by security policy.

Use cases

1. Global enterprises with multiple AWS Regions and business units.
2. Customers that require centrally governed routing policy.
3. Environments that need consistent segmentation between application, shared services, on-premises, and database access networks.
4. Organizations standardizing AWS network management through Cloud WAN.

Advantages

1. Provides centralized policy-based network management.
2. Supports global segmentation across Regions and environments.
3. Can reduce operational complexity compared with many regional bespoke Transit Gateway designs.
4. Helps standardize governance for database access attachments.

Trade-offs

1. Introduces a broader global network operating model.
2. Requires careful segment and route-sharing policy design.
3. May be more complex than needed for single-Region ODB@AWS environments.
4. Requires alignment between cloud networking, security, and application teams.

Conclusion

This blog reviewed several frequently used advanced connectivity patterns for ODB@AWS and outlined the routing approach, use cases, advantages, and trade-offs for each. These patterns include Transit Gateway hub-and-spoke, Direct Connect with Transit Gateway, Site-to-Site VPN with Transit Gateway, centralized inspection VPCs, Cross-AZ disaster recovery over the OCI backbone, Cross-Region disaster recovery over the OCI backbone, Transit Gateway inter-Region peering, and AWS Cloud WAN.

The main design principle is to keep the architecture layered. ODB peering provides the product-specific AWS-to-ODB connectivity foundation, OCI networking can provide the database replication path for Cross-AZ and Cross-Region Data Guard scenarios, Transit Gateway and Cloud WAN provide scalable routing, Direct Connect or VPN provides hybrid access, and inspection VPCs provide centralized security enforcement.

References

Oracle AI Database@AWS documentation

AWS Transit Gateway documentation

AWS Direct Connect documentation

AWS Site-to-Site VPN documentation

AWS Network Firewall documentation

Oracle AI Database@AWS HADR prerequisites documentation – Multi-AZ and Cross-Region

AWS Cloud WAN documentation