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:

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

OCI CLI for Landing Zone Operations

Complete OCI CLI commands for deploying and managing landing zones.

Prerequisites

# Verify OCI CLI and authentication
oci --version
oci iam region list --output table

# Get tenancy OCID (needed for root compartment operations)
export TENANCY_ID=$(oci iam compartment list --all \
  --compartment-id-in-subtree true \
  --access-level ACCESSIBLE \
  --include-root \
  --query "data[?name=='root'].id | [0]" \
  --raw-output)

echo "Tenancy ID: $TENANCY_ID"

Compartment Management

Create Compartment Hierarchy

# 1. Create top-level compartments
NETWORK_CMP=$(oci iam compartment create \
  --compartment-id $TENANCY_ID \
  --name "Network" \
  --description "Network resources and topology" \
  --query 'data.id' --raw-output)

SECURITY_CMP=$(oci iam compartment create \
  --compartment-id $TENANCY_ID \
  --name "Security" \
  --description "Security services" \
  --query 'data.id' --raw-output)

WORKLOADS_CMP=$(oci iam compartment create \
  --compartment-id $TENANCY_ID \
  --name "Workloads" \
  --description "Application workloads" \
  --query 'data.id' --raw-output)

SHARED_CMP=$(oci iam compartment create \
  --compartment-id $TENANCY_ID \
  --name "Shared-Services" \
  --description "Shared platform services" \
  --query 'data.id' --raw-output)

# 2. Create Network sub-compartments
HUB_CMP=$(oci iam compartment create \
  --compartment-id $NETWORK_CMP \
  --name "Hub" \
  --description "Hub VCN for centralized services" \
  --query 'data.id' --raw-output)

SPOKES_CMP=$(oci iam compartment create \
  --compartment-id $NETWORK_CMP \
  --name "Spokes" \
  --description "Spoke VCNs for workloads" \
  --query 'data.id' --raw-output)

# 3. Create Workload compartments
APP1_CMP=$(oci iam compartment create \
  --compartment-id $WORKLOADS_CMP \
  --name "App1" \
  --description "Application 1" \
  --query 'data.id' --raw-output)

# 4. Create environment compartments under App1
APP1_DEV_CMP=$(oci iam compartment create \
  --compartment-id $APP1_CMP \
  --name "Dev" \
  --description "Development environment" \
  --query 'data.id' --raw-output)

APP1_TEST_CMP=$(oci iam compartment create \
  --compartment-id $APP1_CMP \
  --name "Test" \
  --description "Test environment" \
  --query 'data.id' --raw-output)

APP1_PROD_CMP=$(oci iam compartment create \
  --compartment-id $APP1_CMP \
  --name "Prod" \
  --description "Production environment" \
  --query 'data.id' --raw-output)

List Compartment Hierarchy

# List all compartments with hierarchy
oci iam compartment list \
  --compartment-id $TENANCY_ID \
  --compartment-id-in-subtree true \
  --access-level ACCESSIBLE \
  --all \
  --output table

# Get compartment OCID by name
oci iam compartment list \
  --compartment-id $TENANCY_ID \
  --name "Prod" \
  --compartment-id-in-subtree true \
  --query 'data[0].id' \
  --raw-output

Move Resources Between Compartments

# Move compute instance to different compartment
oci compute instance change-compartment \
  --instance-id ocid1.instance.oc1..xxx \
  --compartment-id $APP1_PROD_CMP

# Move VCN to different compartment
oci network vcn change-compartment \
  --vcn-id ocid1.vcn.oc1..xxx \
  --compartment-id $NETWORK_CMP

Tag Namespace and Defaults

Create Tag Namespace

# Create organization tag namespace
TAG_NAMESPACE=$(oci iam tag-namespace create \
  --compartment-id $TENANCY_ID \
  --name "Organization" \
  --description "Organization-wide required tags" \
  --query 'data.id' --raw-output)

echo "Tag Namespace ID: $TAG_NAMESPACE"

