はじめに
2026年1月、OCI に Private Service Access(PSA) という機能がリリースされました。

この記事では、既存機能(Service Gateway / Private Endpoint)との違いを整理しながら、PSA が何を解決してくれるのかを噛み砕いて説明します。
PSA とは?
一言で言うと、VCN 内のプライベート IP を使って、インターネットを経由せずに Oracle 管理サービスへアクセスするための接続ポイントです。
VCN 内のサブネットに「PSA エンドポイント」を作成すると、そこが Oracle 管理ネットワークへの出入り口になります。
VCN 内サブネット
└── PSA エンドポイント(プライベート IP)
└── Oracle 管理ネットワーク
└── 対象サービス
通信はすべてプライベート。インターネットを一切経由しません。
「Service Gateway じゃダメなの?」という疑問
OCI を使い慣れた方は「Service Gateway で十分じゃないの?」と思う方もいるかもしれません。
確かに Service Gateway も「インターネットを使わない」という点は同じです。
ただ、Service Gateway にはいくつか痒いところに手が届かない部分があります。
Service Gateway自体にはNSGやSecurity Listを適用することはできず、通信制御はインスタンス側(サブネットやVNIC)で行う必要があります。
またルートテーブルで経路設定する必要もあります。
「プライベート通信はできているけど、もっと細かく制御したい」という場面で Service Gateway は壁にぶつかります。
Private Endpointの場合
Object Storage などは以前から Private Endpoint が使えました。
サブネット内にエンドポイントを立てて FQDN でアクセスする仕組みで、Security List による IP レベルの制御が可能です。
PSA エンドポイントはこれをさらに進化させたもので、NSG と ZPR による細粒度のアクセス制御が追加されています。
PSA の設定手順
OCI コンソールから以下の順で設定します。
1. VCN とサブネットを用意する
PSA エンドポイントを配置するためのプライベートサブネットを作成します。特別な設定は不要です。
2. PSA エンドポイントを作成する
作成したサブネットを選択し、プライベート・サービス・アクセスから「PSAエンドポイントの作成」を選択します。

PSAの名前の設定などと合わせて作成できるサービスが指定できます。今回はObjectStorageServiceAPIを指定します。

作成のタイミングでZPRやNSGの設定も可能です。

作成されるとIPアドレスとFQDNが表示されるようになります。

ここで同じVCN内インスタンスから接続確認をするためにインスタンスを用意します。
プライベートサブネットに配置し、Instance Principal の認証で利用するauth.
NAT Gateway を経由して外部通信が可能な構成としています。
このインスタンスから作成したエンドポイントを名前解決するとプライベートIPも表示されます。
[opc@admin ~]$ nslookup objectstorage.ap-tokyo-1.oraclecloud.com Server: 169.254.169.254 Address: 169.254.169.254#53 Non-authoritative answer: Name: objectstorage.ap-tokyo-1.oraclecloud.com Address: 10.0.100.64 objectstorage.ap-tokyo-1.oraclecloud.com canonical name = objectstorage.ap-tokyo-1.oci.oraclecloud.com.
試しにtestbucketというバケットからtest.txtをダウンロードしてみます。
[opc@admin ~]$ oci os object get --bucket-name testbucket --name test.txt --file test.txt --auth instance_principal Downloading object [####################################] 100%
問題なくダウンロード出来ました。
3. ZPR設定
ZPRを設定します。ここではdemo-zpr-ns.role:bucketというセキュリティ属性を付与します。

セキュリティ属性を付与したため、先ほどと同じコマンドを実行してもレスポンスが返ってこなくなりました。
[opc@admin ~]$ oci os object get --bucket-name testbucket --name test.txt --file test.txt --auth instance_principal Usage: oci os object get [OPTIONS] Error: Unable to retrieve namespace internally. Please provide the namespace using the option "--['namespace']". [opc@admin ~]$
コンピュートインスタンス側にも属性を付与して、ZPRポリシーを作成して再度実施してみます。
ZPRポリシー
in demo-zpr-ns.network:demovcn VCN allow demo-zpr-ns.role:admin endpoints to connect to demo-zpr-ns.role:bucket endpoints in demo-zpr-ns.network:demovcn VCN allow demo-zpr-ns.role:admin endpoints to connect to '0.0.0.0/0' ※
※Instance Principal を利用する場合、認証トークンの取得・更新のためにauth.
[opc@admin ~]$ oci os object get --bucket-name testbucket --name test.txt --file test.txt --auth instance_principal Downloading object [####################################] 100% [opc@admin ~]$
無事アクセス出来るようになりました。
まとめ
PSA を使うと以下のような利点が考えられます。
- インターネットを経由しないため、通信経路が外部に露出しない
- NSG でポート・プロトコル単位の制御が可能
- ZPR によるゼロトラスト的なパケットルーティング制御ができる
| Service Gateway | Private Endpoint | PSA Endpoint | |
|---|---|---|---|
| インターネット不使用 | ✓ | ✓ | ✓ |
| プライベート IP でアクセス | ✗ | ✓ | ✓ |
| NSG による細粒度制御 | ✗ | ✗ | ✓ |
| ZPR 対応 | ✗ | ✗ | ✓ |
PSA は Service Gateway と Private Endpoint の「いいとこ取り」をしつつ、ZPR というゼロトラスト設計の要素を追加した機能です。
既存構成を見直して「もっと細かくアクセス制御したい」「インターネット経路を完全に断ちたい」と思っている方は、ぜひ PSA への移行を検討してみてください。