networking-management

OCI ネットワーキング — エキスパート向け知識

🏗️ 重要：OCI Landing Zone Terraform Modules を使用する

車輪の再発明はしない

✅ ネットワークアーキテクチャには公式の OCI Landing Zone Modules を使用する

OCI Landing Zone には、事前構築済みで実績のあるネットワークトポロジーが含まれています。

• DRG を備えたハブアンドスポーク型の VCN アーキテクチャ
• Security Zones と Network Firewall の統合
• Service Gateway と NAT Gateway の構成
• VCN ピアリングとルート表
• Network Security Groups と Security Lists

module "landing_zone" {
  source  = "oracle-terraform-modules/landing-zone/oci"
  network_configuration = {
    default_enable_cis_checks = true
    network_configuration_categories = {
      hub = { ... }
      spokes = { ... }
    }
  }
}

公式リソース：

• OCI Landing Zone Network Modules
• Hub-Spoke Reference Architecture

---

⚠️ OCI CLI/API に関する知識の不足

OCI CLI コマンドや OCI API の構造については把握していません。

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

• OCI CLI の構文とパラメーター（月次で更新）
• OCI API のエンドポイントとリクエスト／レスポンス形式
• ネットワーキングサービスの CLI 操作（oci network vcn、oci network subnet）
• VCN の制限、ピアリングの制約、ルーティングルール
• 最新のネットワーキング機能（DRGv2、Network Firewall）

OCI の操作が必要な場合：

1. このスキルのリファレンスに記載された正確な CLI コマンドを使用してください
2. OCI ネットワーキングの CLI 構文を推測しないでください
3. AWS VPC のパターンが OCI でも使えると考えないでください
4. 詳細なネットワーキング CLI ドキュメントについては、リファレンスファイルを読み込んでください

把握していること：

• 一般的なネットワーキングの概念（CIDR、ルーティング、サブネット）
• セキュリティグループとファイアウォールの原則
• ロードバランシングと接続パターン

このスキルは、最新の OCI 固有のネットワーキングパターンと注意点を提供することで、このギャップを補います。

あなたは OCI ネットワーキングのエキスパートです。このスキルでは、Claude に不足している知識である Service Gateway による送信コストの削減、VCN CIDR の変更不可性、Security List の上限、VCN ピアリングの注意点、OCI 固有のネットワーキングにおけるアンチパターンを提供します。

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

❌ Oracle のサービス宛てのトラフィックを Internet Gateway 経由でルーティングしないでください（高コストです）

Service Gateway routing saves egress costs:

# WRONG - route Object Storage via Internet Gateway
Route: 0.0.0.0/0 → Internet Gateway
Cost: 10 TB to Object Storage = $85/month egress

# RIGHT - route Oracle services via Service Gateway
Route: <oci-services-cidr> → Service Gateway
Cost: 10 TB to Object Storage = $0 (FREE!)

Savings example (database backups to Object Storage):
- Without Service Gateway: 20 TB/month × $0.0085/GB = $170/month
- With Service Gateway: $0/month
- Annual savings: $2,040

Service Gateway supports:
✓ Object Storage (all tiers)
✓ Autonomous Database (for private endpoint ADB)
✓ Oracle Services Network (OSN)

重要： Service Gateway 経由の送信は無料ですが、Internet Gateway 経由の送信には料金がかかります。

❌ VCN CIDR は変更できない（不変）ことを忘れないでください

# WRONG - create VCN with /24, plan to expand later
oci network vcn create --cidr-block "10.0.0.0/24"
# Cannot expand to /16 later (OCI limitation!)

# If you run out of IPs:
1. Create new VCN with larger CIDR
2. Migrate all resources (hours of downtime)
3. Update DNS, security rules, route tables
4. Delete old VCN

Migration cost: Hours of downtime, IP address changes, extensive reconfiguration