Create Tag Definitions

# CostCenter tag (mandatory)
COSTCENTER_TAG=$(oci iam tag create \
  --tag-namespace-id $TAG_NAMESPACE \
  --name "CostCenter" \
  --description "Cost center for chargeback" \
  --is-retired false \
  --query 'data.id' --raw-output)

# Environment tag (mandatory, enum)
ENVIRONMENT_TAG=$(oci iam tag create \
  --tag-namespace-id $TAG_NAMESPACE \
  --name "Environment" \
  --description "Environment type" \
  --is-retired false \
  --validator '{
    "validatorType": "ENUM",
    "values": ["Dev", "Test", "Prod", "Sandbox"]
  }' \
  --query 'data.id' --raw-output)

# Owner tag (mandatory)
OWNER_TAG=$(oci iam tag create \
  --tag-namespace-id $TAG_NAMESPACE \
  --name "Owner" \
  --description "Resource owner email or team" \
  --is-retired false \
  --query 'data.id' --raw-output)

# DataClassification tag
DATACLASS_TAG=$(oci iam tag create \
  --tag-namespace-id $TAG_NAMESPACE \
  --name "DataClassification" \
  --description "Data sensitivity classification" \
  --is-retired false \
  --validator '{
    "validatorType": "ENUM",
    "values": ["Public", "Internal", "Confidential", "Restricted"]
  }' \
  --query 'data.id' --raw-output)

# BackupPolicy tag
BACKUP_TAG=$(oci iam tag create \
  --tag-namespace-id $TAG_NAMESPACE \
  --name "BackupPolicy" \
  --description "Backup retention policy" \
  --is-retired false \
  --validator '{
    "validatorType": "ENUM",
    "values": ["None", "Bronze", "Silver", "Gold"]
  }' \
  --query 'data.id' --raw-output)

Set Tag Defaults (Auto-apply Tags)

# Make Environment=Prod default in Prod compartment
oci iam tag-default create \
  --compartment-id $APP1_PROD_CMP \
  --tag-definition-id $ENVIRONMENT_TAG \
  --value "Prod"

# Make Environment=Dev default in Dev compartment
oci iam tag-default create \
  --compartment-id $APP1_DEV_CMP \
  --tag-definition-id $ENVIRONMENT_TAG \
  --value "Dev"

# Make Owner default to creator's username
oci iam tag-default create \
  --compartment-id $WORKLOADS_CMP \
  --tag-definition-id $OWNER_TAG \
  --value "\${iam.principal.name}"

# Make DataClassification=Internal default
oci iam tag-default create \
  --compartment-id $WORKLOADS_CMP \
  --tag-definition-id $DATACLASS_TAG \
  --value "Internal"

List Tags

# List all tag namespaces
oci iam tag-namespace list \
  --compartment-id $TENANCY_ID \
  --all \
  --output table

# List tags in namespace
oci iam tag list \
  --tag-namespace-id $TAG_NAMESPACE \
  --all \
  --output table

Security Zones

Create Security Zone Recipe

# Create CIS Foundation recipe
CIS_RECIPE=$(oci cloud-guard security-zone-recipe create \
  --compartment-id $TENANCY_ID \
  --display-name "CIS-Foundation-Recipe" \
  --description "CIS OCI Foundations Benchmark security policies" \
  --security-policies '["deny-public-ip-on-compute", "deny-public-bucket", "require-boot-volume-backup", "require-block-volume-backup"]' \
  --query 'data.id' --raw-output)

# Create production-specific recipe (stricter)
PROD_RECIPE=$(oci cloud-guard security-zone-recipe create \
  --compartment-id $TENANCY_ID \
  --display-name "Production-Recipe" \
  --description "Production security requirements" \
  --security-policies '["deny-public-ip-on-compute", "deny-public-bucket", "deny-public-lb", "require-encryption-at-rest", "require-encryption-in-transit", "require-boot-volume-backup", "require-block-volume-backup", "deny-internet-gateway-in-private-subnet"]' \
  --query 'data.id' --raw-output)

