Internet Database Configurations for Oracle AI Database 26ai

A public website can use a private database. Visitors reach an application through HTTPS, while the application opens a separate, controlled connection to Oracle. The database does not need a publicly accessible SQL listener simply because the website serves internet users. This separation is the starting point for designing a cloud database configuration.

Consider a learning website that stores course descriptions and student progress in Oracle AI Database 26ai. Visitors need access to lessons, the application needs access to selected tables, and administrators need a maintenance path. The database might also call an external HTTPS service. Each requirement involves a different connection, identity, and set of permissions.

This lesson uses Autonomous AI Database Serverless for specific endpoint and connection examples. Other Oracle cloud services have their own networking and operational requirements. First identify the service and deployment model, then choose how clients reach it.

Four Cloud Connection Patterns

Separate Web Access from Database Access

For the learning website, the browser might request a course page or submit a completed exercise. The application validates that request, determines which records the visitor may access, and runs the necessary database operation. It returns the permitted result as HTML or application data. The visitor does not receive the application's database password.

Keep connection credentials on the server side, using a protected configuration or secrets service appropriate to the deployment. Give the application a dedicated database identity with only the permissions its work requires. An application that reads published course material should not automatically receive permission to administer accounts or modify database structures.

Connection pooling lets an application reuse a controlled set of database sessions across requests. Pool sizing should match the application's workload and the database's capacity. Opening a fresh session for every small web request adds overhead; creating an oversized pool can overload the database. When pooled sessions serve multiple users, the application must also handle transaction completion and user-specific state correctly.

Oracle REST Data Services provides HTTPS interfaces for REST-enabled schemas in Autonomous AI Database. ORDS can support an API architecture, while Oracle APEX supports browser-based applications. These choices do not remove the need to authenticate users and authorize operations. A REST endpoint should expose the intended application capability, with suitable permissions, rather than unrestricted access to the underlying data.

Choose a Public or Private Database Endpoint

An endpoint is the address through which a client reaches a service. A public endpoint and a private endpoint answer a networking question: where can connection traffic arrive? Neither choice, by itself, determines what a database user may do after authentication.

Oracle documents an Allow public access option for Autonomous private-endpoint configurations. It permits selected public IP addresses or supported access from specified virtual cloud networks (VCNs). This is an additional exposure decision, not another name for VCN peering. Review the private endpoint documentation before selecting it.

For the example website, prefer a private database path when it fits the application's hosting arrangement. If an approved external client needs a public endpoint, restrict its source and document why the connection is required. Avoid broad source ranges merely to make an initial connection test succeed.

Protect Database Sessions with TLS or Mutual TLS

Transport Layer Security (TLS) protects communication in transit and supports server identity verification. Mutual TLS (mTLS) additionally uses client certificates so the server can authenticate the connecting client at the transport layer. Database authentication and authorization still determine the session's identity and permitted operations.

Obtain the hostname, service name, and port from the instance's connection information. Supported clients can use TLS without downloading a client wallet. That is a credential-distribution difference, not permission to disable certificate checks. Protect any wallet files used by the application and include credential rotation in operational planning.

Oracle's current Autonomous connection documentation describes TLS 1.3 and explains driver-specific compatibility. Do not assume that every customer-managed Oracle listener has the same configuration. A port number alone does not establish encryption: a conventional TCP listener on port 1521 is not automatically a TLS listener.

Understand What Each Control Does

A successful connection depends on several independent checks. Working DNS cannot compensate for a blocked port. A valid certificate cannot grant access to a table. Troubleshooting becomes easier when you identify which part of the connection failed.

A network security group (NSG) groups traffic rules around participating resources. Configure only the required sources, destinations, and ports. For a private database, also verify the application's DNS resolution and return path. Two resources being in the same cloud account does not establish network connectivity between them.

An on-premises client may use a configured VPN or another supported network connection to reach cloud resources. A VPN can carry encrypted traffic over the public internet; it should not be described as an internet-free path. Private addressing also does not replace the need to protect application-to-database traffic.

Account for the Cloud Service You Operate

