Oracle Cloud Network Load Balancer Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking, Edge, and Connectivity

1. Introduction

Oracle Cloud Network Load Balancer is a managed, Layer 4 (transport-layer) load balancing service designed to distribute TCP and UDP traffic across backend servers with low latency and high throughput.

In simple terms: you place a Network Load Balancer in front of multiple servers (VMs, bare metal, or IP-based targets), and clients connect to a single IP address. The service then forwards each connection to a healthy backend so your application can scale and survive failures.

Technically, Network Load Balancer operates at Layer 4: it does not understand HTTP paths, headers, or cookies. Instead, it balances traffic based on transport information (such as destination port and connection flows). It integrates natively with Oracle Cloud networking constructs like VCNs, subnets, route tables, security lists, and Network Security Groups (NSGs) and is managed via the Console, API, CLI, and Terraform.

What problem it solves: it provides a highly available front door for TCP/UDP services (APIs over TCP, gaming, IoT protocols, DNS, syslog, custom protocols, database proxies) without the overhead of application-layer (Layer 7) processing—and without you having to operate your own HAProxy/Nginx/LVS fleet.

2. What is Network Load Balancer?

Official purpose (OCI service intent): Network Load Balancer in Oracle Cloud Infrastructure (Oracle Cloud) provides Layer 4 load balancing for TCP and UDP traffic, distributing connections across multiple backends while performing health checks to route traffic only to healthy targets.

Core capabilities

Load balancing for TCP and UDP workloads (transport-layer).
Public or private load balancer deployment, depending on whether you need internet-facing or internal-only traffic.
Backend health checks to detect failures and stop sending traffic to unhealthy servers.
Highly available managed service so you don’t manage load balancer nodes, failover, patching, or scaling of the load balancer infrastructure.
Native Oracle Cloud networking integration with VCNs, subnets, NSGs/security lists, and routing.

Major components (conceptual model)

While exact UI labels may evolve, Network Load Balancer implementations typically include:

Network Load Balancer (NLB): the load balancer resource itself, attached to a subnet, providing one or more front-end addresses.
Listener: a front-end protocol/port that accepts client connections (for example TCP/80 or UDP/53).
Backend set: a logical group of backend servers and a health check policy.
Backends: the actual targets (commonly private IP:port combinations) that receive forwarded traffic.
Health check: the probe configuration that determines whether a backend is healthy for receiving traffic.

Service type and scope

Service type: Managed load balancer (LBaaS) focused on Layer 4.
Scope: Network Load Balancer is created within an Oracle Cloud compartment and attached to a VCN subnet in a region.
Regional vs. zonal: Oracle Cloud networking resources are generally regional in nature (VCNs and regional subnets). Network Load Balancer is designed for regional high availability. Availability and implementation details can vary by region—verify in official docs for any region-specific constraints.

How it fits into the Oracle Cloud ecosystem

Network Load Balancer is part of Oracle Cloud’s Networking, Edge, and Connectivity portfolio, complementing: – Oracle Cloud Load Balancer (application-capable load balancing and more advanced L7-style features) – VCN primitives (subnets, route tables, gateways, NSGs) – Compute (VMs/bare metal backends) – Monitoring & Alarms (operational metrics) – Logging & Audit (governance; access logging availability depends on service capabilities—verify in official docs)

3. Why use Network Load Balancer?

Business reasons

Higher availability without custom engineering: you avoid building/operating a redundant load balancer layer.
Faster time to production: an NLB can be provisioned in minutes with consistent patterns across environments.
Cost control via managed service: reduces operational overhead compared to self-managed HAProxy/Nginx fleets.

Technical reasons

Layer 4 performance: ideal when you need minimal overhead and high throughput for TCP/UDP.
Protocol flexibility: works for non-HTTP protocols where a Layer 7 proxy is unnecessary or harmful.
Health-based routing: keeps traffic away from failed or overloaded instances when health checks fail.

Operational reasons

Managed lifecycle: patching and scaling of the load balancer infrastructure is handled by Oracle Cloud.
Automation: infrastructure-as-code support via OCI APIs, CLI, and Terraform makes it CI/CD-friendly.
Clear separation: NLB provides a stable front-end endpoint while backends scale up/down behind it.

Security/compliance reasons

Network segmentation: place backends in private subnets; expose only the NLB.
Policy-based access control: compartment-level IAM policies can strictly control who can create/modify NLBs.
Reduced attack surface: backends do not need public IPs; only NLB subnet must be exposed (for public use cases).

Scalability/performance reasons

Horizontal scaling: add/remove backends without changing the client endpoint.
High availability: reduces single points of failure at the entry point.

When teams should choose it

Choose Network Load Balancer when: – You need TCP or UDP load balancing. – You want low latency and minimal proxy overhead. – You don’t need HTTP-aware features like host/path routing. – You want to keep servers private and present a single stable IP endpoint.

When they should not choose it

Avoid Network Load Balancer when: – You need Layer 7 features (HTTP header routing, URL path routing, cookie-based session persistence, header manipulation). – You need integrated WAF-style HTTP protections at the load balancer layer (generally Layer 7). – You require application-level observability (detailed HTTP access logs, request tracing at the proxy) and NLB doesn’t provide it for your needs (capabilities vary—verify in official docs).

4. Where is Network Load Balancer used?

Industries

SaaS and B2B platforms serving TCP-based APIs
Financial services (internal services, trading gateways, risk engines using TCP)
Telecom and media (streaming control planes, signaling, UDP-based services)
Gaming (real-time multiplayer backends over UDP/TCP)
Manufacturing/IoT (MQTT-like TCP traffic, custom telemetry protocols)
Education and research (HPC control services, internal registries)

Team types

Platform engineering teams standardizing entry points
DevOps/SRE teams improving reliability and scaling
Network/security teams enforcing segmentation and exposure controls
Application teams exposing TCP services without rewriting

