Oracle Database at AWS networking just became much more flexible.
As of February 19, 2026, Oracle Database at AWS supports multiple ODB peering connections per ODB network. In practical terms, that means we have moved from a model where an ODB network could not support multiple direct peering connections, to one where a single ODB network can now be peered with multiple Amazon VPCs. The same update also enables one VPC to connect to multiple ODB networks. For customers building Oracle Database at AWS environments in a real AWS landing zone, this is a meaningful architectural improvement. It simplifies how application VPCs reach Oracle databases running on Exadata infrastructure hosted in AWS data centers, while preserving private connectivity through ODB peering.
What Is an ODB Network?
An ODB network is the private isolated network that hosts OCI infrastructure inside an AWS Availability Zone for Oracle Database at AWS . It is a required foundation for Oracle Exadata infrastructure and VM clusters, and it is the network boundary through which applications in Amazon VPCs privately reach database resources by using ODB peering.
It is also important to remember that ODB peering is not the same as VPC peering. Oracle Database at AWS treats ODB peering as its own resource type, created between an ODB network and a customer-owned VPC. Since July 8, 2025, ODB peering connections have been managed as separate resources, which set the stage for more flexible topologies like the one introduced in 2026.
What Changed?
The key change is simple:
- Before: one ODB network could not have multiple direct ODB peering connections.
- Now: one ODB network can have multiple direct peering connections, supporting multiple VPCs to one ODB network, one VPC to multiple ODB networks, and broader combinations of both. Oracle and AWS documentation state that an ODB network now supports up to 45 peering connections.
This change removes a common pain-point for customers who split workloads across multiple VPCs for production, non-production, shared services, analytics, or organizational separation. Instead of forcing network designs through an extra routing layer, we can now connect multiple application VPCs directly to the same ODB network when that is the simplest fit.
Before vs After
Before
The direct peering model was effectively: one application VPC connected directly to one ODB network.
After
Now the same ODB network can support multiple direct VPC peers, which better matches common AWS network segmentation patterns.
Why This Matters?
The first benefit is simpler architecture. If several application environments need access to the same Oracle databases, they can now each peer directly to the ODB network instead of relying on a single shared VPC as the only direct attachment point.
The second benefit is better alignment with AWS landing zones. Many organizations separate workloads across multiple VPCs by environment, business unit, or security domain. Multi-VPC ODB peering allows the database side to remain centralized while application connectivity scales out cleanly.
The third benefit is more incremental onboarding. Because each ODB peering connection is its own resource with its own lifecycle, teams can add VPCs over time instead of treating initial peering as a one-time all-or-nothing network decision.
What Architects Should Pay Attention To?
1. CIDR planning remains critical.
CIDR ranges must not overlap between the ODB network and peered VPCs, and Oracle Database at AWS also notes that supernet CIDR blocks spanning multiple existing subnets are not supported in these peered configurations.
2. Routing is still a shared responsibility.
On the Oracle Database at AWS side, route handling for the ODB network is managed as part of the peering model, but on the AWS side you still need to update VPC route tables and configure DNS resolution, so traffic reaches the ODB network correctly.
Before, adding the new peered CIDR was done from the ODB network, now, this is done from the ODB peering side.
3. There are practical limits.
An ODB network supports up to 45 peering connections, and each VPC can connect to multiple ODB networks, but only one peering connection to each specific ODB network.
4. Older ODB networks may need attention.
AWS documentation notes that ODB networks in US East (N. Virginia) and US West (Oregon) created before February 7, 2026 require a network upgrade, which in practice means fully recreating the ODB network, before adding more than one ODB peering connection.
Where Transit Gateway Still Fits?
This update does not make AWS Transit Gateway or AWS Cloud WAN obsolete.
Those patterns still make sense when you want centralized routing, broader hub-and-spoke connectivity, or extension to on-premises environments. AWS documentation explicitly keeps both options in the recommended topology: you can either peer multiple VPCs directly to the ODB network, or peer one VPC to the ODB network and use Transit Gateway or Cloud WAN to distribute access more broadly.
A simple way to think about it is:
- Use direct multi-VPC ODB peering when you want the cleanest and most direct connectivity pattern.
- Use Transit Gateway or Cloud WAN when you need centralized routing and broader network transit.
Practical Checklist
- Confirm the target ODB network does not already hit routing, NSG, or peering-count limits.
- Verify that all VPC CIDR ranges are non-overlapping with the ODB network and with each other where routing policy requires it.
- Update AWS route tables and DNS settings for every participating VPC.
- Check whether the ODB network was created before February 7, 2026 in regions that require recreation before scaling beyond one peering.
- Decide early whether direct multi-VPC peering or a Transit Gateway pattern gives the better long-term operational model.
Final Thoughts
Moving to one ODB network peered with multiple VPCs makes Oracle Database at AWS much easier to fit into modern AWS environments. It reduces architectural complexity, improves flexibility, and lets network designs better reflect the way enterprises actually organize applications on AWS today.