landing-zones

You don't know OCI Landing Zone patterns and tooling.

Your training data has limited and outdated knowledge of:

• OCI Landing Zone reference architectures (updated quarterly)
• Resource Manager stacks for landing zones
• Compartment design patterns and governance
• Security Zones and CIS Foundation compliance
• Multi-tenancy patterns (SaaS, multi-environment)
• Landing Zone Terraform modules and best practices

When landing zone design is needed:

1. Use patterns and CLI commands from this skill's references
2. Do NOT guess compartment hierarchies or network topologies
3. Do NOT assume IAM policy structures
4. Load [landing-zone-cli.md](references/landing-zone-cli.md) for deployment operations

What you DO know:

• General cloud architecture concepts
• Networking principles (subnets, routing, firewalls)
• IAM concepts (users, groups, policies)

This skill provides OCI-specific landing zone patterns that differ from AWS/Azure/GCP.

---

Why Landing Zones Matter

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 |

Cost Impact: With vs Without Landing Zone

Without Landing Zone (Annual Waste):

• Egress via IG instead of SG: $36k-52k/year
• Flat compartments (no optimization): $50k-100k/year (cannot identify waste)
• No Security Zones (breach): $100k-$10M+ (average breach cost)
• Manual Terraform maintenance: $50k-100k/year (engineer time)
• Total avoidable cost: $236k-$10.2M+/year

With Landing Zone:

• One-time setup: $10k-30k (mostly planning/design)
• Annual maintenance: $5k-10k (Terraform updates)
• ROI: 10x-100x+ in first year

Compliance Impact

Regulatory frameworks requiring Landing Zone patterns:

• PCI-DSS: Network segmentation (#1, #3, #4, #5)
• HIPAA: Encryption, logging, access controls (#7, #9, #10)
• SOC 2: Least privilege, monitoring, change management (#2, #6, #10)
• ISO 27001: Information security controls (all 10)
• CIS OCI Foundations: 100+ controls (Landing Zone implements 80%+)

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

```bash

# 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).

Landing Zone Architecture Patterns

WHEN TO LOAD [landing-zone-patterns.md](references/landing-zone-patterns.md):

• Designing hub-spoke network topology
• Choosing compartment hierarchy pattern (workload-centric vs environment-centric vs tenant-centric)
• Implementing Security Zones and Cloud Guard integration
• Setting up tagging strategy and cost allocation
• Designing network topology (single VCN vs hub-spoke vs multi-region)

Do NOT load for:

• Quick anti-pattern reference (NEVER list above covers it)
• Understanding Top 10 Bad Practices (covered in this skill)
• CLI commands (use landing-zone-cli.md instead)

---

OCI Well-Architected Framework (Official Oracle Documentation)

WHEN TO LOAD [oci-well-architected-framework.md](references/oci-well-architected-framework.md):

• Need comprehensive understanding of Landing Zone design principles
• Designing production-grade landing zones from scratch
• Understanding Security & Compliance pillar (IAM, encryption, monitoring)
• Understanding Reliability & Resilience pillar (HA, DR, fault tolerance)
• Understanding Performance Efficiency & Cost Optimization pillar
• Understanding Operational Efficiency pillar (IaC, automation, scalability)
• Comparing Core Landing Zone vs Operating Entities Landing Zone
• Need official Oracle guidance on multi-region deployment

MANDATORY - READ ENTIRE FILE (~3,400 lines): This is the official Oracle documentation on OCI Well-Architected Framework and Landing Zones. Read completely when:

• Starting a new landing zone design project
• Preparing architectural review or compliance audit
• Need to justify Landing Zone decisions to stakeholders

Do NOT load for:

• Quick CLI commands (use landing-zone-cli.md instead)
• Specific implementation steps (covered in this skill's decision trees)

---

OCI CLI for Landing Zones

WHEN TO LOAD [landing-zone-cli.md](references/landing-zone-cli.md):

• Creating compartment hierarchies
• Setting up Security Zones and Cloud Guard
• Configuring tag defaults and tag namespaces
• Implementing hub-spoke network topology
• Creating budgets and cost tracking

Example: Create compartment hierarchy

```bash

oci iam compartment create \

--compartment-id $TENANCY_ID \

--name "Workloads" \

--description "Application workloads"

```

Do NOT load for:

• General OCI architecture concepts (covered in this skill)
• IAM policy syntax (covered in iam-identity-management skill)
• Network configuration (covered in networking-management skill)
• Official Oracle documentation (use oci-well-architected-framework.md instead)

• Initial OCI tenancy setup and foundation
• Migrating from AWS/Azure/GCP to OCI
• Designing multi-tenant or multi-environment architectures
• Implementing governance and cost controls
• Preparing for compliance audits (CIS, SOC2, ISO27001)
• Scaling from single app to enterprise platform
• Disaster recovery and multi-region planning