Oracle Cloud Infrastructure

Tenancy and compartments

An OCI tenancy is the top-level container for your Oracle cloud account — the equivalent of an AWS Organization root or an Azure tenant. Below the tenancy sits a tree of compartments — OCI's primary mechanism for isolating resources.

• Compartments are logical containers, not tied to specific regions or networks. A compartment can hold VMs, databases, buckets, networks, and other resources spanning multiple regions.
• Compartments can nest arbitrarily. Common shape: Tenancy/Prod/Payments/ next to Tenancy/Prod/Identity/.
• IAM policies attach to compartments and grant access to the resources within. A policy in compartment Payments doesn't grant anything in Identity.
• Quotas attach to compartments too — per-compartment caps on instance counts, storage, etc. Useful for keeping a runaway team from consuming the whole tenancy.

The IAM policy syntax — written in English

OCI's IAM policy syntax is the most distinctive thing about the platform. Where AWS uses JSON policy documents and GCP uses role bindings, OCI policies are written as English-like statements. Once you read a few, they become readable at a glance:

The four verbs — inspect, read, use, manage — are a strict hierarchy. inspect just lists. read additionally reads metadata. use additionally operates on existing resources. manage additionally creates and deletes. This is a cleaner model than AWS's hundreds of permission strings, at the cost of some granularity.

Dynamic groups let you write policies that apply to resources matching a rule, similar to AWS IAM Roles attached to EC2 instances. The example above grants secret access to "instances tagged role=web" — no key file, no static credential, the resource's own attributes are the auth.

Security Zones

A Security Zone in OCI is a compartment (or set of compartments) with a baked-in security policy that enforces rules at create-time, not just detects them after the fact. If you try to create a resource that violates the zone's policy, the create fails. Standard zone policy includes:

Object Storage, networking, the usual

OCI Object Storage (buckets) supports public buckets, pre-authenticated requests (PARs — the OCI equivalent of S3 presigned URLs and Azure SAS tokens), and customer-managed encryption keys via OCI Vault. The same hardening discipline applies: disable public buckets at the compartment level, prefer PARs to public, use Vault-managed keys for sensitive data.

Networking gives you Virtual Cloud Networks (VCNs) — the OCI VPC — with subnets, route tables, security lists (the OCI security group), and network security groups (a separate, more flexible filtering layer). Private endpoints for OCI services (Object Storage, Autonomous Database, etc.) let workloads reach services privately, same pattern as Azure Private Endpoint and GCP Private Service Connect.

What OCI got right; what users still trip over

Right: Compartments are a cleaner isolation unit than per-account-in-Org models. The English-like policy language is genuinely easier to write and read than JSON. Security Zones bake guardrails into resource creation. Free tier is meaningful: Always Free includes Autonomous Database and Compute instances.

Trip-ups: The default tenancy admin group (Administrators) is unbelievably powerful and frequently includes more humans than it should. Default network ACLs (security lists) on new VCNs allow inbound SSH from 0.0.0.0/0 — verify and lock down on every new VCN. Compartment moves are not free; resources tagged into a compartment have to be physically migrated to leave it.