Best Practices

OCI Best Practices - Expert Knowledge

🏗️ Use OCI Landing Zone Terraform Modules

Don't reinvent the wheel. Use oracle-terraform-modules/landing-zone for OCI architecture.

Landing Zone solves:

• ❌ Bad Practice #1: Generic compartments (Landing Zone provides hierarchical Network/Security/Workloads structure)
• ❌ Bad Practice #2: Administrator for daily ops (Landing Zone enforces least-privilege IAM policies)
• ❌ Bad Practice #4: Poor network segmentation (Landing Zone implements hub-spoke topology with security zones)
• ❌ Bad Practice #8: Creating your own Terraform modules (Landing Zone provides battle-tested, Oracle-maintained, CIS-certified modules)

This skill provides: OCI-specific anti-patterns, architecture patterns, and operational knowledge for resources deployed WITHIN a Landing Zone.

---

⚠️ OCI CLI/API Knowledge Gap

You don't know OCI CLI commands or OCI API structure.

Your training data has limited and outdated knowledge of:

• OCI CLI syntax and parameters (updates monthly)
• OCI API endpoints and request/response formats
• OCI service-specific commands and flags
• Latest OCI features, limits, and regional availability
• CIS Benchmark requirements for OCI

When OCI operations are needed:

1. Use exact CLI commands from skill references
2. Do NOT guess OCI CLI syntax or parameters
3. Do NOT assume API endpoint structures
4. Reference landing-zones skill for Terraform modules

What you DO know:

• General cloud architecture concepts
• Security principles and compliance frameworks
• Multi-tier application design patterns

This skill bridges the gap by providing current OCI-specific patterns and anti-patterns.

---

You are an OCI architecture expert. This skill provides knowledge Claude lacks: OCI-specific anti-patterns, free tier specifics, terminology gotchas, multi-AD patterns, and differences from AWS/Azure/GCP.

NEVER Do This

❌ NEVER use /24 or smaller VCN CIDR (cannot expand)

# WRONG - VCN too small, cannot expand later (OCI limitation)
oci network vcn create --cidr-block "10.0.0.0/24"
# Only 256 IPs total, exhausted quickly

# WRONG - copying AWS habit (/16 VPC default)
# OCI supports larger: /16 to /30

# RIGHT - start with /16, plan for growth
oci network vcn create --cidr-block "10.0.0.0/16"
# 65,536 IPs, room for 256 /24 subnets

# CRITICAL: OCI VCNs CANNOT be resized after creation
# Must create new VCN and migrate if too small

Migration cost: Recreating VCN = hours of downtime, IP changes, security rule updates

❌ NEVER use AD-specific subnets (breaks multi-AD HA)

# WRONG - subnet tied to single AD
oci network subnet create \
  --vcn-id  \
  --cidr-block "10.0.1.0/24" \
  --availability-domain "fMgC:US-ASHBURN-AD-1"  # AD-specific!

# Problem: Can't launch instances in other ADs, no HA

# RIGHT - regional subnet (works in all ADs)
oci network subnet create \
  --vcn-id  \
  --cidr-block "10.0.1.0/24"
  # No --availability-domain flag = regional
  # Instances can be in any AD in region

Gotcha: Some old OCI guides show AD-specific subnets (deprecated pattern)

❌ NEVER confuse Security Lists vs NSGs (different use cases)

OCI has TWO network security mechanisms:

Security Lists (stateful, subnet-level):
- Applied to ALL resources in subnet
- Use for: Broad rules (internet egress, DNS)
- Limit: 5 per subnet
- Changes: Affect all instances in subnet

Network Security Groups (NSG, resource-level):
- Applied to specific resources
- Use for: Granular rules (app tier → DB tier)
- Limit: 5 per resource, 120 rules per NSG
- Changes: Affect only tagged resources

# WRONG - using Security Lists for app-specific rules
Security List: Allow app-tier → database (applies to ENTIRE subnet)

# RIGHT - use NSG for app-tier resources
NSG "app-tier": Allow egress to NSG "db-tier" on port 1521
# Only instances in app-tier NSG can reach DB

Best practice: Security Lists for baseline (internet, DNS), NSGs for application-specific rules

❌ NEVER assume single-AD deployment is acceptable (no SLA)

OCI Availability Domains (ADs):
- 3 ADs per region (most regions)
- Isolated fault domains
-  \
  --availability-domain "fMgC:US-ASHBURN-AD-1"

Fault Domain Additional Layer

Within each AD, OCI has Fault Domains (FD):

• 3 FDs per AD
• Separate power, cooling, network
• <1ms latency within AD

Best practice: Spread instances across ADs AND FDs

AD-1:
  FD-1: Web instance 1
  FD-2: Web instance 2
  FD-3: Web instance 3

AD-2:
  FD-1: Web instance 4
  (repeat pattern)

Protection:
- AD failure: 2 ADs survive (66% capacity)
- FD failure: Only 1 instance affected (16% capacity)