Workloads

TCP APIs (including gRPC-over-TCP patterns where L7 routing isn’t needed)
UDP services (DNS, telemetry ingestion, some real-time protocols)
Custom binary protocols
Internal east-west traffic load balancing (private NLB)

Architectures

Multi-tier VCN architectures with public edge + private application tiers
Hub-and-spoke networks where shared services are fronted by internal NLBs
Hybrid connectivity where on-prem clients reach OCI backends via FastConnect/VPN and a private NLB

Production vs dev/test usage

Production: stable endpoint, health checks, controlled exposure, and operational metrics are strong drivers.
Dev/test: useful for validating scaling and failure behavior; but be cost-aware since load balancers can accrue hourly usage charges (pricing varies—see the Pricing section).

5. Top Use Cases and Scenarios

Below are realistic scenarios where Oracle Cloud Network Load Balancer is a strong fit.

1) Internet-facing TCP API endpoint

Problem: You run multiple stateless API servers and need one stable IP/port for clients.
Why NLB fits: Layer 4 TCP balancing is fast and doesn’t require HTTP awareness.
Example: Mobile apps connect to api.example.com:443 which resolves to an NLB public IP forwarding to multiple API VMs.

2) Internal service load balancing (private endpoint)

Problem: Many internal microservices need a stable endpoint for a TCP service in a private subnet.
Why NLB fits: Private NLB exposes a single internal IP and keeps traffic within the VCN.
Example: Internal “auth” service listens on TCP/8443; private NLB forwards requests from app tier to auth backends.

3) UDP-based DNS forwarding tier

Problem: You need resilient DNS forwarding/recursor endpoints with scaling and health checks.
Why NLB fits: Supports UDP load balancing for DNS traffic.
Example: Clients send UDP/53 to an NLB which forwards to multiple DNS resolvers in private subnets.

4) Telemetry ingestion over TCP (custom protocol)

Problem: Devices send telemetry over a proprietary TCP protocol; you need scaling and failover.
Why NLB fits: Works well for non-HTTP protocols without requiring L7 termination.
Example: Thousands of sensors connect to TCP/9000 on an NLB distributing connections across ingestion nodes.

5) Gaming backend (UDP sessions)

Problem: Real-time game servers need UDP load distribution and fast failover.
Why NLB fits: UDP support and low latency at Layer 4.
Example: Players connect to UDP/27015 on an NLB; sessions distribute across game server fleet.

6) Database proxy tier (TCP)

Problem: You operate database proxies (or read-only replicas behind a proxy layer) and want a stable endpoint.
Why NLB fits: TCP load balancing and health checks can keep traffic away from failed proxies.
Example: Apps connect to NLB TCP/6432 which forwards to pgBouncer instances.

7) Syslog / log forwarding collectors (UDP/TCP)

Problem: Many systems send syslog to a central endpoint; collectors must scale.
Why NLB fits: Supports UDP/TCP; keeps collectors private.
Example: Syslog over UDP/514 hits NLB and distributes to collectors; collectors forward to a SIEM.

8) Blue/green deployments for TCP services

Problem: You want to roll out a new version of a TCP service with minimal client disruption.
Why NLB fits: Move traffic by adding/removing backends or switching backend sets (capabilities vary by configuration).
Example: Add new backend pool “green,” validate health, then gradually drain “blue.”

9) Hybrid access to OCI backends (FastConnect/VPN)

Problem: On-prem clients need to reach OCI services through private connectivity.
Why NLB fits: Private NLB provides a stable private endpoint for on-prem routing.
Example: ERP on-prem connects over FastConnect to private NLB IP that fronts TCP application servers in OCI.

10) Inbound TLS passthrough to service mesh/gateway

Problem: You terminate TLS inside your cluster or gateway and want the load balancer to just forward TCP.
Why NLB fits: As Layer 4, it can forward TCP connections without HTTP termination.
Example: NLB forwards TCP/443 to an internal ingress gateway that handles TLS and routing.

6. Core Features

The exact feature set can evolve by region and release. The items below reflect core, widely expected capabilities of Oracle Cloud Network Load Balancer; confirm any region-specific details in the official documentation.

1) Layer 4 load balancing for TCP and UDP

What it does: Distributes transport connections/flows to backends.
Why it matters: Keeps latency low and supports non-HTTP protocols.
Practical benefit: Works for DNS (UDP), telemetry protocols, database proxies, and generic TCP services.
Caveats: No HTTP header/path routing; not a WAF; not an application gateway.

2) Public and private load balancer options

What it does: Allows internet-facing (public) or internal-only (private) endpoints.
Why it matters: Supports both edge and east-west use cases.
Practical benefit: Keep backends private while exposing only the NLB.
Caveats: Public endpoints must be protected by security rules; private endpoints require correct routing from clients (VCN peering/FastConnect/VPN).

3) Backend sets and health checks

What it does: Groups backends and probes them for availability.
Why it matters: Automated failover; prevents blackholing traffic to dead instances.
Practical benefit: You can patch or replace instances and rely on health checks to gate traffic.
Caveats: Health check types/behavior (TCP vs higher-layer checks) depend on service implementation—use TCP checks if you want the most universally supported approach.

4) Listener configuration per protocol/port

What it does: Exposes one or more front-end ports (e.g., TCP/80, TCP/443, UDP/53).
Why it matters: One NLB can represent multiple service entry points if supported.
Practical benefit: Reduce resource sprawl and simplify endpoint management.
Caveats: Listener count and port range limits are subject to OCI quotas/limits.

5) High availability (managed service)

What it does: Oracle Cloud runs redundant infrastructure so a single LB node failure doesn’t take you down.
Why it matters: Load balancer HA is non-trivial to build correctly and consistently.
Practical benefit: You focus on backends and app logic rather than LB redundancy.
Caveats: Your architecture must still be HA: place backends across failure domains/availability domains when possible.