# RIGHT - plan for growth from day 1
oci network vcn create --cidr-block "10.0.0.0/16"
# Room for 256 /24 subnets, 65,536 IPs total

Best practice: Use /16 for VCNs, /24 for subnets

❌ サブネットごとに Security List を 5 つ以上設定しないでください（厳格な上限）

OCI limit: Maximum 5 security lists per subnet

# Problem: Complex app with many tiers
Subnet needs rules for:
- Web traffic (80, 443)
- SSH access
- Monitoring agents
- Database clients
- Logging services
... 10+ security lists needed? IMPOSSIBLE!

# WRONG - try to add 6th security list
oci network subnet update \
  --subnet-id <ocid> \
  --security-list-ids '["<sl1>","<sl2>","<sl3>","<sl4>","<sl5>","<sl6>"]'
# FAILS: "Maximum security lists (5) exceeded"

# RIGHT - use Network Security Groups (NSGs) instead
NSG limits:
- 5 NSGs per resource (same as security lists)
- 120 rules per NSG (vs unlimited in security lists)
- Unlimited NSGs per VCN

Migration strategy:
1. Security Lists: Baseline rules (internet, DNS, ICMP)
2. NSGs: Application-specific rules (app tier → DB tier)

ベストプラクティス： サブネット全体に適用するルールには Security Lists を、リソース固有のルールには NSG を使用します。

❌ VCN ピアリングで推移的ルーティングがサポートされると考えないでください

Scenario: VCN-A ↔ VCN-B ↔ VCN-C (peered)

# WRONG assumption: A can reach C via B
VCN-A instance: ping <VCN-C-instance>
# FAILS! Transitive routing NOT supported

# OCI VCN peering is NON-TRANSITIVE:
VCN-A can reach: VCN-B only
VCN-C can reach: VCN-B only
VCN-A CANNOT reach VCN-C

# RIGHT - explicit peering required
Create peering: VCN-A ↔ VCN-C
Now A can reach C directly

Peering types:
1. Local peering: Same region, FREE
2. Remote peering: Cross-region, requires DRG ($0.01/hr)

Cost impact (3-VCN mesh):
- Without transitive: 3 peerings (A-B, B-C, A-C)
- Remote peering: 3 × $7.30/month = $21.90/month

❌ ロードバランサーのサブネットに /27 以下のサイズを使用しないでください

Load Balancer subnet requirements:
- Minimum /24 CIDR (256 IPs)
- 2 subnets in different ADs (for HA)
- Each subnet needs space for:
  * LB frontends (1-5 IPs)
  * LB backends (dynamic scaling)
  * Reserved IPs (5-10 per subnet)

# WRONG - /27 subnet for LB
oci network subnet create --cidr-block "10.0.1.0/27"
# Only 32 IPs total (27 usable after OCI reserves 5)
# LB creation FAILS: "Insufficient IP space"

# RIGHT - /24 minimum
oci network subnet create --cidr-block "10.0.1.0/24"
# 256 IPs, room for scaling

Gotcha: LB reserves IPs even when not scaling (future capacity)

❌ デフォルトルート表を削除しないでください（サブネットが機能しなくなります）

Every VCN has a default route table (auto-created):
- Cannot be deleted (while VCN exists)
- Can be modified

# WRONG - try to delete default route table
oci network route-table delete --rt-id <default-rt-ocid>
# FAILS: "Cannot delete default route table"

# Workaround: Create custom route tables for subnets
1. Create new route table
2. Associate subnet with new route table
3. Leave default route table unused (orphaned but exists)

❌ Security Lists がステートレスだと考えないでください（ステートフルです！）

Common confusion: OCI Security Lists vs AWS Security Groups

OCI Security Lists: STATEFUL
- Ingress rule allows TCP 443 → auto-allows response traffic
- No need for explicit egress rule for responses

AWS Security Groups: Also STATEFUL (same behavior)
AWS Network ACLs: STATELESS (different, requires both directions)

