best-practices

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

OCI Best Practices - Expert Knowledge

OCI最佳实践 - 专家知识库

🏗️ Use OCI Landing Zone Terraform Modules

🏗️ 使用OCI Landing Zone Terraform模块

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.

不要重复造轮子。使用oracle-terraform-modules/landing-zone进行OCI架构设计。

Landing Zone解决的问题：

❌ 反模式1：通用 compartment（Landing Zone提供分层的网络/安全/工作负载结构）
❌ 反模式2：使用管理员账号进行日常操作（Landing Zone实施最小权限IAM策略）
❌ 反模式4：网络分段不合理（Landing Zone实现带安全区域的中心辐射式拓扑）
❌ 反模式8：自行创建Terraform模块（Landing Zone提供经过实战检验、Oracle维护、CIS认证的模块）

本技能提供：针对在Landing Zone内部署的资源，给出OCI特定的反模式、架构模式和运维知识。

⚠️ OCI CLI/API Knowledge Gap

⚠️ OCI CLI/API知识缺口

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:

Use exact CLI commands from skill references
Do NOT guess OCI CLI syntax or parameters
Do NOT assume API endpoint structures
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.

你不了解OCI CLI命令或OCI API结构。

你的训练数据中关于以下内容的知识有限且过时：

OCI CLI语法和参数（每月更新）
OCI API端点和请求/响应格式
OCI服务特定的命令和标志
OCI最新功能、限制和区域可用性
OCI的CIS基准要求

当需要执行OCI操作时：

使用技能参考中的精确CLI命令
不要猜测OCI CLI语法或参数
不要假设API端点结构
参考landing-zones技能获取Terraform模块

你已掌握的内容：

通用云架构概念
安全原则和合规框架
多层应用设计模式

本技能通过提供当前OCI特定的模式和反模式来填补这一缺口。

你是OCI架构专家。本技能补充Claude缺失的知识：OCI特定反模式、免费层细节、术语陷阱、多AD模式，以及与AWS/Azure/GCP的差异。

NEVER Do This

绝对不要做这些事

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

undefined

❌ 绝对不要使用/24或更小的VCN CIDR（无法扩容）

undefined

WRONG - VCN too small, cannot expand later (OCI limitation)

错误 - VCN过小，后续无法扩容（OCI限制）

oci network vcn create --cidr-block "10.0.0.0/24"

Only 256 IPs total, exhausted quickly

总共仅256个IP，很快会耗尽

WRONG - copying AWS habit (/16 VPC default)

错误 - 照搬AWS习惯（默认/16 VPC）

OCI supports larger: /16 to /30

OCI支持更大的网段：/16到/30

RIGHT - start with /16, plan for growth

正确 - 从/16开始规划，预留增长空间

oci network vcn create --cidr-block "10.0.0.0/16"

65,536 IPs, room for 256 /24 subnets

65536个IP，可容纳256个/24子网

CRITICAL: OCI VCNs CANNOT be resized after creation

关键提示：OCI VCN创建后无法调整大小

Must create new VCN and migrate if too small

如果过小，必须创建新VCN并迁移资源


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

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


**迁移成本**：重新创建VCN会导致数小时停机、IP变更和安全规则更新

❌ **绝对不要使用AD专属子网（破坏多AD高可用）**

WRONG - subnet tied to single AD

错误 - 子网绑定到单个AD

oci network subnet create
--vcn-id <vcn-ocid>
--cidr-block "10.0.1.0/24"
--availability-domain "fMgC:US-ASHBURN-AD-1" # AD-specific!

oci network subnet create
--vcn-id <vcn-ocid>
--cidr-block "10.0.1.0/24"
--availability-domain "fMgC:US-ASHBURN-AD-1" # 专属AD！

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

问题：无法在其他AD中启动实例，无高可用

RIGHT - regional subnet (works in all ADs)

正确 - 区域子网（适用于所有AD）

oci network subnet create
--vcn-id <vcn-ocid>
--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

oci network subnet create
--vcn-id <vcn-ocid>
--cidr-block "10.0.1.0/24"

不带--availability-domain标志 = 区域子网

实例可部署在区域内的任意AD


**注意**：部分旧OCI指南仍展示AD专属子网（已弃用模式）

❌ **绝对不要混淆安全列表（Security Lists）与NSG（使用场景不同）**

OCI有两种网络安全机制：

安全列表（Security Lists，有状态，子网级）：

