ADB Private Endpoints and Networking

By default Autonomous Database can be reached over the public internet through a secured endpoint, and for a quick start that is convenient. For a real estate it is rarely what you want. Most organisations need the database to sit on a private network where it can only be reached from inside their own virtual cloud network, and getting that configuration right at the start saves a painful re networking exercise later.

The problem is that the easy default and the right default are not the same. A new Autonomous Database created without thought is reachable from the internet, protected by credentials and access controls but still exposed in a way that most security teams will not accept for production data. Moving it onto a private endpoint after applications already connect to it means changing connection strings and network paths across the estate, which is exactly the kind of disruptive change you want to avoid.

What a private endpoint actually does

A private endpoint places the database inside your virtual cloud network with a private address, so it behaves like any other resource on your private network rather than a service on the public internet. Traffic to the database stays within your network and the connections you control, and the database is no longer reachable from outside. This is the configuration that matches how most organisations think about their data: it lives on the inside, and only things on the inside can reach it.

Choosing this at creation time is far cleaner than retrofitting it. When the database is born on a private endpoint, every application that connects to it is built around the private path from day one. When it is born public and moved later, every one of those connections has to be revisited. For any database that will hold real data, a private network configuration should be the default decision, not an afterthought.

Public versus private access

The networking decisions that make it work

A private endpoint only helps if the things that need the database can reach it and the things that do not are kept out. That comes down to a few deliberate choices. The subnet you place the endpoint in should be a private subnet, not one with a path to the internet. The network security rules around it should allow the database port only from the application tiers that need it, and nothing else. And the name resolution has to work so that applications inside the network resolve the database to its private address rather than a public one.

These are the same principles that govern any well designed private tier, and they connect to broader networking design covered across our networking writing. The practical point is that the private endpoint is one piece of a private network design, and it works best when the subnet, the security rules, and the name resolution are all set up to support it. Getting any one of them wrong produces the frustrating situation where the database is private but the application cannot reach it.

Connecting applications over the private path

Applications connect to a private Autonomous Database the same way they connect to any database, using a connection string and credentials, with the difference that the path stays inside your network. For applications running on OCI in the same network this is straightforward. For applications elsewhere, the connection comes in over the private connectivity you have established between your networks, whether that is a connection from another cloud, from on prem, or across regions. The detail of how applications wire up to the database is covered in our connecting apps to Autonomous Database guide.

The discipline that matters here is to keep the private path private the whole way. A database on a private endpoint that is reached through a public hop somewhere in the chain has given back much of the benefit. The goal is a connection that never touches the public internet from application to database, and that is achievable when the network is designed for it from the start.

A checklist for a private Autonomous Database

Access from outside the network

A private endpoint keeps the database inside your network, but real estates often need to reach it from places that are not in that network, such as an office, another cloud, or an on prem environment. The right answer is not to make the database public, it is to bring those places onto the private path. A secure connection from on prem or from another cloud into your virtual cloud network lets traffic reach the private endpoint without ever touching the public internet, which preserves the benefit of the private configuration while still allowing the access that the business needs.

This is worth designing deliberately, because the easy shortcut, exposing the database publicly so a remote team can reach it, gives back exactly the protection the private endpoint provided. Keeping the path private the whole way is more work to set up once and far safer to live with afterwards. For human administrative access specifically, a bastion pattern lets people reach the private database through a controlled, audited hop rather than by opening the database to the wider network.

Bringing it together

A private endpoint is the right home for an Autonomous Database that holds real data, and the cost of choosing it is small if you choose it at creation and large if you retrofit it. Put the database on a private subnet, restrict the access rules to the tiers that need it, fix name resolution, and keep the connection path private end to end. Done this way, the database sits quietly inside your network where it belongs. The wider security posture this supports is covered in our security features guide and the complete guide, and our IAM and security work helps you design the private network around it.