Autonomous settings should not be copied mechanically into Oracle Base Database Service or Exadata procedures. In Base Database Service, connection planning includes the DB system's addressing and network configuration. Oracle's DB system connection guidance distinguishes public and private connection contexts. Identify who is responsible for configuring and maintaining each network and database component.

Cloud gateways serve different purposes. In applicable designs, a network address translation (NAT) gateway provides outbound internet access for private resources. A service gateway provides access to supported Oracle services through the Oracle services network. It is not a general substitute for internet access. Review the selected service's VCN and subnet requirements before designing routes.

Multicloud deployments add provider-specific networking and operational boundaries. Confirm the available service, region, supported database release, and connectivity model before planning an implementation. The useful architectural questions remain the same: where does the application run, how does it reach Oracle, and which team owns each part of that path?

Control Database-Initiated HTTPS Calls

Suppose the learning application needs information from an external service. One design makes the request in the application tier. Another uses a database operation that calls the service through UTL_HTTP. Choose the location deliberately: an external dependency can affect response time, transaction duration, and failure handling.

For a database-initiated call, a database network access control list (ACL) governs whether the relevant principal may contact the external host through supported PL/SQL networking facilities. The DBMS_NETWORK_ACL_ADMIN package administers this authorization. These outbound permissions are distinct from the Autonomous endpoint rules that admit incoming clients.

The call also needs a working network path, suitable egress rules, certificate trust, and any credentials required by the destination API. Granting a host permission does not configure a route, and establishing TLS does not authorize an API operation. Keep credentials outside SQL examples and grant access to the intended host rather than an unrestricted collection of destinations.

Autonomous has service-specific rules for public and private targets. The ROUTE_OUTBOUND_CONNECTIONS property affects the use of the private endpoint VCN for outbound traffic. Therefore, a private endpoint alone does not prove that every outbound request traverses a customer-configured NAT gateway. Oracle's web service call documentation explains routing and wallet considerations. Depending on the service and target, managed certificate trust may be available; not every request requires a newly created wallet.

Apply the Choices to Three Scenarios

1. A Public Learning Website

Visitors reach the public application over HTTPS. The server-side application owns the database connection configuration and uses a restricted account over a private path. Separate read-only course access from operations that update student records. Keep administrative credentials out of the application's pool. Test a normal student request as well as a request for information that the student should not be allowed to see.

2. An Approved External SQL Client

An administrator or developer needs a controlled connection from outside the application's network. If a restricted Autonomous public endpoint fits the requirement, allow the approved source and use the instance's selected TLS or mTLS configuration. The SQL client holds the relevant connection credentials. Plan for changes to the client's outbound IP address and revoke access when the task ends.

3. An Internal Application

An internal reporting application uses a private database endpoint. Its application servers and authorized users reach the appropriate private network through configured connectivity. Database credentials remain with the server-side component that opens sessions. Administrative access follows a separately approved path, so a reporting user does not inherit maintenance privileges merely by reaching the application.

Verify the Configuration in Stages

1. Confirm the target: identify the cloud service, instance, endpoint type, hostname, and database service name.
2. Check name resolution and routes: verify them from the actual application or client environment, not only from an administrator's laptop.
3. Check network admission: compare the client's effective source address with the relevant access rules and required destination port.
4. Validate transport security: use the intended protocol, trusted certificates, and required client credentials. Resolve certificate errors rather than bypassing validation.
5. Test the database identity: connect using the intended restricted account and perform an operation that account is expected to execute.
6. Test application authorization: confirm both permitted and denied user actions. A successful database login does not validate the whole application.
7. Test outbound access separately: verify host authorization, routing, certificate trust, API authentication, and failure handling for any external service call.

A timeout suggests a different investigation from an explicit login rejection. A connection can also succeed while a particular SQL operation fails because the account lacks permission. Record the exact error and connection stage before changing configuration. Review the resulting access again after network changes, wallet rotation, or application deployment.

The essential design decision is to assign a clear purpose to every connection. Keep public web access, database client access, administrative access, and outbound service calls distinct. The next lesson turns to password management, which complements these network and transport controls by governing database account credentials.