When customers start planning cross-region disaster recovery for Exadata Database on Oracle Database@Multicloud, the conversation usually begins with the database layer. Data Guard, protection mode, switchover, failover, and recovery objectives tend to dominate the early design sessions.
During the Data Guard configuration, connectivity between the active database and the standby database needs to be in place.
The architecture is straightforward once you see it on paper, but building it consistently across two regions takes attention to detail. The hub VCNs, LPGs, DRGs, remote peering connections, route tables, and NSGs all have to line up. One missing route or one incomplete peering step is enough to turn a clean DR design into a long troubleshooting session.
There are three practical ways to implement this part of the solution.
- Build it in the OCI Web UI
- Build it with Terraform
- Build it with an OCI Cloud Shell script
Build it in the OCI Web UI
The OCI console is the most direct way to understand the design because you create every object yourself. If the goal is to learn the topology, this is still the best place to start. You can follow the Oracle reference implementation step by step, region by region, and see exactly how the hub VCN, LPGs, DRG attachments, and route tables fit together.
The drawback is not complexity. It is repetition.
This is manageable for a lab. It becomes much less comfortable when you need repeatability, auditability, or a clean rollback path.
The step by step UI implementation is covered in this Reference Architecture.
Build it with Terraform
Terraform is the right fit when you want the networking design captured as infrastructure as code. It is easier to review, easier to version, and easier to promote across environments. If your team already operates with Terraform, this option usually makes the most sense in the long run.
It also fits well when OCI networking is part of a broader landing zone or platform engineering model.
The tradeoff is that it introduces a fuller IaC workflow. That is a strength for some teams, but it can feel heavier than needed for teams that want to stay close to OCI Cloud Shell and move quickly.
The terraform scripts can be found in the official github of the Multicloud Product Management.
Build it with an OCI Cloud Shell script
Terraform is the desired infrastructure as a code solution but for some projects this can be overcomplicated to follow the CI/CD process and customer need a more simpler solution that uses cloud native tooling to implement the infrastructure.
In this github there is a script bundle that focuses on the implementation of the cross region DR for an Exadata in an Oracle Database@Multicloud.
The bundle focuses only on the OCI networking tasks from the cross-region DR architecture. It uses OCI CLI, Bash, and standard Python already available in OCI Cloud Shell. It keeps all files in a single folder, reads one config file, writes one log file, and produces a timestamped state file for rollback.
In practical terms, the setup script validates the inputs, confirms the Exadata VCNs exist in the expected compartments, discovers the client and backup subnets by CIDR, creates the hub VCNs, creates and peers LPGs, creates and peers the DRGs and RPCs, updates the route tables, and creates NSGs for cross-region Oracle Net access. The rollback script removes only the artifacts created by setup and is designed to behave safely even after partial failures.
That makes it a good middle path:
- lighter than a full Terraform workflow
- more repeatable than manual console work
- close enough to the reference architecture that troubleshooting remains intuitive
The value of the bundle is not that it can create a DRG or an LPG. The OCI console can already do that.
The real value is in the guardrails:
- validation before creation starts
- clear failure behavior when a configured subnet is missing or ambiguous
- deterministic naming
- explicit peering verification
- route programming across the Exadata VCN, hub VCN, and DRG layers
- incremental state capture for rollback
- cleanup that removes only what the setup created
That is the kind of operational discipline that matters in DR work.
Which option should you choose?
If you are learning the pattern, start with the Web UI.
If you are building a repeatable platform, Terraform is the better long-term home.
If you want a practical OCI-native automation path that is easy to run from Cloud Shell and keeps the scope tightly focused on networking, the script bundle is a very good fit.
Final thought
Cross-region DR is never just about failover mechanics. It is about whether the entire path is ready before you need it.
That is why this networking layer deserves more attention than it sometimes gets. Once the OCI connectivity is built correctly and verified, the database side of the DR design has a much stronger foundation. And that is exactly where a focused Cloud Shell automation bundle can make a real difference.