6) Works with IP-based backends in VCN networking

What it does: Targets are typically addressed by private IP and port.
Why it matters: Decouples backends from specific compute constructs; works across VMs and appliances.
Practical benefit: You can load balance to custom appliances, containers on VMs, or on-prem reachable IPs (subject to routing and security).
Caveats: Ensure routing and security rules permit the NLB to reach backend IPs.

7) Native integration with security lists and Network Security Groups (NSGs)

What it does: Uses VCN subnet security and NSGs to control inbound/outbound traffic.
Why it matters: Consistent security posture with the rest of Oracle Cloud networking.
Practical benefit: Least-privilege rules: only allow required ports from NLB subnet to backends.
Caveats: Misconfigured NSG/security lists are the #1 cause of “unhealthy backend” issues.

8) Observability via metrics (Monitoring service)

What it does: Publishes LB metrics for traffic, backend health, and performance indicators (exact metric names vary).
Why it matters: Enables SRE practices: alerts, SLO tracking, and capacity planning.
Practical benefit: Alarm when healthy backend count drops or traffic spikes.
Caveats: Access logging/flow logging availability varies by service—use VCN Flow Logs where appropriate and verify NLB-specific logs in docs.

9) Automation via Console, API, CLI, and Terraform

What it does: Fully manageable as code.
Why it matters: Repeatable environments, safe changes, and auditability.
Practical benefit: Use Terraform to create NLBs per environment with consistent naming and tagging.
Caveats: Apply change control; load balancers are critical shared infrastructure.

10) Compartment-based governance and tagging

What it does: Uses OCI compartments and tags for governance, billing, and access control.
Why it matters: Network services can sprawl quickly without governance.
Practical benefit: Allocate costs by project/team; enforce policies per compartment.
Caveats: Tagging is only effective if enforced via policy and used consistently.

7. Architecture and How It Works

High-level architecture

A Network Load Balancer sits inside a VCN subnet and exposes one or more front-end addresses. Clients connect to the listener. The NLB selects a healthy backend from a backend set and forwards the connection (TCP) or flow (UDP).

Request/data/control flow

Control plane (management):
You create/update the NLB using Console/API/CLI/Terraform.
IAM policies control who can manage the resource.
Audit logs record API calls (via OCI Audit).
Data plane (traffic):
Client connects to NLB frontend IP:port.
NLB forwards to a healthy backend IP:port.
Health checks continually evaluate backend health; unhealthy backends are removed from rotation.

Integrations with related services

VCN & Subnets: NLB is attached to a subnet (public or private). Route tables and gateways determine reachability.
NSGs/Security Lists: Enforce inbound access to the NLB and backend access from the NLB to targets.
Compute (VM/BM): Common backend targets.
Monitoring & Alarms: Metrics-based alerting for backend health and traffic.
Logging/Audit: Audit records management operations; traffic logging depends on features—verify in official docs.
Terraform/Resource Manager: Infrastructure as code provisioning and changes.

Dependency services

At minimum, you need: – A VCN – A subnet (often regional) – Backend targets reachable from that subnet via VCN routing – Correct security rules (NLB ingress and backend ingress)

Security/authentication model

IAM: Policies grant permissions to create and manage network load balancers and to use networking resources (subnets, NSGs).
Network security: Implemented through security lists/NSGs and route tables.

Networking model (practical view)

For a public NLB, inbound client traffic comes from the internet to the NLB’s public endpoint; backend traffic stays within the VCN to private IPs.
For a private NLB, both clients and backends are internal; clients reach the NLB via VCN routing (local, peering, DRG, FastConnect, or VPN).

Monitoring/logging/governance considerations

Track:
Healthy backend count
Connection/packet/byte rates (exact metrics vary)
Error conditions (health check failures, backend resets)
Use:
OCI Monitoring alarms for thresholds and anomaly indicators
OCI Audit to detect and investigate configuration changes
VCN Flow Logs (where enabled) to debug traffic patterns at subnet/VNIC level (useful when access logs aren’t available)

Simple architecture diagram (Mermaid)

flowchart LR
  C[Client] -->|TCP/80 or UDP/53| NLB[Oracle Cloud\nNetwork Load Balancer]
  NLB --> B1[Backend 1\n10.0.1.10:80]
  NLB --> B2[Backend 2\n10.0.1.11:80]
  HC[Health Checks] -.-> B1
  HC -.-> B2

Production-style architecture diagram (Mermaid)

flowchart TB
  Internet((Internet)) --> Edge[Oracle Cloud Edge\n(DDoS protections at edge)]
  Edge --> PubNLB[Public Network Load Balancer\nSubnet: Public]

  subgraph VCN[VCN 10.0.0.0/16]
    direction TB

    subgraph PublicSubnet[Public Subnet]
      PubNLB
    end

    subgraph PrivateAppSubnets[Private App Subnets (regional)]
      App1[App VM 1\nNSG: app-nsg]
      App2[App VM 2\nNSG: app-nsg]
      AutoScale[Instance Pool / Autoscaling\n(optional)]
    end

    subgraph DataSubnet[Private Data Subnet]
      DB[(Database / Service)]
    end

    PubNLB -->|Forward TCP| App1
    PubNLB -->|Forward TCP| App2
    App1 --> DB
    App2 --> DB
  end

  Ops[Monitoring + Alarms] --- PubNLB
  Audit[OCI Audit] --- PubNLB
  Bastion[OCI Bastion\n(Admin SSH)] --> App1
  Bastion --> App2

8. Prerequisites

Before you start, confirm the following.

Tenancy and compartment requirements

An active Oracle Cloud tenancy.
Access to a compartment where you can create networking and compute resources.

Permissions / IAM policies

You typically need permissions to: – Create/manage Network Load Balancer – Use/manage VCNs, subnets, NSGs/security lists – Read instances and private IPs (if needed for backend discovery)

