Setting Up Oracle Cloud Infrastructure the Right Way: Tenancy, Compartments and Landing Zones
The mistakes that haunt an OCI estate are almost always made in the first month — a flat tenancy, everything in the root compartment, no tagging, no budgets. A landing zone fixes that before it starts.
Tenancy, regions and the building blocks
Your OCI tenancy is the root container for everything you run. Inside it, resources live in compartments — logical, hierarchical containers that are the primary unit of access control, isolation and cost tracking in OCI. Physically, OCI is organised into regions, each with one or more Availability Domains (isolated data centres) and, within those, Fault Domains for hardware-level resilience.
Why compartment design matters so much
Unlike some clouds where a project is just a tag, OCI compartments are structural: you write IAM policies against them, isolate environments with them, and report cost by them. Get the compartment hierarchy right — typically separating environments (prod/non-prod), workloads and shared services — and access control and cost visibility fall out naturally. Dump everything in the root compartment and you will be untangling it for years.
Never build production in the root compartment. The root should hold only top-level policies and child compartments — it cannot be deleted, and resources there are hard to isolate and govern later.
Start from a landing zone, not a blank tenancy
A landing zone is a pre-designed, secure foundation: a sensible compartment structure, baseline IAM groups and policies, network segmentation, logging, and guardrails, deployed as code. Oracle publishes reference landing zones (including a CIS-aligned OCI Landing Zone), and using one means your tenancy starts governed instead of being retrofitted after the first audit. It is the single highest-leverage decision in an OCI adoption.
- Tag from day one — defined tag namespaces make cost allocation and automation possible; retrofitting tags across a live estate is painful.
- Set budgets and alerts at the compartment level so spend is visible per environment and team.
- Centralise logging and audit — OCI Audit and the Logging service should be on and aggregated before workloads land.
Related: planning a move to OCI? See the hidden realities of EBS-to-OCI migration and how OCI compares in our AWS vs OCI guide. More in the OCI knowledge hub.
Starting on OCI, or cleaning up a flat tenancy?
We design OCI landing zones — compartments, IAM, network and guardrails as code — so your foundation is governed from the first workload, not retrofitted after the first audit.
Explore the OCI Knowledge Hub
