Oracle Cloud Infrastructure (OCI) is Oracle's second-generation cloud, built with a strong focus on enterprise networking, predictable performance, and — compared to the hyperscaler norm — very competitive pricing on compute and egress. If you come from AWS or Azure, most concepts will feel familiar, but a few OCI-specific ideas (compartments especially) deserve a proper mental model before you deploy anything.
Physical layout: regions, ADs, and fault domains
- Region — a geographic location (for example, Jeddah or Riyadh in Saudi Arabia). Regions are independent of each other; multi-region designs are how you get disaster recovery.
- Availability Domain (AD) — an isolated data centre within a region, with independent power and cooling. Some regions have three ADs, many have one.
- Fault Domain (FD) — a grouping of hardware within an AD. Every AD has three fault domains, so even in a single-AD region you can spread instances across separate racks and avoid a single hardware failure taking down your whole tier.
Rule of thumb: spread application tiers across fault domains within an AD for high availability, and across regions for disaster recovery.
Compartments: OCI's organising superpower
The concept newcomers most often misuse is the compartment — a logical container for resources that exists purely for organisation, isolation, and access control. Compartments are not regional; a compartment can hold resources from every region in your tenancy. A clean structure usually mirrors environments or workloads:
tenancy (root)
├── network # shared VCNs, DRGs, firewalls
├── security # vaults, bastions, logging
├── prod
│ ├── app
│ └── db
└── nonprod
Because IAM policies attach to compartments, this structure becomes your security model:
network admins get power in network, application teams get scoped access to
their own compartments, and nobody works in the root compartment day-to-day.
IAM: groups, policies, and plain-English rules
OCI IAM policies are human-readable statements that grant a group a level of access to a resource type in a compartment:
Allow group NetworkAdmins to manage virtual-network-family in compartment network
Allow group AppTeam to use instance-family in compartment prod:app
Allow group Auditors to read all-resources in tenancy
The verbs escalate: inspect → read → use →
manage. Two more pieces complete the picture: dynamic groups
let resources themselves (like compute instances or functions) hold permissions without
stored credentials, and identity federation connects OCI to your existing IdP so people sign
in with corporate accounts.
Networking: the VCN
The Virtual Cloud Network (VCN) is your software-defined network — a private CIDR block
(say 10.0.0.0/16) divided into subnets. The gateways define what can reach
what:
| Gateway | Purpose |
|---|---|
| Internet Gateway | Public inbound/outbound internet for public subnets |
| NAT Gateway | Outbound-only internet for private subnets |
| Service Gateway | Private path to OCI services (Object Storage, etc.) without internet |
| Dynamic Routing Gateway (DRG) | Site-to-site VPN, FastConnect, and VCN/region peering |
Traffic is filtered twice: security lists at subnet level and network security groups (NSGs) at the VNIC level. Prefer NSGs for application rules — they follow the workload rather than the subnet, which keeps rules readable as environments grow.
Compute and storage in one paragraph each
Compute comes as VMs or bare metal, and OCI's flexible shapes are a genuine differentiator: you dial in OCPUs and memory independently (e.g. an E5.Flex with 4 OCPUs and 48 GB), instead of picking the least-bad fixed size. Instance pools and autoscaling handle horizontal growth.
Storage splits into block volumes (boot and data disks with adjustable performance tiers), object storage (S3-like, with lifecycle rules and cross-region replication), and file storage (NFS). Block volume backups and cross-region replication are the raw material of most DR designs.
Where to start
OCI's Always Free tier is generous — ARM compute, block storage, and two autonomous databases cost nothing and are enough to build a real lab. Start by designing your compartment tree and IAM groups before creating workloads; retrofitting governance onto a flat tenancy is the single most common OCI regret. Once the foundations are right, everything else — Terraform automation, DR, cost management — lands on solid ground.
back to all posts