OCI Compute Management - Expert Knowledge

NEVER Do This

NEVER launch instances without checking service limits first

oci limits resource-availability get \
  --service-name compute \
  --limit-name "standard-e4-core-count" \
  --compartment-id <ocid> \
  --availability-domain <ad>

87% of "out of capacity" errors are actually quota limits, not infrastructure capacity. Check limits BEFORE launching to get accurate error messages.

NEVER use console serial connection as primary access

Creates security audit findings (bypasses SSH key controls)
Use only for boot troubleshooting when SSH fails
Delete connection immediately after troubleshooting

NEVER mix regional and AD-specific resources in templates

Breaks portability when moving between regions
Use AD-agnostic designs: spread via fault domains, not hardcoded ADs

NEVER forget boot volume preservation flag in dev/test

oci compute instance terminate --instance-id <id> --preserve-boot-volume false

Without --preserve-boot-volume false: $50+/month per deleted instance (orphaned boot volumes accumulate silently)

NEVER enable public IP on production instances

Use bastion service or private endpoints for access
Cost impact: $500–5000+ per security incident from exposed instances

NEVER use fixed shapes when Flex covers the same specs

Fixed shapes (e.g., VM.Standard2.1) are often MORE expensive than Flex equivalents
Always compare Flex pricing first before choosing a fixed shape

Capacity Error Decision Tree

"Out of host capacity for shape X"?
│
├─ Check service limits FIRST (87% of cases)
│  └─ oci limits resource-availability get
│     ├─ available = 0 → Request limit increase (NOT a capacity issue)
│     └─ available > 0 → True capacity issue, continue below
│
├─ Same shape, different AD?
│  └─ Try each AD in region (PHX/IAD each have 3, all independent)
│
├─ Different shape, same series?
│  └─ E4 failed → try E5 (newer gen, often more available)
│  └─ Standard failed → try Optimized or DenseIO variants
│
├─ Different architecture?
│  └─ AMD → ARM (A1.Flex often has capacity when Intel/AMD full)
│
└─ All ADs exhausted?
   └─ Create capacity reservation (guarantees future launches)

Shape Selection: Cost vs Performance

Budget-critical (save ~66%):

VM.Standard.A1.Flex (ARM): $0.01/OCPU/hr vs $0.03 AMD
Caveat: test ARM compatibility — not all software runs on ARM

General purpose (balanced):

VM.Standard.E4.Flex: 2:16 CPU:RAM ratio, $0.03/OCPU/hr
Start with 2 OCPUs, scale based on metrics — not guesses

Memory-intensive (databases, caches):

VM.Standard.E4.Flex with custom ratio: up to 1:64 CPU:RAM
Cost: $0.03/OCPU + $0.0015/GB RAM

Quick Cost Reference

Shape Family	$/OCPU/hr	$/GB RAM/hr	Best For
A1.Flex (ARM)	$0.01	$0.0015	Cost-critical, ARM-compatible
E4.Flex (AMD)	$0.03	$0.0015	General purpose
E5.Flex (AMD)	$0.035	$0.0015	Latest gen, premium performance
Optimized3.Flex	$0.025	$0.0015	Network-intensive

Free Tier: 2x AMD VM (1/8 OCPU, 1GB) + 4 ARM cores (24GB total) — always free

Formula: (OCPUs × $/OCPU + GB × $0.0015) × 730 hrs/month Example: 2 OCPU, 16GB E4 = (2×$0.03 + 16×$0.0015) × 730 = $61.32/month

Instance Principal Authentication (Production)

When an instance needs to call OCI APIs, NEVER put user credentials on the instance.

# 1. Create dynamic group
oci iam dynamic-group create \
  --name "app-instances" \
  --matching-rule "instance.compartment.id = '<compartment-ocid>'"

# 2. Grant permissions (IAM policy)
# "Allow dynamic-group app-instances to read object-family in compartment X"

# 3. Code uses instance principal — no credentials needed:
signer = oci.auth.signers.InstancePrincipalsSecurityTokenSigner()
client = oci.object_storage.ObjectStorageClient(config={}, signer=signer)

Benefits: No credential rotation, no secrets to manage, automatic token refresh.

OCI-Specific Gotchas

Availability Domain names are tenant-specific

Your AD: fMgC:US-ASHBURN-AD-1
Another tenant: ErKW:US-ASHBURN-AD-1
MUST query your own tenant: oci iam availability-domain list
Hardcoding AD names from examples breaks cross-tenant portability

Boot Volume backups do NOT include instance config

Backup captures disk only — NOT shape, networking, or metadata
For DR: use custom images (captures config) or Terraform for infrastructure

Instance Metadata Service has 3 versions — always use v2

v1: http://169.254.169.254/opc/v1/ (legacy, vulnerable to SSRF)
v2: http://169.254.169.254/opc/v2/ (requires session token, prevents SSRF)
v1 is still enabled by default on older instances

Progressive Loading Reference

Load references/oci-compute-shapes-reference.md when:

Comparing flexible shape specs (E4 vs E5 vs E6 vs A1/A2/A4.Flex)
Looking up bare metal, GPU, Dense I/O, or HPC shapes
Need official Oracle specs (memory limits, OCPU counts, network bandwidth)

Do NOT load for quick cost comparisons, capacity troubleshooting, or shape selection — this file covers those.

compute-management