A landing zone is the prepared foundation every OCI workload lands on. Get its principles right and the estate grows cleanly. Get them wrong and you pay for it on every project after the first.
The first workload to land in a new OCI tenancy almost never waits for a landing zone. There is pressure to show progress, the workload is urgent, and OCI makes it easy to provision whatever is needed in minutes. The landing zone, the prepared foundation that should have been laid first, gets deferred. Months later, when there are forty resources, three teams and an audit on the horizon, the absence of that foundation is felt on every change. This article sets out the principles that make a landing zone durable, so it is built once and built right rather than retrofitted under pressure.
A landing zone is not a product or a single artifact. It is the set of decisions and configurations, the compartments, identity, networking, security baseline, logging and guardrails, that every workload inherits when it lands. The detailed treatment of each piece lives in its own article, linked below. What follows is the set of principles that should guide all of them, the ideas that separate a landing zone that ages well from one that becomes the thing everyone works around.
The most common landing zone mistake is sizing the design for the first workload rather than the eventual estate. A flat structure with everything in one compartment works perfectly for one application and becomes unmanageable at twenty. Design instead for where the estate is going, with a structure that has room for more environments, more teams and more workloads than you have today. This does not mean over engineering. It means choosing patterns that extend rather than patterns that have to be replaced. The broader architecture this fits into is set out in the cluster pillar, OCI Landing Zone and Architecture: A Complete Guide.
A good landing zone keeps things separate unless there is a reason to connect them. Environments are isolated so a mistake in development cannot touch production. Workloads are isolated so one team's resources are not visible or reachable by another without intent. This isolation is expressed mainly through compartments and networking, and it is far easier to relax isolation later than to introduce it after everything has been built flat. The compartment side of this principle is covered in Compartment Strategy for OCI.
Identity should exist before the first workload, not after. When access is designed up front, with groups that map to roles and policies that grant the least privilege needed, every workload that lands inherits a clean access model. When identity is retrofitted, the estate accumulates ad hoc grants that nobody can safely remove. The identity model that anchors a landing zone is explored in Identity Domains in OCI Architecture, and the wider habit it supports in Security by Design on OCI.
A landing zone should set a security floor that every workload starts above. Encryption defaults, logging that is on everywhere, network controls that deny by default, and monitoring that watches the whole tenancy. The point of a baseline is that security is not something each team has to remember, it is the starting state. Teams can add to it but cannot fall below it, which is what makes a large estate auditable rather than a patchwork of individual decisions.
There are two ways to keep an estate safe, gates that require approval before anything happens, and guardrails that allow teams to move freely within safe boundaries. Gates slow everyone and breed workarounds. Guardrails, expressed through policies, quotas and budgets, let teams self serve while preventing the actions that would cause harm. A good landing zone leans heavily on guardrails, so that doing the right thing is the easy path and doing the dangerous thing is blocked automatically rather than by a meeting.
A landing zone defined by clicking through the console is a landing zone that drifts, because the next person clicks differently and there is no record of intent. A landing zone defined as code is reproducible, reviewable and recoverable. It can be applied to a second tenancy, rolled back when wrong, and read to understand exactly how the estate is configured. This is why infrastructure as code is not an optional extra but a core principle, set out in OCI Resource Manager and Terraform.
Translating those principles into an actual landing zone produces a recognisable set of components. The table below lists them with the principle each one mainly serves.
| Component | What it provides | Principle served |
|---|---|---|
| Compartment hierarchy | Grouping and isolation | Isolate by default |
| Identity domains and policies | Least privilege access | Identity before workloads |
| Core network | Connectivity and segmentation | Isolate by default |
| Security baseline | Encryption, logging, controls | A floor everything inherits |
| Budgets and quotas | Spending and capacity limits | Guardrails over gates |
| Terraform definitions | Reproducible foundation | Make it code |
A landing zone built on these principles has a few visible signatures. New workloads land into an existing compartment and inherit access, network and security without bespoke setup. Cost reports attribute spend cleanly because the structure maps to how the organisation thinks about ownership. Access requests resolve by adding a person to a group rather than crafting a new policy. Audits are quick because the baseline is uniform. And the whole foundation can be rebuilt from code if it ever needs to be. None of this is visible on day one, and all of it compounds over the life of the estate.
The failures are as predictable as the principles. Everything in the root compartment, because compartments felt like overhead. Identity added after the first three workloads, leaving a tangle of direct grants. A flat network that has to be re segmented later. A security baseline that exists in a document rather than in configuration. And a landing zone built by hand, so nobody can say with confidence how it is actually configured. Each of these is the inverse of a principle above, and each is avoidable with a week of deliberate design before the first workload lands.
There is a temptation to copy a reference landing zone wholesale, and a reference is a fine starting point, but the landing zone has to fit the organisation that will live in it. A small team building a handful of workloads does not need the elaborate structure that a regulated enterprise with dozens of teams requires, and forcing the heavy version onto the small team creates friction that breeds workarounds. The art is in choosing a structure that is rich enough to support where the organisation is going without being so elaborate that day to day work fights it. A landing zone that people route around is worse than a simpler one they actually use, so right sizing the foundation to the organisation is itself a design principle.
A landing zone is built once but it is never finished, because the estate it serves keeps changing. New compliance requirements arrive, the organisation restructures, new kinds of workload need new patterns, and the landing zone has to evolve with them. The estates that stay healthy treat the foundation as something they maintain, reviewing it periodically against how the estate has grown and updating it deliberately, rather than letting it ossify while the real estate drifts away from it. Because the landing zone is defined as code, this evolution is manageable, a change reviewed and applied rather than a risky manual edit. Treating the foundation as living rather than fixed is what keeps it relevant as the years pass.
Designing and building the landing zone is the opening move of most of our OCI Consulting and Advisory engagements, and the foundation our OCI Implementation team builds on. We design it as code, set the guardrails that let your teams move safely, and document it so ownership transfers cleanly. The result is a foundation that makes every workload after the first one faster and safer, which is the entire point of building one.
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.