OCI Architecture Foundations: How Regions, Domains, and IAM Actually Fit Together

Source: Dev.to

🧠 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:

1. Physical resilience – where workloads run
2. 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 such as racks, power units, and cooling are isolated per FD
• OCI performs maintenance in only one FD at a time

If you place multiple instances in different Fault Domains:

• 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:

Rule of thumb

• FDs → hardware failure
• ADs → data‑center failure
• Regions → disaster recovery

OCI provides the tools; 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?

IAM has two responsibilities:

1. Authentication – who you are (proving identity)
2. 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

1. Create groups based on roles
2. Attach policies to groups
3. 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 API calls to trusted networks
• Enforce source‑IP‑based policies for IAM

Typical scenario: Limit sensitive operations to corporate networks.

They’re referenced directly in policies for fine‑grained control.

✅ 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.