The shape you give an OCI estate in the first month decides how easily it grows for the next five years. This is the complete guide to getting the foundation right, from the landing zone through tenancy, networking, identity and resilience.
Most problems with an Oracle Cloud Infrastructure estate are not problems with OCI. They are problems with the decisions made in the first few weeks, before anyone knew enough to make them well. A tenancy laid out by guesswork, compartments that map to nothing, a flat network that has to be unpicked later, identity that was bolted on after the first workload landed. None of these stop the first project, and all of them tax every project after it. Architecture is the discipline of making those early decisions deliberately, so the estate grows by extension rather than by rework.
This guide is the complete picture of how a well structured OCI estate fits together. It moves from the landing zone, which is the foundation everything else sits on, through the tenancy and compartment model that organises it, the network that connects it, the identity that secures it, and the resilience and automation that keep it running and let it change safely. Each section links to a detailed treatment, and together they describe an estate that is cheaper to run, safer to operate and far easier to grow than one assembled workload by workload.
A landing zone is the prepared foundation a cloud estate is built on, the equivalent of laying out plots, roads and utilities before anyone builds a house. It is the tenancy structure, the compartment layout, the core networking, the identity model, the security baseline, the logging and the guardrails, all defined once and applied consistently so that every workload that lands afterwards inherits a known, safe, well organised environment. Building workloads without a landing zone is possible, and it is also how estates end up needing expensive remediation a year later. The principles that make a landing zone durable are set out in OCI Landing Zone Design Principles.
It helps to see an OCI estate as a small number of layers, each built on the one below. Get the lower layers right and the upper layers become straightforward. Get them wrong and every layer above inherits the flaw.
| Layer | What it defines | Why it comes first |
|---|---|---|
| Tenancy | The top of the estate, regions, billing | Everything sits inside it |
| Compartments | Logical grouping and isolation | Drives access and cost visibility |
| Identity | Who can do what, where | Security depends on it being early |
| Networking | How resources connect and isolate | Hardest to change later |
| Resilience | How the estate survives failure | Must be designed, not added |
| Automation | How the estate is built and changed | Makes the rest repeatable |
The tenancy is the top of an OCI estate, and how it is structured shapes billing, isolation and blast radius. The main decision is whether one tenancy serves the whole organisation or whether separate tenancies separate, for example, production from everything else, or one business unit from another. There is no single right answer, only a right answer for a given organisation's risk appetite and operating model, and the trade offs are set out in OCI Tenancy Structure Best Practices.
Within a tenancy, compartments are how resources are grouped, isolated and made visible. A good compartment strategy makes access control simple, cost attribution accurate and the blast radius of any mistake small. A poor one, where everything lands in the root compartment or compartments map to nothing meaningful, makes all three of those harder forever. The patterns that work, organised by environment, by application or by business unit, are covered in Compartment Strategy for OCI.
Identity in OCI decides who can do what and where, and it is far cheaper to design early than to retrofit. Identity domains, groups, policies and dynamic groups together form the spine that every access decision runs through, and a clean model keeps that spine simple as the estate grows. The role identity domains play in an estate's architecture, and how they keep access manageable at scale, is explored in Identity Domains in OCI Architecture. Identity is also where security stops being a layer you add and becomes a property of the design itself, a theme covered in Security by Design on OCI.
Of all the layers, networking is the one that punishes a poor early decision hardest, because changing the network under running workloads is slow, risky and sometimes impossible without downtime. The virtual cloud network, its subnets, route tables, gateways and security lists, is where connectivity and isolation are decided, and the patterns that scale are set out in VCN Design Patterns on OCI. As estates grow beyond a single network, the question becomes how to connect many of them, and the dominant answer is a central hub that shared services and connectivity flow through, described in Hub and Spoke Networking on OCI.
Resilience is not a feature you switch on, it is a property you design in. OCI gives you the building blocks, availability domains, fault domains, regions, but how you arrange workloads across them decides whether a single failure is invisible or catastrophic. Designing for high availability within a region means spreading workloads so no single point of failure can take a service down, a discipline set out in Designing for High Availability on OCI. Surviving the loss of an entire region means going further, into a multi region design, covered next.
A single region is enough for many workloads, but some need to survive the loss of a whole region, or to serve users across continents with low latency, or to satisfy data residency rules that span jurisdictions. A multi region architecture answers all three, at the cost of additional complexity in data replication, traffic steering and operational discipline. When a second region earns its keep and how to design one without doubling the operational burden is the subject of Multi Region Architecture on OCI.
Individual decisions are easier when they sit inside a framework that names the things you should be optimising for. The well architected approach organises architecture around a small set of pillars, security, reliability, performance, cost and operations, and gives you a checklist of questions to ask of any design before you commit to it. How that framework applies specifically to OCI, and how to use it as a review tool rather than a box ticking exercise, is set out in OCI Well Architected Framework Explained.
You rarely have to design from a blank page. Common workload shapes, a three tier web application, a data platform, a resilient database, a Kubernetes estate, have well understood reference architectures that encode the lessons of many prior builds. Starting from a reference and adapting it is faster and safer than inventing one, and a walkthrough of the most useful OCI reference architectures is in OCI Reference Architectures Walkthrough. The skill is in knowing which reference fits and where your situation genuinely differs from the assumptions it makes.
An architecture that works at launch must also work at ten times the load, and the patterns that get you there, horizontal scaling, autoscaling, load distribution, decoupling through queues, are worth designing for early even if you do not need them yet. The patterns that let an OCI estate grow without re architecture are covered in Scaling Patterns on OCI. The point is not to build for scale you do not have, it is to avoid choices that make future scale impossible.
An architecture that lives only in a diagram drifts from reality the moment someone makes a manual change. Infrastructure as code is what keeps the running estate and the intended design in agreement, because the design is the code that builds the estate. OCI Resource Manager and Terraform together let you define the landing zone, the network and the workloads as version controlled code that can be reviewed, tested and reapplied, a practice set out in OCI Resource Manager and Terraform. Architecture without automation is a hope. Architecture as code is a guarantee.
The order is deliberate. Each step depends on the ones before it, and skipping a lower step to reach a workload faster is the decision that creates the rework everyone regrets. An estate built in this sequence reaches its first workload only slightly later and every subsequent workload far faster.
It is tempting to treat the landing zone as overhead that delays the first deliverable, and tempting is exactly how unstructured estates begin. The arithmetic is the other way around. The week spent on the foundation is repaid many times over in the workloads that land cleanly, the access requests that resolve in minutes, the costs that attribute correctly, the audits that pass, and the failures that stay contained. The estates that are painful to run are almost always the ones that skipped the foundation to save a week.
An architecture you cannot see into is an architecture you cannot operate or secure. That is why logging and observability belong in the foundation rather than being added per workload later. A landing zone should turn on audit logging across the tenancy, collect the logs somewhere durable, and establish the monitoring that watches the whole estate from the start. When observability is part of the foundation, every workload that lands is visible the moment it exists, which means problems are caught early and audits have the evidence they need. When it is retrofitted, there are always blind spots, the resources that predate the monitoring and never got added to it. The discipline of building observability in rather than bolting it on is one of the clearest markers of a mature estate.
It is easy to treat cost as something finance worries about after the architecture is built, but the architecture is exactly what determines the cost. The compartment structure decides whether spend can be attributed. The network design decides how much egress the estate generates. The choice of shapes and the use of autoscaling decide how much capacity sits idle. Building cost awareness into the foundation, with budgets, quotas and a tagging strategy in place from the start, means the estate is governable from day one rather than needing a cleanup once the bill becomes alarming. An architecture that ignores cost is an architecture that will need an expensive optimisation pass later, when it could have been lean from the beginning.
A foundation that only its builders understand is a fragile foundation, because people leave and memory fades. A well built landing zone is documented, both in the code that defines it and in the decisions that explain why it is shaped the way it is. The reasoning behind the tenancy choice, the compartment pattern, the network segmentation and the security baseline matters as much as the configuration itself, because future teams need to know not just what was built but why, so they can extend it without breaking its intent. Building for ownership transfer, so that the team who runs the estate understands it as well as the team who designed it, is what turns a one time build into a durable foundation.
Designing and building the foundation is the core of our OCI Consulting and Advisory work, from the tenancy decision through the landing zone to the network and identity model that everything else inherits. We build it as code, document it so your team can own it, and design it for the estate you will have in three years rather than the one workload in front of you today. The work begins with an assessment of where you are and where you need to be, because a foundation is only right when it fits the organisation it serves.
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.