应用于子网内所有资源
用途：宽泛规则（互联网出口、DNS）
限制：每个子网最多5个
变更影响：子网内所有实例

网络安全组（NSG，资源级）：

应用于特定资源
用途：精细化规则（应用层→数据库层）
限制：每个资源最多5个，每个NSG最多120条规则
变更影响：仅影响标记的资源

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

NSG "app-tier": Allow egress to NSG "db-tier" on port 1521

NSG "app-tier"：允许出口到NSG "db-tier"的1521端口

Only instances in app-tier NSG can reach DB

仅属于app-tier NSG的实例可访问数据库


**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
<1ms latency between ADs


**最佳实践**：安全列表用于基准规则（互联网、DNS），NSG用于应用特定规则

❌ **绝对不要假设单AD部署是可接受的（无SLA保障）**

OCI可用域（ADs）：

大多数区域每个区域有3个AD
独立故障域
AD间延迟<1ms

WRONG - all resources in single AD

错误 - 所有资源部署在单个AD

All instances in AD-1 → AD failure = complete outage

所有实例在AD-1 → AD故障 = 完全 outage

RIGHT - distribute across ADs

正确 - 跨AD分布

Production instances: AD-1, AD-2, AD-3 Load balancer: Automatically multi-AD Database: Autonomous (auto 3-AD) or RAC (2+ nodes)