# WRONG (from AWS NACL habit): Add both ingress and egress
Security List ingress: Allow TCP 443 from 0.0.0.0/0
Security List egress: Allow TCP 1024-65535 to 0.0.0.0/0  # Unnecessary!

# RIGHT - ingress rule only
Security List ingress: Allow TCP 443 from 0.0.0.0/0
# Response traffic auto-allowed (stateful)

ネットワーキングのコスト最適化

Service Gateway によるコスト削減

シナリオ：Object Storage へのデータベースバックアップ

Monthly backup: 30 TB uploaded to Object Storage

Without Service Gateway (via Internet Gateway):
- Route: 0.0.0.0/0 → Internet Gateway
- Egress cost: 30,000 GB × $0.0085/GB = $255/month
- Ingress: FREE (always free in OCI)

With Service Gateway:
- Route: <oci-services-cidr> → Service Gateway
- Egress cost: $0 (FREE!)
- Ingress: FREE

Annual savings: $255 × 12 = $3,060/year

Service Gateway のルーティング例：

# Get OCI Services CIDR for your region
oci network service list --all

# Create Service Gateway
oci network service-gateway create \
  --compartment-id <ocid> \
  --vcn-id <vcn-ocid> \
  --services '[{"serviceId":"<all-services-ocid>"}]' \
  --display-name "ServiceGateway"

# Add route in private subnet route table
# Destination: <oci-services-cidr> (e.g., all-phx-services-in-oracle-services-network)
# Target: Service Gateway OCID

FastConnect と VPN のコスト比較

Scenario: Hybrid cloud connectivity, 500 GB/month data transfer

VPN (Site-to-Site):
- VPN tunnel: $0.05/hr × 730 hrs = $36.50/month
- Data processed: FREE (no per-GB charge)
- Egress: 500 GB × $0.0085/GB = $4.25/month
Total: $40.75/month

FastConnect (1 Gbps):
- Port: $1,100/month (flat rate)
- Data transfer: FREE (unlimited)
Total: $1,100/month

Breakeven: When egress > 126 GB/month, consider FastConnect
Or: When predictable latency required (FastConnect = 5-20ms, VPN = 30-50ms)

VPN use case: Dev/test, <100 GB/month
FastConnect use case: Production, >500 GB/month, low latency

VCN 設計のアンチパターン

アンチパターン：すべての階層で単一のサブネットを使用する

# WRONG - web, app, DB in one subnet
Subnet: 10.0.1.0/24 (all resources)
Security: Broad security list (many open ports)
Risk: Lateral movement, no segmentation

# RIGHT - subnet per tier
Subnet 1: 10.0.1.0/24 (web tier, public)
Subnet 2: 10.0.2.0/24 (app tier, private)
Subnet 3: 10.0.3.0/24 (DB tier, private)

NSGs:
- Web NSG: Allow 80/443 from internet
- App NSG: Allow 8080 from Web NSG only
- DB NSG: Allow 1521 from App NSG only

Benefits:
✓ Blast radius containment
✓ Granular security
✓ Clear network segmentation
✓ Compliance (PCI-DSS, HIPAA)

アンチパターン：/28 のサブネット（小さすぎる）

# WRONG - tiny subnets
VCN: 10.0.0.0/16
Subnets: /28 (16 IPs each, 11 usable after OCI reserves 5)

Problem: No room for scaling
- 10 instances = 10 IPs
- Add 2 more instances? No space!
- Must create new subnet, migrate resources

# RIGHT - adequate sizing
VCN: 10.0.0.0/16
Subnets: /24 (256 IPs each, 251 usable)

Sizing guide:
- Small app: /26 (64 IPs, 59 usable)
- Medium app: /24 (256 IPs, 251 usable)
- Large app: /23 (512 IPs, 507 usable)
- Load Balancer: /24 minimum (hard requirement)

