What separates an OCI tenancy that runs quietly for years from one that turns into a monthly fire drill? Having watched teams migrate to Oracle Cloud Infrastructure, the pattern is rarely about which compute shape they picked. It comes down to a handful of design decisions made early, often by whoever happened to be on the project that week, that either scale gracefully or quietly become technical debt. (NIST SP 800-145: The NIST Definition of Cloud Computing)
This article walks through the practices that consistently matter, where teams commonly slip up, and how to build a tenancy that stays manageable as it grows.
Start With the Well-Architected Framework, Not With a VM
Oracle publishes an OCI Well-Architected Framework organized around pillars: operational excellence, security, reliability, performance, cost optimization, and, in later revisions, sustainability. It is the closest thing to a shared vocabulary for design reviews, and it is worth reading before anyone clicks “Create Instance.”
The practical trap is treating these frameworks as marketing collateral. They are not. Each pillar maps to concrete OCI services and settings, and the questions in the framework are the same ones a good architect asks in a review: What happens when this availability domain fails? Who can read this bucket? What does this workload cost per month at ten times the traffic?
One caveat worth knowing: Oracle reorganizes its documentation paths fairly often, and some “best practices” pages are solution briefs rather than normative guidance. When a design decision hinges on a specific recommendation, check the page’s last-updated date rather than trusting a version number quoted in a slide deck from last year.
Get Compartments and IAM Right Before Anything Else
Compartments are OCI’s core isolation primitive, and they are the single most consequential early decision. A tenancy with one giant compartment and broad policies is nearly impossible to retrofit later, because every policy, budget, and tag you add inherits that sprawl.
What works in practice:
- Model compartments after ownership and lifecycle, not after the org chart. A platform team compartment, an application compartment per environment, and a shared-services compartment usually beat one compartment per department.
- Scope policies to compartments, never to the tenancy root. Grant least privilege at the compartment level so a compromised credential cannot reach the whole estate.
- Separate production from non-production at the compartment level, so a policy mistake in a sandbox cannot touch live data.
A common mistake is writing a policy that looks narrow but is not. Policies like “manage all-resources in tenancy” get copied from tutorials into production far more often than anyone admits. Another is forgetting that groups, not users, should be the unit of authorization; users change roles, groups stay stable.
Identity Domains: Know Which Model Your Tenancy Uses
OCI has been moving toward identity domains as the default model for new tenancies, while older tenancies may still run the legacy IAM model. This is a genuine source of confusion, because documentation and tutorials often assume one model while the reader’s tenancy uses the other. Before following any IAM walkthrough, confirm which model your tenancy uses. Getting this wrong wastes hours chasing menu items that do not exist in your console.
Network Design: Private by Default
The default posture for a new VCN should be private subnets, with public exposure as a deliberate exception. The pattern that holds up is a segmented or hub-and-spoke VCN layout with:
- Private subnets for application and database tiers.
- A NAT service for outbound internet access, so instances never need public IPs to download patches.
- A private service path for traffic to OCI services like Object Storage, keeping that traffic off the public internet entirely.
- Security lists and network security groups applied at the narrowest scope possible.
The mistake here is treating security lists as a firewall afterthought. Teams often open a broad CIDR range “temporarily” during a migration and never close it. Network security groups, which attach to individual VNIs rather than entire subnets, are usually the better tool for application-level rules because they follow the workload.
Design for Failure Across Availability and Fault Domains
OCI regions vary in how many availability domains they offer, and some regions have only one. That single fact reshapes your resilience design: in a single-AD region, spreading across fault domains and using cross-region replication becomes the substitute for multi-AD redundancy.
The practice that works is to decide your failure model explicitly and write it down. Ask three questions:
| Question | Why it matters |
|---|---|
| How many ADs does this region have? | Determines whether multi-AD redundancy is even possible |
| Are instances spread across fault domains? | Protects against correlated hardware failure within an AD |
| What is the recovery time if the region is lost? | Forces a real conversation about cross-region strategy |
A frequent error is assuming every region looks like the home region. Teams build a resilient architecture in a multi-AD region, then deploy the same template to a single-AD region and inherit a false sense of safety. Reading a cloud region announcement carefully, including the AD count and service availability, prevents this. (AI cloud architecture: When infrastructure becomes intelligent) (Cloud computing)
Security Zones and Cloud Guard: Guardrails Over Willpower
Two OCI services do most of the heavy lifting for continuous security posture. Security Zones enforce a maximum-security recipe on a compartment, blocking things like public buckets and requiring encryption. Cloud Guard monitors the tenancy for risky configurations and can respond automatically.
The practical advice is to apply Security Zones to compartments where developers self-serve, precisely because willpower does not scale. If a bucket can be made public, eventually one will be. If a security zone forbids it, the mistake becomes impossible rather than merely discouraged.
Cloud Guard deserves a scheduled review rather than a set-and-forget deployment. Problem detectors generate findings, and findings that nobody reads are just noise. Assign an owner per finding category and tune out the detectors that do not apply to your workload.
Tagging and Cost Management: Do It on Day One
Cost surprises in OCI almost always trace back to missing tags. Oracle supports defined tags and cost-tracking tags, and the teams that manage spend well treat tagging as a deployment requirement, not a nice-to-have.
What actually works:
- Define a small tag taxonomy (cost center, environment, owner, application) and enforce it through defined tags with default values.
- Set budgets and alert rules early, before the first production workload, so a runaway job surfaces as an alert rather than an invoice.
- Review cost by tag monthly, not quarterly. Quarterly reviews arrive after the damage.
The common failure is a sprawling free-form tag vocabulary where “prod,” “Production,” and “PROD” all coexist, making cost reports useless. Defined tags with a controlled value list solve this. A clearer approach to tracking data transfer costs also helps, since egress is one of the line items teams most often misattribute.
Automate With Terraform From the Beginning
Oracle’s reference architectures lean on Terraform, and OCI Resource Manager is built on it. Provisioning through code rather than the console is the difference between a reproducible environment and a snowflake that nobody dares rebuild.
The mistake is treating infrastructure as code as a later-phase project. Retrofitting Terraform onto a hand-built tenancy means importing dozens of resources and discovering every undocumented manual change along the way. Start with the network and compartments, even if applications are still deployed by hand, and expand from there.
State management matters too. Keep state in a shared backend with locking, split it by environment, and never let two engineers apply against the same state file simultaneously.
Operational Excellence: Observability and Documentation
Monitoring in OCI requires more than default metrics. Configure alarms on the signals that predict outages rather than only on those that confirm them: latency percentiles, error rates, connection pool saturation, and backup completion. Logging and Monitoring services are inexpensive relative to the cost of an undetected failure.
Documentation is the unglamorous pillar that determines whether the tenancy survives staff turnover. Runbooks for common failures, a record of why each compartment exists, and a decision log for architectural choices pay for themselves the first time someone is on call at 2 a.m. Good technical writing for infrastructure teams is a reliability practice, not a compliance chore. (How cloud reliability skills transfer to AI infrastructure)
Common Mistakes Worth Avoiding
A short list of the errors that show up again and again:
- Building production in the tenancy root compartment because it was faster.
- Granting broad IAM policies “temporarily” during a migration.
- Assuming every region has multiple availability domains.
- Skipping tagging until the first cost review, then retrofitting it painfully.
- Treating Security Zones as optional for developer-facing compartments.
- Deploying by console and promising to “Terraform it later.”
None of these are exotic. They are ordinary shortcuts taken under deadline pressure, and each one costs more to fix than to avoid.
Conclusion
Oracle Cloud Infrastructure rewards discipline more than cleverness. The practices that hold up are unglamorous: compartments that mirror ownership, least-privilege policies scoped tightly, private-by-default networking, resilience designed around the actual availability domain count, guardrails that make mistakes impossible, tagging enforced from day one, and infrastructure provisioned through code.
None of this requires a large platform team. It requires deciding these things early and writing them down. Teams that do find that OCI scales quietly with them. Teams that skip the groundwork spend their second year untangling the shortcuts from their first.
Frequently Asked Questions
What is the most important OCI best practice for a new tenancy?
Getting compartments and IAM policies right first. Compartments are the isolation boundary that every policy, budget, and tag depends on, and they are painful to restructure later. Model them around ownership and lifecycle, scope policies to compartments rather than the tenancy root, and keep production separate from non-production from the start.
How many availability domains does an OCI region have?
It varies. Some regions offer multiple availability domains, while others have only one. This directly changes your resilience design, because a single-AD region cannot provide multi-AD redundancy and must lean on fault domain spreading and cross-region replication instead. Always confirm the AD count for the specific region before reusing a design template.
Should I use Security Zones or Cloud Guard?
Use both, for different jobs. Security Zones enforce a maximum-security configuration on a compartment, preventing things like public buckets outright. Cloud Guard continuously monitors the tenancy for risky configurations and can respond automatically. Security Zones prevent mistakes; Cloud Guard detects ones that slip through elsewhere.
Do I need Terraform if I am only running a few resources?
Yes, and the smaller the footprint, the easier it is to start. OCI Resource Manager is built on Terraform, so the tooling is native. Starting with just the network and compartments gives you a reproducible foundation, and it avoids the painful retrofit of importing hand-built resources later.
Why does tagging matter so much in OCI?
Because cost visibility depends on it. Defined tags and cost-tracking tags are how budgets, alerts, and cost reports attribute spend to a team or application. Without a controlled tag vocabulary, reports become unusable as “prod,” “Production,” and “PROD” all appear as separate categories. Enforce tags at deployment time rather than adding them later.
How do identity domains affect IAM guidance?
New tenancies generally default to identity domains, while older tenancies may still use the legacy IAM model. The two have different console layouts and documentation, so a tutorial written for one can send you hunting for menu items that do not exist in your tenancy. Confirm your model before following any IAM walkthrough.
