DEV Community: Lwandile Majola

Understanding IP Management in Oracle Cloud Infrastructure (OCI)

Lwandile Majola — Thu, 26 Feb 2026 00:01:10 +0000

Navigating the complexities of cloud networking is crucial for building robust and scalable applications. In Oracle Cloud Infrastructure (OCI), effective IP address management forms the backbone of your network architecture. This guide will demystify OCI's IP address categories, explore their use cases, and introduce advanced concepts like Reserved Public IPs, Bring Your Own IP (BYOIP), and Public IP Pools.

🏛️The Two Pillars: Private and Public IP Addresses

OCI categorizes IP addresses into two primary types, each serving distinct communication needs.

🔒Private IP Addresses

These are used for internal communication within your OCI network and with connected on-premises environments.

Internal Communication: Instances within the same Virtual Cloud Network (VCN) communicate seamlessly using private IPs.
VCN Peering: Connecting multiple VCNs, whether in the same or different regions, relies on private IP routing.
On-premises Connectivity: Secure connections to your data centers via the Dynamic Routing Gateway (DRG).
Instance Allocation: Each instance receives at least one primary private IP.
VNIC Capacity: Every Virtual Network Interface Card (VNIC) includes one primary private IP address and supports up to 32 secondary private IP addresses, totaling 33 private IPs per VNIC.

🌍Public IP Addresses

These are designed for internet accessibility, allowing your resources to communicate with the outside world.

Internet Reachability: Public IPs are reachable from the internet, assigned to a private IP object on your OCI resource.
Prerequisites: For a public IP to function, your VCN requires an Internet Gateway, and the associated public subnet must have correctly configured Route Tables and Security Lists.
Flexibility: Resources can be assigned multiple public IPs across single or multiple VNICs.

⏳Types of Public IP Addresses: Ephemeral vs. Reserved

OCI offers two types of public IP addresses to cater to different operational requirements.

Reserved Public IP Addresses in Detail

Creation: You create them individually.
Limits: Up to 50 Reserved Public IPs are allowed per region.
Assignment: Assigned to resources after creation.
Unassignment: When unassigned, they return to your tenancy pool for future use.
Scope: These are regional resources.
Configuration: Specify a name, compartment, and source during creation.

🚢Bring Your Own IP (BYOIP): Extending Your Network into OCI

BYOIP allows you to import your existing public IPv4 CIDR blocks or IPv6 prefixes into OCI, providing seamless network continuity.

📋Requirements & Limits

Ownership Verification: You must demonstrate ownership of the public prefix through a supported Regional Internet Registry (RIR).
IPv4 Size: Minimum /24, Maximum /8.
IPv6 Size: /48 or larger.
Management: BYOIP addresses are managed through IP Pools.

✨BYOIP Benefits

Solution Continuity: Preserve existing IP addresses hard-coded in devices or applications during migration.
IP Reputation: Maintain your established IP reputation with external services.
IP Pool Management: Group your imported IP addresses into pools for simplified resource deployment (e.g., Load Balancers).

📋BYOIP Process Overview

The process involves OCI verifying your ownership with an RIR.

Request Import: Initiate the import of your public IPv4/IPv6 prefix to Oracle.
Token Issuance: Oracle provides a unique verification token.
RIR Update: Add the verification token to your RIR records (typically takes ~1 day).
Create ROA: Create a Route Origin Authorization (ROA) with your RIR. The ROA allows Oracle to advertise your CIDR block.
Finish Import: Request Oracle to complete the import. (typically takes up to 10 business days, while Oracle verifies ownership with the RIR).
Provision Addresses: Oracle provisions the addresses to a specified compartment in your tenancy.

🏊Public IP Pools: Structured IP Management

A Public IP Pool is a dedicated set of IPv4 CIDR blocks allocated exclusively to your tenancy, offering granular control over IP assignments.

⚙️Core Characteristics

Definition: A collection of IPv4 CIDR blocks.
Source: Can consist of all or part of a BYOIP CIDR block.
Exclusivity: These pools are unique to your specific tenancy.
Sizing: Blocks within a pool range from a minimum /28 to a maximum /24.
Restriction: Public IP Pool functionality is currently limited to IPv4 addresses.

🛠️Benefits & Usage

Public IP Pools provide a structured way to manage and allocate public IP addresses to your cloud resources.

Allocation Source: Use the pool as the source for IP allocation when deploying: NAT Gateways, Load Balancers, Compute Instances
Reservation: Create Reserved Public IPs directly from the pool and attach them to your resources.
Direct Launch: Launch resources with IPs directly sourced from the pool.

🎯Conclusion

Effective IP address management is a foundational skill for anyone working with Oracle Cloud Infrastructure. By understanding the distinction between private and public IPs, leveraging Reserved Public IPs for persistence, and exploring advanced options like BYOIP and Public IP Pools, you can design more resilient, flexible, and secure network architectures in OCI. Mastering these concepts empowers you to optimize your cloud environment for performance and operational continuity.

OCI Networking Explained: Virtual Cloud Networks (VCN) Deep Dive

