landing-zones

What this skill does

# 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`](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.

---

## 🚨 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**
```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/
  ├─