Private Connectivity Patterns on OCI

A good rule for any cloud network is that traffic should travel privately unless there is a reason for it to be public. Private paths reduce the attack surface, often lower egress cost, and usually deliver more predictable performance. OCI provides several mechanisms for private connectivity, and the skill is combining them so that workloads reach what they need without ever touching the public internet unnecessarily. This guide covers the main patterns and when each one fits.

The private connectivity toolkit

OCI gives you a set of components that, used together, keep traffic private. Private subnets hold resources that have no public IP address. The service gateway provides a private path to Oracle services such as object storage. Private endpoints let managed services be reached over private addresses inside your VCN. The NAT gateway gives private resources controlled outbound internet access without making them reachable inbound. FastConnect provides a private link to on premises. Private DNS ties it together by resolving names to private addresses.

Start with private subnets

The foundation of private connectivity is simple: if a resource does not need to be reachable from the internet, it should not have a public address. Databases, internal application tiers, batch workers and management hosts all belong in private subnets. This single decision removes them from the public attack surface entirely. Public addresses should be the exception, reserved for the small number of resources that genuinely must accept inbound traffic from the internet, and even those usually sit behind a load balancer rather than exposing the instance directly. The subnet design guide covers how to lay this out from the start.

Reaching Oracle services privately

Workloads constantly talk to Oracle services such as object storage, and by default that traffic would go out through the internet. The service gateway provides a private path so the traffic stays on the Oracle network, which is both more secure and avoids internet egress. Any private subnet whose resources use OCI services should route that traffic through a service gateway. For managed services that support them, private endpoints go a step further by placing the service on a private address inside your VCN, so the workload reaches it as if it were a local resource. The mechanics are covered in service gateway and NAT.

Controlled outbound with NAT

Private resources still often need to reach out, to pull patches, call a third party API or fetch a package. The NAT gateway provides this outbound path without giving the resource a public address or making it reachable inbound. It is the right way to let a private subnet talk to the internet when it must, while keeping the subnet private from the internet's point of view. Combine it with egress rules so that private resources can reach only the external destinations they actually need.

A private connectivity framework

Private DNS ties it together

Private connectivity falls apart if names still resolve to public addresses, because traffic will follow the address it is given. Private DNS zones inside the VCN let you resolve internal and service names to private addresses, so an application that looks up a database or a service reaches it over the private path rather than being sent out to the internet. This is an easy step to overlook and a common reason traffic that should be private quietly is not. Confirm resolution as part of validating any private design.

Why private by default pays off

The argument for keeping traffic private is not only about security, though that is the headline. A resource with no public address simply cannot be reached from the internet, which removes an entire class of risk before any rule is written. But there are two further benefits that make private by default an easy decision. Private paths are usually more predictable in performance, because they avoid the variable conditions of the public internet, and they often cost less, because traffic that stays on the Oracle network does not draw on internet egress the way public traffic does. Security, performance and cost all point the same way, which is rare enough to be worth taking advantage of.

This is why mature estates treat a public IP as a deliberate, documented exception rather than a default. The question at design time is not whether a resource can be private, but whether it has a specific reason to be public, and for the large majority of resources the honest answer is no. Starting from that posture produces a smaller, cleaner attack surface that is easier to reason about and easier to defend.

Private endpoints in practice

Private endpoints deserve particular attention because they change how a workload reaches a managed service. Instead of the service being something out on the network that your traffic travels to, the service is given a private address inside your own VCN, so the workload reaches it as though it were a local resource. This keeps the traffic on the private path, simplifies the security rules because you are governing a known internal address, and removes the need to send that traffic out and back. Where a managed service supports a private endpoint and your workload uses it regularly, the private endpoint is almost always the right choice, and retrofitting one into an estate that was reaching the service publicly is a common and worthwhile improvement.

The thing to watch is name resolution. A private endpoint only delivers private traffic if the workload resolves the service name to the private address, which is exactly why private DNS is part of the toolkit. Configure the resolution alongside the endpoint, and verify it, because an endpoint that exists but is bypassed by a public DNS answer gives you the cost and complexity without the benefit.

A reference private topology

Putting the patterns together produces a recognisable shape. Public facing entry points, where they exist at all, sit behind a load balancer in a dedicated public subnet. Everything else, application logic, data, internal services and management hosts, lives in private subnets with no public address. Those private subnets reach Oracle services through a service gateway, reach the small set of necessary external destinations through a NAT gateway, reach managed services through private endpoints, and reach on premises over a private FastConnect circuit terminated on the DRG. Private DNS resolves every internal and service name to a private address so that traffic follows the private path by default. This topology is not exotic and it is not expensive. It is simply the result of applying each private connectivity pattern consistently, and it is the baseline a well run estate starts from.

Bringing private connectivity together

The end state is an estate where almost nothing has a public address, traffic to Oracle services stays on the Oracle network, managed services are reached privately, outbound access is controlled through NAT, the on premises link is a private circuit, and DNS keeps every lookup on the private path. Each pattern is simple on its own. The value comes from applying them consistently so that public exposure is a deliberate, rare exception. Pair this with the network security best practices for the rules that govern those private flows, and see the complete OCI networking guide for the wider picture. When you want a private by default network designed and validated, our OCI networking solution delivers it.