Lwandile Majola — Mon, 23 Feb 2026 13:41:13 +0000

When I started learning networking in Oracle Cloud Infrastructure, one thing became obvious very quickly: If IAM controls who can access resources, networking controls how everything communicates.

In this article, I’m breaking down Virtual Cloud Networks (VCN) properly. Not just definitions, but how it actually works underneath.

🧠 Part 1: CIDR Blocks and IP Notation (The Foundation)

Before we touch VCNs, we need to understand CIDR.

What is CIDR?

CIDR stands for Classless Inter-Domain Routing.

Format: A.B.C.D/x

Example: 10.0.0.0/16

/x = network portion
Remaining bits = host portion

An IPv4 address has:

4 octets
8 bits each
32 bits total

The Rule of Size
The smaller the prefix, the larger the network.

Formula to calculate total IP addresses:
2^(32 - x)

Example:

For 10.0.0.0/16

2^(32 - 16) = 2^16 = 65,536 IP addresses

Binary Conversion
Each octet is based on powers of 2:

| 128 | 64 | 32 | 16 | 8 | 4 | 2 | 1 |

Example:

192.168.0.2 in binary:

11000000.10101000.00000000.00000010

You don’t need to convert manually every day, but understanding this makes subnetting much easier.

🏗️ Part 2: What is a VCN?

A Virtual Cloud Network (VCN) in OCI is:

Software-defined
Private
Regional
Highly available

It lives inside a single OCI region but can span multiple Availability Domains. Think of it as your own private data center network inside Oracle Cloud.

CIDR Limits

Prefix must be between /16 and /30
A VCN can have up to 16 IPv4 and IPv6 CIDR blocks

Reserved IPs in Every Subnet

Oracle reserves 3 IP addresses:

First IP → Network address
Second IP → Default gateway
Last IP → Broadcast address

You can’t assign these to instances.

🧱 Part 3: Subnets

A VCN is divided into subnets.

Each subnet:

Is a contiguous range of IPs
Cannot overlap with other subnets in the same VCN

Subnet Scope

AD-Specific
Exists in one Availability Domain

Regional (Recommended)
Spans all ADs for high availability

Public vs Private Subnets

| Feature           | Public         | Private             |
| ----------------- | -------------- | ------------------- |
| Public IP         | Yes            | No                  |
| Internet Access   | Direct         | Via NAT             |
| Use Case          | Web servers    | Databases, backend  |

Important: You cannot change a subnet from public to private later.

🛣️ Part 4: Route Tables

Route Tables control where traffic goes.

Every subnet must be associated with exactly one Route Table.

A Route Table rule contains:

Destination CIDR
Target (next hop)

Example:

| Destination CIDR    | Route Target                    |
| ------------------- | ------------------------------- |
| 0.0.0.0/0           | Internet Gateway                |
| 192.168.0.0/16      | Dynamic Routing Gateway (DRG)   |

Longest Prefix Match (LPM)

If multiple routes match a destination, the most specific one wins.

Example:
For a packet destined to 192.168.20.19, if the table has 192.168.0.0/16 and 192.168.20.16/28, the /28 route is chosen because it is more specific (longer prefix).

🌍 Gateways Explained

Internet Gateway (IGW)

Provides bi-directional internet access.

Requirements:

Public subnet
Public IP
Security rules allowing traffic

Only one IGW per VCN.

NAT Gateway

Allows private subnet instances to access the internet without a public IP.

Characteristics:

Outbound only
Internet cannot initiate a connection
Supports TCP, UDP, ICMP
Up to 20,000 concurrent connections

Service Gateway

Allows private access to Oracle services over Oracle’s internal backbone.

Instead of hardcoding IP ranges, OCI uses Service CIDR Labels like:

All region services
Object Storage specific label

This removes manual maintenance when Oracle expands IP ranges.

Dynamic Routing Gateway (DRG)

Used to connect:

On-prem data centers
Other VCNs in different regions
Cross-region networks

This is how hybrid cloud connectivity is built securely.

🔐 Part 5: Security Layers

OCI networking uses layered security.

Security Lists (SL)

Applied at subnet level
Applies to all instances in subnet

Network Security Groups (NSG)

Applied at VNIC level
Granular, resource-specific control
Can reference other NSGs

Stateful vs Stateless

Stateful (Default):

Tracks connections
Response traffic is automatically allowed

Stateless:

No connection tracking
Requires manual response rules
Useful for high-volume traffic

The Union Rule
If both SLs and NSGs are used, traffic is allowed if any rule in Subnet Security List or attached NSG permits it.

This is OR logic, not AND.

🏘️ Simple Analogy

VCN → Entire housing estate
Subnet → A block inside the estate
Route Table → GPS directing traffic
Internet Gateway → Exit gate
Security List → Guard at block entrance
NSG → Guard at a specific house

🧠 Final Thoughts

If IAM is about identity, VCN is about connectivity.

Understanding CIDR, route tables, gateways (IGW, NAT, Service Gateway, DRG), and layered security is what separates “cloud user” from “cloud engineer”.

🔔 What’s Coming Next

