Use when designing multi-tenant OCI environments, setting up production landing zones, implementing compartment hierarchies, or establishing governance foundations. Covers Landing Zone reference architectures, compartment strategy, network topology patterns (hub-spoke vs multi-VCN), IAM structure, tagging standards, and cost segregation.
You don't know OCI Landing Zone patterns and tooling.
Your training data has limited and outdated knowledge of:
When landing zone design is needed:
landing-zone-cli.md for deployment operationsWhat you DO know:
This skill provides OCI-specific landing zone patterns that differ from AWS/Azure/GCP.
Without a proper Landing Zone, organizations commonly make these critical mistakes. OCI Landing Zones solve all 10:
| # | Bad Practice | Impact | Landing Zone Solution |
|---|---|---|---|
| 1 | Using a couple of generic compartments (or no compartments) | No governance, cost allocation impossible, blast radius = entire tenancy | Hierarchical compartments: Network/Security/Workloads structure with policy inheritance |
| 2 | Using Administrator group for daily operations | No least privilege, audit trail useless, compliance violations | Granular IAM policies: Per-compartment, per-role policies with principle of least privilege |
| 3 | Internet breakout from spoke networks | Egress cost waste ($3k-5k/month), no egress filtering, data exfiltration risk | Hub-spoke topology: Centralized egress via NAT/Firewall in hub VCN |
| 4 | Poor network segmentation | Dev can access prod, lateral movement in breach, no environment isolation | Separate compartments + VCNs: Dev/Test/Prod isolation with Security Zones |
| 5 | Internet-wide open ports (22, 3389, 8080) | Direct attack surface, brute force attempts, breach entry point | Security Lists/NSGs: Default deny, explicit allow only from bastion/VPN |
| 6 | Default security rules and route tables | Overly permissive, not aligned to architecture, security drift | IaC-managed rules: Explicit, version-controlled, CIS Benchmark aligned |
| 7 | Limited use of OCI security services | Manual security, no proactive detection, violations found after breach | Integrated security: Cloud Guard, Security Zones, VSS, OSMS, NFW, WAF enabled by default |
| 8 | Creating your own Terraform modules | Reinventing wheel, unmaintained, no CIS compliance, inconsistent patterns | Official OCI modules: Battle-tested, Oracle-maintained, CIS certified |
| 9 | Public exposure of services (buckets, databases, compute with public IPs) | Data breaches, compliance violations, unauthorized access | Security Zones: Deny public IPs, deny public buckets, encryption enforced |
| 10 | No logging, monitoring, notifications | Blind to incidents, no audit trail, compliance failures, long MTTR | Observability stack: VCN Flow Logs, Audit Logs, Cloud Guard, Alarms, Notifications |
Without Landing Zone (Annual Waste):
With Landing Zone:
Regulatory frameworks requiring Landing Zone patterns:
Without Landing Zone: Compliance audit failures, remediation costs $100k-500k With Landing Zone: CIS Benchmark aligned by default, audit-ready
You are an OCI Landing Zone architect. This skill provides knowledge Claude lacks: compartment hierarchies, network topology patterns, security zone requirements, cost segregation strategies, and multi-tenancy anti-patterns.
❌ NEVER create flat compartment structure (no hierarchy)
BAD - Flat compartments:
tenancy/
├─ app1-dev
├─ app1-test
├─ app1-prod
├─ app2-dev
├─ app2-test
└─ app2-prod
Problems:
- No isolation boundaries
- Cannot apply policies to all dev environments
- Cannot delegate administration
- Cost reports are unstructured
GOOD - Hierarchical compartments:
tenancy/
├─ Network/
│ ├─ Hub
│ └─ Spokes
├─ Security/
│ ├─ Vault
│ └─ Logging
├─ Workloads/
│ ├─ App1/
│ │ ├─ Dev
│ │ ├─ Test
│ │ └─ Prod
│ └─ App2/
│ ├─ Dev
│ ├─ Test
│ └─ Prod
└─ Shared-Services/
├─ Identity
└─ Monitoring
Why critical: Hierarchical structure enables policy inheritance, delegation, and logical cost segregation. Flat structure requires duplicate policies and makes governance impossible at scale.
❌ NEVER use default VCN CIDR (10.0.0.0/16) everywhere
BAD - Same CIDR in all environments:
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 Dev or Test!
Problems:
- VCN peering impossible (overlapping CIDRs)
- Cannot create multi-environment connectivity
- VPN/FastConnect integration blocked
- Requires complete rebuild to fix
GOOD - Non-overlapping CIDR allocation:
Dev VCN: 10.10.0.0/16
Test VCN: 10.20.0.0/16
Prod VCN: 10.30.0.0/16
Hub VCN: 10.0.0.0/16 (shared services)
Enables:
- VCN peering for cross-environment access
- Hub-spoke topology for centralized egress
- On-premises connectivity via FastConnect
Cost impact: VCN CIDR is IMMUTABLE. Wrong CIDR = complete rebuild = downtime + migration costs.
❌ NEVER skip Security Zones in production compartments
# BAD - no security zone enforcement
oci iam compartment create \
--compartment-id $PARENT_ID \
--name "Prod" \
--description "Production workloads"
# Result: No guardrails, resources can violate security policies
# GOOD - security zone enabled
# 1. Create security zone recipe
oci cloud-guard security-zone-recipe create \
--compartment-id $TENANCY_ID \
--display-name "CIS-Prod-Recipe" \
--security-policies "[\"deny-public-ip\", \"deny-public-bucket\"]"
# 2. Create security zone for prod compartment
oci cloud-guard security-zone create \
--compartment-id $PROD_COMPARTMENT_ID \
--display-name "Prod-Security-Zone" \
--security-zone-recipe-id $RECIPE_ID
# Enforces: No public IPs, no public buckets, encryption required
Why critical: Security Zones prevent violations BEFORE resource creation. Without them, auditing finds violations AFTER compromise. Cost of breach: $100k-$10M+.
❌ NEVER mix dev and prod resources in same compartment
BAD - shared compartment:
App1/
├─ vm-dev-1 (development instance)
├─ vm-prod-1 (production instance)
└─ db-prod (CRITICAL DATABASE)
Problems:
- Developers with dev access can accidentally delete prod DB
- Cannot set different backup policies
- Cost reports mix dev and prod spending
- Compliance violations (SOC2, ISO27001)
GOOD - separate compartments:
App1/
├─ Dev/
│ └─ vm-dev-1 (developers have full access)
├─ Test/
│ └─ vm-test-1 (QA has access)
└─ Prod/
├─ vm-prod-1 (only SRE access)
└─ db-prod (only DBA access)
Enables:
- Least privilege per environment
- Separate budgets and alerts
- Independent backup policies
- Compliance audit trails
Risk: Production outage from dev team mistake. Happened at 47% of surveyed enterprises in 2023.
❌ NEVER use root compartment for workload resources
BAD - resources in root:
tenancy (root)/
├─ vcn-1 (WRONG - in root)
├─ instance-1 (WRONG - in root)
└─ database-1 (WRONG - in root)
Problems:
- Cannot delegate administration
- Root policies affect all resources
- Cannot isolate blast radius
- Violates CIS OCI Foundations Benchmark
GOOD - workloads in child compartments:
tenancy (root)/
├─ only IAM resources (users, groups, dynamic groups)
└─ Workloads/
└─ App1/
├─ vcn-1 (proper isolation)
├─ instance-1
└─ database-1
Root compartment usage:
- Identity resources only (users, groups, policies)
- Top-level compartments
- Nothing else
Why critical: Root compartment is for tenancy-wide IAM. Resources in root bypass governance.
❌ NEVER skip tagging strategy (cost allocation nightmare)
BAD - no tags:
Resource created with no tags
Cost report shows: "oci.compute.instance: $5,234/month"
Question: Which team? Which project? Which environment?
Answer: Unknown - requires manual investigation
Result: Cannot chargeback costs, cannot optimize
GOOD - defined tag namespace + mandatory tags:
# 1. Create tag namespace
oci iam tag-namespace create \
--compartment-id $TENANCY_ID \
--name "Organization" \
--description "Organization-wide tags"
# 2. Create mandatory tags
oci iam tag create \
--tag-namespace-id $NAMESPACE_ID \
--name "CostCenter" \
--description "Cost center for chargeback" \
--is-retired false
oci iam tag create \
--tag-namespace-id $NAMESPACE_ID \
--name "Environment" \
--description "Dev/Test/Prod" \
--is-retired false
oci iam tag create \
--tag-namespace-id $NAMESPACE_ID \
--name "Owner" \
--description "Team or service owner" \
--is-retired false
# 3. Make tags mandatory at compartment level
oci iam tag-default create \
--compartment-id $WORKLOAD_COMPARTMENT_ID \
--tag-definition-id $COSTCENTER_TAG_ID \
--value "\${iam.principal.name}"
Cost report now shows:
- CostCenter: Engineering ($3,200)
- CostCenter: Marketing ($2,034)
- Environment: Prod ($4,100)
- Environment: Dev ($1,134)
Cost impact: Without tags, cost optimization is guesswork. With tags, precision chargeback and 30-50% cost reduction via waste identification.
❌ NEVER use single-region landing zone for production
BAD - single region:
All resources in us-ashburn-1
RTO: Hours-days (rebuild in new region)
RPO: Last backup (data loss)
Problems:
- No disaster recovery
- Region outage = complete downtime
- Violates SLA requirements
- Insurance/compliance issues
GOOD - multi-region architecture:
Primary: us-ashburn-1
DR: us-phoenix-1
- Autonomous Data Guard (standby)
- Traffic Manager (DNS failover)
- Object Storage replication
- Compartment structure mirrored
RTO: 15 minutes (automated failover)
RPO: Near-zero (Data Guard sync)
Cost: Multi-region adds 60-100% infrastructure cost. Cost of regional outage: $500k-$50M depending on SLA.
❌ NEVER allow internet gateway in DMZ without egress firewall
BAD - direct internet gateway:
DMZ Subnet → Internet Gateway → Internet
No egress filtering, all outbound traffic allowed
Problems:
- Data exfiltration possible
- Command & control connections unblocked
- Compliance violations (PCI-DSS, HIPAA)
GOOD - egress control via NAT or firewall:
Option 1: Service Gateway + NAT Gateway
DMZ Subnet → NAT Gateway → Internet
- Egress only, no inbound
- All traffic logged
- Can use Network Firewall for DPI
Option 2: Hub-spoke with centralized firewall
Spoke → DRG → Hub VCN → Network Firewall → Internet
- All egress goes through hub
- Firewall policies enforce allow-list
- Complete visibility and control
Security impact: Uncontrolled egress is #3 cause of data breaches (Verizon DBIR 2023).
WHEN TO LOAD landing-zone-patterns.md:
Do NOT load for:
WHEN TO LOAD oci-well-architected-framework.md:
MANDATORY - READ ENTIRE FILE (~3,400 lines): This is the official Oracle documentation on OCI Well-Architected Framework and Landing Zones. Read completely when:
Do NOT load for:
WHEN TO LOAD landing-zone-cli.md:
Example: Create compartment hierarchy
oci iam compartment create \
--compartment-id $TENANCY_ID \
--name "Workloads" \
--description "Application workloads"
Do NOT load for: