When designing cloud architecture, security and accessibility are often at odds. You want your external clients to reach your database, but directly exposing a database to the public internet is a major security risk.
So, how do you bridge the gap? One highly effective approach is using an Oracle Cloud Infrastructure (OCI) Network Load Balancer (NLB).
Here is how it works, why it is used, and the crucial architectural trade-offs you need to keep in mind.
The Architecture: Keeping the Database Private
When direct exposure isn’t an option, an OCI Network Load Balancer provides a clean, secure separation between your clients and your data.
[ External Client ] ──> ( Public Subnet: Network LB ) ──TCP/1521──> [ Private Subnet: Oracle DB Node ]
Instead of opening your database to the world, you place it safely inside a private subnet. The NLB sits in a public subnet, acting as a stable, public-facing endpoint with a reserved IP. External clients connect directly to the NLB, which then forwards the traffic over port 1521 to the backend database.
Why standard Load Balancers won’t work
It is important to note that you cannot use a standard OCI Load Balancer (Layer 7) for this setup. Standard load balancers are designed for HTTP/HTTPS traffic. Because Oracle Net traffic utilizes SQL*Net, which is fundamentally TCP-based, you must use a Network Load Balancer operating at Layer 4.
The Mechanics: How Layer 4 Handling Impacts Performance
Because the NLB operates strictly at the network layer (Layer 4), it offers incredible speed and low latency, but it lacks application-level intelligence. Here is what that means in practice:
-
No Protocol Awareness: The NLB doesn’t validate database session readiness or understand the Oracle Net protocol.
-
No TLS Termination: It cannot handle SSL/TLS decryption or termination at the balancer level.
-
Simple Health Checks: Health checks are strictly TCP-based. The NLB will confirm that port 1521 is reachable, but it cannot verify if the database is actually open and accepting new sessions.
Developer Note: Because the load balancer doesn’t manage connection-level intelligence, your clients must handle retries and connection resilience within the application logic.
The Core Trade-Off
Before implementing this design, it is vital to understand the fundamental trade-off:
| The Good | The Catch |
| Security & Isolation: Your database is no longer directly exposed to the public internet, drastically reducing your attack surface. | Network-Level Only: The NLB is a network-level abstraction, not a database-aware proxy. It has zero awareness of the actual database state. |
Summary
Using an OCI Network Load Balancer is a fantastic, lightweight pattern for securing database traffic. It gives you the public endpoint you need without sacrificing the isolation of your private subnet. Just ensure that your client applications are built to handle connection resilience, and you’ll have a robust, secure cloud database architecture.