OCI IAM policy syntax and exact resource-type names can vary by service family. Use the official IAM policy reference and Network Load Balancer documentation to confirm the correct policy statements for your environment: – https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm – https://docs.oracle.com/en-us/iaas/Content/NetworkLoadBalancer/home.htm

Billing requirements

Network Load Balancer is generally a paid service (usage-based). Oracle Cloud Free Tier/Always Free eligibility varies by resource type and region—verify in official docs and pricing.

Tools (recommended)

Oracle Cloud Console (web UI)
OCI CLI (optional but useful): https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm
SSH client to connect to compute instances
Optional: Terraform OCI provider for IaC: https://registry.terraform.io/providers/oracle/oci/latest/docs

Region availability

Network Load Balancer is not necessarily available in all regions or may have region-specific constraints. Verify region availability in the official documentation.

Quotas/limits

Plan for limits such as: – Maximum number of load balancers per compartment – Maximum listeners/backend sets/backends – Bandwidth/throughput shaping constraints (service-defined)

Check current limits here: – https://docs.oracle.com/en-us/iaas/Content/General/Concepts/servicelimits.htm

Prerequisite services

For the hands-on lab you will need: – VCN with at least: – One public subnet (for a public NLB) – One private subnet (for backend instances) – Two compute instances (VMs) in the private subnet (or public if you simplify, though private is recommended)

9. Pricing / Cost

Oracle Cloud Network Load Balancer pricing is usage-based. Exact prices vary by region and can change, so do not rely on static numbers in a tutorial.

Pricing dimensions (typical model)

From Oracle Cloud pricing patterns for networking services, Network Load Balancer costs commonly depend on some combination of: – Load balancer hours (how long the NLB exists/provisions) – Bandwidth/throughput capacity or data processed (GB in/out through the NLB) – Possibly additional features (if applicable in your region)

For authoritative pricing, use: – Official Oracle Cloud price list (Networking section): https://www.oracle.com/cloud/price-list/ – OCI cost estimator: https://www.oracle.com/cloud/costestimator.html – Network Load Balancer documentation: https://docs.oracle.com/en-us/iaas/Content/NetworkLoadBalancer/home.htm

Free tier

Oracle Cloud Free Tier includes some Always Free resources, but load balancer free usage is not guaranteed and varies by service and region. Verify current Free Tier coverage: – https://www.oracle.com/cloud/free/

Main cost drivers

Number of NLBs and how long they run (dev/test environments often forget to delete them).
Traffic volume (GB processed) in production.
Cross-zone/region/hybrid network patterns (if traffic traverses gateways or DRG, additional networking charges may apply).
Backend compute costs (VMs/bare metal), which usually exceed LB cost for heavy workloads.

Hidden or indirect costs to watch

Data egress to the internet: Public internet egress is commonly billed separately.
Inter-region traffic: If you front multi-region architectures, inter-region data transfer can become a major cost.
Logging/monitoring ingestion: If you enable VCN flow logs or other logs at high volume, Logging ingestion/storage can add costs.
NAT Gateway / Bastion: If used for patching or admin access, they may have their own costs.

Cost optimization tips

Use private NLBs for internal traffic when possible (can reduce exposure and may reduce egress-related costs depending on architecture).
Right-size environments:
For dev/test, keep NLB lifetime short and automate cleanup.
Prefer regional subnets and keep traffic inside the region/VCN when possible.
Set Monitoring alarms on unusual traffic spikes and on “resource exists” checks (tag-based governance helps).

Example low-cost starter estimate (no fabricated numbers)

A low-cost lab environment typically includes: – 1 Network Load Balancer running for a few hours – 2 small compute instances – Minimal traffic (curl tests)

To estimate: 1. In the cost estimator, add Network Load Balancer for your region and specify the smallest practical usage duration. 2. Add Compute for the instances and any boot volume/storage. 3. Add any internet egress if you expect significant external traffic.

Example production cost considerations

In production, estimate and track: – Expected sustained throughput and peak traffic windows – Number of environments (prod, staging, DR) – Multi-region strategy (active-active doubles LB footprint) – Logging and monitoring ingestion volume – Egress patterns (internet vs private circuits)

10. Step-by-Step Hands-On Tutorial

This lab deploys a public Network Load Balancer that distributes TCP/80 traffic to two private backend VMs running NGINX. You’ll verify traffic distribution and backend health, then clean up.

Objective

Create an Oracle Cloud Network Load Balancer with: – One TCP listener on port 80 – One backend set with two backend servers – Health checks so only healthy backends receive traffic – A public endpoint for testing with curl

Lab Overview

You will: 1. Create networking (VCN + subnets + NSGs/security rules). 2. Launch two backend compute instances and install NGINX. 3. Create a Network Load Balancer, listener, backend set, and backends. 4. Validate load balancing behavior. 5. Troubleshoot common issues. 6. Clean up all resources to stop billing.

Cost note: This lab may incur charges for the load balancer, compute, and data transfer. Use a short duration and delete resources afterward.

Step 1: Create a compartment and choose a region

In the Oracle Cloud Console, confirm the region you will use.
Create or select a compartment for the lab (recommended).

Expected outcome: You have a dedicated compartment and region selected for all lab resources.

Step 2: Create a VCN with public and private subnets

You can use the VCN wizard or create manually. The key is to have: – A public subnet for the public NLB – A private subnet for backend instances

Console path: Networking → Virtual Cloud Networks → Create VCN

Recommended (example) CIDRs: – VCN: 10.0.0.0/16 – Public subnet: 10.0.0.0/24 – Private subnet: 10.0.1.0/24

Ensure: – Public subnet has a route to an Internet Gateway – Private subnet has no direct route to the Internet Gateway (optional NAT gateway if you need outbound patching)

Expected outcome: VCN created with one public subnet and one private subnet.

Step 3: Create Network Security Groups (recommended)

