Private Access

This topic gives an overview of the options for enabling private access to services within Oracle Cloud Infrastructure. Private access means that traffic does not go over the internet. Access can be from hosts within your virtual cloud network (VCN) or your on-premises network.

Tip

This topic does not discuss access to services through an internet gateway. However, remember that traffic through an internet gateway between a VCN and a public IP address that is part of Oracle Cloud Infrastructure is routed without being sent over the internet.

Highlights

  • You can enable private access to certain services within Oracle Cloud Infrastructure from your VCN or on-premises network by using either a private endpoint or a service gateway. See the sections that follow.
  • For each private access option, these services or resource types are available:

    • With a private endpoint: Autonomous Database (shared Exadata infrastructure)
    • With a service gateway: Available services
  • With either private access option, the traffic stays within the Oracle Cloud Infrastructure network and does not traverse the internet. However, if you use a service gateway, requests to the service use a public endpoint for the service.
  • If you do not want to access a given Oracle service through a public endpoint, Oracle recommends using a private endpoint in your VCN (assuming the service supports private endpoints). A private endpoint is represented as a private IP address within a subnet in your VCN.

About Private Endpoints

A private endpoint is a private IP address within your VCN that you can use to access a given service within Oracle Cloud Infrastructure. The service sets up the private endpoint in a subnet of your choice within the VCN. You can think of the private endpoint as just another VNIC  in your VCN. You can control access to it like you would for any other VNIC: by using security rules. However, the service sets up this VNIC and maintains its availability on your behalf. You only need to maintain the subnet and the security rules.

The following diagram illustrates the concept.

This diagram shows a VCN with a private endpoint for a resource.

The private endpoint gives hosts within your VCN and your on-premises network access to a single resource within the Oracle service of interest (for example, one Autonomous Database with shared Exadata infrastructure). Compare that private access model with a service gateway (see the next section): If you created five Autonomous Databases for a given VCN, all five would be accessible through a single service gateway by sending requests to a public endpoint for the service. However, with the private endpoint model, there would be five separate private endpoints: one for each Autonomous Database, and each with its own private IP address.

Note

The service that sets up the private endpoint in your VCN might provide you a DNS name (fully qualified domain name, or FQDN) for the private endpoint, and not the private IP address itself. If you've configured your network setup for DNS, your hosts can access the private endpoint by using the FQDN. If the service supports the use of network security groups (NSGs) with its resources, you can request that the service set up the private endpoint in an NSG of your choice within your VCN. NSGs let you write security rules to control access to the private endpoint without knowing the private IP address assigned to the private endpoint.

If you have a private endpoint for a resource, hosts within the VCN can use the private endpoint's FQDN or private IP address to access the resource. You set up security rules to control access between hosts in the VCN and the private endpoint. For an example of how to do this with Autonomous Data Warehouse, see Autonomous Database with Private Endpoint.

You can also set up transit routing with your VCN so that hosts in the on-premises network can use the private endpoint. To enable on-premises hosts to use the private endpoint's FQDN instead of its private IP address, you have two options:

  • Set up an instance in the VCN to be a custom DNS server. For an example of an implementation of this scenario with the Oracle Terraform provider, see Hybrid DNS Configuration.
  • Manage hostname resolution yourself manually.

You might have multiple VCNs with hosts that need access to the specific resource of interest. You can peer the VCNs so that hosts in the other VCNs can also use the private endpoint (the preceding diagram does not show any peered VCNs).

About Service Gateways

A service gateway gives resources in your VCN and on-premises network private access to multiple services within Oracle Cloud Infrastructure, without the traffic going over the internet.

The following diagram illustrates the concept. The diagram refers to the Oracle Services Network, which is a conceptual network in Oracle Cloud Infrastructure that is reserved for Oracle services.

This diagram shows a VCN with a service gateway for access to the Oracle Services Network.

To use a service gateway from a particular subnet within your VCN, you set up a route rule in the subnet's route table, and specify the service gateway as the target of the rule. You also set up security rules to control access between hosts in the VCN and the services available through the service gateway.

If you have more than one VCN in your tenancy, you can configure each with its own service gateway.

You can also set up transit routing for the Oracle Services Network so that hosts in your on-premises network can use a VCN's service gateway.