When people first learn Oracle Cloud Infrastructure, they usually memorize terms: Regions, Availability Domains, Fault Domains, Identity Domains, Compartments, Policies.
That works for exams.
It doesn’t really help when you’re designing a real system.
This article connects the dots so OCI feels like architecture, not just terminology.
🧠 The Core Idea Behind OCI
OCI is built around one assumption:
Failure is normal. Design for it.
That idea shows up everywhere:
- How Oracle designs data centers
- In how workloads are deployed
- In how access is controlled
OCI’s foundation has two layers:
- Physical resilience: where workloads run
- Logical control: who can access what
Let’s walk through both.
🌍 Regions
A Region is a geographic location where OCI operates cloud infrastructure.
You choose regions based on:
- Latency (closer to users is better)
- Legal and data residency requirements
- Service availability
Regions are isolated from each other.
If an entire region goes down, others are unaffected.
This isolation is what makes disaster recovery possible.
🏢 Availability Domains (ADs)
Availability Domains are physically separate data centers inside a region.
Each AD:
- Has its own power, cooling, and hardware
- Does not share physical infrastructure with other ADs
- Is connected to other ADs via low-latency links
If one AD goes down, workloads in other ADs continue operating.
Not every region has multiple ADs, which directly impacts how you design for high availability.
🧩 Fault Domains (FDs)
Fault Domains exist inside an Availability Domain.
A Fault Domain is a logical grouping of hardware within an AD.
Key points:
- Each AD has three Fault Domains
- Hardware like racks, power units, and cooling are isolated
- OCI performs maintenance in only one FD at a time
If you place multiple instances in different FDs:
- A single hardware failure won’t take everything down
- Planned maintenance won’t affect all instances at once
FDs protect you from local hardware failures, ADs protect you from data center failures.
🛡️ Designing for High Availability
A simple, practical strategy:
- Within one AD Deploy the same workload across different Fault Domains
- Across ADs Replicate workloads to protect against full data center failure
- Across Regions Use region pairs for disaster recovery
Rule of thumb:
- FDs → hardware failure
- ADs → data center failure
- Regions → disaster recovery
OCI provides you with the tools, but you decide how resilient your system will be.
🔐 OCI Identity and Access Management (IAM)
Once workloads are running, the next question is obvious:
Who is allowed to touch this?
That’s where OCI Identity and Access Management (IAM) comes in.
IAM has two responsibilities:
- Authentication: who you are (proving identity)
- Authorization: what you’re allowed to do (enforcing permissions)
👤 Authentication (AuthN)
Authentication verifies who you are before granting access.
OCI supports:
- Username and password
- API keys
- OAuth 2.0 tokens
- Multi-Factor Authentication (MFA)
- Instance Principals (no stored credentials)
- Federation using SAML 2.0 with external identity providers
The goal is secure, verifiable access without exposing secrets.
🪪 Authorization (AuthZ): Policies Decide Access
OCI uses deny-by-default authorization.
Nothing is allowed unless a policy explicitly permits it.
The logic is always:
Who → can do what → on which resources → in which location
Policies are the enforcement layer that makes IAM predictable and auditable.
🧑🤝🧑 Identity Domains
An Identity Domain is a logical container for identities.
It holds:
- Users
- Groups
- Applications
- Federation settings
Think of identity domains the same way you think of compartments, but for people instead of resources.
High-level view:
OCI Tenancy
└─ Compartment
└─ Identity Domain
└─ Users / Groups / Applications
🧩 The Default Identity Domain
Every OCI tenancy comes with a Default Identity Domain.
Important facts:
- It cannot be deleted or disabled
- It’s replicated to all subscribed regions
- It always appears on the sign-in page
It includes:
- One user, the creator of the tenancy
- An Administrators group with full tenancy access
- An All Domain Users group
This domain is typically used for managing OCI infrastructure access.
🏗️ Why Create Additional Identity Domains?
Multiple identity domains are about isolation and control.
Common use cases:
- Separate Production and Development access
- Isolate partner access
- Manage consumer identities for public applications
Each domain can have:
- Its own admins
- Its own security policies
- Its own user population
This prevents one team’s mistakes from impacting another.
📦 Compartments
Compartments are logical containers for OCI resources.
They are:
- Global across regions
- Nestable up to six levels
- Used for isolation, billing, quotas, and access control
Policies are scoped to compartments, not directly to resources.
Best practice:
- Attach policies at the lowest level possible.
👥 Groups and Delegated Administration
Permissions are assigned to groups, not individual users.
Good practice:
- Create groups based on roles
- Attach policies to groups
- Add users to groups
OCI also supports delegated admin roles, such as:
- Security Administrator
- Application Administrator
- Help Desk Administrator
- Audit Administrator
This avoids giving everyone full admin access.
🌐 Network Sources
A Network Source defines allowed IP ranges or VCNs.
Used to:
- Restrict admin access to corporate networks
- Limit sensitive operations to trusted locations
They’re referenced directly in policies for fine-grained control.
They don’t grant access.
They limit access already granted by a policy.
✅ Final Takeaway
OCI isn’t complex by accident.
It’s structured because it’s designed for scale and failure.
- Regions, ADs, and FDs protect availability
- Compartments organize resources
- Identity Domains organize people
- Policies enforce least privilege
When you treat IAM and infrastructure as architecture decisions, OCI becomes predictable, scalable, and secure.
And that’s the point.
🔔 What’s Coming Next
This article focuses on OCI’s architectural and IAM foundations.
In the next part, we’ll go deeper into IAM policies: how authorization actually works, how policies are evaluated, and why most access issues in OCI come down to policy design.
Stay tuned.
Top comments (0)