Use NSGs for clearer, least-privilege rules.

Create two NSGs: 1. nlb-public-nsg (attached to the NLB, if supported by the NLB configuration in your region) 2. app-backend-nsg (attached to backend VMs)

Rules to add:

A) NLB ingress rule (allow clients to reach the NLB) – Ingress to nlb-public-nsg: – Source: 0.0.0.0/0 – Protocol: TCP – Destination port: 80

B) Backend ingress rule (allow NLB to reach backends on 80) – Ingress to app-backend-nsg: – Source: the public subnet CIDR (example 10.0.0.0/24) or the NLB subnet CIDR – Protocol: TCP – Destination port: 80

If NSG attachment to NLB is not available in your region/tenant, apply equivalent rules using security lists on the subnets. Always follow current OCI documentation for the NLB networking model.

Expected outcome: Security rules exist for inbound TCP/80 to the NLB and from the NLB subnet to backend servers.

Step 4: Launch two backend compute instances in the private subnet

Launch two VMs (Oracle Linux is a common choice).

Console path: Compute → Instances → Create instance

For each instance: – Subnet: Private subnet – Assign public IP: No (keep private) – NSG: attach app-backend-nsg – Add an SSH key you control

Install NGINX and set unique index pages

Connect through a bastion, private access method, or temporarily assign a public IP for lab purposes (least secure). A safer approach is OCI Bastion: – https://docs.oracle.com/en-us/iaas/Content/Bastion/home.htm

Once connected via SSH, run:

sudo dnf -y install nginx
sudo systemctl enable --now nginx

echo "Hello from $(hostname) - $(hostname -I)" | sudo tee /usr/share/nginx/html/index.html
sudo firewall-cmd --permanent --add-service=http || true
sudo firewall-cmd --reload || true

Repeat on both instances.

Expected outcome: – Both VMs run NGINX and respond on TCP/80. – Each serves a slightly different page so you can see load distribution.

Step 5: Create the Network Load Balancer (public)

Console path: Networking → Network Load Balancers → Create Network Load Balancer

Configure: – Type: Public – Subnet: Public subnet – (Optional) NSG: attach nlb-public-nsg if the UI supports it for NLB in your region

When the NLB is created, note: – The public IP address (or public endpoint information)

Expected outcome: NLB exists with a public endpoint.

Step 6: Create a backend set and add backends

In the NLB configuration: 1. Create a backend set (name example: web-bes) 2. Add backends using the private IPs of the two VMs: – Backend 1: 10.0.1.10:80 (example) – Backend 2: 10.0.1.11:80 (example)

Configure a health check: – Use a simple TCP health check to port 80 (most universally supported for Layer 4). – Interval/timeout/retries: use defaults unless you have a reason to tune.

Expected outcome: – Backends appear in the backend set. – After a short time, backend health should become Healthy.

Step 7: Create a TCP listener on port 80

Create a listener: – Protocol: TCP – Port: 80 – Default backend set: web-bes

Expected outcome: Listener becomes active; NLB starts accepting connections on port 80.

Step 8: Validate from your local machine

From your laptop/terminal:

NLB_IP="<your_nlb_public_ip>"
curl -s "http://$NLB_IP/"
curl -s "http://$NLB_IP/"
curl -s "http://$NLB_IP/"

You should see alternating responses such as:

Hello from web-1 - 10.0.1.10 ...
Hello from web-2 - 10.0.1.11 ...

Expected outcome: Requests succeed and rotate across both backends over multiple attempts.

Validation

Use this checklist: – NLB shows the listener as Active – Backend set shows 2 healthy backends – curl http://<NLB_IP>/ returns content – If one backend is stopped, traffic still succeeds (after health check detects failure)

To test failover: 1. Stop NGINX on one backend: bash sudo systemctl stop nginx 2. Wait for the health check interval to mark it unhealthy. 3. Run curl several times again.

Expected outcome: Only the healthy backend responds.

Troubleshooting

Common issues and fixes:

Backends show “Unhealthy” – Check backend VM is listening on port 80: bash sudo ss -lntp | grep ':80' – Check OS firewall allows TCP/80 (Oracle Linux firewall-cmd steps above). – Check app-backend-nsg ingress allows TCP/80 from the NLB subnet CIDR. – Verify route tables allow traffic within the VCN (usually automatic for intra-VCN).
NLB public IP doesn’t respond – Confirm the NLB is in a public subnet with a route to an Internet Gateway. – Confirm NLB ingress security rule allows TCP/80 from 0.0.0.0/0. – Check any local corporate firewall restrictions.
Only one backend ever responds – Confirm both backends are healthy. – Ensure both are in the backend set and port is correct. – Some load distribution behaviors can be connection/flow-based; try closing connections between tests (curl does this by default) and repeat.
SSH access to private instances – Use OCI Bastion or a jump host. – Avoid assigning public IPs to private tier in real deployments.

Cleanup

To stop ongoing charges, delete resources in this order:

Delete the Network Load Balancer (and any reserved public IPs if separately billed/managed).
Terminate the two compute instances.
Delete NSGs (optional if deleting the VCN).
Delete the VCN (this will remove subnets, route tables, gateways—confirm dependencies first).

Expected outcome: All lab resources are removed, and billing stops for those resources.

11. Best Practices

Architecture best practices

Use Network Load Balancer for TCP/UDP and Oracle Cloud Load Balancer when you need HTTP-aware features.
Keep backends in private subnets; expose only the load balancer.
Distribute backend instances across fault domains/availability domains where applicable.
Design for failure:
Health checks should reflect real service readiness
Automate backend replacement (instance pools, autoscaling, or CI-driven rebuild)

IAM/security best practices

Use least privilege:
Separate roles for network admins vs app operators.
Use compartments to isolate environments:
network-prod, app-prod, network-nonprod, etc.
Require tags (if your governance model supports tag defaults and tag enforcement).

