OCI Architecture
Compartment Strategy for OCI
Compartments are how an OCI estate is organised, isolated and made visible. A clear strategy makes access, cost and safety easy. A vague one makes all three hard for the life of the estate.
Compartments are how an OCI estate is organised, isolated and made visible. A clear strategy makes access, cost and safety easy. A vague one makes all three hard for the life of the estate.
Compartments are one of the first decisions in an OCI estate and one of the most consequential, which is unfortunate because they are also one of the least understood at the start. They look like folders, so people treat them like folders, dropping resources wherever seems convenient. But compartments are not folders. They are the unit of access control, cost attribution and isolation in OCI, and a strategy that is vague or absent makes every one of those three harder for as long as the estate exists. This article sets out how to design a compartment strategy that ages well.
The good news is that a sound compartment strategy is not complicated. It follows from a few clear ideas about what compartments are for and a choice between a small number of organising patterns. The sections below explain what compartments actually do, the patterns that work, and the mistakes that turn this early decision into a long running tax. It sits within the broader foundation described in the cluster pillar, OCI Landing Zone and Architecture: A Complete Guide.
A compartment in OCI does three jobs at once. It is a boundary for access, because policies grant permissions on compartments, so where a resource lives decides who can touch it. It is a unit of cost, because spend can be reported by compartment, so the structure decides how cleanly you can attribute cost. And it is a blast radius, because a misconfigured policy or a mistaken action is contained to the compartment it applies to. A good strategy makes all three of these align with how the organisation actually thinks about ownership.
There are three organising patterns that estates tend to choose between, often in combination. Each suits a different way of thinking about the estate.
| Pattern | Top level split | Best when |
|---|---|---|
| By environment | Production, non production, shared | Operations think in environments |
| By application | One compartment per workload | Teams own whole applications |
| By business unit | One compartment per unit or team | Cost and access follow org structure |
The environment pattern separates production from non production at the top level, which makes the single most important isolation, keeping development mistakes away from production, structural rather than a matter of care. Policies can then grant broad access in non production and tight access in production, and cost reports show the split between what is serving customers and what is supporting development. Many estates use environment as the top level and then nest applications below it, which combines two patterns cleanly.
The application pattern gives each workload its own compartment, which suits organisations where teams own whole applications end to end. Access maps naturally, because the team that owns the application gets access to its compartment and nothing else. Cost maps naturally too, because each application's spend is its own line. The trade off is that shared resources, networking and common services, need a home that sits above the individual applications, which is where a nested structure helps.
The business unit pattern aligns the top level of the compartment structure with the organisation chart, which makes cost attribution and access governance follow lines that finance and management already understand. It suits larger organisations where business units have real autonomy and budgets. The risk is that the organisation chart changes more often than the estate, so a structure tied tightly to it may need periodic rework, which argues for keeping the top level stable and expressing finer detail below it.
Compartments nest, and good strategies use nesting to combine patterns, for example environment at the top, then business unit, then application. The cardinal rule is to keep the root compartment nearly empty, because the root is the hardest place to apply isolation and the easiest place for resources to accumulate ungoverned. Resources in the root are visible and reachable in ways that resources in child compartments are not, so a disciplined estate treats the root as a place for the structure itself and almost nothing else. The access policies that run across this structure are explored in Identity Domains in OCI Architecture.
A clean compartment strategy is the foundation of two other disciplines. Security benefits because least privilege becomes easy to express when resources are grouped by who should access them, a theme covered in Security by Design on OCI. Cost governance benefits because spend attributes cleanly to teams and workloads, which is what makes showback and accountability possible. A vague compartment structure undermines both, forcing security into a tangle of individual grants and cost into guesswork. The structure is therefore not an administrative detail but a precondition for governing the estate well.
The failures repeat across estates. Everything in the root, because compartments felt like ceremony at the start. A structure so fine grained that there are hundreds of compartments and nobody can find anything. A structure so coarse that one compartment holds half the estate and isolation is meaningless. A layout that maps to nothing the organisation recognises, so cost reports are useless. And a structure that was right for the first three workloads and never revisited as the estate grew tenfold. Each is avoidable with a strategy chosen deliberately and reviewed as the estate changes.
One underused benefit of a clean compartment strategy is that it gives you a natural place to apply quotas, the limits that cap how much of a resource a part of the estate can consume. Because compartments map to teams or workloads, a quota set on a compartment limits that team or workload specifically, which is a powerful guardrail. A development compartment can be capped so that an experiment cannot accidentally provision an expensive fleet, while production carries higher limits. Without a meaningful compartment structure, quotas have nowhere sensible to attach, so the structure is a precondition for this form of cost and capacity control as much as it is for access and attribution.
A practical question that arises as estates evolve is whether resources can move between compartments, and for most resource types on OCI they can, which is reassuring because it means an early structural mistake is not necessarily permanent. That said, moving resources is not free of effort or risk, because policies, dependencies and references may need to follow, and some moves are more disruptive than others. The lesson is not that the structure does not matter because it can be changed, but that getting it close to right early avoids a steady stream of moves later. A structure designed with room to grow needs far fewer corrective moves than one that was sized only for the first workload.
Designing the compartment strategy is part of the landing zone work in most of our OCI Consulting and Advisory engagements, and it underpins the access model our IAM and Security practice builds. We choose a structure that fits how your organisation actually operates, keep it simple enough to live with, and document it so it survives the people who designed it. The payoff is an estate where access, cost and isolation are easy rather than a constant source of friction.
Moving Oracle workloads to OCI, or already running on OCI and not sure the architecture or the spend is right? Most teams bring in a specialist before they commit to a region, a shape, or a Universal Credits number. OCISpecialists.com plans the landing zone, runs the migration, and manages the estate after go live, on a fixed project fee, a managed monthly retainer, or a cost optimization fee paid only on verified savings. For the Oracle licensing and BYOL side of any OCI move, Redress Compliance is the leading independent Oracle licensing and negotiation firm, with 500+ engagements across Oracle's full product line.