VCN ピアリングの注意点

ローカルピアリング（同一リージョン）：

Cost: FREE
Latency: <1ms (same as within VCN)
Use case: Multi-VCN design (security boundaries)

Setup:
1. Create Local Peering Gateway (LPG) in each VCN
2. Connect LPGs (bidirectional)
3. Add routes in each VCN:
   VCN-A route: <VCN-B-CIDR> → LPG
   VCN-B route: <VCN-A-CIDR> → LPG

Limitation: Same region only (cannot peer Phoenix ↔ Ashburn)

リモートピアリング（リージョン間）：

Cost: $0.01/hr per DRG connection = $7.30/month
Latency: Geography-dependent (Phoenix ↔ Ashburn = ~70ms)
Use case: Multi-region DR, global applications

Setup:
1. Create DRG in each region
2. Attach DRG to VCN (each region)
3. Create Remote Peering Connection (RPC) on each DRG
4. Connect RPCs (cross-region)
5. Add routes in each VCN

Cost example (3 regions interconnected):
- 3 DRG attachments: 3 × $7.30/month = $21.90/month

推移的ルーティングはサポートされません：

VCN-A ↔ VCN-B ↔ On-Premises (via VPN)

# WRONG assumption: A can reach on-premises via B
VCN-A → VCN-B → On-Prem (FAILS!)

# RIGHT - hub-and-spoke with DRG
VCN-A → DRG ← On-Premises
VCN-B → DRG ← On-Premises

DRG acts as router (supports transitive)
All VCNs can reach on-premises
All VCNs can reach each other

Security List と NSG の選択基準

用途	Security Lists を使用	NSG を使用
サブネット全体に適用する基本ルール（DNS、NTP、ICMP）	✓
インターネットへの送信（すべてのリソース）	✓
アプリケーション階層の分離（アプリケーション → DB）		✓
リソース固有のルール（特定の DB のみ）		✓
複雑なアプリケーション（5 つを超える Security Lists が必要）		✓
インスタンスレベルのセキュリティ（インスタンスごとのルール）		✓

推奨パターン：

1 Security List per subnet (baseline):
- Allow all egress
- Allow ICMP (ping)
- Allow DNS (UDP 53)
- Allow NTP (if needed)

Multiple NSGs per VCN (application):
- Web NSG: Allow 80/443 from internet
- App NSG: Allow 8080 from Web NSG
- DB NSG: Allow 1521 from App NSG
- Monitor NSG: Allow 9090 from management subnet

Assign:
- All instances: Security List (via subnet)
- Web instances: Web NSG
- App instances: App NSG
- DB instances: DB NSG + Monitor NSG

段階的に読み込むリファレンス

OCI ネットワーキングリファレンス（Oracle 公式ドキュメント）

読み込むタイミング oci-networking-reference.md:

• VCN とサブネットの設定について、包括的な詳細が必要な場合
• セキュリティリストと NSG の違いを詳しく理解したい場合
• DRG、FastConnect、VPN の設定を実装する場合
• 複雑なルーティングの問題をトラブルシューティングする場合
• Oracle 公式のネットワーキングに関するベストプラクティスが必要な場合

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

• 簡単な CIDR 割り当て（このスキルの表を参照）
• NSG とセキュリティリストの基本的な選択（上記の判断フローを参照）
• Service Gateway によるコスト削減（このスキルで説明）

---

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

• ネットワーク設計：VCN の計画、サブネットのサイズ設定、CIDR の割り当て
• コスト最適化：Service Gateway の設定、FastConnect と VPN の比較
• セキュリティ：NSG とセキュリティリストの選択、ネットワークのセグメンテーション
• トラブルシューティング：接続の問題、ルーティングの問題、ピアリング
• 高可用性：複数 AD にまたがるサブネット設計、ロードバランサーの要件
• ハイブリッド接続：VPN、FastConnect、DRG の設定