Home / OCI

OCICheat sheetIntermediate

Advisory: choosing the entry point on OCI - Load Balancer, Network Load Balancer, API Gateway, WAF and DNS steering

How traffic enters an OCI workload decides its security controls and failover behaviour. Match the need to the flexible Load Balancer, Network Load Balancer, API Gateway, WAF and DNS traffic steering, combine them in proven layers, and settle certificates, timeouts and origin protection during design.

Deepak Bhardwaj3 min read

Applies toOCI Flexible Load Balancer, Network Load Balancer, API Gateway, OCI WAF (policies on load balancers), DNS Traffic Management steering policies, Certificates service

Quick map

Need Service
HTTP(S) routing, TLS termination, hostnames/paths Flexible Load Balancer
TCP/UDP pass-through, source IP preservation, high throughput Network Load Balancer
API management: auth (JWT/OAuth, custom authorizer functions), rate limiting, usage plans, request/response transformation API Gateway
Layer 7 protection (OWASP rules, bot management, rate limiting) OCI WAF policy attached to the load balancer
Multi-region failover or geo routing DNS Traffic Management steering policies (failover, geolocation, load balancing)

Proven layers

Users ─► DNS steering (failover between regions) ─► LB + WAF policy ─► app tier (instance pool / OKE ingress)
Partners ─► API Gateway (JWT auth, rate limits, usage plans) ─► private LB / Functions / OKE services
Internal clients ─► private LB / NLB ─► backends (no public exposure)
Databases, custom TCP ─► NLB (private)

Comparison

LB NLB API Gateway
Layer 7 (and 4) 4 7 (API)
WAF Attach WAF policy No Use LB+WAF in front or gateway policies (rate limit, auth)
TLS Terminate / re-encrypt Pass-through Terminate
Private deployment Yes Yes Yes (private gateways)
Cost model Hourly + bandwidth No charge (check) Per API call

Design decisions to settle early

Topic Decide
Certificates OCI Certificates service with auto-renewal vs uploaded certs; expiry alerts (see the expired certificate Sev1 post)
WAF ownership Who tunes rules, how false positives are handled (see the WAF tuning post)
Origin protection Backends in private subnets; NSGs allow only the LB/NLB/API Gateway
Timeouts LB listener idle timeout vs backend keep-alive; API Gateway backend timeout vs function timeout
Health checks Dedicated health endpoints; intervals and thresholds
Failover DNS steering health checks and TTLs; regional LB per region

Traps

Trap Note
Public LB per microservice Use a shared ingress controller in OKE, or hostnames on one LB
DNS failover with long TTLs Clients keep the old answer; keep TTLs short on steered records
API Gateway as the only defence for a public web app Combine with WAF on an LB for web traffic
NLB where you need HTTP features Use LB, or NLB in front of LB only when static IP/pass-through is required

Design review questions

  • Draw the request path with each hop's timeout, TLS termination and health check.
  • What stops someone reaching a backend directly?
  • How are rate limits enforced, and what does an over-limit client see?
  • How does it fail over between ADs/fault domains and regions, and was it tested?

Tip

Put the WAF policy in detection mode for a week before switching to blocking. The logs show which rules would block real traffic, and you tune before customers notice.

Checklist

  • Entry services chosen per traffic type
  • WAF placement and ownership
  • Certificates with auto-renewal and alerts
  • Backends private, NSGs restricted
  • Timeouts and health checks aligned
  • Regional failover with DNS steering tested

Related fixes