In the next part of this OCI series, I’ll break down IP Management in OCI:

Private vs Public IP
Ephemeral vs Reserved
BYOIP
Public IP Pools

Because networking doesn’t stop at connectivity, it continues with smart IP design. And that’s where real architecture begins.

Stay tuned.

OCI IAM Policies Explained: How Authorization Actually Works

Lwandile Majola — Mon, 19 Jan 2026 11:10:21 +0000

In Part 1, we looked at how Oracle Cloud Infrastructure is structured physically and logically.

Now comes the part where OCI usually starts to feel confusing in practice:
IAM policies

Policies are where OCI stops being theoretical and starts enforcing reality.
If something doesn’t work in OCI, nine times out of ten, it’s a policy issue.

Let’s break them down properly.

🧠 The One Rule to Remember

OCI IAM follows a strict rule:
Everything is denied by default.

There are no implicit permissions.
No “but I’m an admin” shortcuts.
If a policy doesn’t allow it, it won’t happen.

This makes OCI predictable and secure, but only if you understand how policies are evaluated.

🔐 What a Policy Really Does

A policy answers four questions:

Who → can do what → on which resources → where

If any part is missing or wrong, access is denied.

Policies are not attached to users.
They are attached to groups and scoped to compartments or the tenancy.

🧱 Policy Syntax (The Core Pattern)

Every OCI policy follows the same structure:

Allow <Subject> to <Verb> <Resource-Type> in <Location> where <Condition>

Once this clicks, policies become much easier to reason about.

👥 Subject: Who Is Allowed?

The subject defines who gets the permission.

Common options:

A group (most common)
A dynamic group (for compute instances)
any-user (rare, dangerous, usually avoided)

Example:

Allow group NetworkAdmins to manage virtual-network-family in compartment Prod

Best practice:
Always grant permissions to groups, never individual users.

🧩 Verbs: What Actions Are Allowed?

OCI has four verbs, and they are cumulative.

🔍 Inspect

List resources
No sensitive data

📖 Read

Inspect +
View metadata and configuration

🛠️ Use

Read +
Interact with existing resources
Cannot create or delete

🧨 Manage

Full control
Create, update, delete

If someone can’t do something, check the verb first.

📦 Resource Types: What Is Being Accessed?

OCI groups related resources into families.

Examples:

instance-family
virtual-network-family
object-family
database-family

Using families avoids writing dozens of policies.

Example:

Allow group StorageAdmins to manage object-family in compartment Data

📍 Location: Where the Policy Applies

Policies are scoped to:

The tenancy (root compartment), or
A specific compartment

Example:

Allow group DevOps to use instance-family in compartment Dev

Important:

Policies attached to a parent compartment are inherited by children
OCI evaluates policies top-down

Best practice:
Attach policies at the lowest possible level.

🎯 Conditions: Making Policies Precise

The where clause is optional, but powerful.

It lets you restrict access using conditions like:

Compartment name
Resource OCID
Network source
Requesting group

Example:

Allow group Admins to manage all-resources in tenancy
where request.networkSource.name = 'CorpNet'

This means:
Even admins must come from a trusted network.

🤖 Dynamic Groups (Policies for Compute)

Dynamic groups are how OCI grants permissions to instances, not people.

Example use case:

A compute instance needs access to Object Storage
No API keys
No stored credentials

You define:

A dynamic group based on instance rules
A policy granting permissions to that dynamic group

Example:

Allow dynamic-group AppServers to read object-family in compartment Data

This is how Instance Principals work securely.

🧪 Common Policy Mistakes (Real-World Pain)

Here’s where people usually get stuck:

Granting read when use is required
Writing policies at tenancy level “just to test”
Forgetting policy inheritance
Using the wrong compartment
Mixing identity domain admin roles with OCI resource access

Quick check when something fails:

Is the user in the right group?
Is the policy in the correct compartment?
Is the verb strong enough?
Is a condition blocking access?

🧠 How OCI Evaluates Policies (Mental Model)

OCI evaluates policies like this:

Start at the resource’s compartment
Walk up the compartment hierarchy
Apply all matching policies
If any policy allows, access is granted
If none allow, access is denied

There are no explicit deny policies.
Silence equals denial.

🧭 Best Practices That Actually Scale

Design compartments first
Map roles to groups
Write policies per role, not per service
Use manage sparingly
Restrict admin access with network sources
Review policies regularly

Good IAM design feels boring.
That’s how you know it’s working.

✅ Final Takeaway

Policies are not configuration details.
They are your security model.

Once you understand:

Subjects
Verbs
Resource families
Compartments
Conditions

OCI IAM stops feeling strict and starts feeling precise.

That’s when you move from “why is this denied?”
to “I know exactly why this is allowed.”

🔔 What’s Coming Next

In the next article, we’ll shift focus to OCI networking, starting with Virtual Cloud Networks (VCNs).
We’ll break down how VCNs, subnets, route tables, gateways, and security lists fit together, and how networking decisions shape everything built on top of OCI.

Stay tuned.

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

Lwandile Majola — Mon, 19 Jan 2026 00:51:58 +0000

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.