Apply Security Zone to Compartment

# Apply production recipe to prod compartment
oci cloud-guard security-zone create \
  --compartment-id $APP1_PROD_CMP \
  --display-name "App1-Prod-Security-Zone" \
  --description "Security zone for App1 production" \
  --security-zone-recipe-id $PROD_RECIPE

# Apply CIS recipe to test compartment
oci cloud-guard security-zone create \
  --compartment-id $APP1_TEST_CMP \
  --display-name "App1-Test-Security-Zone" \
  --description "Security zone for App1 test" \
  --security-zone-recipe-id $CIS_RECIPE

List Security Zones

# List all security zones
oci cloud-guard security-zone list \
  --compartment-id $TENANCY_ID \
  --compartment-id-in-subtree true \
  --all \
  --output table

# Get security zone details
oci cloud-guard security-zone get \
  --security-zone-id ocid1.securityzone.oc1..xxx

Cloud Guard Configuration

Enable Cloud Guard

# Enable Cloud Guard for tenancy
oci cloud-guard configuration update \
  --reporting-region us-ashburn-1 \
  --status ENABLED \
  --self-manage-resources true

# Check Cloud Guard status
oci cloud-guard configuration get

Create Cloud Guard Target

# Create target for workloads compartment
CLOUDGUARD_TARGET=$(oci cloud-guard target create \
  --compartment-id $TENANCY_ID \
  --display-name "Workloads-Target" \
  --description "Cloud Guard monitoring for all workloads" \
  --target-resource-type COMPARTMENT \
  --target-resource-id $WORKLOADS_CMP \
  --target-detector-recipes '[
    {
      "detectorRecipeId": "ocid1.cloudguarddetectorrecipe.oc1..configuration",
      "detector": "IAAS_CONFIGURATION_DETECTOR"
    },
    {
      "detectorRecipeId": "ocid1.cloudguarddetectorrecipe.oc1..activity",
      "detector": "IAAS_ACTIVITY_DETECTOR"
    }
  ]' \
  --query 'data.id' --raw-output)

List Cloud Guard Problems

# List all open problems
oci cloud-guard problem list \
  --compartment-id $TENANCY_ID \
  --compartment-id-in-subtree true \
  --lifecycle-state OPEN \
  --output table

# List problems by risk level
oci cloud-guard problem list \
  --compartment-id $WORKLOADS_CMP \
  --risk-level CRITICAL \
  --output table

Budget Management

Create Budget for Compartment

# Create monthly budget for production
PROD_BUDGET=$(oci budgets budget create \
  --compartment-id $TENANCY_ID \
  --amount 25000 \
  --reset-period MONTHLY \
  --target-type COMPARTMENT \
  --targets "[$APP1_PROD_CMP]" \
  --display-name "App1-Prod-Monthly-Budget" \
  --description "Production environment monthly budget: \$25,000" \
  --query 'data.id' --raw-output)

# Create budget for dev environment (lower threshold)
DEV_BUDGET=$(oci budgets budget create \
  --compartment-id $TENANCY_ID \
  --amount 5000 \
  --reset-period MONTHLY \
  --target-type COMPARTMENT \
  --targets "[$APP1_DEV_CMP]" \
  --display-name "App1-Dev-Monthly-Budget" \
  --description "Dev environment monthly budget: \$5,000" \
  --query 'data.id' --raw-output)

# Create budget for tags (cost center-based)
oci budgets budget create \
  --compartment-id $TENANCY_ID \
  --amount 50000 \
  --reset-period MONTHLY \
  --target-type TAG \
  --targets '["Organization.CostCenter=Engineering"]' \
  --display-name "Engineering-CostCenter-Budget" \
  --description "Engineering cost center budget: \$50,000"

Create Budget Alert Rules

