Compartment Design Patterns for Growing Tenancies

Compartments are logical containers, not network or physical boundaries, and that is exactly what makes them powerful: they are the abstraction OCI uses to answer the question who may do what, to which resources, at what cost. Every IAM policy is written against a compartment. Every quota statement scopes to one. Every budget can watch one. A tenancy's compartment tree is therefore not a filing system but a control surface, and it deserves the same design attention as the network. This article lays out the patterns that survive growth, the naming and depth rules that keep trees navigable, and the honest options when a tenancy has outgrown the tree it started with. It is part of our series on advanced OCI operations.

What a compartment boundary buys you

Four controls inherit from the tree. Policy: IAM statements grant groups access within a compartment and, by inheritance, its children, so the tree defines the shape of least privilege. Quotas: the preventive ceilings described in service limits and quotas on OCI scope to compartments, so the tree defines where experimentation is cheap and where it is impossible. Budgets and cost: spend reporting and alerting group naturally by compartment, so the tree defines financial visibility. And lifecycle: a workload that lives in one compartment can be found, audited, and one day decommissioned as a unit, while a workload smeared across ten compartments can only be reconstructed archaeologically. The design question is always the same: along which lines do you want to grant, cap, see, and retire?

The three base patterns

Almost every real tenancy is a variation on three patterns. Environment first puts production, test, and development at the top, with workloads nested inside each. It optimizes for the strongest single boundary in most organizations, the production wall, and makes environment wide policy trivial: one statement keeps contractors out of production, one quota set keeps sandboxes cheap. Its weakness is workload visibility, since one application's footprint spans three top branches. Workload first inverts the tree: each application or platform at the top, environments nested inside. Cost reporting per workload becomes trivial and decommissioning is one subtree deletion, at the price of more policy statements to maintain the production wall across many branches. Team first mirrors the org chart, which makes ownership unambiguous, and ages exactly as well as the org chart, which is to say badly, because reorganizations now imply infrastructure projects.

The hybrid that most growing estates converge on puts a shared services branch beside the workload branches: networking, security tooling, observability, and image pipelines live in shared compartments owned by the platform team, while each workload branch carries its own environments inside it. The production wall is rebuilt with a policy convention rather than a tree position, typically a naming standard that lets one policy template stamp the same environment rules into every workload branch. The tree carries workload identity, the convention carries environment identity, and both controls stay one statement deep.

Depth, naming, and the rules that keep trees navigable

OCI allows compartments six levels deep, and almost no estate should use all of them. Every level adds a segment to every policy statement, another step in every console navigation, and another opportunity for two teams to disagree about where something lives. Three levels covers the overwhelming majority of real designs, shared or workload, then environment, then an optional component split for large applications, and a tree that wants a fourth level usually wants a second top level branch instead. Sibling count matters less than depth: twenty tidy branches at level two beat twelve levels of nesting every time.

Naming deserves ten minutes of design and then permanence. Lowercase, short, hyphenless if your conventions allow or consistently delimited if not, with the same environment suffixes everywhere, so that policy templates and automation can derive a compartment's role from its name mechanically. The moment names need a lookup table, the convention has failed. And names should describe function, not history: a compartment named after a project that ended two years ago is a small permanent tax on everyone's comprehension. The same logic governs the metadata layer above the tree, where consistent cost tracking and classification tags, covered properly in tagging governance on OCI, carry the dimensions the tree cannot, team, project, data classification, across whatever structure the tree imposes.

Policy inheritance, and the root compartment rule

Policy flows down the tree: a grant at a parent applies to all descendants, which is the mechanism that makes a well shaped tree cheap to govern and a flat tree expensive. The corollary is the root compartment rule: almost nothing belongs in the root, neither resources nor generous policy. Resources in the root are visible to every broad grant ever written, and policy at the root is inherited by everything forever. A healthy root contains the top level branches, the tenancy wide security policies written deliberately, and nothing else. Auditing the root, what sits in it, what is granted at it, is the fastest single health check we run on an unfamiliar tenancy, and the findings are reliably proportional to the estate's age.

Restructuring a tree you have outgrown

Tenancies accumulate structure the way houses accumulate wiring, and sooner or later most teams face a tree that no longer matches reality. The honest news: compartments can be moved, a subtree can be reparented, and many resources can be moved between compartments individually, so restructuring is possible without rebuilding. The cautionary news: every move changes what existing policies, quotas, and budgets apply to, and the failure mode is not the move itself but the policy that silently stopped, or started, applying afterward. A workable restructuring runs as a project: map the current tree and every policy, quota, and budget attached to it, design the target, move in small planned steps with the affected controls reviewed before and after each, and keep the cost reporting continuity in mind, since spend history follows the resource into its new compartment context. For estates heading toward multiple tenancies rather than deeper trees, the governance constructs above the single tenancy are covered in organizations and child tenancies, and the right answer to some restructuring problems is that second tenancy, not a seventh level.

Compartments and the network: separate trees, deliberate seams

A recurring design confusion deserves its own section: compartments are not network boundaries, and the two hierarchies should be designed separately and joined deliberately. A virtual cloud network lives in a compartment, but the subnets inside it can hold resources from other compartments, and security rules neither know nor care about compartment lines. This is a feature. The common hub and spoke arrangement puts the shared network itself, the hub, the DRGs, the firewalls, in a network compartment owned by the platform team, while workload compartments hold the compute and databases that plug into it, granted use of the network through policy without ever owning it. The seam between the trees is where mistakes concentrate, usually as overly generous network grants written to make a deadline, so the seam deserves explicit policy templates and a place in the quarterly audit. The test of a healthy separation: the network team can restructure routing without touching workload compartments, and a workload team can decommission its entire branch without holding a meeting about firewall rules.

A six step design sequence

Getting it right the first time, or the second

Compartment design is a one day decision that shapes years of operations, which is why it sits at the heart of every landing zone we build. The pattern above, hybrid tree, three levels, stamped controls, quarterly root audit, comes from watching what survives contact with growth across 500+ OCI engagements: the tenancies that scale calmly are the ones where the tree made the controls cheap. If your estate is starting fresh, the structure belongs in the landing zone design our OCI implementation service delivers as standard. If your estate is living with a tree that fights every change, the restructuring is a contained, plannable project, and considerably cheaper than another year of policy workarounds. Either way, the wall is load bearing. Build it like one.