SLA impact: Single-AD: NO SLA (OCI doesn't guarantee) Multi-AD: 99.95% SLA


**Critical**: Oracle **refuses** SLA claims for single-AD deployments in regions with 3 ADs

❌ **NEVER hardcode AD names (tenant-specific)**

生产实例：AD-1、AD-2、AD-3 负载均衡器：自动多AD部署数据库：自治数据库（自动3AD）或RAC（2+节点）

SLA影响：单AD部署：无SLA（Oracle不提供保障）多AD部署：99.95% SLA


**关键提示**：对于有3个AD的区域，Oracle**拒绝**单AD部署的SLA索赔

❌ **绝对不要硬编码AD名称（租户专属）**

WRONG - AD names are tenant-specific, not portable

错误 - AD名称是租户专属的，不具备可移植性

availability_domain = "fMgC:US-ASHBURN-AD-1" # Only works in YOUR tenancy!

availability_domain = "fMgC:US-ASHBURN-AD-1" # 仅在你的租户中有效！

Another tenant's AD name for same physical AD:

同一物理AD在另一个租户中的名称：

availability_domain = "xYzA:US-ASHBURN-AD-1" # Different prefix!

availability_domain = "xYzA:US-ASHBURN-AD-1" # 前缀不同！

RIGHT - query AD names dynamically

正确 - 动态查询AD名称

data "oci_identity_availability_domains" "ads" { compartment_id = var.tenancy_ocid }

resource "oci_core_instance" "web" { availability_domain = data.oci_identity_availability_domains.ads.availability_domains[0].name }


**Why**: OCI generates unique AD prefixes per tenant for security isolation

❌ **NEVER enable Cloud Guard auto-remediation without testing**

Cloud Guard = OCI threat detection + auto-response

data "oci_identity_availability_domains" "ads" { compartment_id = var.tenancy_ocid }

resource "oci_core_instance" "web" { availability_domain = data.oci_identity_availability_domains.ads.availability_domains[0].name }


**原因**：OCI为每个租户生成唯一的AD前缀以实现安全隔离

❌ **绝对不要未经测试就启用Cloud Guard自动修复**

Cloud Guard = OCI威胁检测+自动响应

DANGER - auto-remediation can break production

危险 - 自动修复可能破坏生产环境

Detector: "Public bucket detected" Auto-remediation: Make bucket private → breaks public website!

Detector: "Security list allows 0.0.0.0/0" Auto-remediation: Remove rule → breaks internet access!

检测器："检测到公共存储桶" 自动修复：将存储桶设为私有 → 破坏公共网站！

检测器："安全列表允许0.0.0.0/0" 自动修复：删除规则 → 中断互联网访问！

SAFER approach:

更安全的方法：

Enable detectors (read-only mode first)
Review findings for 1-2 weeks
Tune responders to avoid false positives
Enable auto-remediation for trusted patterns only


**Gotcha**: Cloud Guard enabled by default in some tenancies, can auto-break things

❌ **NEVER assume you need Oracle Linux (common misconception)**

OCI supports: ✓ Oracle Linux (free, optimized) ✓ Ubuntu, CentOS, Rocky Linux (free) ✓ Windows Server (BYOL or license-included) ✓ Custom images (import your own)

先启用检测器（只读模式）
审查1-2周的检测结果
调整响应器以避免误报
仅对可信模式启用自动修复


**注意**：部分租户默认启用Cloud Guard，可能自动破坏现有环境

❌ **绝对不要假设必须使用Oracle Linux（常见误解）**

OCI支持： ✓ Oracle Linux（免费，优化） ✓ Ubuntu、CentOS、Rocky Linux（免费） ✓ Windows Server（自带许可证或包含许可证） ✓ 自定义镜像（可导入自己的镜像）

WRONG assumption: "OCI = must use Oracle Linux"

错误假设："OCI必须使用Oracle Linux"

Reality: Any Linux works, Ubuntu has larger community

实际情况：任何Linux发行版都可使用，Ubuntu拥有更大的社区

Cost: Oracle Linux is FREE (no license cost)

成本：Oracle Linux是免费的（无许可费用）

But if team knows Ubuntu → use Ubuntu

但如果团队熟悉Ubuntu → 就使用Ubuntu


**Marketing confusion**: Oracle pushes Oracle Linux, but it's not required


**营销混淆点**：Oracle主推Oracle Linux，但并非强制要求

OCI Always-Free Tier (Exact Limits)

OCI永久免费层（精确限制）

Generous permanent free tier (no credit card trial, no expiration):

慷慨的永久免费层（无需信用卡试用，无到期时间）：

Compute

计算

2 AMD VMs: VM.Standard.E2.1.Micro (1/8 OCPU, 1 GB RAM each)
4 Arm OCPUs: VM.Standard.A1.Flex (allocate as 1×4 OCPU or 4×1 OCPU)
- Up to 24 GB total RAM (6 GB per OCPU)
- Example: Run 4× 1OCPU/6GB Arm instances free forever

2台AMD虚拟机：VM.Standard.E2.1.Micro（每台1/8 OCPU，1GB内存）
4个Arm OCPU：VM.Standard.A1.Flex（可分配为1×4 OCPU或4×1 OCPU）
- 总内存最高24GB（每OCPU6GB）
- 示例：永久免费运行4台1OCPU/6GB的Arm实例

Database

数据库

2 Autonomous Databases: 1 OCPU each, 20 GB storage per ADB
- Can be ATP or ADW
- Limit: 2 total per tenancy across all regions

2个自治数据库：每个1 OCPU，每个ADB 20GB存储
- 可为ATP或ADW
- 限制：每个租户所有区域总计2个

Storage

存储

Block volumes: 200 GB total (2× 100 GB boot volumes + custom)
Object storage: 10 GB Standard tier
Archive storage: 10 GB Archive tier
Block volume backups: 10 GB

块存储卷：总计200GB（2个100GB启动卷+自定义卷）
对象存储：10GB标准层
归档存储：10GB归档层
块存储卷备份：10GB

Networking

网络

Load balancer: 1 flexible LB, 10 Mbps bandwidth
VCN: 2 VCNs per region (free, no OCID cost)
Public IPv4: 1 reserved public IP free per region

负载均衡器：1个弹性LB，10Mbps带宽
VCN：每个区域2个VCN（免费，无OCID成本）
公网IPv4：每个区域免费预留1个公网IP

Observability

可观测性

Monitoring: 1 billion data points ingested
Logging: 10 GB ingested per month
Notifications: 1 million emails per month

监控：每月摄入10亿个数据点
日志：每月摄入10GB
通知：每月100万封邮件

Always-Free Gotchas

永久免费层注意事项

CRITICAL limits often missed:

undefined

常被忽略的关键限制：

undefined

Gotcha 1: 2 ADB limit is TENANCY-wide, not per region

注意事项1：2个ADB的限制是租户级的，而非区域级

Can have: 1 ATP in Phoenix + 1 ADW in Ashburn = 2 (limit reached) Cannot: Add 3rd ADB in any region

可部署：凤凰城1个ATP + 阿什本1个ADW = 2个（已达限制）不可部署：在任何区域添加第3个ADB

Gotcha 2: Arm instances must be VM.Standard.A1.Flex only

注意事项2：Arm实例必须是VM.Standard.A1.Flex类型

Cannot: Use newer A2 shapes (paid only)

不可使用：较新的A2规格（仅付费）

Gotcha 3: Free tier != trial credits

注意事项3：免费层≠试用额度

Free tier: Permanent, no expiration Trial: $300 credit for 30 days (separate)

免费层：永久有效，无到期试用：30天300美元额度（独立于免费层）

Gotcha 4: Stopped ADB counts toward 2 ADB limit

注意事项4：已停止的ADB仍计入2个ADB的限制

To free slot: Must DELETE ADB, not just STOP

undefined

释放名额：必须删除ADB，而非仅停止

undefined

OCI Terminology vs AWS/Azure

OCI术语与AWS/Azure对比

Migrating from AWS/Azure? Terminology traps:

OCI Term	AWS Equivalent	Azure Equivalent
VCN	VPC	Virtual Network
Subnet	Subnet	Subnet
Security List	VPC Security Group	NSG (network-level)
NSG	Security Group	Application Security Group
DRG	Virtual Private Gateway	VPN Gateway
Compartment	Resource Group / OU	Resource Group
Tenancy	Account	Subscription
Region	Region	Region
AD (Availability Domain)	Availability Zone	Availability Zone
Fault Domain	(within AZ)	Availability Set
Dynamic Group	IAM Role (for instances)	Managed Identity
Instance Principal	EC2 Instance Profile	Managed Identity
OCIR	ECR	Container Registry
OKE	EKS	AKS

Critical difference: OCI has both Security Lists (subnet) and NSGs (resource). AWS only has Security Groups (resource-level).

从AWS/Azure迁移？术语陷阱：

OCI术语	AWS等效术语	Azure等效术语
VCN	VPC	Virtual Network
Subnet	Subnet	Subnet
Security List	VPC安全组	NSG（网络级）
NSG	安全组	应用安全组
DRG	虚拟专用网关	VPN网关
Compartment	资源组/OU	资源组
Tenancy	账号	订阅
Region	区域	区域
AD（Availability Domain）	可用区	可用区
Fault Domain	（可用区内）	可用性集
Dynamic Group	IAM角色（用于实例）	托管标识
Instance Principal	EC2实例配置文件	托管标识
OCIR	ECR	容器注册表
OKE	EKS	AKS

关键差异：OCI同时拥有安全列表（子网级）和NSG（资源级）。AWS仅拥有安全组（资源级）。

Multi-AD Architecture Patterns

多AD架构模式

OCI multi-AD specifics:

OCI多AD特定内容：

AD Distribution Strategy

AD分布策略

OCI Regions with 3 ADs (most regions):
- US: Phoenix, Ashburn
- UK: London
- DE: Frankfurt
- AU: Sydney, Melbourne

Pattern: Distribute instances across all 3 ADs

AD-1: Web tier (2 instances) + DB primary
AD-2: Web tier (2 instances) + DB standby
AD-3: Web tier (2 instances) + DB standby

Load Balancer: Automatically spans ADs

Gotcha: Some shapes only available in specific ADs (check first)

bash

undefined

拥有3个AD的OCI区域（大多数区域）：
- 美国：凤凰城、阿什本
- 英国：伦敦
- 德国：法兰克福
- 澳大利亚：悉尼、墨尔本

模式：跨所有3个AD分布实例

AD-1：Web层（2个实例）+ 主数据库
AD-2：Web层（2个实例）+ 备用数据库
AD-3：Web层（2个实例）+ 备用数据库

负载均衡器：自动跨AD覆盖

注意：部分规格仅在特定AD可用（需提前检查）

bash

undefined

Check shape availability by AD

按AD检查规格可用性

oci compute shape list
--compartment-id <ocid>
--availability-domain "fMgC:US-ASHBURN-AD-1"

undefined

oci compute shape list
--compartment-id <ocid>
--availability-domain "fMgC:US-ASHBURN-AD-1"

undefined

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)