# Alert at 50% threshold
oci budgets alert-rule create \
  --budget-id $PROD_BUDGET \
  --type ACTUAL \
  --threshold 50 \
  --threshold-type PERCENTAGE \
  --display-name "Prod-50%-Warning" \
  --message "Production budget at 50% (\$12,500)" \
  --recipients "sre-team@example.com"

# Alert at 80% threshold
oci budgets alert-rule create \
  --budget-id $PROD_BUDGET \
  --type ACTUAL \
  --threshold 80 \
  --threshold-type PERCENTAGE \
  --display-name "Prod-80%-Critical" \
  --message "Production budget at 80% (\$20,000) - CRITICAL" \
  --recipients "sre-team@example.com,cfo@example.com"

# Alert at 100% threshold
oci budgets alert-rule create \
  --budget-id $PROD_BUDGET \
  --type ACTUAL \
  --threshold 100 \
  --threshold-type PERCENTAGE \
  --display-name "Prod-100%-Exceeded" \
  --message "Production budget EXCEEDED (\$25,000)" \
  --recipients "sre-team@example.com,cfo@example.com,ceo@example.com"

# Forecast alert (predict 100% in current month)
oci budgets alert-rule create \
  --budget-id $PROD_BUDGET \
  --type FORECAST \
  --threshold 100 \
  --threshold-type PERCENTAGE \
  --display-name "Prod-Forecast-100%" \
  --message "Production forecasted to exceed budget this month" \
  --recipients "sre-team@example.com"

List Budgets

# List all budgets
oci budgets budget list \
  --compartment-id $TENANCY_ID \
  --target-type COMPARTMENT \
  --output table

# Get budget utilization
oci budgets budget get \
  --budget-id $PROD_BUDGET

Hub-Spoke Network Topology

Create Hub VCN

