OCI Landing Zones - Expert Architecture
NEVER Do This
NEVER create a flat compartment structure
BAD:
tenancy/ app1-dev, app1-test, app1-prod, app2-dev ...
Problems:
- Cannot apply a single policy to all dev environments
- Cannot delegate administration per team
- Cost reports are unstructured
- Policy duplication grows O(n) with team count
GOOD - hierarchical:
tenancy/
Network/ (Hub, Spokes)
Security/ (Vault, Logging)
Workloads/
App1/ (Dev, Test, Prod)
App2/ (Dev, Test, Prod)
Shared-Services/ (Identity, Monitoring)
Policy inheritance flows DOWN the tree. One policy at Workloads/ applies to all workloads.
NEVER reuse 10.0.0.0/16 across VCNs
BAD - same CIDR everywhere:
Dev VCN: 10.0.0.0/16
Test VCN: 10.0.0.0/16 # Cannot peer with Dev
Prod VCN: 10.0.0.0/16 # Cannot peer with either
VCN CIDR is IMMUTABLE. Wrong CIDR = complete rebuild + downtime.
GOOD - non-overlapping allocation:
Hub VCN: 10.0.0.0/16
Dev VCN: 10.10.0.0/16
Test VCN: 10.20.0.0/16
Prod VCN: 10.30.0.0/16
NEVER skip Security Zones for production compartments
# BAD: Compartment with no guardrails
oci iam compartment create --compartment-id $PARENT --name "Prod"
# Result: Anyone can create public IPs, unencrypted buckets, etc.
# GOOD: Security Zone enforces policies BEFORE resource creation
oci cloud-guard security-zone-recipe create \
--compartment-id $TENANCY_ID \
--display-name "CIS-Prod-Recipe" \
--security-policies '["deny-public-ip","deny-public-bucket"]'
oci cloud-guard security-zone create \
--compartment-id $PROD_COMPARTMENT_ID \
--display-name "Prod-Security-Zone" \
--security-zone-recipe-id $RECIPE_ID
Security Zones prevent violations BEFORE resource creation. Auditing finds them AFTER compromise.
NEVER put workload resources in the root compartment
Root compartment is for tenancy-wide IAM only (users, groups, policies).
Resources in root bypass governance, cannot be delegated, violate CIS OCI Foundations Benchmark.
Root should contain ONLY:
- Top-level child compartments
- Tenancy-wide IAM policies
Nothing else.
NEVER mix dev and prod resources in the same compartment
Developers with dev access can accidentally delete prod resources. Cannot set different backup policies, tagging strategies, or budget alerts per environment.
NEVER skip tagging strategy
# Without tags: "oci.compute.instance: $5,234/month" — which team? which project?
# Cannot chargeback, cannot identify waste.
# RIGHT: Create tag namespace with mandatory defaults
oci iam tag-namespace create --compartment-id $TENANCY_ID --name "Organization"
# Create: CostCenter, Environment, Owner tags
# Apply tag-defaults at compartment level (auto-applied to all resources)
oci iam tag-default create \
--compartment-id $WORKLOAD_COMPARTMENT_ID \
--tag-definition-id $COSTCENTER_TAG_ID \
--value '${iam.principal.name}'
NEVER allow internet egress from spoke VCNs directly
BAD: Spoke subnet → Internet Gateway
- Data exfiltration undetectable
- Egress cost $3k-5k/month per spoke (unmetered)
- No DPI or egress filtering
GOOD - hub-spoke with centralized control:
Spoke → DRG → Hub VCN → Network Firewall → NAT Gateway → Internet
- Single egress point with firewall policies
- Complete visibility via VCN Flow Logs
NEVER use single-region for production workloads requiring SLA
Region outage = complete downtime. No automatic failover without DR.
Multi-region pattern:
Primary: us-ashburn-1 + DR: us-phoenix-1
- Autonomous Data Guard for database (near-zero RPO)
- Traffic Manager for DNS failover (RTO ~15 minutes)
- Object Storage cross-region replication
- Mirror compartment structure in DR region
Multi-Tenant IAM Decision Tree
Workloads single-tenant?
│
├─ YES → Environment-centric model
│ Compartments: Network, Shared-Services, Workloads/App/Dev-Test-Prod
│ IAM: Per-env groups (DevAdmins, ProdOps) scoped to env compartment
│
└─ NO (Multi-tenant SaaS)?
│
├─ Strict tenant isolation required?
│ ├─ YES → Tenant-per-compartment: Org/TenantA, Org/TenantB
│ │ Dynamic Group per tenant VCN for instance principal auth
│ │ Policy: `allow dynamic-group TenantA-VMs to manage all-resources
│ │ in compartment TenantA`
│ └─ NO → Shared compartment + per-tenant tagging
│ (faster setup, shared blast radius)
│
├─ Multiple environments per tenant?
│ └─ Nest: TenantA/Dev, TenantA/Test, TenantA/Prod
│ Policies inherit down the tree automatically
│
└─ Centralized shared services?
└─ Shared-Services compartment (Logging, Monitoring, Identity)
Grant tenancy-level Ops group least-privileged read access
IAM policy template for multi-tenant:
Allow group TenantA-Admins to manage all-resources in compartment TenantA
Allow dynamic-group TenantA-VCN to manage virtual-network-family in compartment TenantA
Allow group Shared-Network to use virtual-network-family in compartment Shared-Services
Guardrails:
- Never grant tenant-specific policies at root; scope to tenant compartment hierarchy
- Require DRG route approval workflow before adding new tenants
- Refer to
iam-identity-managementskill for fine-grained policy verb syntax
Security Zone Rollout Checklist
- Inventory compartments — export JSON filtered by tag
Environment=Prod - Create/update recipe — clone Oracle CIS recipe, append custom policies (no public LB, require CMEK). See
references/security-zone-automation.md - Apply via CLI/Terraform — loop compartments or use Terraform module
- Detect drift nightly —
oci cloud-guard security-zone list-problems; alert onPROBLEMstate - Rollback procedure — only remove zones with CISO approval; delete recipe only after all zones removed
Full scripts in references/security-zone-automation.md. Treat as MANDATORY for bulk Security Zone changes.
Reference Files
Load references/landing-zone-patterns.md when:
- Choosing compartment hierarchy pattern (workload-centric vs environment-centric vs tenant-centric)
- Designing hub-spoke network topology with DRG
- Setting up tagging strategy and cost allocation across compartments
Load references/landing-zone-cli.md when:
- Creating compartment hierarchies via CLI
- Configuring Security Zones and Cloud Guard in bulk
- Setting up tag defaults and tag namespaces
- Creating budgets with cost tracking
Load references/security-zone-automation.md when (MANDATORY for bulk changes):
- Rolling out or updating Security Zone recipes across multiple compartments
- Remediating drift (compartment lost Security Zone enforcement)
- Writing Terraform automation for Cloud Guard recipes
Load references/oci-well-architected-framework.md when:
- Starting a new landing zone design from scratch
- Preparing architectural review or compliance audit
- Comparing Core Landing Zone vs Operating Entities Landing Zone
- Need official Oracle guidance on all five pillars (Security, Reliability, Performance, Cost, Operations)