landing-zones

OCI Landing Zones - Expert Architecture

⚠️ OCI Landing Zone Knowledge Gap

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

---

🚨 Top 10 OCI Bad Practices - Solved by Landing Zones

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 Do This

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

Progressive Loading References

Landing Zone Architecture Patterns

WHEN TO LOAD 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:

• 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:

• 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

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)

When to Use This Skill

• 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