在每个AD内，OCI有故障域（FD）：

每个AD有3个FD
独立电源、冷却、网络
AD内延迟<1ms

最佳实践：跨AD和FD分布实例

AD-1：
  FD-1：Web实例1
  FD-2：Web实例2
  FD-3：Web实例3

AD-2：
  FD-1：Web实例4
  （重复模式）

防护能力：
- AD故障：2个AD存活（66%容量）
- FD故障：仅1个实例受影响（16%容量）

何时使用FD：仅用于超关键应用（会增加复杂度）

Compartment Strategy Best Practices

Compartment策略最佳实践

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:

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

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

Compartment层级（OCI特定IAM边界）：

根Compartment（租户）
│
├─ SharedServices（网络、安全）
│  ├─ Network（VCN、DRG）
│  └─ Security（Vault、KMS、Cloud Guard）
│
├─ Production
│  ├─ App1
│  │  ├─ Compute
│  │  ├─ Database
│  │  └─ Storage
│  └─ App2
│
├─ NonProduction
│  ├─ Development
│  ├─ Testing
│  └─ Staging
│
└─ Sandbox（开发者环境，自动清理）

核心原则：

账单分离：Compartment标签支持按环境进行成本报告
IAM边界：策略作用于Compartment（最小权限）
配额隔离：每个Compartment有独立限制
生命周期管理：删除整个Compartment = 删除内部所有资源

