While studying for the OCI 2025 Network Professional exam, I ran into something that is easy to miss at first: OCI Realms. They define boundaries between regions, and they matter a lot, especially when working with OCI Dedicated Regions. One of the most asked questions during technical workshops for OCI Dedicated Region is “Can I only run a single OCI Dedicated Region deployment in my data center and use the public (commercial) OCI region as a secondary site?“.
To answer this question, we have to understand the basic concept of realms first.
What are realms?
Oracle Cloud Infrastructure (OCI) regions are organized into separate cloud realms for customers with differing security and compliance needs. Realms are isolated from each other and share no physical infrastructure, resources, data, accounts, or network connections. OCI has multiple realms, including commercial, government, and dedicated realms. You can’t access regions that aren’t in your realm.
Customer tenancies exist in a single realm and can access only regions that belong to that realm.
Example: The regions Paris, Frankfurt, Madrid, Stockholm, and Zurich all have the same realm key “OC1” and therefore belong to the same realm. The Serbian region has the realm key “OC20 and belongs to a different realm.
Dedicated Regions are public regions assigned to a single organization. Region-specific details, such as region ID and region key are not available in public documentation. You need to ask your Oracle representative for this information for your OCI Dedicated Region.
Note: Please be aware that I took this screenshot from the OCI 2025 Network Professional course’s student guide. Follow this link to get an actual view of the currently available cloud regions.
Yes, this also means that the EU Sovereign Cloud realm is completely isolated from the commercial public cloud realm.
So, we have learned that by default, all commercial OCI regions live in the same realm. That means they can talk to each other using native OCI services like VCN peering, object storage replication, IAM policies, etc.
What else should you know?
Let us come back to our question “Can I only run a single OCI Dedicated Region deployment in my data center and use the public (commercial) OCI region as a secondary site?”.
First of all, we have to ask ourselves: Why do we want to connect a Dedicated (private) Region to a public commercial region? Just because of money?
Most customers have anyways already have two data center locations. What is stopping you from deploying two OCI Dedicated Regions?
Second, what is the impact if I host my primary site locally in an OCI Dedicated Region and, for disaster recovery purposes, use a commercial region?
Connect an OCI Dedicated Region to another commercial region
Oracle does not provide the tools to connect regions across a realm boundary via their network backbone. But in such cases, it is still possible to leverage OCI FastConnect. From my understanding, we would need to provision/have Virtual Cloud Networks (VCNs) with non-overlapping CIDR blocks. We would then make use of Dynamic Routing Gateways (DRGs), one in your local Dedicated Region and one DRG in Zurich, to allow traffic between both VCNs.
The DRG is a virtual router that provides a path for private network traffic between VCNs in the same region, between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.
Disaster recovery across realms: Not recommended
Oracle recommends configuring disaster recovery (DR) within the same realm due to the isolation between realms.
Some OCI services might support manual DR between realms, others require custom scripts or tools (like rsync, Data Pump, or GoldenGate), and some services (like Autonomous DB or native Object Storage replication) just won’t work across realms. No replication. No failover.
Oracle’s best practices are clear: If you need disaster recovery, keep both OCI (Dedicated) Regions in the same realm.
When you cross realms, you are building everything manually: replication, IAM, automation, failover
The result? You are unsupported by some OCI services (make sure you validate your architecture, requirements, and configuration). And nobody wants a manual, high-risk, and unsupported path. Right? 🙂