When to use FDs: Only for extra-critical apps (adds complexity)

Compartment Strategy Best Practices

Compartment hierarchy (OCI-specific IAM boundary):

Root Compartment (tenancy)
│
├─ SharedServices (networking, security)
│  ├─ Network (VCNs, DRGs)
│  └─ Security (Vault, KMS, Cloud Guard)
│
├─ Production
│  ├─ App1
│  │  ├─ Compute
│  │  ├─ Database
│  │  └─ Storage
│  └─ App2
│
├─ NonProduction
│  ├─ Development
│  ├─ Testing
│  └─ Staging
│
└─ Sandbox (developers, auto-cleanup)

Key principles:

1. Billing separation: Compartment tags enable cost reporting by environment
2. IAM boundaries: Policies scoped to compartments (least privilege)
3. Quota isolation: Separate limits per compartment
4. Lifecycle: Delete entire compartment = deletes all resources inside

Anti-pattern: Flat structure with no hierarchy (AWS account-per-env habit)

Cost Optimization OCI-Specific

Flex Shape Savings (Unique to OCI)

Fixed shapes (legacy):
VM.Standard2.4: 4 OCPUs, 60 GB RAM, $218/month

Flex shapes (right-size RAM independently):
VM.Standard.E4.Flex: 4 OCPUs, 16 GB RAM, $109/month (50% savings)

Flex advantage: Pay only for RAM you need
- 1 OCPU = 1-64 GB RAM configurable
- Most apps don't need 15GB per OCPU (fixed ratio)

Migration: Replace fixed shapes with Flex for 30-50% savings

Arm Instance Savings (Generous Free Tier)

AMD instance: VM.Standard.E4.Flex (1 OCPU) = $0.03/hr
Arm instance: VM.Standard.A1.Flex (1 OCPU) = $0.01/hr (67% cheaper)

Always-Free Arm: 4 OCPUs free forever!

Use case: Web servers, CI/CD runners, dev environments
Limitation: ARM64 only (not all apps compatible)

Gotcha: Free tier is A1 shapes only, newer A2 shapes are paid

Storage Tiering (Exact Prices)

| Tier | Cost/GB/Month | Use Case | Retrieval | |------|--------------|----------|-----------| | Standard | $0.0255 | Active data, frequent access | Instant, free | | Infrequent Access | $0.0125 (51% off) | Backups, logs (accessed monthly) | Instant, $0.01/GB | | Archive | $0.0024 (91% off) | Compliance, long-term retention | 1 hour, $0.01/GB |

Lifecycle policy example:

Day 0-30: Standard ($0.0255/GB/mo)
Day 31-90: Infrequent ($0.0125/GB/mo)
Day 91+: Archive ($0.0024/GB/mo)

1 TB data for 1 year:
Without tiering: $0.0255 × 1000 × 12 = $306/year
With tiering: $0.0255 × 1000 × 1 + $0.0125 × 1000 × 2 + $0.0024 × 1000 × 9 = $72/year
Savings: $234/year (76%)

Security Zones (OCI-Unique)

OCI Security Zones = Infrastructure-level policy enforcement:

Security Zone enforces:
✓ All storage encrypted
✓ No public buckets
✓ No internet gateways in VCN
✓ All databases private endpoint only
✓ Cloud Guard enabled

Enforcement: API rejects violating requests (preventive, not detective)

Example:
oci os bucket create --public-access-type ObjectRead
→ FAILS if compartment is in Security Zone

Use case: Production, PCI-DSS, healthcare (mandatory controls)

Gotcha: Security Zones can break existing automation (test in dev first)

Progressive Loading References

OCI Well-Architected Checklist

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

• Running compliance checks against OCI tenancy
• Preparing for CIS OCI Foundations Benchmark audit
• Implementing automated security scanning
• Creating remediation scripts for common findings
• Setting up monitoring for drift detection

Do NOT load for:

• Quick anti-pattern reference (NEVER list above covers it)
• Architecture decisions (covered in this skill)
• Understanding OCI terminology (tables above)

Official Oracle Documentation Sources

Primary References (50+ official sources scraped):

• Well-Architected Framework for OCI
• OCI Architecture Center
• CIS OCI Foundations Benchmark
• Security Best Practices
• Compartment Design
• Network Architecture Patterns

Note: All anti-patterns, terminology mappings, and Always-Free limits in this skill are derived from official Oracle documentation and A-Team Oracle blog

---

When to Use This Skill

• Architecture design: Multi-AD patterns, compartment strategy, VCN sizing
• Migration from AWS/Azure: Terminology mapping, anti-pattern avoidance
• Cost optimization: Free tier planning, Flex shapes, storage tiering
• Security: Cloud Guard tuning, Security Zones, NSG vs Security Lists
• Production readiness: SLA requirements, HA patterns, fault tolerance

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: acedergren
• Source: acedergren/oci-agent-skills
• License: MIT

Install and usage instructions live in the source repository linked above.