ODB Network Design

The minimum CIDR size for the client subnet is /27, and the maximum size is /16. The following table shows IP addresses consumed by the Oracle AI Database@AWS service and the infrastructure components for the client subnet CIDR:

The minimum CIDR size for the backup subnet is /28, and the maximum size is /16. The following table shows IP addresses consumed by the Oracle AI Database@AWS service and the infrastructure components for the backup subnet CIDR:

The following table explains how IP addresses are consumed in the ODB network for various VM clusters configurations.

The following table shows how many instances of each configuration are possible with a particular client subnet CIDR range. This table doesn't show all possible scenarios.

The following table shows how many instances of each configuration are possible with a particular backup subnet CIDR range. This table doesn't show all possible scenarios.

• An ODB network supports up to 45 ODB peering connections.
• An AWS placement group is created after setting up an ODB network. To learn how to place an Amazon EC2 instance into the created placement group, see AWS documentation for High Performance Networking.
• If the ODB network is in US East (N. Virginia) or US West (Oregon), and the network was created before February 7, 2026, then you must upgrade the network before adding ODB peering. Upgrade requires you to fully recreate your ODB network. Deletion of more than 1 ODB peering. To upgrade, you need to fully recreate your ODB network. Deletion of an ODB network requires you to delete all Exadata VMs but doesn't require you to delete or recreate your Exadata Infrastructure.

The following restrictions apply for the CIDR range of the ODB network subnets:

1. Valid private IPv4 CIDR ranges required: The CIDR block must be private and IPv4. For example, 10.0.0.0/16, 172.16.0.0/16, 192.168.1.0/26.

2. Restricted CIDR blocks

   The following IP addresses can't be used for an ODB network:

   1. 100.64.0.0/10 - Reserved for the cluster interconnect by OCI automation
   2. 169.254.0.0/16 - Oracle Cloud reserved range CIDR
   3. 224.0.0.0 - 239.255.255.255 - Reserved Class D
   4. 240.0.0.0 - 255.255.255.255 - Reserved Class E

3. Restricted associations: You can't use the VPC CIDR ranges in the Restricted associations column in the table in IPv4 CIDR block association restrictions.
4. You can't overlap the IP address CIDR ranges of the client subnets and backup subnets.
5. You can't overlap the IP address CIDR ranges of the client and backup subnets with the VPC CIDR ranges used to connect to the ODB network.
6. You can't overlap the IP address CIDR ranges of the client and backup subnets with any of the existing VPC CIDR ranges in a region for the "buyer" or "owner" AWS Account. See AWS Account for details on these account types.
7. You can't overlap the IP address CIDR ranges allocated for the Client subnets and Backup subnets with on-premises or other networks required to connect to the ODB network through AWS Transit Gateway or AWS Cloud WAN.

Oracle AI Database@AWS uses Oracle-managed NSGs for system-level communication and default client connectivity in an ODB network. Review these behaviors before modifying NSG rules or attaching VM clusters.

Depending on the resource and network configuration, Oracle-managed NSGs can include the following NSGs:

• EXA_STATIC_NSG
• EXA_1521_ADJUSTABLE_NSG
• EXA_BACKUP_STATIC_NSG
• EXA_BACKUP_ADJUSTABLE_NSG
• ADB_STATIC_NSG
• ADB_1521_2484_ADJUSTABLE_NSG
• DNS_NSG
• ZRCV_NSG

• Oracle-managed NSGs: The service automatically creates and manages NSGs (Static, Adjustable, DNS and ZRCV) as part of ODB network configuration. These NSGs support required service functionality, including intra-cluster communication, SCAN listeners, ICMP traffic, and related service dependencies. Security rules are automatically populated based on peered CIDRs, and Oracle-managed NSGs are automatically attached to VM clusters.
• Automation and reconciliation: During ODB network modify and update operations, the system reconciles Oracle-managed NSGs to the expected baseline state. Manually added rules can be removed, modified rules can revert to their original state, and default rules that were removed can be re-applied. This behavior is expected and ensures consistency, stability, and supportability of the service.
• Customer access: By default, the adjustable NSG allows access from all peered CIDRs and environments to Oracle AI Database@AWS resources. Review this default access model against your security requirements before using it.
• Recommended approach: For customer-specific connectivity and stricter security requirements, use customer-managed (custom) NSGs. Create custom NSGs, define only the required ingress and egress rules, attach the custom NSGs to the VM clusters, and detach the default adjustable NSGs from the VM clusters. This approach provides full and persistent control over security rules while avoiding conflicts with automation reconciliation behavior.