Cost best practices

Delete unused load balancers in dev/test.
Monitor traffic volume and egress patterns; optimize data flows (keep traffic within region/VCN when possible).
Use alarms to detect abnormal traffic spikes early.

Performance best practices

Prefer L4 load balancing for simple TCP/UDP services where you don’t need proxy behavior.
Ensure backend instances have sufficient NIC throughput and OS tuning for expected concurrency.
Validate health check intervals:
Too frequent can add noise/overhead
Too slow delays failover

Reliability best practices

Use at least two backends for HA.
Keep immutable infrastructure patterns (replace instances rather than patching in place, where feasible).
Consider multi-region DR if the service is business critical (front with DNS failover / traffic management).

Operations best practices

Create dashboards and alarms:
Healthy backends count
Connection/throughput anomalies
Use change control for NLB listener/backend changes.
Record configuration in IaC (Terraform) to prevent drift.

Governance/tagging/naming best practices

Naming convention example:
nlb-<env>-<app>-<region>-public
bes-<env>-<app>-tcp80
Tags:
CostCenter, Owner, Environment, DataClassification

12. Security Considerations

Identity and access model

OCI IAM controls who can:
Create/delete NLBs
Modify listeners/backend sets/backends
Attach NLBs to subnets/NSGs
Scope access by compartment and use separate compartments for prod vs non-prod.

Encryption

Network Load Balancer is Layer 4; encryption strategy depends on your design:
If your protocol is TLS, terminate TLS at the backend (TLS passthrough) or use a Layer 7/termination-capable service when required.
For any TLS termination features on NLB (if available in your region), verify in official docs and manage certificates properly.

Network exposure

Public NLB:
Restrict inbound ports to the minimum required (e.g., TCP/443 only).
Consider IP allowlists where possible.
Private NLB:
Limit who can reach it via NSGs and routing (DRG route tables, security rules).

Secrets handling

Avoid embedding secrets in instance user-data or images.
Use OCI Vault for secrets/keys where appropriate:
https://docs.oracle.com/en-us/iaas/Content/KeyManagement/home.htm

Audit/logging

Use OCI Audit to track configuration changes to the NLB and networking resources.
For traffic troubleshooting, use VCN Flow Logs where appropriate; verify if NLB provides native traffic logs in your region.

Compliance considerations

Ensure network segmentation meets compliance (PCI, HIPAA, SOC2) requirements:
Backends in private subnet
Strict ingress rules
Controlled admin access (Bastion)
Use tagging and compartments to support auditability and cost allocation.

Common security mistakes

Leaving NLB listener open to 0.0.0.0/0 on admin/debug ports.
Allowing backend instances to have public IPs “temporarily” and forgetting to remove them.
Overly broad NSG rules (e.g., allowing all VCN traffic to backend ports).
No monitoring/alarms on backend health, leading to silent partial outages.

Secure deployment recommendations

Default to private subnets for backends.
Use Bastion or private connectivity for administration.
Enforce least-privilege NSG rules:
NLB subnet → backend ports only
Client sources → NLB listener ports only
Use IaC with code review for NLB and security changes.

13. Limitations and Gotchas

Always confirm current limitations in official docs (service capabilities evolve). Common limitations/gotchas for Layer 4 load balancers include:

Not Layer 7: no HTTP path routing, header-based routing, cookie persistence, or rewrites.
Observability gaps vs L7: detailed HTTP access logs and request-level tracing may not exist (or may differ). Use app-level logs and VCN flow logs as needed.
Health check nuance: TCP health checks confirm port reachability, not full application correctness.
Security rule complexity: NLB + private subnets commonly fail due to missing NSG rules or wrong CIDR sources.
Subnet placement constraints: NLB is attached to specific subnet(s); multi-subnet designs differ from L7 load balancers. Verify current NLB subnet requirements.
Quotas: listener limits, backend limits, and NLB count per compartment can block deployments.
Traffic distribution behavior: some L4 load balancers distribute by connection/flow; repeated requests from one client may look “sticky” depending on client behavior.
Hybrid routing: when clients come from on-prem, ensure DRG route tables and security rules permit traffic to the NLB and backends.
Data transfer billing surprises: internet egress and inter-region transfer can dominate costs at scale.

14. Comparison with Alternatives

Alternatives inside Oracle Cloud

Oracle Cloud Load Balancer (the broader load balancer service): better for HTTP/HTTPS and advanced features.
DNS-based distribution / Traffic Management (where applicable): good for global routing and failover, not a replacement for L4/L7 balancing.
Self-managed HAProxy/Nginx/Envoy on Compute: maximum flexibility at the cost of operations burden.

Alternatives in other clouds

AWS Network Load Balancer (L4)
Azure Load Balancer (L4)
Google Cloud TCP/UDP Load Balancing (regional/global variants)

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Oracle Cloud Network Load Balancer	TCP/UDP services needing low latency	Managed HA, L4 performance, VCN-native	Not L7; fewer HTTP features	Non-HTTP or simple TCP/UDP entry points; private/internal endpoints
Oracle Cloud Load Balancer	HTTP/HTTPS and application delivery	More app-aware capabilities (routing, TLS termination features depending on config)	More overhead; not ideal for raw UDP workloads	Web apps, HTTP APIs, need L7 controls
OCI DNS / Traffic Management (where applicable)	Global routing/failover	Great for multi-region steering	Not a per-connection load balancer	Multi-region active/active steering combined with regional LBs
Self-managed HAProxy/Nginx on Compute	Custom features or edge cases	Full control, custom modules	Operational burden, patching, HA design	When managed services don’t meet requirements or for specialized protocols
AWS NLB / Azure Load Balancer / GCP TCP/UDP LB	Cross-cloud parity	Mature ecosystems, familiar patterns	Different IAM/networking models	If you’re implementing the same architecture across multiple clouds

15. Real-World Example

