ODB Network CIDR Collision in AWS

The draft 10.20.0.0/16 cannot be kept because it overlaps the prod VPC. VPC peering and ODB peering require non-overlapping address space; NAT does not solve overlapping private IPs for database clients that must preserve source addresses and return paths. Re-IP of prod or on-premises is out of scope, so change the ODB network.

Use 172.30.0.0/16 for the ODB network after confirming it does not conflict with any existing 172.16/12 routes. If it does, use 100.64.0.0/16 as a private CGNAT range, provided no ISP or remote-access pool uses it.

Topology:

• Create an ODB peering from the ODB network to the prod VPC. ODB peering is local and keeps prod application-to-database traffic on the AWS regional network, which supports the <2 ms p95 target.
• Create a second ODB peering to the shared-services VPC for DBA tooling and monitoring.
• Do not attempt to attach Transit Gateway directly to the ODB network. TGW attaches to VPCs. For on-premises access, route 172.30.0.0/16 from TGW to the shared-services VPC, then route from that VPC to the ODB peering. ODB peering is not transitive by itself, so the shared-services VPC must explicitly forward and have security-group rules that permit the flow.
• Keep nonprod on a separate ODB network or separate peering with deny-by-default security groups; do not route nonprod through prod.

Segment by ODB network, not just by subnet. If nonprod and prod share one ODB network, a single misconfigured security group or route table can expose prod. Give nonprod its own ODB network and its own ODB peering to the nonprod VPC.

DBAs: Put DBA tooling in the shared-services VPC and grant access through separate security groups and IAM roles per environment. The toolchain can be identical - same SQL client, same monitoring agent, same DNS suffix - while the network paths and credentials differ. Use AWS IAM Identity Center permission sets for console access and a secrets manager for database credentials, not shared bastion accounts.

Naming: Use scan.prod.oradb.local and scan.nonprod.oradb.local in separate Route 53 private hosted zones. This prevents a nonprod application from resolving a prod SCAN name by accident.

Guardrails: Deny-by-default security groups, no route from nonprod to the prod ODB peering, VPC flow logs on both sides, and an AWS Config rule that alerts if a nonprod route table gains a route to the prod ODB CIDR.

DNS: Create a Route 53 private hosted zone for oradb.local, associated with the prod and shared-services VPCs. The ODB network provides private DNS resolver addresses; create a Route 53 Resolver outbound endpoint in the shared-services VPC and a conditional forwarder for oradb.local to those resolver IPs. For on-premises DBAs, create an inbound endpoint so queries for the SCAN name resolve consistently. Do not use public DNS records for database endpoints.

Traffic controls:

• ODB network security groups allow only the application subnet CIDRs on the database listener ports, and only DBA/tooling CIDRs for management ports.
• No internet gateway route in the VPCs that host ODB peering; use VPC endpoints for S3, CloudWatch, and Secrets Manager.
• Network ACLs as a second layer, with explicit deny for the nonprod range.
• VPC flow logs and ODB flow logs sent to a central logging account; alert on any flow from an unexpected source or to a public IP.
• Use AWS Network Firewall only if inspection is required; otherwise the native security groups and route isolation satisfy the no-third-party-appliance constraint.