反模式：无层级的扁平结构（照搬AWS按环境分账号的习惯）

Cost Optimization OCI-Specific

OCI特定成本优化

Flex Shape Savings (Unique to OCI)

弹性规格节省成本（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

固定规格（传统）：
VM.Standard2.4：4 OCPUs，60GB内存，每月218美元

弹性规格（独立调整内存）：
VM.Standard.E4.Flex：4 OCPUs，16GB内存，每月109美元（节省50%）

弹性规格优势：仅为所需内存付费
- 1 OCPU = 可配置1-64GB内存
- 大多数应用不需要每OCPU15GB内存（固定比例）

迁移建议：将固定规格替换为弹性规格，节省30-50%

Arm Instance Savings (Generous Free Tier)

Arm实例节省成本（慷慨的免费层）

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

AMD实例：VM.Standard.E4.Flex（1 OCPU）= 每小时0.03美元
Arm实例：VM.Standard.A1.Flex（1 OCPU）= 每小时0.01美元（便宜67%）

永久免费Arm实例：4个OCPU永久免费！

适用场景：Web服务器、CI/CD运行器、开发环境
限制：仅支持ARM64（并非所有应用兼容）

注意：免费层仅包含A1规格，较新的A2规格为付费

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%)

层级	每月每GB成本	适用场景	检索
标准层	$0.0255	活跃数据、频繁访问	即时，免费
低频访问层	$0.0125（优惠51%）	备份、日志（每月访问）	即时，每GB$0.01
归档层	$0.0024（优惠91%）	合规、长期留存	1小时，每GB$0.01

生命周期策略示例：

第0-30天：标准层（$0.0255/GB/月）
第31-90天：低频访问层（$0.0125/GB/月）
第91天及以后：归档层（$0.0024/GB/月）

1TB数据存储1年：
不分层：$0.0255 × 1000 × 12 = 每年306美元
分层：$0.0255 × 1000 × 1 + $0.0125 × 1000 × 2 + $0.0024 × 1000 × 9 = 每年72美元
节省：每年234美元（76%）

Security Zones (OCI-Unique)

安全区域（OCI独有）

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)

OCI安全区域 = 基础设施级策略强制：

安全区域强制实施：
✓ 所有存储加密
✓ 无公共存储桶
✓ VCN无互联网网关
✓ 所有数据库仅使用私有端点
✓ 启用Cloud Guard

强制方式：API拒绝违规请求（预防性，而非检测性）

示例：
oci os bucket create --public-access-type ObjectRead
→ 如果Compartment在安全区域内，操作失败

适用场景：生产环境、PCI-DSS、医疗保健（强制控制）

注意：安全区域可能破坏现有自动化（先在开发环境测试）

Progressive Loading References

渐进式加载参考

OCI Well-Architected Checklist

OCI架构完善度检查清单

WHEN TO LOAD

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)

何时加载

oci-well-architected-checklist.md

：

对OCI租户执行合规检查
准备CIS OCI基础基准审计
实施自动化安全扫描
创建常见问题的修复脚本
设置漂移检测监控

不要加载：

快速查阅反模式（上述"绝对不要做这些事"已涵盖）
架构决策（本技能已涵盖）
了解OCI术语（上述术语表已涵盖）

Official Oracle Documentation Sources

官方Oracle文档来源

Primary References (50+ official sources scraped):

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

主要参考（50+官方来源整理）：

说明：本技能中的所有反模式、术语映射和永久免费层限制均来自Oracle官方文档和Oracle A-Team博客

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

架构设计：多AD模式、Compartment策略、VCN规划
云迁移：从AWS/Azure迁移，术语映射，规避反模式
成本优化：免费层规划、弹性规格、存储分层
安全：Cloud Guard调优、安全区域、NSG与安全列表对比
生产就绪：SLA要求、高可用模式、容错能力