landing-zones

OCI ランディングゾーン - エキスパートアーキテクチャ

⚠️ OCI ランディングゾーンに関する知識の不足

OCI ランディングゾーンのパターンやツールについての知識がありません。

トレーニングデータに含まれる以下の知識は限られており、古くなっています。

• OCI ランディングゾーンのリファレンスアーキテクチャ（四半期ごとに更新）
• ランディングゾーン用の Resource Manager スタック
• コンパートメントの設計パターンとガバナンス
• Security Zones と CIS Foundation への準拠
• マルチテナンシーパターン（SaaS、複数環境）
• ランディングゾーンの Terraform モジュールとベストプラクティス

ランディングゾーンの設計が必要な場合：

1. このスキルのリファレンスにあるパターンと CLI コマンドを使用してください
2. コンパートメントの階層やネットワークトポロジーを推測しないでください
3. IAM ポリシーの構造を決めつけないでください
4. デプロイ操作については landing-zone-cli.md を読み込んでください

知っていること：

• クラウドアーキテクチャの一般的な概念
• ネットワークの原則（サブネット、ルーティング、ファイアウォール）
• IAM の概念（ユーザー、グループ、ポリシー）

このスキルでは、AWS／Azure／GCP とは異なる、OCI 固有のランディングゾーンパターンを提供します。

---

🚨 ランディングゾーンで解決する OCI の悪習慣トップ 10

ランディングゾーンが重要な理由

適切なランディングゾーンがないと、組織では次のような重大なミスがよく発生します。OCI ランディングゾーンは、この 10 項目すべてを解決します。

#	悪習慣	影響	ランディングゾーンによる解決策
1	汎用的なコンパートメントを少数だけ使用する（またはコンパートメントを使用しない）	ガバナンスが機能せず、コスト配分が不可能になり、影響範囲がテナンシ全体に及ぶ	階層型コンパートメント：ポリシーを継承するネットワーク／セキュリティ／ワークロード構造
2	日常の運用に Administrator グループを使用する	最小権限が守られず、監査証跡が役に立たず、コンプライアンス違反が発生する	きめ細かな IAM ポリシー：最小権限の原則に基づく、コンパートメントごと、ロールごとのポリシー
3	スポークネットワークからインターネットへ直接接続する	送信コストの無駄（毎月 3,000～5,000 ドル）、送信トラフィックのフィルタリングなし、データ流出のリスク	ハブアンドスポーク型トポロジー：ハブ VCN 内の NAT／ファイアウォールを介した一元的な送信
4	ネットワークのセグメント化が不十分	開発環境から本番環境へアクセスでき、侵害時にラテラルムーブメントが可能になり、環境が分離されない	個別のコンパートメントと VCN：Security Zones による Dev／Test／Prod の分離
5	インターネットに対してポートを広く開放する（22、3389、8080）	直接攻撃の対象となり、ブルートフォース攻撃を受け、侵害の侵入口となる	セキュリティ・リスト／NSG：デフォルトですべて拒否し、踏み台または VPN からの接続のみ明示的に許可
6	デフォルトのセキュリティ・ルールとルート表を使用する	許可範囲が広すぎ、アーキテクチャに合致せず、セキュリティ設定にずれが生じる	IaC で管理するルール：明示的で、バージョン管理され、CIS Benchmark に準拠
7	OCI のセキュリティサービスを十分に活用しない	セキュリティが手動になり、事前検知が行われず、侵害後に違反が発覚する	統合されたセキュリティ：Cloud Guard、Security Zones、VSS、OSMS、NFW、WAF をデフォルトで有効化
8	独自の Terraform モジュールを作成する	車輪の再発明、保守されない、CIS に準拠しない、一貫性のないパターン	公式 OCI モジュール：実績があり、Oracle が保守し、CIS 認定済み
9	サービスをパブリックに公開する（バケット、データベース、パブリック IP を持つコンピュート）	データ侵害、コンプライアンス違反、不正アクセス	Security Zones：パブリック IP を拒否し、パブリックバケットを拒否し、暗号化を強制
10	ロギング、モニタリング、通知を行わない	インシデントを把握できず、監査証跡がなく、コンプライアンス違反が発生し、MTTR が長くなる	可観測性スタック：VCN Flow Logs、Audit Logs、Cloud Guard、Alarms、Notifications