Enterprise example: Hybrid financial services risk engine

Problem: An on-prem risk engine must call OCI-hosted pricing services over TCP with strict uptime and private connectivity.
Proposed architecture:
On-prem → FastConnect → DRG → VCN
Private Network Load Balancer fronting multiple pricing service instances in private subnets
Backends spread across fault domains/availability domains (where available)
Monitoring alarms on backend health and latency indicators
Why Network Load Balancer was chosen:
L4 TCP service, no need for HTTP routing
Private endpoint aligns with compliance and segmentation
Managed HA reduces operations risk
Expected outcomes:
Stable endpoint for on-prem clients
Automated failover from unhealthy instances
Reduced change windows (backend rotation without client-side changes)

Startup/small-team example: IoT telemetry ingestion

Problem: A small team ingests telemetry from devices over a custom TCP protocol and needs to scale quickly.
Proposed architecture:
Public Network Load Balancer on TCP/9000
Backends are autoscaled compute instances running ingestion service
Data stored in managed database/streaming service (depending on design)
Alerts when backend health drops below threshold
Why Network Load Balancer was chosen:
Supports generic TCP without forcing HTTP
Simple operational model
Allows the team to keep backends private and replace them frequently
Expected outcomes:
Smooth scaling during device onboarding waves
Fewer outages due to single instance failures
Simpler deployments with immutable backend replacement

16. FAQ

Is Oracle Cloud Network Load Balancer Layer 4 or Layer 7?
Network Load Balancer is primarily a Layer 4 service for TCP and UDP traffic. If you need HTTP-aware routing, evaluate Oracle Cloud Load Balancer.
Can I use Network Load Balancer for HTTP/HTTPS web apps?
You can forward TCP/80 or TCP/443, but you won’t get Layer 7 features like path routing. For typical web apps, Oracle Cloud Load Balancer is often a better fit.
Does Network Load Balancer support UDP?
Yes, UDP is a key use case for Network Load Balancer.
Can I create an internal-only load balancer?
Yes. Use a private Network Load Balancer in a private subnet and ensure clients have private network reachability.
Do my backend servers need public IP addresses?
No. A common best practice is to keep backends on private IPs in private subnets.
How does health checking work?
The NLB performs health checks (often TCP-based) to decide whether a backend should receive traffic. Configure intervals and thresholds appropriate to your application’s recovery time.
What is the most common reason for unhealthy backends?
Security rules: missing NSG/security list ingress allowing the NLB subnet to reach backend ports, or OS firewall blocking the port.
Can I attach Network Load Balancer to multiple subnets?
Subnet attachment models vary by load balancer type and OCI implementation. Verify in official docs for current NLB subnet requirements in your region.
How do I do TLS termination?
If you need TLS termination at the load balancer, evaluate Oracle Cloud Load Balancer or confirm whether your NLB configuration supports it (verify in official docs). Many L4 designs do TLS passthrough and terminate on the backend.
Does Network Load Balancer preserve the client source IP?
Source IP preservation behavior can depend on the service and configuration. Verify in official docs and validate with packet captures or application logs.
Can I use Network Load Balancer with Kubernetes (OKE)?
OKE commonly provisions Oracle Cloud Load Balancer for Service type=LoadBalancer. NLB integration may be possible depending on OCI/OKE features and annotations—verify in official OKE docs.
How do I monitor Network Load Balancer health?
Use OCI Monitoring metrics and create alarms on healthy backend count and traffic anomalies. Use OCI Audit for configuration changes.
How do I restrict who can change the load balancer?
Use compartment-scoped IAM policies and separate admin roles. Limit “manage” permissions to a small group.
What happens during backend maintenance?
Put backend into maintenance by stopping the service or removing it from the backend set; health checks should mark it unhealthy and drain traffic (depending on behavior). Plan maintenance windows and validate.
Is Network Load Balancer global?
It is generally regional in scope and attached to regional networking constructs. Use DNS/traffic steering for multi-region architectures.
What is the difference between NLB and a reverse proxy?
NLB is a managed L4 traffic distributor; a reverse proxy is typically L7 and can modify HTTP traffic. Choose based on protocol needs and operational preference.
How do I estimate cost accurately?
Use the official OCI price list and cost estimator for your region and expected traffic profile. Costs are sensitive to runtime duration and data processed.

17. Top Online Resources to Learn Network Load Balancer

Resource Type	Name	Why It Is Useful
Official documentation	Network Load Balancer docs: https://docs.oracle.com/en-us/iaas/Content/NetworkLoadBalancer/home.htm	Primary reference for capabilities, limits, and configuration steps
Official documentation	OCI Networking overview: https://docs.oracle.com/en-us/iaas/Content/Network/home.htm	Helps you understand VCNs, subnets, routing, gateways, and security
Official documentation	OCI IAM overview: https://docs.oracle.com/en-us/iaas/Content/Identity/home.htm	Required to secure who can manage NLB resources
Official pricing	Oracle Cloud Price List: https://www.oracle.com/cloud/price-list/	Authoritative pricing categories and SKUs (region-dependent)
Official calculator	OCI Cost Estimator: https://www.oracle.com/cloud/costestimator.html	Build realistic estimates for lab and production
Official limits	Service Limits: https://docs.oracle.com/en-us/iaas/Content/General/Concepts/servicelimits.htm	Understand quotas and request limit increases
Architecture center	Oracle Architecture Center: https://docs.oracle.com/en/solutions/	Reference architectures and patterns for production designs
Official CLI docs	OCI CLI install/use: https://docs.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm	Automate NLB provisioning and operations
Terraform provider docs	OCI Terraform Provider: https://registry.terraform.io/providers/oracle/oci/latest/docs	Infrastructure-as-code patterns for repeatable deployments
Official tutorials	Oracle Cloud Tutorials (landing): https://docs.oracle.com/en/learn/	Hands-on learning paths; search for load balancing and networking labs
Official YouTube	Oracle Cloud Infrastructure channel: https://www.youtube.com/@OracleCloudInfrastructure	Videos and walkthroughs (search within channel for load balancing)
Community (reputable)	OCI GitHub org: https://github.com/oracle	Samples and tooling; validate relevance and currency to NLB