# Create Hub VCN in Hub compartment
HUB_VCN=$(oci network vcn create \
  --compartment-id $HUB_CMP \
  --display-name "Hub-VCN" \
  --cidr-blocks '["10.0.0.0/16"]' \
  --dns-label "hub" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

# Create Hub subnets
HUB_PUBLIC_SUBNET=$(oci network subnet create \
  --compartment-id $HUB_CMP \
  --vcn-id $HUB_VCN \
  --display-name "Hub-Public-Subnet" \
  --cidr-block "10.0.1.0/24" \
  --prohibit-public-ip-on-vnic false \
  --dns-label "hubpub" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

HUB_PRIVATE_SUBNET=$(oci network subnet create \
  --compartment-id $HUB_CMP \
  --vcn-id $HUB_VCN \
  --display-name "Hub-Private-Subnet" \
  --cidr-block "10.0.2.0/24" \
  --prohibit-public-ip-on-vnic true \
  --dns-label "hubpriv" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

Create DRG (Dynamic Routing Gateway)

# Create DRG for hub-spoke connectivity
DRG=$(oci network drg create \
  --compartment-id $NETWORK_CMP \
  --display-name "Hub-Spoke-DRG" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

# Attach Hub VCN to DRG
HUB_DRG_ATTACHMENT=$(oci network drg-attachment create \
  --drg-id $DRG \
  --display-name "Hub-VCN-Attachment" \
  --vcn-id $HUB_VCN \
  --wait-for-state ATTACHED \
  --query 'data.id' --raw-output)

Create Spoke VCNs

# Create Spoke VCN for App1 Prod
SPOKE1_VCN=$(oci network vcn create \
  --compartment-id $SPOKES_CMP \
  --display-name "Spoke-App1-Prod-VCN" \
  --cidr-blocks '["10.10.0.0/16"]' \
  --dns-label "app1prod" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

# Attach Spoke1 to DRG
SPOKE1_DRG_ATTACHMENT=$(oci network drg-attachment create \
  --drg-id $DRG \
  --display-name "Spoke-App1-Prod-Attachment" \
  --vcn-id $SPOKE1_VCN \
  --wait-for-state ATTACHED \
  --query 'data.id' --raw-output)

# Create Spoke VCN for App1 Dev
SPOKE2_VCN=$(oci network vcn create \
  --compartment-id $SPOKES_CMP \
  --display-name "Spoke-App1-Dev-VCN" \
  --cidr-blocks '["10.11.0.0/16"]' \
  --dns-label "app1dev" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

# Attach Spoke2 to DRG
SPOKE2_DRG_ATTACHMENT=$(oci network drg-attachment create \
  --drg-id $DRG \
  --display-name "Spoke-App1-Dev-Attachment" \
  --vcn-id $SPOKE2_VCN \
  --wait-for-state ATTACHED \
  --query 'data.id' --raw-output)

Configure Hub NAT Gateway (Shared Egress)

# Create NAT Gateway in Hub VCN
HUB_NAT=$(oci network nat-gateway create \
  --compartment-id $HUB_CMP \
  --vcn-id $HUB_VCN \
  --display-name "Hub-NAT-Gateway" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

# Create Service Gateway in Hub VCN (free egress to OCI services)
HUB_SGW=$(oci network service-gateway create \
  --compartment-id $HUB_CMP \
  --vcn-id $HUB_VCN \
  --services '[{"serviceId": "ocid1.service.oc1.iad.xxx"}]' \
  --display-name "Hub-Service-Gateway" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

# Get default route table for Hub VCN
HUB_RT=$(oci network vcn get \
  --vcn-id $HUB_VCN \
  --query 'data["default-route-table-id"]' \
  --raw-output)

# Add route to NAT Gateway for internet egress
oci network route-table update \
  --rt-id $HUB_RT \
  --route-rules '[
    {
      "destination": "0.0.0.0/0",
      "destinationType": "CIDR_BLOCK",
      "networkEntityId": "'$HUB_NAT'"
    },
    {
      "destination": "all-iad-services-in-oracle-services-network",
      "destinationType": "SERVICE_CIDR_BLOCK",
      "networkEntityId": "'$HUB_SGW'"
    }
  ]' \
  --force

Configure DRG Route Tables (Spoke-to-Hub Routing)

# Get DRG route table ID
DRG_RT=$(oci network drg list-drg-route-tables \
  --drg-id $DRG \
  --query 'data[0].id' \
  --raw-output)

# Add route distribution to allow spokes to reach hub
oci network drg-route-distribution create \
  --drg-id $DRG \
  --distribution-type IMPORT \
  --display-name "Import-All-VCN-Routes"

Resource Manager Stacks

Upload Landing Zone Terraform Configuration

# Create ZIP file with Terraform configs
cd landing-zone-terraform/
zip -r ../landing-zone.zip ./*
cd ..

# Create Resource Manager stack
STACK=$(oci resource-manager stack create \
  --compartment-id $TENANCY_ID \
  --display-name "OCI-Landing-Zone-Stack" \
  --description "Complete landing zone deployment" \
  --config-source-type ZIP_UPLOAD \
  --zip-file-base64 "$(base64 landing-zone.zip)" \
  --variables '{
    "tenancy_ocid": "'$TENANCY_ID'",
    "region": "us-ashburn-1",
    "compartment_hierarchy": true,
    "security_zones_enabled": true,
    "hub_spoke_topology": true
  }' \
  --wait-for-state SUCCEEDED \
  --query 'data.id' --raw-output)

# Plan the stack
PLAN_JOB=$(oci resource-manager job create-plan-job \
  --stack-id $STACK \
  --wait-for-state SUCCEEDED \
  --query 'data.id' --raw-output)

# Apply the stack
APPLY_JOB=$(oci resource-manager job create-apply-job \
  --stack-id $STACK \
  --execution-plan-strategy AUTO_APPROVED \
  --wait-for-state SUCCEEDED \
  --query 'data.id' --raw-output)

# Get outputs
oci resource-manager stack get-stack-tf-state \
  --stack-id $STACK \
  --file stack-outputs.tfstate

Multi-Region Setup

Create DR Region Landing Zone

# Set DR region
export OCI_CLI_REGION=us-phoenix-1

# Create same compartment hierarchy in DR region
# (Compartments are global, but resources are regional)

# Create DR Hub VCN
DR_HUB_VCN=$(oci network vcn create \
  --compartment-id $HUB_CMP \
  --display-name "Hub-VCN-DR" \
  --cidr-blocks '["10.100.0.0/16"]' \
  --dns-label "hubdr" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

# Create DR DRG
DR_DRG=$(oci network drg create \
  --compartment-id $NETWORK_CMP \
  --display-name "Hub-Spoke-DRG-DR" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

# Create Remote Peering Connection (primary to DR)
export OCI_CLI_REGION=us-ashburn-1
PRIMARY_RPC=$(oci network remote-peering-connection create \
  --compartment-id $NETWORK_CMP \
  --drg-id $DRG \
  --display-name "Primary-to-DR-RPC" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

export OCI_CLI_REGION=us-phoenix-1
DR_RPC=$(oci network remote-peering-connection create \
  --compartment-id $NETWORK_CMP \
  --drg-id $DR_DRG \
  --display-name "DR-to-Primary-RPC" \
  --wait-for-state AVAILABLE \
  --query 'data.id' --raw-output)

# Connect the peering
oci network remote-peering-connection connect \
  --remote-peering-connection-id $DR_RPC \
  --peer-id $PRIMARY_RPC \
  --peer-region-name us-ashburn-1

Validation and Reporting

List All Landing Zone Resources

# List compartments
oci iam compartment list \
  --compartment-id $TENANCY_ID \
  --compartment-id-in-subtree true \
  --all \
  --output table

# List VCNs across all compartments
oci network vcn list \
  --compartment-id $TENANCY_ID \
  --all \
  --output table

# List Security Zones
oci cloud-guard security-zone list \
  --compartment-id $TENANCY_ID \
  --compartment-id-in-subtree true \
  --all \
  --output table

# List Budgets
oci budgets budget list \
  --compartment-id $TENANCY_ID \
  --output table

Generate Cost Report by Compartment

# Get usage data for compartment
oci usage-api usage summarized-usage get \
  --tenant-id $TENANCY_ID \
  --time-usage-started "2026-01-01T00:00:00Z" \
  --time-usage-ended "2026-01-31T23:59:59Z" \
  --granularity MONTHLY \
  --query-type COST \
  --group-by "[\"compartmentPath\"]" \
  --output json | jq '.data.items[] | {
    compartment: .tags["Oracle-Tags"]["CreatedBy"],
    cost: .["computed-amount"]
  }'

Best Practices

Always Use --wait-for-state

# ✅ GOOD - waits for compartment to be active
oci iam compartment create \
  --compartment-id $TENANCY_ID \
  --name "Prod" \
  --wait-for-state ACTIVE

# ❌ BAD - returns immediately, compartment may not be ready
oci iam compartment create \
  --compartment-id $TENANCY_ID \
  --name "Prod"

Use Environment Variables for OCIDs

# ✅ GOOD - reusable, maintainable
PROD_CMP=$(oci iam compartment create ... --query 'data.id' --raw-output)
oci network vcn create --compartment-id $PROD_CMP

# ❌ BAD - error-prone
oci network vcn create --compartment-id ocid1.compartment.oc1..xxx

Document CIDR Allocations

# Maintain CIDR allocation table
cat > cidr-allocation.txt <<EOF
Hub VCN: 10.0.0.0/16
Spoke-App1-Prod: 10.10.0.0/16
Spoke-App1-Test: 10.20.0.0/16
Spoke-App1-Dev: 10.30.0.0/16
Spoke-App2-Prod: 10.40.0.0/16
On-premises: 172.16.0.0/12
Reserved-Future: 10.50.0.0/16 - 10.99.0.0/16
EOF

# Check for overlaps before creating VCN
grep "10.10.0.0" cidr-allocation.txt

When to Use Landing Zone CLI

Use these commands when you need to:

• Set up initial OCI tenancy structure
• Create compartment hierarchies
• Implement Security Zones and Cloud Guard
• Configure tagging strategy
• Deploy hub-spoke network topology
• Create budgets and cost controls
• Implement multi-region DR

Don't use for:

• Individual resource creation (covered in service-specific skills)
• Day-to-day operations (use service-specific CLIs)
• Troubleshooting (covered in other skills)

OCI Landing Zone Patterns Reference

Landing Zone Topology Patterns

Pattern 1: Hub-Spoke Topology (Recommended for Multi-Tenancy)

                    ┌─────────────────────────┐
                    │   Hub VCN (10.0.0.0/16) │
                    │                         │
                    │  - Network Firewall     │
                    │  - NAT Gateway          │
                    │  - Service Gateway      │
                    │  - DRG (on-prem)        │
                    └────────────┬────────────┘
                                 │
                                DRG
                    ┌────────────┼────────────┐
                    │            │            │
        ┌───────────▼──┐  ┌──────▼─────┐  ┌──▼───────────┐
        │ Spoke 1 VCN  │  │ Spoke 2 VCN│  │ Spoke 3 VCN  │
        │ App1-Prod    │  │ App2-Prod  │  │ Shared-Svcs  │
        │ 10.10.0.0/16 │  │ 10.20.0.0/16│ │ 10.30.0.0/16 │
        └──────────────┘  └────────────┘  └──────────────┘

Benefits:
- Centralized egress control (cost + security)
- Spoke isolation (network segmentation)
- Shared services (DNS, monitoring, bastion)
- Transitive routing via DRG

Cost savings: $3,000-5,000/month via single NAT Gateway vs per-VCN

Pattern 2: Multi-Compartment Hierarchy

Tenancy (Root)
│
├─ Network [Network admins only]
│   ├─ Hub
│   └─ Spokes
│
├─ Security [Security team only]
│   ├─ Vault (keys, secrets)
│   ├─ Bastion
│   └─ Logging (audit logs, flow logs)
│
├─ Workloads [Application teams]
│   ├─ App1
│   │   ├─ Dev [Developers full access]
│   │   ├─ Test [QA full access]
│   │   └─ Prod [SRE read, operators limited write]
│   │
│   └─ App2
│       ├─ Dev
│       ├─ Test
│       └─ Prod
│
├─ Shared-Services [Platform team]
│   ├─ Identity (IDCS, federation)
│   ├─ Monitoring (APM, Logging Analytics)
│   └─ DevOps (CI/CD, artifact registry)
│
└─ Sandbox [Developers experiment, auto-delete after 30 days]
    ├─ User1-Sandbox
    └─ User2-Sandbox

Policy inheritance:
- Network policies apply to Hub + Spokes
- Workload policies apply to all App environments
- Sandbox policies enforce auto-cleanup

Pattern 3: Security Zones & Cloud Guard Integration

Compartment: Prod
│
├─ Security Zone Recipe: CIS-Level-1
│   ├─ deny-public-ip-on-compute
│   ├─ deny-public-bucket
│   ├─ require-encryption-at-rest
│   ├─ require-encryption-in-transit
│   └─ deny-internet-gateway-in-private-subnet
│
├─ Cloud Guard Target
│   ├─ Detector: Configuration issues
│   ├─ Detector: Activity anomalies
│   └─ Responder: Auto-remediate violations
│
└─ Resources
    ├─ Compute: Public IP blocked ✓
    ├─ Object Storage: Private only ✓
    ├─ ADB: TDE enabled ✓
    └─ Load Balancer: SSL enforced ✓

Result: Security violations prevented at creation time, not detected after

Compartment Design Decision Tree

"How should I structure compartments?"
│
├─ Single application, simple lifecycle?
│   └─ Pattern: Workload-centric
│       Workloads/
│         └─ MyApp/
│             ├─ Dev
│             ├─ Test
│             └─ Prod
│
├─ Multiple applications, shared platform?
│   └─ Pattern: Environment-centric
│       Workloads/
│         ├─ Dev/
│         │   ├─ App1
│         │   └─ App2
│         ├─ Test/
│         │   ├─ App1
│         │   └─ App2
│         └─ Prod/
│             ├─ App1
│             └─ App2
│
├─ Multi-tenant SaaS (customers isolated)?
│   └─ Pattern: Tenant-centric
│       Tenants/
│         ├─ Customer-A/
│         │   ├─ Network
│         │   ├─ Compute
│         │   └─ Database
│         └─ Customer-B/
│             ├─ Network
│             ├─ Compute
│             └─ Database
│
└─ Large enterprise, multiple business units?
    └─ Pattern: Business-unit-centric
        BusinessUnits/
          ├─ BU-Engineering/
          │   └─ [Workload-centric per BU]
          ├─ BU-Marketing/
          │   └─ [Workload-centric per BU]
          └─ BU-Sales/
              └─ [Workload-centric per BU]

Key principle: Choose hierarchy that matches org structure + cost allocation

Network Topology Decision Tree

"Which network pattern should I use?"
│
├─ Single application, no shared services?
│   └─ Single VCN
│       Cost: Lowest
│       Complexity: Simplest
│       Use when: Proof of concept, single app
│
├─ Multiple apps, need isolation, shared egress?
│   └─ Hub-Spoke via DRG
│       Cost: $100/month DRG + $45/month NAT (shared)
│       Complexity: Medium
│       Egress savings: $3,000-5,000/month
│       Use when: Multi-app production
│
├─ Multi-region disaster recovery?
│   └─ Hub-Spoke + DRG Remote Peering
│       Primary Region: Hub-Spoke
│       DR Region: Hub-Spoke
│       Cost: +$100/month DRG per region
│       Use when: RTO < 1 hour required
│
└─ On-premises integration?
    └─ Hub-Spoke + FastConnect
        Hub VCN: FastConnect → On-prem
        Spokes: Route via hub
        Cost: $500-2,000/month FastConnect
        Use when: Hybrid cloud architecture

Tagging Strategy

Required Tags (Mandatory)

Tag Namespace: Organization
Tags:
  - CostCenter: [Finance code for chargeback]
    Type: String
    Mandatory: Yes
    Default: None

  - Environment: [Dev | Test | Prod | Sandbox]
    Type: Enum
    Mandatory: Yes
    Default: None

  - Owner: [Email or team name]
    Type: String
    Mandatory: Yes
    Default: ${iam.principal.name}

  - DataClassification: [Public | Internal | Confidential | Restricted]
    Type: Enum
    Mandatory: Yes (for data resources)
    Default: Internal

  - BackupPolicy: [None | Bronze | Silver | Gold]
    Type: Enum
    Mandatory: Yes (for stateful resources)
    Default: Bronze

Optional Tags (Recommended)

  - Project: [Project or product name]
  - ExpiryDate: [Auto-cleanup date for sandbox]
  - Compliance: [PCI | HIPAA | SOC2]
  - ManagedBy: [Terraform | Manual | Ansible]

Cost Allocation Patterns

Budget Hierarchy

Tenancy Budget: $100,000/month
├─ Network: $10,000/month (fixed)
├─ Security: $5,000/month (fixed)
├─ Workloads: $75,000/month
│   ├─ App1-Dev: $5,000/month
│   ├─ App1-Test: $8,000/month
│   ├─ App1-Prod: $25,000/month
│   ├─ App2-Dev: $3,000/month
│   ├─ App2-Test: $4,000/month
│   └─ App2-Prod: $30,000/month
└─ Shared-Services: $10,000/month

Alerts:
- 50% threshold: Warning
- 80% threshold: Critical (page on-call)
- 100% threshold: Auto-stop dev/test resources