OCI Service Gateway

解決する課題

• Object Storage や Autonomous Database など OCI サービスへの通信をインターネットに出さず閉域化したい
• プライベートサブネットのインスタンスから OCI サービスへ到達したいが、そのために NAT ゲートウェイのデータ処理課金や往復遅延を払いたくない
• パブリック IP を持たないリソースから、安全に バックアップ・パッチ・ログ転送 などのサービス通信を行いたい
• 規制要件などで トラフィックを Oracle のネットワーク内に閉じ込めたい

主要概念と用語

• Service Gateway (SGW): VCN に1つ作るゲートウェイ。VCN 内から Oracle Services Network 上の対象サービスへインターネットを経由せず到達させる
• Oracle Services Network: Object Storage や Autonomous Database などのパブリック OCI サービスが乗っている Oracle 内部のネットワーク
• サービス CIDR ラベル: 個々の IP ではなく、対象サービス群をまとめて表す論理ラベル。代表的に2種類ある
  • OCI 「リージョン名」 Object Storage: そのリージョンの Object Storage のみを対象にする狭いラベル
  • All 「リージョン名」 Services In Oracle Services Network: そのリージョンで SGW 経由が可能な OCI サービス全体を対象にする広いラベル
• ルートルール: サブネットのルートテーブルに、宛先をサービス CIDR ラベル、ターゲットを SGW とするルールを書く
• トランスポート（NAT との違い）: SGW は 送信元 IP を変換しない。プライベート IP のまま OCI サービス側に到達する

仕様・制限・クォータ

• SGW は VCN ごとに1つ作成し、複数サブネットのルートテーブルから共有して参照する
• 通すのは 対応する OCI サービス向けの通信のみ。一般的なインターネット宛先や任意の外部 API には使えない（それは IGW / NAT の役割）
• 経路はリージョン内のサービスに閉じる。別リージョンのサービスや、SGW 非対応のサービスへはこの経路では到達しない
• SGW 経由でも IAM の認可は別途必要。経路が通ることとアクセス権があることは独立
• VCN・サブネット数などと同様、テナンシ/リージョンごとのサービス制限の枠内で利用する

内部の仕組み

横にスクロール

SGW は「サービス向けの特別な出口」です。サブネットのルートテーブルに、宛先＝サービス CIDR ラベル、ターゲット＝SGW というルールを置くと、対象サービス宛のトラフィックだけが SGW を通り、Oracle Services Network へ閉域で流れます。

• 対象サービス宛: サービス CIDR ラベル → Service Gateway（インターネットを経由しない）
• それ以外の外向き: 通常どおり 0.0.0.0/0 → NAT Gateway（外向き専用）または 0.0.0.0/0 → Internet Gateway
• 送信元はプライベート IP のまま到達するため、NAT による IP 変換やインターネット往復が発生しない

なお、SGW を作っただけでは通信は始まりません。対象サブネットのルートテーブルにルールを追加し、セキュリティリストまたは NSG で対象ポートを許可して初めて到達します。

設計パターン / ベストプラクティス

• プライベートサブネット＋SGW: パブリック IP を持たない App/DB 層から Object Storage や Autonomous Database へは SGW で到達させ、NAT を介さない
• NAT との役割分担: 一般的なインターネット宛は NAT、OCI サービス宛は SGW、と経路を明確に分ける
• 最小ラベル原則: まず狭いラベル（Object Storage 専用）で要件を満たせるか検討し、足りない場合のみ All Services ラベルに広げる
• バックアップ/ログ経路の閉域化: DB バックアップやログのエクスポート先が Object Storage の場合、SGW を通すことで通信を Oracle 内部に閉じる

運用・監視

• 到達性の切り分け順: ルートテーブルに SGW ルールがあるか → ラベルが対象サービスを含むか → セキュリティリスト/NSG で許可されているか → IAM 認可があるか
• VCN Flow Logs（OCI Logging）でサブネットの通信の許可/拒否を確認し、SGW 経由のトラフィックを観測
• Network Path Analyzer で送信元から対象サービスまでの経路と遮断ポイントを静的に解析
• ルートテーブルは複数サブネットで共有しがちなので、ラベルの広狭がどのサブネットに効くかを運用台帳で管理

コスト

セキュリティ

• トラフィックを Oracle 内部に閉じることで、インターネット経由の暴露面を減らせる
• SGW は経路を提供するだけで、実際のアクセス制御は IAM ポリシー・セキュリティリスト/NSG で行う。経路の閉域化と認可は別レイヤーとして両方設計する
• ラベルは必要最小限にし、All Services ラベルを安易に選ばない
• パブリック IP を持たせず、OCI サービス通信は SGW、その他外向きが必要なら NAT、という最小公開を徹底

Well-Architected の観点

• セキュリティ: OCI サービス通信をインターネットから切り離し、攻撃面を縮小。プライベートサブネットのまま必要なサービスへ到達でき、最小公開を保てる
• 経路の閉域化と IAM 認可を多層防御として組み合わせることで、設定ミス時の影響を限定できる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 対象リージョンで利用できるサービス（CIDR ラベル）を確認
oci network service list

# Service Gateway を作成（All Services ラベルを使う例）
# serviceId には上記 list で得たラベルの OCID を指定する
oci network service-gateway create \
  --compartment-id ocid1.compartment.oc1..xxxx \
  --vcn-id ocid1.vcn.oc1..xxxx \
  --services '[{"serviceId":"ocid1.service.oc1.iad.xxxx"}]' \
  --display-name demo-sgw

# サブネットのルートテーブルに「サービス宛 → SGW」のルールを追加
# destination にはサービス CIDR ラベルの OCID を指定する
oci network route-table update \
  --rt-id ocid1.routetable.oc1..xxxx \
  --route-rules '[{
    "destinationType":"SERVICE_CIDR_BLOCK",
    "destination":"ocid1.service.oc1.iad.xxxx",
    "networkEntityId":"ocid1.servicegateway.oc1..xxxx"
  }]'