18. Training and Certification Providers

The following training providers may offer Oracle Cloud, networking, and load balancing-oriented learning. Confirm current course catalogs directly on their sites.

Institute	Suitable Audience	Likely Learning Focus	Mode	Website
DevOpsSchool.com	Beginners to working engineers	DevOps, cloud operations, CI/CD, networking fundamentals	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Students, junior engineers	SCM, DevOps foundations, cloud basics	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud/ops practitioners	Cloud operations, monitoring, reliability practices	Check website	https://cloudopsnow.in/
SreSchool.com	SREs, platform teams	SRE principles, observability, reliability engineering	Check website	https://sreschool.com/
AiOpsSchool.com	Ops + automation teams	AIOps concepts, automation, monitoring analytics	Check website	https://aiopsschool.com/

19. Top Trainers

These sites may function as trainer profiles, training portals, or platforms. Verify offerings, credentials, and course relevance before purchase.

Platform/Site	Likely Specialization	Suitable Audience	Website
RajeshKumar.xyz	DevOps/cloud coaching (check specifics)	Beginners to intermediate engineers	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training and mentoring	DevOps engineers, SREs	https://www.devopstrainer.in/
devopsfreelancer.com	DevOps consulting/training marketplace (verify)	Teams seeking short-term help	https://devopsfreelancer.com/
devopssupport.in	Operational support and training resources (verify)	Ops teams and engineers	https://www.devopssupport.in/

20. Top Consulting Companies

These organizations may provide consulting services related to cloud architecture, DevOps, and operations. Validate service scope and references directly with each provider.

Company	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website
cotocus.com	Cloud/DevOps services (verify specialization)	Architecture, migrations, operations	Designing VCN + NLB patterns; implementing monitoring/alarms; IaC rollout	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training	DevOps transformation, platform engineering	Standardizing NLB + compute deployment patterns; CI/CD + Terraform enablement	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify portfolio)	Automation, reliability, operations	Building production-ready OCI networking landing zone; NLB operational runbooks	https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before this service

To use Oracle Cloud Network Load Balancer effectively, learn: – OCI fundamentals: compartments, VCNs, subnets, route tables, gateways – IP networking: CIDR, TCP vs UDP, stateful firewalls, NAT – Security basics: least privilege, NSGs vs security lists – Linux server basics: systemd, firewall, ports, troubleshooting tools (ss, tcpdump, curl)

What to learn after this service

Oracle Cloud Load Balancer (for L7 needs)
OCI DNS and multi-region design (failover and traffic steering)
Observability: Monitoring, Logging, alarms, dashboards, SLOs
IaC: Terraform modules, drift detection, policy-as-code
Advanced networking: DRG, FastConnect, VPN, peering architectures

Job roles that use it

Cloud Engineer / Cloud Network Engineer
Solutions Architect
DevOps Engineer / Platform Engineer
Site Reliability Engineer (SRE)
Security Engineer (network segmentation and exposure)

Certification path (if available)

Oracle offers OCI certifications; availability and names can change. Start by checking Oracle University and OCI certification pages and map your learning plan to: – OCI Foundations – OCI Architect – OCI Networking-focused training (if available)

Verify current certifications here: – https://education.oracle.com/

Project ideas for practice

Build a private NLB fronting an internal TCP service reachable via VPN/DRG.
Deploy blue/green backends and practice safe cutover using backend membership changes.
Create Terraform modules for NLB + NSGs + backend compute and add CI validation.
Implement alarms on backend health and run a chaos test (stop one backend).

22. Glossary

Backend: A target server (usually an IP:port) that receives traffic from the load balancer.
Backend set: A logical group of backends with a shared health check policy.
CIDR: IP address range notation (e.g., 10.0.0.0/16).
Compartment: OCI governance boundary used for access control and cost tracking.
DRG (Dynamic Routing Gateway): OCI gateway for hybrid connectivity (VPN/FastConnect) and advanced routing.
Fault domain: OCI construct for spreading instances across hardware to reduce correlated failures.
Health check: Probe used to decide if a backend should receive traffic.
IAM policy: Authorization rules defining who can manage OCI resources.
Listener: Front-end port/protocol configuration that accepts client traffic.
NSG (Network Security Group): Virtual firewall applied to VNICs/resources to control traffic.
Public subnet: Subnet that can host resources reachable from the internet via an Internet Gateway (with proper routing and security).
Private subnet: Subnet without direct internet exposure (no direct route to Internet Gateway).
Layer 4 (L4): Transport layer (TCP/UDP) load balancing, not application-aware.
VCN (Virtual Cloud Network): OCI virtual network containing subnets, routing, and security controls.

23. Summary

Oracle Cloud Network Load Balancer (in Networking, Edge, and Connectivity) is a managed Layer 4 load balancer for TCP and UDP services. It matters because it provides a stable endpoint, health-based failover, and managed high availability without the operational burden of running your own load balancer fleet.

It fits best in Oracle Cloud architectures where you need low-latency transport load balancing, private backend segmentation, and straightforward scaling. Cost is driven by how long the NLB runs and how much traffic it processes, plus indirect networking costs (especially internet egress). Security success depends on correct IAM policies, subnet routing, and NSG/security list rules—most real-world issues come from misconfigured network controls.

Use Network Load Balancer when you need TCP/UDP distribution and don’t need HTTP-aware routing; choose Oracle Cloud Load Balancer when you need Layer 7 features.

Next learning step: implement the same lab via Terraform and add Monitoring alarms for backend health so you can operate Network Load Balancer like production infrastructure.

rajeshkumar

Category