A practical FAQ for choosing how your private workloads should access OCI services.

When you design networks in Oracle Cloud Infrastructure (OCI), you often need private workloads to reach OCI services without using the public internet. OCI has three main options for this: Service Gateway (SGW), Private Endpoint (PE), and Private Service Access (PSA).

All three keep traffic on the Oracle network. The main differences are what your clients connect to, how DNS and routing choose the path, and how much control you need.

Service Gateway

Service Gateway is usually the simplest way for a VCN to reach supported Oracle services privately. A service gateway is regional and attached to a VCN. Route tables send traffic for an Oracle service CIDR label, such as regional Object Storage or all supported regional services, to the gateway.

This model is easy to operate because one gateway can serve many subnets and many supported services. It can also support on-premises access when the VCN is the transit point through FastConnect private peering or Site-to-Site VPN. The trade-off is that SGW still uses public service endpoints and service CIDR labels, even though the traffic stays on the Oracle network.

SGW is best when simplicity matters more than fine-grained control. It is also useful during migration, when your workload needs services that are not yet available through PSA or PE, or when a broad regional path is acceptable.

Private Endpoint

A Private Endpoint provides a private IP address in a VCN for a specific service resource. The OCI service creates and manages the endpoint VNIC in the selected subnet. You manage the subnet, routing, DNS reachability, and security rules.

The key idea is resource scope. If you create several supported resources, such as several autonomous databases with private access, the design usually includes separate private endpoints. Each resource gets its own private endpoint address and FQDN from the service, so your workloads in the VCN can use the assigned private name without creating a DNS record for each endpoint.

Extra DNS work is usually needed only when your clients sit outside that DNS context, such as on-premises networks or other VCNs that use separate DNS. In those cases, external resolvers need forwarding or custom DNS so they can resolve the private endpoint FQDN. Routing must also reach the private address.

Private Endpoint is also the option to evaluate when a service needs Reverse Connection Endpoint (RCE) capability. RCE lets a supported OCI service create a secure reverse connection into your network. SGW and PSA are mainly customer-to-service access models.

Private Service Access (PSA)

Private Service Access creates a dedicated private IP address and FQDN in a selected VCN and subnet for a supported OCI service API. In simple terms, it is a private endpoint for a service API rather than for one resource. You can control access with security lists, NSGs, and, where used, Zero Trust Packet Routing (ZPR).

PSA is scoped to a service API, not to one resource. One PSA endpoint can provide private access to a supported service API for your workloads in the VCN. If your workload uses multiple API endpoints for the same broad service, plan for each endpoint instead of assuming one PSA covers everything.

PSA is also DNS driven. When DNS is configured correctly, the normal service FQDN resolves to the PSA private IP. Applications, SDKs, CLI tools, and Terraform providers can keep using the standard service URL. On-premises networks can use PSA by forwarding the right service names to an OCI resolver listening endpoint or by managing the FQDN-to-private-IP mapping manually.

Object Storage note:
For Object Storage, PSA blocks anonymous access, cross-tenancy pre-authenticated requests, and foreign tenancy credentials. It is usually the better default for security-sensitive Object Storage access.

You can further reduce data-exfiltration risk by pairing PSA with IAM deny policies. For example, Object Storage access can be denied when the request gateway is missing or when the gateway type is not Private Service Access.

PSA is best when you need private access without changing application URLs and want tighter controls for sensitive services.

Key Differences

When to Use Each Option

Use Service Gateway when you need a quick, proven way for private subnets to access supported regional OCI services. SGW is a good fit when broad service access is acceptable, when a service is not available through PSA or PE, or when SGW is needed during migration.

Use Private Endpoint when the design must isolate access to a specific service resource. PE is often the right choice when the service provides a resource-level FQDN, a per-resource private IP, or a supported Reverse Connection Endpoint (RCE) pattern.

Use Private Service Access when you want a supported OCI service API to be reachable through a private IP while keeping the standard service FQDN. PSA is especially useful for data-exfiltration controls, security-sensitive Object Storage access, and per-service controls without application URL changes.

Frequently Asked Questions

Coexistence and Migration Guidance

These options can coexist in the same OCI environment. A common migration starts with SGW for broad access, adds PSA for sensitive supported services, and keeps PE for services that need resource-level private endpoints. During overlap, DNS usually decides the path first. If the service FQDN resolves to a PSA private IP, your clients use PSA. If it resolves to public service IPs and routing points to SGW, your clients continue through SGW.

For strict security or data-exfiltration requirements, review whether SGW should stay enabled for sensitive services. PSA can reduce exposure because it uses private IPs, supports per-service controls, and has stronger Object Storage access behavior. Review IAM policies, network sources, NSGs, route tables, and ZPR policies together.

In hub-and-spoke environments, decide whether PSA endpoints should live in each spoke, in a hub or shared-services VCN, or in a mix of both places. Distributed PSA usually makes ownership and failure domains clearer. Centralized PSA can reduce endpoint count, but shared DNS, resolver capacity, routing, and rollback become more important.

Conclusion

OCI provides several private access models because your workloads may need different balances of simplicity, isolation, and control. Service Gateway focuses on broad regional private reachability. Private Endpoint focuses on a specific service resource. Private Service Access focuses on private IP access to a supported service API while keeping the standard service FQDN.

Understanding these differences will help you design a secure and efficient OCI network architecture that aligns with your business and compliance requirements.

Reference Links

OCI Private Access overview  |  Access to Oracle Services: Service Gateway

Access to Oracle Services: Private Service Access Endpoints  |  Private Endpoint supported services

Service Gateway and PSA supported services