ランディングゾーンあり／なしによるコストへの影響

ランディングゾーンなし（年間の無駄なコスト）：

• SG ではなく IG 経由のエグレス：年間36k～52kドル
• フラットなコンパートメント（最適化なし）：年間50k～100kドル（無駄を特定できません）
• セキュリティゾーンなし（侵害）：100k～10Mドル以上（侵害による平均コスト）
• Terraform の手動メンテナンス：年間50k～100kドル（エンジニアの作業時間）
• 回避可能なコストの合計：年間236k～10.2Mドル以上

ランディングゾーンあり：

• 初回セットアップ：10k～30kドル（大部分は計画／設計）
• 年間メンテナンス：5k～10kドル（Terraform の更新）
• ROI：初年度に10～100倍以上

コンプライアンスへの影響

ランディングゾーンのパターンを必要とする規制フレームワーク：

• PCI-DSS：ネットワークのセグメンテーション（#1、#3、#4、#5）
• HIPAA：暗号化、ログ記録、アクセス制御（#7、#9、#10）
• SOC 2：最小権限、モニタリング、変更管理（#2、#6、#10）
• ISO 27001：情報セキュリティ管理策（全10項目）
• CIS OCI Foundations：100以上の管理策（ランディングゾーンで80％以上を実装）

ランディングゾーンなし：コンプライアンス監査の不合格、是正コスト100k～500kドル ランディングゾーンあり：デフォルトでCISベンチマークに準拠し、監査対応済み

---

あなたはOCIランディングゾーンのアーキテクトです。このスキルでは、Claudeに不足しているコンパートメント階層、ネットワークトポロジーパターン、セキュリティゾーンの要件、コスト分離の戦略、マルチテナンシーのアンチパターンに関する知識を提供します。

絶対にしてはいけないこと

❌ フラットなコンパートメント構造（階層なし）を絶対に作成しないでください

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

重要な理由：階層構造により、ポリシーの継承、委任、論理的なコスト分離が可能になります。フラットな構造ではポリシーの重複が必要になり、大規模環境でのガバナンスが不可能になります。

❌ デフォルトのVCN CIDR（10.0.0.0/16）をあらゆる場所で絶対に使用しないでください

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

コストへの影響：VCN CIDRは変更できません。CIDRを間違えると、全面的な再構築が必要になり、ダウンタイムと移行コストが発生します。

❌ 本番環境のコンパートメントでセキュリティゾーンを絶対に省略しないでください

# 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

重要な理由：セキュリティゾーンは、リソース作成前に違反を防ぎます。セキュリティゾーンがなければ、侵害後に監査で違反が発見されます。侵害によるコスト：100k～10Mドル以上。

❌ 開発環境と本番環境のリソースを同じコンパートメントに絶対に混在させないでください

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

リスク：開発チームのミスによって本番環境が停止する可能性があります。2023年に調査対象となった企業の47％で発生しました。

❌ ワークロードのリソースにルートコンパートメントを絶対に使用しないでください

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

重要な理由：ルートコンパートメントは、テナンシ全体のIAMに使用します。ルート内のリソースはガバナンスを回避します。

❌ タグ付け戦略を絶対に省略しないでください（コスト配賦が悪夢になります）

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)

コストへの影響：タグがなければ、コスト最適化は当て推量になります。タグがあれば、正確なチャージバックが可能になり、無駄の特定によってコストを30～50％削減できます。

❌ 本番環境に単一リージョンのランディングゾーンを絶対に使用しないでください

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)

コスト：マルチリージョン化により、インフラコストが60～100％増加します。リージョンの停止によるコストは、SLAに応じて500k～50Mドルです。

❌ エグレスファイアウォールなしでDMZ内のインターネットゲートウェイを絶対に許可しないでください

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

セキュリティへの影響：制御されていないエグレスは、データ侵害の原因の第3位です（Verizon DBIR 2023）。

段階的な読み込みに関する参照資料

ランディングゾーンのアーキテクチャパターン

次の場合に読み込みます landing-zone-patterns.md：

• ハブ＆スポーク型のネットワークトポロジーを設計する
• コンパートメント階層のパターン（ワークロード中心型、環境中心型、テナント中心型）を選択する
• セキュリティゾーンとCloud Guardの統合を実装する
• タグ付け戦略とコスト配賦を設定する
• ネットワークトポロジー（単一VCN、ハブ＆スポーク、マルチリージョン）を設計する

次の場合は読み込まないでください：

• アンチパターンをすばやく参照する場合（上記の「絶対にしてはいけないこと」で説明しています）
• 上位10件の悪いプラクティスを把握する場合（このスキルで説明しています）
• CLIコマンドを確認する場合（代わりにlanding-zone-cli.mdを使用してください）

---

OCI Well-Architected Framework（Oracle 公式ドキュメント）

読み込むタイミング oci-well-architected-framework.md：

• Landing Zone の設計原則を包括的に理解する必要がある
• 本番環境に対応した Landing Zone をゼロから設計する
• セキュリティとコンプライアンスの柱（IAM、暗号化、監視）を理解する
• 信頼性とレジリエンスの柱（HA、DR、フォールトトレランス）を理解する
• パフォーマンス効率とコスト最適化の柱を理解する
• 運用効率の柱（IaC、自動化、スケーラビリティ）を理解する
• Core Landing Zone と Operating Entities Landing Zone を比較する
• マルチリージョン展開に関する Oracle 公式のガイダンスが必要である

必須 — ファイル全体を読む（約3,400行）：これは OCI Well-Architected Framework と Landing Zone に関する Oracle 公式ドキュメントです。次の場合は最後まで読んでください：

• 新しい Landing Zone 設計プロジェクトを開始する
• アーキテクチャレビューまたはコンプライアンス監査の準備をする
• Landing Zone に関する決定をステークホルダーに説明する必要がある

次の場合は読み込まないでください：

• CLI コマンドをすぐに確認したい場合（代わりに landing-zone-cli.md を使用してください）
• 特定の実装手順を確認したい場合（このスキルの判断ツリーで説明しています）

---

Landing Zone 用 OCI CLI

読み込むタイミング landing-zone-cli.md：

• コンパートメント階層を作成する
• Security Zones と Cloud Guard を設定する
• タグのデフォルト値とタグ名前空間を設定する
• ハブアンドスポーク型のネットワークトポロジーを実装する
• 予算とコスト追跡を作成する

例：コンパートメント階層を作成する

oci iam compartment create \
  --compartment-id $TENANCY_ID \
  --name "Workloads" \
  --description "Application workloads"

次の場合は読み込まないでください：

• OCI アーキテクチャの一般的な概念を確認したい場合（このスキルで説明しています）
• IAM ポリシーの構文を確認したい場合（iam-identity-management スキルで説明しています）
• ネットワーク設定を確認したい場合（networking-management スキルで説明しています）
• Oracle 公式ドキュメントを確認したい場合（代わりに oci-well-architected-framework.md を使用してください）

このスキルを使用する場面

• OCI テナンシーの初期設定と基盤の構築
• AWS／Azure／GCP から OCI への移行
• マルチテナントまたはマルチ環境のアーキテクチャ設計
• ガバナンスとコスト管理の実装
• コンプライアンス監査（CIS、SOC2、ISO27001）の準備
• 単一のアプリからエンタープライズプラットフォームへの拡張
• 災害復旧とマルチリージョン計画