{"id":946,"date":"2026-04-17T05:47:13","date_gmt":"2026-04-17T05:47:13","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/oracle-cloud-load-balancer-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-edge-and-connectivity\/"},"modified":"2026-04-17T05:47:13","modified_gmt":"2026-04-17T05:47:13","slug":"oracle-cloud-load-balancer-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-edge-and-connectivity","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/oracle-cloud-load-balancer-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking-edge-and-connectivity\/","title":{"rendered":"Oracle Cloud Load Balancer Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking, Edge, and Connectivity"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking, Edge, and Connectivity<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p>Oracle Cloud Infrastructure (OCI) <strong>Load Balancer<\/strong> is a managed networking service that distributes incoming traffic across multiple backend servers. It helps you build highly available, scalable applications without manually operating a load-balancing fleet.<\/p>\n\n\n\n<p>In simple terms: you put a Load Balancer in front of your app, point users to the Load Balancer, and OCI automatically spreads requests across healthy backend instances so your app stays responsive even if a server fails.<\/p>\n\n\n\n<p>Technically, OCI Load Balancer provides <strong>Layer 4 and Layer 7<\/strong> traffic distribution (depending on listener type), health checks, TLS termination, routing policies, and operational metrics. It is deployed inside your <strong>VCN<\/strong> and subnets, integrates with OCI IAM, Logging, Monitoring, and works with OCI Compute instances and other backends reachable in your network.<\/p>\n\n\n\n<p>The problem it solves: <strong>single-server fragility and scaling pain<\/strong>. Instead of exposing individual servers and hoping they stay healthy, you expose a stable front door (public or private) and let OCI handle failover, health-based routing, and traffic distribution.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Load Balancer?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Official purpose<\/h3>\n\n\n\n<p>OCI <strong>Load Balancer<\/strong> is a managed service that provides <strong>automated traffic distribution<\/strong> to backend servers, improving <strong>availability<\/strong>, <strong>scalability<\/strong>, and <strong>security<\/strong> for applications deployed in Oracle Cloud.<\/p>\n\n\n\n<p>Primary official documentation entry point:<br\/>\nhttps:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Balance\/home.htm<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Core capabilities<\/h3>\n\n\n\n<p>OCI Load Balancer commonly includes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Public and private load balancers<\/strong><\/li>\n<li><strong>Listeners<\/strong> (front-end ports\/protocols) for HTTP, HTTPS, and TCP (feature set varies; verify listener options for your region\/service version in official docs)<\/li>\n<li><strong>Backend sets<\/strong> with health checks and load balancing policies<\/li>\n<li><strong>TLS\/SSL termination<\/strong> and certificate management (upload certificates; integrate with OCI Certificates services where applicable\u2014verify the current recommended approach in docs)<\/li>\n<li><strong>Session persistence<\/strong> (useful for legacy apps)<\/li>\n<li><strong>Connection management and timeouts<\/strong><\/li>\n<li><strong>Observability<\/strong> via OCI Monitoring metrics and OCI Logging (where enabled and supported)<\/li>\n<\/ul>\n\n\n\n<p>OCI also offers a separate service named <strong>Network Load Balancer<\/strong> (NLB) for high-performance Layer 4 use cases. This tutorial focuses on <strong>Load Balancer<\/strong> as the primary service name you provided, and calls out when <strong>Network Load Balancer<\/strong> might be a better fit.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Major components (mental model)<\/h3>\n\n\n\n<p>A typical OCI Load Balancer configuration includes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Load Balancer<\/strong>: The managed resource with a public or private IP frontend.<\/li>\n<li><strong>Subnets<\/strong>: Where the load balancer is placed (one or two subnets depending on region\/AD design).<\/li>\n<li><strong>Listener<\/strong>: Defines protocol\/port on the frontend (e.g., HTTP :80, HTTPS :443).<\/li>\n<li><strong>Backend set<\/strong>: A logical pool of backends (instances\/IPs) plus a health check and load balancing policy.<\/li>\n<li><strong>Backends<\/strong>: Compute instances or IP addresses reachable from the LB subnets.<\/li>\n<li><strong>Health check<\/strong>: Periodic checks (HTTP\/TCP) to determine backend health.<\/li>\n<li><strong>Security rules<\/strong>: Security lists\/NSGs controlling what can reach the LB and what the LB can reach on backends.<\/li>\n<li><strong>Certificates<\/strong> (for HTTPS): Server cert\/key and optional intermediate chain; SNI if you host multiple TLS sites (verify current constraints in docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Service type and scope<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Service type<\/strong>: Managed load balancing (data plane managed by OCI; you control configuration).<\/li>\n<li><strong>Scope<\/strong>: <strong>Regional<\/strong> service deployed into your chosen <strong>VCN subnets<\/strong> within a region. The configuration is managed in a <strong>compartment<\/strong>.<\/li>\n<li><strong>Public vs private<\/strong>:<\/li>\n<li><strong>Public Load Balancer<\/strong> exposes a public IP and is reachable from the internet (subject to network security rules).<\/li>\n<li><strong>Private Load Balancer<\/strong> exposes a private IP for internal traffic only (e.g., east-west or private ingress).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Fit in the Oracle Cloud ecosystem<\/h3>\n\n\n\n<p>OCI Load Balancer sits in the <strong>Networking, Edge, and Connectivity<\/strong> category and commonly integrates with:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>VCN<\/strong> (core networking), <strong>subnets<\/strong>, <strong>route tables<\/strong>, <strong>security lists<\/strong>, <strong>NSGs<\/strong><\/li>\n<li><strong>Compute<\/strong> instances (common backend type)<\/li>\n<li><strong>Container workloads<\/strong> (e.g., Kubernetes services\/ingress patterns\u2014implementation varies; verify current recommended architectures)<\/li>\n<li><strong>OCI DNS<\/strong> for friendly names pointing to the LB IP<\/li>\n<li><strong>OCI WAF<\/strong> (when placing WAF in front of internet-facing apps; integration patterns depend on the specific WAF capabilities and association options\u2014verify in official docs)<\/li>\n<li><strong>Monitoring<\/strong> and <strong>Logging<\/strong> for metrics and logs<\/li>\n<li><strong>IAM<\/strong> and <strong>Audit<\/strong> for governance<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Load Balancer?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Reduce downtime risk<\/strong>: If a backend fails, traffic shifts to healthy backends.<\/li>\n<li><strong>Improve customer experience<\/strong>: More consistent latency and fewer errors under load.<\/li>\n<li><strong>Faster delivery<\/strong>: Teams can scale and update backends without changing the public entry point.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Health-based routing<\/strong>: Only healthy backends receive traffic.<\/li>\n<li><strong>Horizontal scaling<\/strong>: Add\/remove backends to match demand.<\/li>\n<li><strong>TLS termination<\/strong>: Centralize certificate handling and offload crypto from app servers.<\/li>\n<li><strong>Layer 7 features<\/strong>: HTTP routing behaviors (where supported) can simplify application architecture.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Managed infrastructure<\/strong>: No patching\/operating HAProxy\/Nginx fleets for basic load balancing.<\/li>\n<li><strong>Standardized patterns<\/strong>: Consistent configuration model (listeners, backend sets, health checks).<\/li>\n<li><strong>Observability<\/strong>: Metrics and (where enabled) logs help triage production issues.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Controlled exposure<\/strong>: Put only the Load Balancer in a public subnet; keep backends private where possible.<\/li>\n<li><strong>Central policy enforcement<\/strong>: TLS versions\/ciphers (as supported), WAF in front, security rules at the edge.<\/li>\n<li><strong>Auditability<\/strong>: Changes are governed by IAM and recorded in Audit.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Elastic bandwidth (shape-dependent)<\/strong>: Flexible capacity (exact mechanics vary by load balancer type\/shape; verify the current model in docs).<\/li>\n<li><strong>Connection handling<\/strong>: Efficient fan-in for many clients.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Use OCI Load Balancer when you need:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A stable entry point for one or more backend servers<\/li>\n<li>HA for stateless or lightly stateful services<\/li>\n<li>Managed TLS termination<\/li>\n<li>Blue\/green or rolling updates by changing backend membership<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it<\/h3>\n\n\n\n<p>Consider alternatives when:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You only have one backend and do not need HA (though you may still want a stable IP).<\/li>\n<li>You need <strong>extreme Layer 4 performance<\/strong> and minimal features\u2014<strong>Network Load Balancer<\/strong> may fit better.<\/li>\n<li>You need <strong>global anycast<\/strong> style cross-region traffic distribution (OCI has DNS steering\/traffic management patterns; Load Balancer itself is regional).<\/li>\n<li>You need deep API-level management and auth at the edge\u2014OCI <strong>API Gateway<\/strong> may be a better front door for APIs.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Load Balancer used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SaaS and enterprise software<\/li>\n<li>Financial services (customer portals, internal apps)<\/li>\n<li>Retail and e-commerce (web\/mobile backends)<\/li>\n<li>Healthcare (patient portals\u2014ensure compliance controls)<\/li>\n<li>Media and gaming (traffic bursts; multi-backend scaling)<\/li>\n<li>Education and public sector (reliability requirements)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Platform engineering teams standardizing ingress<\/li>\n<li>DevOps\/SRE teams operating production web systems<\/li>\n<li>Security teams enforcing TLS\/WAF controls<\/li>\n<li>Application teams running multi-instance services<\/li>\n<li>Cloud infrastructure teams migrating from on-prem load balancers<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Web applications (HTTP\/HTTPS)<\/li>\n<li>REST\/gRPC-style APIs (verify protocol support and constraints for your use case)<\/li>\n<li>Microservices front doors (often with private LBs internally)<\/li>\n<li>Legacy apps needing session persistence<\/li>\n<li>Internal line-of-business apps<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Two-tier and three-tier apps<\/li>\n<li>Hub-and-spoke VCN designs (LB in spoke or shared services VCN, depending on routing)<\/li>\n<li>DMZ-style public ingress with private backends<\/li>\n<li>Active\/active backend pools for HA<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Real-world deployment contexts<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production<\/strong>: Typically uses private backends, separate subnets, WAF for public apps, strict IAM, monitoring\/alerting, and IaC.<\/li>\n<li><strong>Dev\/Test<\/strong>: Often uses a public LB for convenience, smaller capacity, shorter retention logs, and aggressive cleanup to minimize cost.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic OCI Load Balancer use cases with the \u201cproblem \u2192 fit \u2192 scenario\u201d framing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Highly available website frontend<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A single web server causes outages during failures or maintenance.<\/li>\n<li><strong>Why Load Balancer fits<\/strong>: Health checks and multi-backend distribution provide HA without custom failover scripting.<\/li>\n<li><strong>Scenario<\/strong>: Two Compute instances run NGINX; Load Balancer routes internet traffic to healthy nodes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Blue\/green deployments<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Deployments risk downtime or require complex traffic switching.<\/li>\n<li><strong>Why it fits<\/strong>: You can shift traffic by changing backend set membership or weights\/policies (capabilities vary\u2014verify supported policies).<\/li>\n<li><strong>Scenario<\/strong>: Deploy v2 servers as a new backend set; switch listener to point to it during a release window.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) TLS termination and certificate centralization<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Managing certificates on dozens of servers is error-prone.<\/li>\n<li><strong>Why it fits<\/strong>: Terminate HTTPS at the Load Balancer; backends can run HTTP internally (or re-encrypt if required).<\/li>\n<li><strong>Scenario<\/strong>: Upload a cert chain; serve HTTPS publicly while backends stay on private IPs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Private service ingress for internal applications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Internal consumers need a stable endpoint, but services must not be internet-exposed.<\/li>\n<li><strong>Why it fits<\/strong>: Private Load Balancer provides a private VIP inside your VCN.<\/li>\n<li><strong>Scenario<\/strong>: Internal HR app is reachable only from corporate VPN\/DRG-connected networks.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Scaling API traffic during peak events<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Traffic spikes cause timeouts and uneven load.<\/li>\n<li><strong>Why it fits<\/strong>: Adds a buffer layer and distributes requests across more backends.<\/li>\n<li><strong>Scenario<\/strong>: Add more Compute instances to the backend set before a marketing campaign.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) Multi-tenant ingress with host-based routing (where supported)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Many domains\/services need to share infrastructure while staying isolated.<\/li>\n<li><strong>Why it fits<\/strong>: L7 routing can reduce the number of public IPs and LBs (verify current routing-rule features).<\/li>\n<li><strong>Scenario<\/strong>: <code>api.example.com<\/code> and <code>app.example.com<\/code> route to different backend sets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Legacy sticky sessions<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: An application stores session state locally and breaks if requests bounce between servers.<\/li>\n<li><strong>Why it fits<\/strong>: Session persistence (\u201csticky sessions\u201d) can preserve user experience while you modernize.<\/li>\n<li><strong>Scenario<\/strong>: Enable cookie-based persistence for a legacy Java app.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Canary rollout (limited traffic to new version)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: You want early feedback without full cutover.<\/li>\n<li><strong>Why it fits<\/strong>: Some load balancing policies support gradual shift (verify exact options).<\/li>\n<li><strong>Scenario<\/strong>: 10% traffic goes to vNext backends; increase as error rate stays low.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Backend isolation with NSGs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Backends should only accept traffic from the load balancer, not the internet.<\/li>\n<li><strong>Why it fits<\/strong>: Combine LB + private subnets + NSG rules that only allow LB subnet\/NSG.<\/li>\n<li><strong>Scenario<\/strong>: Backend NSG allows TCP\/80 only from the LB NSG.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Central ingress for multiple application tiers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Different app tiers require different ports\/protocols and health checks.<\/li>\n<li><strong>Why it fits<\/strong>: Multiple listeners and backend sets (within service limits) can consolidate ingress.<\/li>\n<li><strong>Scenario<\/strong>: Port 443 for web UI, port 8443 for admin, each with separate backends.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Reduced operational burden vs self-managed proxies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Teams spend time patching and tuning self-managed HAProxy\/Nginx LBs.<\/li>\n<li><strong>Why it fits<\/strong>: Managed service reduces maintenance overhead and standardizes operations.<\/li>\n<li><strong>Scenario<\/strong>: Replace two custom HAProxy VMs with one OCI Load Balancer plus monitoring\/alerts.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) Migration from on-prem F5\/NetScaler patterns (subset)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: Migrating legacy load-balanced apps to cloud requires familiar constructs.<\/li>\n<li><strong>Why it fits<\/strong>: Listener\/backend-set model maps to common enterprise LB concepts.<\/li>\n<li><strong>Scenario<\/strong>: Lift-and-shift a multi-node app and recreate VIP + pool + health monitor patterns in OCI.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<blockquote>\n<p>Note: OCI evolves quickly. For the definitive list and limits, verify in the official Load Balancer documentation: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Balance\/home.htm<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Public and private load balancers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Creates either internet-facing (public) or internal-only (private) entry points.<\/li>\n<li><strong>Why it matters<\/strong>: Supports both north-south and east-west traffic patterns.<\/li>\n<li><strong>Practical benefit<\/strong>: Secure architectures keep backends private while still providing external access via the LB.<\/li>\n<li><strong>Caveats<\/strong>: Subnet requirements differ; ensure route tables and security rules align with public\/private design.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Listeners (frontend ports\/protocols)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Defines how clients connect (port\/protocol) and where to route requests (backend set).<\/li>\n<li><strong>Why it matters<\/strong>: You can expose multiple services through one load balancer (within limits).<\/li>\n<li><strong>Practical benefit<\/strong>: Standardize HTTP\/HTTPS entry; consolidate IPs.<\/li>\n<li><strong>Caveats<\/strong>: Some advanced L7 routing features may have constraints; confirm supported listener\/routing features in your region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Backend sets and load balancing policies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Groups backends, defines health checks, and load distribution behavior.<\/li>\n<li><strong>Why it matters<\/strong>: Keeps traffic away from unhealthy nodes; spreads load predictably.<\/li>\n<li><strong>Practical benefit<\/strong>: Easier scaling\u2014add\/remove backends with minimal disruption.<\/li>\n<li><strong>Caveats<\/strong>: Policy options and behavior differ across LB types; verify exact policies available.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Health checks<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Probes backends on a specified protocol\/port\/path to determine availability.<\/li>\n<li><strong>Why it matters<\/strong>: Prevents sending traffic to broken instances.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster failure detection and automatic recovery.<\/li>\n<li><strong>Caveats<\/strong>: Misconfigured health checks are a common cause of 503\/502 errors; align check path with app readiness.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">TLS\/SSL termination (HTTPS listeners)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Offloads TLS at the load balancer, using configured certificates.<\/li>\n<li><strong>Why it matters<\/strong>: Centralizes certificate rotation and can reduce CPU load on app servers.<\/li>\n<li><strong>Practical benefit<\/strong>: Backends can run plain HTTP on private networks (or you can re-encrypt if needed).<\/li>\n<li><strong>Caveats<\/strong>: You must manage cert lifecycle and ensure the correct chain; be careful with cipher\/TLS version settings if configurable.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Session persistence<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Attempts to keep a client mapped to the same backend.<\/li>\n<li><strong>Why it matters<\/strong>: Supports legacy apps that aren\u2019t stateless.<\/li>\n<li><strong>Practical benefit<\/strong>: Avoids user session breakage without immediate refactoring.<\/li>\n<li><strong>Caveats<\/strong>: Sticky sessions can reduce load distribution efficiency and complicate scaling; prefer stateless designs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Observability: metrics and (where supported) logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Exposes performance\/health metrics in OCI Monitoring; can emit logs depending on configuration and supported logging features.<\/li>\n<li><strong>Why it matters<\/strong>: You need visibility into 4xx\/5xx rates, backend health, latency, and connection errors.<\/li>\n<li><strong>Practical benefit<\/strong>: Faster incident triage and capacity planning.<\/li>\n<li><strong>Caveats<\/strong>: Logging may require explicit enablement and can add cost (log ingestion\/retention).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integration with OCI networking controls<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: Works with VCN security lists, NSGs, route tables, gateways (Internet\/NAT\/DRG), and DNS.<\/li>\n<li><strong>Why it matters<\/strong>: Load balancing is inseparable from network security and routing.<\/li>\n<li><strong>Practical benefit<\/strong>: Clear blast radius and segmentation.<\/li>\n<li><strong>Caveats<\/strong>: Misaligned rules (LB subnet vs backend subnet rules) are the #1 deployment pitfall.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">High availability design (managed)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does<\/strong>: OCI manages the underlying availability of the load balancing service in the region.<\/li>\n<li><strong>Why it matters<\/strong>: Eliminates the need to run active\/passive LB VMs.<\/li>\n<li><strong>Practical benefit<\/strong>: Simpler HA than self-managed solutions.<\/li>\n<li><strong>Caveats<\/strong>: You still must design backends for HA (multi-AD or multi-FD where applicable) and follow subnet requirements.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>OCI Load Balancer has:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A <strong>control plane<\/strong>: API\/Console operations (create LB, listeners, backend sets, health checks).<\/li>\n<li>A <strong>data plane<\/strong>: Where traffic flows from clients \u2192 LB frontend \u2192 selected backend \u2192 responses.<\/li>\n<\/ul>\n\n\n\n<p>You configure the service through the OCI Console, CLI, SDKs, or IaC (Terraform). OCI runs and maintains the load-balancing infrastructure.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Request \/ data flow<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Client resolves DNS to the Load Balancer IP (public or private).<\/li>\n<li>Client opens a connection to the Load Balancer listener (e.g., TCP\/80 or TCP\/443).<\/li>\n<li>Load Balancer selects a healthy backend using the configured policy.<\/li>\n<li>Load Balancer forwards the request to the backend (usually to the backend\u2019s private IP and port).<\/li>\n<li>Backend responds; the Load Balancer returns the response to the client.<\/li>\n<\/ol>\n\n\n\n<p>If TLS is terminated at the LB:\n&#8211; Client TLS session ends at the LB.\n&#8211; Backend traffic may be unencrypted HTTP (common in private subnets) or re-encrypted (HTTPS to backend), depending on your architecture and compliance requirements.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Control flow (configuration)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>You create the Load Balancer in a <strong>compartment<\/strong>, within a <strong>VCN<\/strong> and <strong>subnets<\/strong>.<\/li>\n<li>You create <strong>backend sets<\/strong> and <strong>listeners<\/strong>.<\/li>\n<li>You attach <strong>backends<\/strong> (Compute instance IPs or other reachable endpoints).<\/li>\n<li>You configure <strong>network security<\/strong> so:<\/li>\n<li>Clients can reach the LB listener.<\/li>\n<li>The LB can reach backend ports.<\/li>\n<li>Health checks can reach backend health endpoints.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCI Compute<\/strong>: backends frequently run on Compute instances.<\/li>\n<li><strong>Instance Pools \/ Autoscaling<\/strong>: scale backends; update LB backend membership (automation approach varies\u2014verify best practice patterns).<\/li>\n<li><strong>OCI DNS<\/strong>: point a DNS record to the LB public IP.<\/li>\n<li><strong>OCI Logging and Monitoring<\/strong>: metrics, alarms, log ingestion.<\/li>\n<li><strong>OCI WAF<\/strong>: protect internet-facing HTTP(S) apps (verify association model for your setup).<\/li>\n<li><strong>OCI Certificates \/ Vault<\/strong>: manage TLS assets (exact service pairing depends on your chosen certificate management approach\u2014verify current recommendations).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<p>A working deployment typically depends on:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>VCN + subnets<\/li>\n<li>Route tables (Internet Gateway for public access; NAT if private backends need outbound)<\/li>\n<li>Security lists and\/or NSGs<\/li>\n<li>Compute instances or other backends<\/li>\n<li>DNS (optional but recommended)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IAM<\/strong> controls who can create\/modify load balancers and related networking resources.<\/li>\n<li><strong>Network security<\/strong> controls traffic: security lists\/NSGs, route tables, and gateways.<\/li>\n<li><strong>Audit<\/strong> logs control-plane changes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Load Balancer is placed in subnets within your VCN.<\/li>\n<li>Public LB requires public subnets (and proper route to Internet Gateway).<\/li>\n<li>Private LB uses private subnets and is reachable only within connected networks (VCN, peering, DRG-connected on-prem).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create alarms on backend health counts, 5xx rates, high latency, and rejected connections (metric names and availability vary; confirm in Monitoring docs).<\/li>\n<li>Use tagging and naming to tie LBs to apps\/environments and support cost allocation.<\/li>\n<li>Use compartments to separate dev\/test\/prod and enforce least privilege.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  U[Users \/ Clients] --&gt;|HTTP\/HTTPS| LB[(OCI Load Balancer&lt;br\/&gt;Public)]\n  LB --&gt;|Health checks + traffic| B1[Backend 1&lt;br\/&gt;Compute instance]\n  LB --&gt;|Health checks + traffic| B2[Backend 2&lt;br\/&gt;Compute instance]\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  DNS[OCI DNS] --&gt; LB[(OCI Load Balancer&lt;br\/&gt;Public Subnets)]\n  Internet[Internet Users] --&gt; DNS\n\n  subgraph VCN[VCN]\n    subgraph Pub[Public Subnets]\n      LB\n      Bastion[Bastion or OCI Bastion Service&lt;br\/&gt;(recommended)]\n    end\n\n    subgraph Priv[Private App Subnets]\n      APP1[App VM\/Pod 1]\n      APP2[App VM\/Pod 2]\n      APP3[App VM\/Pod 3]\n    end\n\n    subgraph Data[Private Data Subnet]\n      DB[(Database)]\n    end\n\n    NAT[NAT Gateway]:::net\n    IGW[Internet Gateway]:::net\n    Logs[OCI Logging]:::ops\n    Mon[OCI Monitoring\/Alarms]:::ops\n  end\n\n  LB --&gt; APP1\n  LB --&gt; APP2\n  LB --&gt; APP3\n  APP1 --&gt; DB\n  APP2 --&gt; DB\n  APP3 --&gt; DB\n\n  Priv --&gt; NAT --&gt; IGW\n  LB --&gt; Logs\n  LB --&gt; Mon\n\n  classDef net fill:#eef,stroke:#99f;\n  classDef ops fill:#efe,stroke:#9c9;\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Tenancy\/account requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Oracle Cloud<\/strong> (OCI) tenancy.<\/li>\n<li>Access to a compartment where you can create networking and load balancing resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions \/ IAM<\/h3>\n\n\n\n<p>You need permissions to manage:\n&#8211; Load balancers\n&#8211; Virtual cloud networks, subnets, route tables, gateways\n&#8211; Compute instances (for backend servers)\n&#8211; Network security (security lists\/NSGs)<\/p>\n\n\n\n<p>OCI IAM policies vary by org structure. If you don\u2019t have admin access, ask for a policy that grants required permissions in your compartment. Verify exact policy verbs\/resources in official IAM docs:\nhttps:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Identity\/home.htm<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Load Balancer is typically a <strong>paid service<\/strong> (Always Free may not cover it fully; verify current Free Tier details).<\/li>\n<li>Ensure your tenancy has billing enabled and a valid payment method if required.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<p>Recommended:\n&#8211; <strong>OCI Console<\/strong> (for the lab steps)\n&#8211; <strong>OCI Cloud Shell<\/strong> (browser-based shell; often preconfigured with OCI CLI\u2014verify in your tenancy\/region)\n&#8211; <strong>OCI CLI<\/strong> (optional but useful): https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/API\/Concepts\/cliconcepts.htm<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Load Balancer is broadly available across OCI regions, but exact features can vary.<\/li>\n<li>Verify your target region supports the specific Load Balancer capabilities you need in the official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas \/ limits<\/h3>\n\n\n\n<p>OCI enforces service limits (quotas), including:\n&#8211; Number of load balancers per region\/compartment\n&#8211; Number of listeners, backend sets, and backends per LB\n&#8211; Bandwidth or shape constraints<\/p>\n\n\n\n<p>Check and request increases if needed:\nhttps:\/\/docs.oracle.com\/en-us\/iaas\/Content\/General\/Concepts\/servicelimits.htm<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services<\/h3>\n\n\n\n<p>For this tutorial you will create\/use:\n&#8211; VCN + subnet(s)\n&#8211; Internet Gateway (for a public LB)\n&#8211; Compute instances (two small servers)\n&#8211; Security lists and\/or NSGs<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<blockquote>\n<p>Pricing changes and is region\/currency dependent. Do not rely on blog posts for exact numbers. Use official OCI pricing pages and the cost estimator for authoritative figures.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Official pricing sources<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI pricing (Networking section): https:\/\/www.oracle.com\/cloud\/price-list\/ (navigate to Networking)  <\/li>\n<li>OCI Cost Estimator: https:\/\/www.oracle.com\/cloud\/cost-estimator.html  <\/li>\n<li>OCI Load Balancing docs: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Balance\/home.htm<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing dimensions (how you are charged)<\/h3>\n\n\n\n<p>OCI Load Balancer pricing typically involves combinations of:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Load balancer hours<\/strong>: per LB, per hour (or partial hour) the LB exists.<\/li>\n<li><strong>Bandwidth \/ capacity<\/strong>: depending on LB shape model (for example flexible bandwidth minimum\/maximum settings). The specific billing dimension depends on the LB type\/shape\u2014verify the current pricing model on the official price list.<\/li>\n<li><strong>Data transfer<\/strong>: internet egress and cross-region traffic can add cost (standard OCI data transfer pricing applies).<\/li>\n<li><strong>Logging<\/strong> (if enabled): log ingestion, storage, and retention costs.<\/li>\n<li><strong>Backends<\/strong>: Compute instances, block volumes, and outbound traffic are separate charges.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Free tier considerations<\/h3>\n\n\n\n<p>OCI has an Always Free tier for some services (notably limited Compute shapes and some networking). <strong>Load Balancer may not be Always Free<\/strong>, or may have limited free allocations depending on current OCI offers. Verify current Free Tier coverage:\nhttps:\/\/www.oracle.com\/cloud\/free\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Main cost drivers<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Number of load balancers<\/strong>: one per environment (dev\/test\/prod) can triple costs.<\/li>\n<li><strong>LB size\/capacity<\/strong>: higher bandwidth\/capacity settings increase cost.<\/li>\n<li><strong>Internet egress<\/strong>: serving large downloads or global traffic can dominate costs.<\/li>\n<li><strong>Logging volume<\/strong>: access logs for high-traffic apps can be significant.<\/li>\n<li><strong>Backend scaling<\/strong>: more instances means more compute and potentially more outbound traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>NAT Gateway<\/strong> charges can apply if you keep backends private but require outbound updates (yum\/apt, container pulls).<\/li>\n<li><strong>WAF<\/strong> (if used) is separate.<\/li>\n<li><strong>Certificates management<\/strong> can carry costs depending on your chosen approach and services used.<\/li>\n<li><strong>Cross-AD or cross-subnet design<\/strong> might influence data path; verify whether any intra-region data transfer charges apply for your architecture.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network\/data transfer implications<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Public LB serving internet users often leads to <strong>internet egress<\/strong> from OCI.<\/li>\n<li>If your backends call external APIs, NAT egress adds additional costs.<\/li>\n<li>Cross-region failover solutions typically rely on DNS steering and replicate data\u2014those components have their own costs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>one LB per environment<\/strong> only when necessary; consolidate where safe (multi-listener\/multi-host routing) while keeping blast radius acceptable.<\/li>\n<li>Start with <strong>minimal capacity<\/strong> and scale up after measuring.<\/li>\n<li>Use <strong>private load balancers<\/strong> for internal services to reduce unnecessary public exposure and possibly reduce egress (depending on client location).<\/li>\n<li>Be intentional with <strong>logging<\/strong>: enable what you need, set retention policies.<\/li>\n<li>Remove idle dev\/test LBs quickly\u2014<strong>LB hours<\/strong> accumulate even when traffic is zero.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (conceptual)<\/h3>\n\n\n\n<p>A small dev setup typically includes:\n&#8211; 1 public Load Balancer (minimum capacity)\n&#8211; 2 small Compute instances as backends\n&#8211; Basic logging (optional)<\/p>\n\n\n\n<p>Your bill will mainly be:\n&#8211; LB hours + capacity\n&#8211; Compute hours\n&#8211; Minimal internet egress for testing<\/p>\n\n\n\n<p>Use the OCI cost estimator with your region and expected bandwidth\/traffic to get a real number.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>In production, plan for:\n&#8211; Higher LB capacity and more backends\n&#8211; WAF (if internet-facing)\n&#8211; Centralized logging and longer retention (costly at scale)\n&#8211; Multiple environments and DR strategy (can double resources)\n&#8211; Data transfer for real user traffic<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<p>This lab builds a small but real web application entry point using OCI Load Balancer and two backend Compute instances.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Create a <strong>public OCI Load Balancer<\/strong> that distributes HTTP traffic across <strong>two web servers<\/strong>, verify distribution and health checks, and clean up resources safely.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will:\n1. Create a VCN (public subnet design for simplicity).\n2. Launch two small Compute instances and install a web server.\n3. Create a public Load Balancer with an HTTP listener and a backend set.\n4. Validate that requests load balance across both backends.\n5. Troubleshoot common issues (security rules, health checks).\n6. Clean up all resources to avoid ongoing charges.<\/p>\n\n\n\n<blockquote>\n<p>Cost note: A public load balancer is usually billable. Keep the lab short and clean up when done.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Choose a compartment and region<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>In the OCI Console, select a <strong>region<\/strong> near you.<\/li>\n<li>Create or choose a <strong>compartment<\/strong> for this lab (recommended):<br\/>\n<strong>Identity &amp; Security \u2192 Compartments \u2192 Create Compartment<\/strong><\/li>\n<li>Record the compartment name. You will create all resources inside it.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: You have a dedicated compartment to isolate lab resources.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create a VCN with Internet connectivity<\/h3>\n\n\n\n<p>For a beginner-friendly setup, use the wizard:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Networking \u2192 Virtual Cloud Networks<\/strong><\/li>\n<li>Click <strong>Create VCN<\/strong><\/li>\n<li>Select <strong>VCN with Internet Connectivity<\/strong><\/li>\n<li>Provide:\n   &#8211; VCN name: <code>lb-lab-vcn<\/code>\n   &#8211; CIDR block: keep default (or choose something like <code>10.0.0.0\/16<\/code>)\n   &#8211; Public subnet: keep default settings (ensure it is public)<\/li>\n<li>Create.<\/li>\n<\/ol>\n\n\n\n<p>This usually creates:\n&#8211; VCN\n&#8211; Internet Gateway\n&#8211; Route table with route to Internet Gateway\n&#8211; A public subnet\n&#8211; Default security list<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: You have a VCN and a public subnet suitable for a public Load Balancer and public Compute instances.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Open the VCN details and confirm:\n  &#8211; An <strong>Internet Gateway<\/strong> exists and is attached.\n  &#8211; The public subnet\u2019s route table has <code>0.0.0.0\/0<\/code> to the Internet Gateway.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create two Compute instances (backend web servers)<\/h3>\n\n\n\n<p>Create two small instances in the same compartment and VCN.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Compute \u2192 Instances \u2192 Create instance<\/strong><\/li>\n<li>Name the first instance: <code>lb-backend-1<\/code><\/li>\n<li>Choose:\n   &#8211; Image: Oracle Linux (or another supported Linux)\n   &#8211; Shape: choose a small\/low-cost shape (Always Free eligible if available in your tenancy\u2014verify current eligibility)\n   &#8211; Networking: select <code>lb-lab-vcn<\/code> and the <strong>public subnet<\/strong>\n   &#8211; Assign a public IPv4 address: <strong>Yes<\/strong> (for easier SSH in this lab)<\/li>\n<li>Create and download\/save SSH keys if needed.<\/li>\n<li>Repeat for the second instance: <code>lb-backend-2<\/code><\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: Two running instances with private IPs (and likely public IPs).<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; On each instance page, record:\n  &#8211; <strong>Private IP<\/strong> (used by the LB backend registration)\n  &#8211; Public IP (for SSH access)<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Install and configure a web server on each backend<\/h3>\n\n\n\n<p>Use SSH to connect and install a simple HTTP server, and customize content so you can see load balancing working.<\/p>\n\n\n\n<p>From your local terminal (or OCI Cloud Shell), SSH into backend 1:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh -i \/path\/to\/private_key opc@&lt;BACKEND1_PUBLIC_IP&gt;\n<\/code><\/pre>\n\n\n\n<p>Install NGINX (Oracle Linux example; commands vary by OS version):<\/p>\n\n\n\n<pre><code class=\"language-bash\">sudo dnf -y install nginx || sudo yum -y install nginx\nsudo systemctl enable --now nginx\necho \"Hello from backend-1\" | sudo tee \/usr\/share\/nginx\/html\/index.html\n<\/code><\/pre>\n\n\n\n<p>Exit and do the same on backend 2:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh -i \/path\/to\/private_key opc@&lt;BACKEND2_PUBLIC_IP&gt;\nsudo dnf -y install nginx || sudo yum -y install nginx\nsudo systemctl enable --now nginx\necho \"Hello from backend-2\" | sudo tee \/usr\/share\/nginx\/html\/index.html\n<\/code><\/pre>\n\n\n\n<p><strong>Expected outcome<\/strong>: Each backend serves a different index page over port 80.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\nFrom your machine:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -s http:\/\/&lt;BACKEND1_PUBLIC_IP&gt;\/\ncurl -s http:\/\/&lt;BACKEND2_PUBLIC_IP&gt;\/\n<\/code><\/pre>\n\n\n\n<p>You should see:\n&#8211; <code>Hello from backend-1<\/code>\n&#8211; <code>Hello from backend-2<\/code><\/p>\n\n\n\n<p>If curl fails, you likely need to open port 80 in the subnet security list\/NSG.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Open network security for HTTP (backends and load balancer)<\/h3>\n\n\n\n<p>For this lab, you need to allow:\n&#8211; Internet \u2192 Load Balancer (TCP\/80)\n&#8211; Load Balancer \u2192 backends (TCP\/80)\n&#8211; Health checks (typically same as backend port\/path)<\/p>\n\n\n\n<p>If you used default security lists, you may need to add <strong>ingress<\/strong> rules. A safe baseline for the lab:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Networking \u2192 Virtual Cloud Networks \u2192 lb-lab-vcn<\/strong><\/li>\n<li>Open the <strong>public subnet<\/strong><\/li>\n<li>Open the associated <strong>security list<\/strong> (or NSG if you\u2019re using NSGs)<\/li>\n<\/ol>\n\n\n\n<p>Add ingress rule:\n&#8211; Source CIDR: <code>0.0.0.0\/0<\/code>\n&#8211; IP Protocol: TCP\n&#8211; Destination port: 80<\/p>\n\n\n\n<blockquote>\n<p>Security warning: Opening <code>0.0.0.0\/0<\/code> is fine for a short lab, but in production you\u2019d restrict sources and\/or place backends in private subnets.<\/p>\n<\/blockquote>\n\n\n\n<p><strong>Expected outcome<\/strong>: Port 80 is reachable (at least to the LB; and in this simplified lab, also to instances).<\/p>\n\n\n\n<p><strong>Verification<\/strong>\nRe-run:<\/p>\n\n\n\n<pre><code class=\"language-bash\">curl -I http:\/\/&lt;BACKEND1_PUBLIC_IP&gt;\/\n<\/code><\/pre>\n\n\n\n<p>Should return <code>HTTP\/1.1 200 OK<\/code> (or similar).<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: Create the Load Balancer<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Networking \u2192 Load Balancers<\/strong><\/li>\n<li>Click <strong>Create load balancer<\/strong><\/li>\n<li>\n<p>Choose:\n   &#8211; Load balancer name: <code>lb-lab-public<\/code>\n   &#8211; Visibility: <strong>Public<\/strong>\n   &#8211; Virtual cloud network: <code>lb-lab-vcn<\/code>\n   &#8211; Subnet(s): select the public subnet  <\/p>\n<ul>\n<li>In regions with multiple availability domains, OCI Load Balancer may require <strong>two subnets in different ADs<\/strong> for high availability. If prompted, create\/select a second public subnet in another AD. Follow the console guidance for your region.<\/li>\n<li>Shape\/bandwidth: choose the smallest suitable option (often \u201cFlexible\u201d with a minimum bandwidth). <strong>Do not guess<\/strong>; choose the console default\/minimum for low cost, and verify the pricing implications on the official pricing page.<\/li>\n<\/ul>\n<\/li>\n<li>\n<p>Create.<\/p>\n<\/li>\n<\/ol>\n\n\n\n<p>Provisioning can take a few minutes.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: Load Balancer is in \u201cActive\u201d state and has a public IP address.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; On the LB details page, record the <strong>Public IP address<\/strong>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7: Create a backend set with health check<\/h3>\n\n\n\n<p>In the Load Balancer details:\n1. Go to <strong>Backend Sets \u2192 Create Backend Set<\/strong>\n2. Name: <code>web-bes<\/code>\n3. Policy: choose a default (e.g., round robin) if presented\n4. Health check:\n   &#8211; Protocol: HTTP\n   &#8211; Port: 80\n   &#8211; URL path: <code>\/<\/code>\n   &#8211; Interval\/timeout: leave defaults for now\n5. Create.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: Backend set exists and is ready for backends.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 8: Add the two backends to the backend set<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Open backend set <code>web-bes<\/code><\/li>\n<li>Click <strong>Add backends<\/strong><\/li>\n<li>Add each backend (choose instance-based selection or IP-based):\n   &#8211; Backend 1: IP = <code>&lt;BACKEND1_PRIVATE_IP&gt;<\/code>, port = 80\n   &#8211; Backend 2: IP = <code>&lt;BACKEND2_PRIVATE_IP&gt;<\/code>, port = 80<\/li>\n<li>Save.<\/li>\n<\/ol>\n\n\n\n<p>Wait for health to show as <strong>OK<\/strong> (may take a minute or two).<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: Both backends become healthy.<\/p>\n\n\n\n<p><strong>Verification<\/strong>\n&#8211; Backend set page shows health status as \u201cOK\u201d for both backends.\n&#8211; If health is \u201cCritical\u201d or \u201cUnknown,\u201d go to Troubleshooting below.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 9: Create an HTTP listener on port 80<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Go to <strong>Listeners \u2192 Create Listener<\/strong><\/li>\n<li>Name: <code>http-80<\/code><\/li>\n<li>Protocol: HTTP<\/li>\n<li>Port: 80<\/li>\n<li>Default backend set: <code>web-bes<\/code><\/li>\n<li>Create.<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: Listener is active and routes traffic to the backend set.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Step 10 (Optional but recommended): Point DNS to the Load Balancer<\/h3>\n\n\n\n<p>If you own a domain and use OCI DNS:\n&#8211; Create an <code>A<\/code> record like <code>app.example.com<\/code> \u2192 LB public IP.<\/p>\n\n\n\n<p>If not, you can test using the IP directly.<\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: You have a stable hostname for the app.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>From your terminal, send repeated requests to the LB public IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">for i in {1..10}; do curl -s http:\/\/&lt;LB_PUBLIC_IP&gt;\/; done\n<\/code><\/pre>\n\n\n\n<p>You should see responses alternating between:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><code>Hello from backend-1<\/code><\/li>\n<li><code>Hello from backend-2<\/code><\/li>\n<\/ul>\n\n\n\n<p>Also validate from a browser:\n&#8211; Open <code>http:\/\/&lt;LB_PUBLIC_IP&gt;\/<\/code><\/p>\n\n\n\n<p><strong>Expected outcome<\/strong>: The Load Balancer distributes requests and the service remains available if one backend is stopped.<\/p>\n\n\n\n<p><strong>Extra validation (fail one backend)<\/strong>\n1. Stop nginx on backend 2:\n   <code>bash\n   ssh -i \/path\/to\/private_key opc@&lt;BACKEND2_PUBLIC_IP&gt;\n   sudo systemctl stop nginx<\/code>\n2. Wait for health check to mark backend 2 unhealthy.\n3. Curl again:\n   <code>bash\n   for i in {1..10}; do curl -s http:\/\/&lt;LB_PUBLIC_IP&gt;\/; done<\/code>\nYou should mostly\/only see <code>Hello from backend-1<\/code>.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: Backends show \u201cCritical\u201d (unhealthy)<\/h4>\n\n\n\n<p>Common causes:\n&#8211; Security rules block LB \u2192 backend on port 80\n&#8211; Wrong backend port\n&#8211; Wrong health check path (e.g., <code>\/health<\/code> not present)\n&#8211; Backend service not running (nginx not started)\n&#8211; Using public IP for backend registration instead of private IP (usually you should register the private IP reachable in the VCN)<\/p>\n\n\n\n<p>Fix steps:\n1. Confirm nginx is running:\n   <code>bash\n   sudo systemctl status nginx<\/code>\n2. Confirm backend responds locally:\n   <code>bash\n   curl -I http:\/\/127.0.0.1\/<\/code>\n3. Confirm the backend listens on port 80:\n   <code>bash\n   sudo ss -lntp | grep :80<\/code>\n4. Re-check security list\/NSG rules to allow port 80.\n5. Verify the backend IP you added is the instance <strong>private IP<\/strong>.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: Curl to LB IP times out<\/h4>\n\n\n\n<p>Common causes:\n&#8211; No ingress rule allowing <code>0.0.0.0\/0<\/code> to TCP\/80 for the LB subnet security list\/NSG\n&#8211; LB is private, not public\n&#8211; Route table missing route to Internet Gateway for LB subnet<\/p>\n\n\n\n<p>Fix:\n&#8211; Ensure the LB is <strong>public<\/strong> and in a <strong>public subnet<\/strong> with a route to IGW.\n&#8211; Ensure ingress rule exists to allow TCP\/80.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: You get 502\/503 errors<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>502 often indicates backend connection failure.<\/li>\n<li>503 often indicates no healthy backends.<\/li>\n<\/ul>\n\n\n\n<p>Fix:\n&#8211; Check backend health in the console.\n&#8211; Confirm backend port and health check match your nginx configuration.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\">Problem: Two-subnet requirement blocks creation<\/h4>\n\n\n\n<p>In some regions with multiple availability domains, OCI Load Balancer may require <strong>two subnets<\/strong> (one per AD). Create an additional public subnet in the same VCN in another AD and retry.<\/p>\n\n\n\n<blockquote>\n<p>Verify current subnet requirements in the official docs for your region.<\/p>\n<\/blockquote>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p>To avoid charges, delete resources in this order:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Delete Load Balancer<\/strong>: Networking \u2192 Load Balancers \u2192 <code>lb-lab-public<\/code> \u2192 Delete<br\/>\n   (Wait until deletion completes.)<\/li>\n<li><strong>Terminate Compute instances<\/strong>: Compute \u2192 Instances \u2192 <code>lb-backend-1<\/code>, <code>lb-backend-2<\/code> \u2192 Terminate<\/li>\n<li><strong>Delete VCN<\/strong>: Networking \u2192 Virtual Cloud Networks \u2192 <code>lb-lab-vcn<\/code> \u2192 Delete VCN<br\/>\n   (This deletes subnets, gateways, and related components created by the wizard, if they\u2019re not used elsewhere.)<\/li>\n<\/ol>\n\n\n\n<p><strong>Expected outcome<\/strong>: No billable LB hours continue accruing.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Put <strong>public Load Balancers<\/strong> in <strong>public subnets<\/strong>, and keep <strong>backends in private subnets<\/strong> whenever possible.<\/li>\n<li>Use <strong>multiple backends<\/strong> across fault domains\/availability domains (where available) for resilience.<\/li>\n<li>Keep the load balancer as a <strong>thin routing layer<\/strong>; don\u2019t embed app logic in routing rules if it creates operational complexity.<\/li>\n<li>Consider <strong>separate LBs<\/strong> for workloads with different security postures or change cadences to reduce blast radius.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>least privilege<\/strong> IAM policies; restrict LB management to platform\/network teams.<\/li>\n<li>Use separate <strong>compartments<\/strong> for dev\/test\/prod and enforce guardrails.<\/li>\n<li>Prefer <strong>NSGs<\/strong> for fine-grained, app-centric rules instead of broad subnet-level security lists.<\/li>\n<li>Control who can modify listeners and backend sets; these changes directly impact production traffic.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Delete unused dev\/test load balancers quickly.<\/li>\n<li>Start with minimal capacity settings and scale with evidence.<\/li>\n<li>Avoid excessive log retention; store only what you need for security\/ops.<\/li>\n<li>Consolidate where appropriate (multi-listener \/ host-based routing) but balance against outage blast radius.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Align health checks with <strong>readiness<\/strong> (not just liveness). Ensure the health endpoint verifies dependencies if that\u2019s appropriate.<\/li>\n<li>Tune timeouts for your app (idle timeout, backend connect timeout\u2014exact knobs vary; verify in docs).<\/li>\n<li>Avoid sticky sessions unless necessary; they can reduce distribution quality.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Ensure at least two backends; plan for rolling maintenance.<\/li>\n<li>Use automation (Terraform\/Resource Manager) to recreate LBs consistently.<\/li>\n<li>Design DNS with reasonable TTLs; for DR, combine with DNS steering or run multi-region patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Create Monitoring alarms for:<\/li>\n<li>Unhealthy backend count<\/li>\n<li>Elevated 5xx rates<\/li>\n<li>High latency<\/li>\n<li>Sudden drop in request count (could signal outage)<\/li>\n<li>Use tags: <code>env<\/code>, <code>app<\/code>, <code>owner<\/code>, <code>cost-center<\/code>, <code>data-classification<\/code>.<\/li>\n<li>Document standard ports, health check endpoints, and emergency procedures (disable backend, drain traffic).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Naming: <code>&lt;env&gt;-&lt;app&gt;-lb-&lt;purpose&gt;<\/code> (example: <code>prod-payments-lb-public<\/code>)<\/li>\n<li>Tagging:<\/li>\n<li>Defined tags for cost center\/compliance<\/li>\n<li>Freeform tags for owner\/team\/contact<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>OCI IAM governs who can:<\/li>\n<li>Create\/delete load balancers<\/li>\n<li>Modify listeners, certificates, backend sets<\/li>\n<li>Change networking (subnets, security lists\/NSGs)<\/li>\n<li>Use compartments and policies to separate duties:<\/li>\n<li>NetSec team manages VCN\/subnets<\/li>\n<li>Platform team manages LB config<\/li>\n<li>App team manages backend instances and deployments<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>In transit<\/strong>: Use HTTPS listeners with modern TLS settings (capabilities depend on OCI LB configuration options\u2014verify TLS policy controls).<\/li>\n<li><strong>Backend encryption<\/strong>:<\/li>\n<li>For internal traffic in private subnets, HTTP may be acceptable for many orgs.<\/li>\n<li>For strict compliance, re-encrypt from LB to backends (HTTPS to backend) or use service mesh patterns (outside LB scope).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep backends private whenever possible.<\/li>\n<li>If backends must be public (lab convenience), lock down inbound rules:<\/li>\n<li>Only allow backend ports from the LB subnet CIDR or the LB NSG.<\/li>\n<li>Avoid exposing admin ports through the LB.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Never store TLS private keys in source control.<\/li>\n<li>Prefer centralized secret management (OCI Vault where applicable) and least-privileged access patterns.<\/li>\n<li>Rotate certificates regularly and monitor expiry.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>OCI Audit<\/strong> to track configuration changes (who changed listeners\/backends).<\/li>\n<li>Enable LB logs if supported and needed for forensics; restrict access to logs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>For regulated workloads:<\/li>\n<li>Enforce TLS requirements<\/li>\n<li>Maintain change control and approvals for LB changes<\/li>\n<li>Retain logs appropriately<\/li>\n<li>Use WAF for internet-facing apps where required by policy<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Leaving backend servers directly exposed to <code>0.0.0.0\/0<\/code><\/li>\n<li>Using weak TLS settings or expired certificates<\/li>\n<li>Failing to restrict who can modify backend sets (traffic hijack risk)<\/li>\n<li>No alarms for backend health degradation<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Public LB + private backends + strict NSGs + WAF (if needed)<\/li>\n<li>Least-privilege IAM + compartment separation<\/li>\n<li>Automated provisioning (Terraform) + reviewed change process<\/li>\n<li>Continuous monitoring and certificate expiry alerts<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<p>Always confirm current limits in the service limits page and Load Balancer documentation:\n&#8211; https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Balance\/home.htm<br\/>\n&#8211; https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/General\/Concepts\/servicelimits.htm<\/p>\n\n\n\n<p>Common limitations\/gotchas include:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Subnet requirements<\/strong>: Some regions\/architectures require <strong>two subnets<\/strong> (often in different availability domains) for the load balancer.<\/li>\n<li><strong>Public vs private choice<\/strong>: You may not be able to switch a load balancer from public to private without recreation (verify current behavior).<\/li>\n<li><strong>VCN\/subnet immutability<\/strong>: Moving an LB to a different VCN\/subnet may require recreation.<\/li>\n<li><strong>Health check mismatch<\/strong>: Incorrect path\/port causes all backends to be unhealthy \u2192 503.<\/li>\n<li><strong>Security list\/NSG confusion<\/strong>: You must allow both:<\/li>\n<li>Client \u2192 LB listener port<\/li>\n<li>LB \u2192 backend port (including health checks)<\/li>\n<li><strong>Source IP visibility<\/strong>: Backends may not see the real client IP without specific headers (e.g., <code>X-Forwarded-For<\/code>) or protocol support (proxy protocol). Verify support and configuration steps in docs.<\/li>\n<li><strong>Timeout defaults<\/strong>: Default idle\/timeouts may break long-lived connections if not tuned (verify supported timeout settings).<\/li>\n<li><strong>Logging costs<\/strong>: Detailed access logs at high traffic can be expensive.<\/li>\n<li><strong>Quota surprises<\/strong>: Hitting limits on listeners\/backends\/LBs per compartment\/region can block deployments.<\/li>\n<li><strong>TLS certificate chain issues<\/strong>: Missing intermediate certs causes browser trust errors.<\/li>\n<li><strong>Operational coupling<\/strong>: Consolidating too many services behind one LB can increase blast radius.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>OCI provides multiple ways to route traffic. Here\u2019s how OCI Load Balancer compares.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Key alternatives<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCI Network Load Balancer<\/strong>: Layer 4 focused, often used for extreme performance and source IP preservation use cases (verify feature differences).<\/li>\n<li><strong>OCI API Gateway<\/strong>: API management, authentication, throttling, transforms (not a general-purpose LB).<\/li>\n<li><strong>OCI DNS Traffic Management \/ Steering Policies<\/strong>: Global-ish traffic distribution using DNS responses; not a per-request load balancer.<\/li>\n<li><strong>Self-managed HAProxy\/Nginx on Compute<\/strong>: Full control, but you operate HA and patching.<\/li>\n<li>Other clouds:<\/li>\n<li><strong>AWS ALB\/NLB<\/strong><\/li>\n<li><strong>Azure Application Gateway \/ Azure Load Balancer<\/strong><\/li>\n<li><strong>Google Cloud Load Balancing<\/strong><\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Comparison table<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>OCI Load Balancer<\/strong><\/td>\n<td>Managed L7\/L4 app ingress in a region<\/td>\n<td>Managed HA, health checks, TLS termination, integrates with OCI networking and monitoring<\/td>\n<td>Regional scope; some features\/limits vary; costs accrue while provisioned<\/td>\n<td>Most web\/app workloads needing reliable ingress<\/td>\n<\/tr>\n<tr>\n<td><strong>OCI Network Load Balancer<\/strong><\/td>\n<td>High-performance L4, simple passthrough<\/td>\n<td>Often better for L4 throughput\/latency and preserving client IP (verify)<\/td>\n<td>Less L7 functionality<\/td>\n<td>TCP\/UDP heavy workloads, ultra-low latency L4 needs<\/td>\n<\/tr>\n<tr>\n<td><strong>OCI API Gateway<\/strong><\/td>\n<td>API front door and governance<\/td>\n<td>Auth, rate limiting, API lifecycle<\/td>\n<td>Not a generic LB; backend patterns differ<\/td>\n<td>Public APIs needing auth and governance controls<\/td>\n<\/tr>\n<tr>\n<td><strong>OCI DNS steering<\/strong><\/td>\n<td>Multi-region failover\/geo routing<\/td>\n<td>Simple global distribution via DNS<\/td>\n<td>DNS TTL delays; not per-request<\/td>\n<td>Active\/passive multi-region patterns<\/td>\n<\/tr>\n<tr>\n<td><strong>Self-managed HAProxy\/Nginx<\/strong><\/td>\n<td>Full control\/custom behavior<\/td>\n<td>Maximum flexibility; custom modules<\/td>\n<td>You manage HA, scaling, patching, monitoring<\/td>\n<td>Special requirements not met by managed LB<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS ALB\/NLB<\/strong><\/td>\n<td>AWS-native apps<\/td>\n<td>Very mature ecosystem; global patterns with Route 53<\/td>\n<td>Different cloud; migration overhead<\/td>\n<td>If your stack is primarily AWS<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Application Gateway<\/strong><\/td>\n<td>Azure-native L7<\/td>\n<td>Tight Azure integration<\/td>\n<td>Different cloud; feature differences<\/td>\n<td>If your stack is primarily Azure<\/td>\n<\/tr>\n<tr>\n<td><strong>GCP Load Balancing<\/strong><\/td>\n<td>GCP-native apps<\/td>\n<td>Strong global LB story in GCP<\/td>\n<td>Different cloud; design differences<\/td>\n<td>If your stack is primarily GCP<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Internal + external portals with segmented ingress<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A large enterprise runs an employee portal (internal) and a customer portal (external). They need strict segmentation, auditing, and predictable operations.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>Public Load Balancer in public subnets for customer portal<\/li>\n<li>Private Load Balancer for internal employee portal<\/li>\n<li>Backends in private subnets; access controlled with NSGs<\/li>\n<li>WAF in front of the public portal (verify best practice association model)<\/li>\n<li>Centralized Monitoring alarms and Logging with retention policies<\/li>\n<li>IAM policies restricting changes to platform team; change approvals via CI\/CD + Terraform<\/li>\n<li><strong>Why Load Balancer was chosen<\/strong>:<\/li>\n<li>Managed HA and health checks reduce operational burden<\/li>\n<li>TLS termination centralizes certificate lifecycle<\/li>\n<li>Clear separation between public and private exposure<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Reduced outage frequency due to backend failures<\/li>\n<li>Faster patching\/maintenance with rolling backend updates<\/li>\n<li>Improved security posture and audit readiness<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Simple HA web app without running proxies<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem<\/strong>: A small team has a web app that outgrew a single VM. They want HA but don\u2019t want to operate HAProxy.<\/li>\n<li><strong>Proposed architecture<\/strong>:<\/li>\n<li>One public OCI Load Balancer<\/li>\n<li>Two small Compute instances running NGINX + app<\/li>\n<li>Basic health checks and Monitoring alarms<\/li>\n<li>DNS points to the LB IP<\/li>\n<li><strong>Why Load Balancer was chosen<\/strong>:<\/li>\n<li>Quick to deploy; minimal operational overhead<\/li>\n<li>Enables adding more instances later without changing the public endpoint<\/li>\n<li><strong>Expected outcomes<\/strong>:<\/li>\n<li>Zero-downtime maintenance (stop one backend at a time)<\/li>\n<li>Better performance under traffic spikes<\/li>\n<li>Clear path to autoscaling backends later<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">1) Is OCI Load Balancer a global service?<\/h3>\n\n\n\n<p>No. OCI Load Balancer is typically <strong>regional<\/strong> and deployed into subnets in a specific region\/VCN. For multi-region traffic distribution, use DNS steering\/traffic management patterns and deploy LBs per region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">2) What\u2019s the difference between \u201cLoad Balancer\u201d and \u201cNetwork Load Balancer\u201d in Oracle Cloud?<\/h3>\n\n\n\n<p><strong>Load Balancer<\/strong> is the general managed load balancing service (often used for HTTP\/HTTPS and application ingress). <strong>Network Load Balancer<\/strong> is oriented toward <strong>Layer 4<\/strong> and high-performance network traffic. Choose based on protocol needs and feature set; verify current differences in OCI docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">3) Do I need one or two subnets for a load balancer?<\/h3>\n\n\n\n<p>It depends on the region and availability domain design. Some OCI regions\/configurations require <strong>two subnets<\/strong> (often in different ADs). Follow the console prompts and verify the requirement in official documentation.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">4) Can I create a private load balancer?<\/h3>\n\n\n\n<p>Yes. A <strong>private Load Balancer<\/strong> is internal-only and uses private IPs in private subnets. It\u2019s common for internal microservices or private app ingress.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">5) Can the backends be in private subnets?<\/h3>\n\n\n\n<p>Yes, and that\u2019s recommended for production. Ensure security rules allow the LB to reach backend ports, and use NAT if private backends need outbound internet access.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6) Does Load Balancer support TLS termination?<\/h3>\n\n\n\n<p>Yes, for HTTPS listeners you can terminate TLS at the load balancer using configured certificates. Confirm supported TLS policies and certificate formats in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">7) How do I make sure my backend sees the real client IP?<\/h3>\n\n\n\n<p>Common approaches include using HTTP headers such as <code>X-Forwarded-For<\/code> (for HTTP traffic). Some environments use proxy protocol for TCP. Verify the supported method and configuration in OCI Load Balancer docs for your listener type.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">8) Why do I get 503 Service Unavailable from the load balancer?<\/h3>\n\n\n\n<p>Usually because there are <strong>no healthy backends<\/strong> in the backend set. Check health check configuration, backend service status, and security rules.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">9) Can I use Load Balancer with Kubernetes?<\/h3>\n\n\n\n<p>Common architectures use load balancers for ingress to Kubernetes services. The exact implementation depends on your cluster and controller choices. Verify current OCI Container Engine for Kubernetes (OKE) integration patterns.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">10) How do I scale?<\/h3>\n\n\n\n<p>You typically scale by:\n&#8211; Adding more backend instances\/pods\n&#8211; Adjusting LB capacity\/bandwidth settings (shape-dependent)\n&#8211; Automating backend registration with IaC\/CI pipelines<br\/>\nVerify current scaling mechanisms in OCI docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">11) Do I pay when there\u2019s no traffic?<\/h3>\n\n\n\n<p>Often yes. Charges commonly include <strong>LB-hours<\/strong> and possibly provisioned capacity. Check the official price list for the exact pricing dimensions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">12) Can I attach a WAF?<\/h3>\n\n\n\n<p>OCI WAF is commonly used in front of internet-facing applications. The association\/integration options depend on current OCI WAF capabilities and your architecture. Verify the latest recommended pattern in OCI docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">13) What\u2019s a backend set?<\/h3>\n\n\n\n<p>A backend set is a <strong>pool definition<\/strong>: backends + health check + load balancing policy. Listeners route to backend sets.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">14) What\u2019s the most common misconfiguration?<\/h3>\n\n\n\n<p>Security rules. You must allow:\n&#8211; Client \u2192 LB listener port\n&#8211; LB \u2192 backend port (and health check path\/port)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">15) Can I do path-based or host-based routing?<\/h3>\n\n\n\n<p>OCI Load Balancer may support certain L7 routing rules depending on service capabilities. Verify current routing rule support in official docs.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">16) How do I do zero-downtime maintenance?<\/h3>\n\n\n\n<p>Use at least two backends. Drain\/disable one backend, update it, re-enable it, then repeat for others. Validate health checks before returning nodes to service.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">17) What should I monitor first?<\/h3>\n\n\n\n<p>Start with:\n&#8211; Backend health status\n&#8211; 4xx\/5xx counts (if available)\n&#8211; Latency\n&#8211; Connection errors\/timeouts<br\/>\nThen add app-level metrics from your backends.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Load Balancer<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>OCI Load Balancer docs: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Balance\/home.htm<\/td>\n<td>Authoritative feature set, configuration model, limits, and procedures<\/td>\n<\/tr>\n<tr>\n<td>Official IAM documentation<\/td>\n<td>OCI IAM docs: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/Identity\/home.htm<\/td>\n<td>Correct policies, compartments, and least-privilege guidance<\/td>\n<\/tr>\n<tr>\n<td>Service limits<\/td>\n<td>OCI Service Limits: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/General\/Concepts\/servicelimits.htm<\/td>\n<td>Prevents quota surprises in production<\/td>\n<\/tr>\n<tr>\n<td>Official pricing<\/td>\n<td>OCI Price List (Networking): https:\/\/www.oracle.com\/cloud\/price-list\/<\/td>\n<td>Official pricing dimensions; region\/currency-dependent<\/td>\n<\/tr>\n<tr>\n<td>Cost calculator<\/td>\n<td>OCI Cost Estimator: https:\/\/www.oracle.com\/cloud\/cost-estimator.html<\/td>\n<td>Build realistic estimates for LB + compute + bandwidth<\/td>\n<\/tr>\n<tr>\n<td>Free tier<\/td>\n<td>OCI Free Tier: https:\/\/www.oracle.com\/cloud\/free\/<\/td>\n<td>Understand Always Free eligibility and constraints<\/td>\n<\/tr>\n<tr>\n<td>CLI documentation<\/td>\n<td>OCI CLI concepts: https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/API\/Concepts\/cliconcepts.htm<\/td>\n<td>Automate LB operations and integrate with pipelines<\/td>\n<\/tr>\n<tr>\n<td>Architecture guidance<\/td>\n<td>OCI Architecture Center: https:\/\/docs.oracle.com\/en\/solutions\/<\/td>\n<td>Reference architectures and patterns (search for load balancer + VCN patterns)<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Oracle Cloud Infrastructure YouTube: https:\/\/www.youtube.com\/@OracleCloudInfrastructure<\/td>\n<td>Walkthroughs and feature demos (verify videos match current UI\/version)<\/td>\n<\/tr>\n<tr>\n<td>Tutorials\/labs<\/td>\n<td>Oracle Cloud \u201cTutorials\u201d and docs-linked walkthroughs (start from docs home): https:\/\/docs.oracle.com\/en-us\/iaas\/Content\/home.htm<\/td>\n<td>Hands-on learning aligned with official procedures<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Institute<\/th>\n<th>Suitable Audience<\/th>\n<th>Likely Learning Focus<\/th>\n<th>Mode<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>Beginners to advanced DevOps\/SRE<\/td>\n<td>DevOps foundations, cloud operations, CI\/CD, infrastructure automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>ScmGalaxy.com<\/td>\n<td>Students, SCM\/DevOps learners<\/td>\n<td>Source control, DevOps tooling, automation practices<\/td>\n<td>Check website<\/td>\n<td>https:\/\/www.scmgalaxy.com\/<\/td>\n<\/tr>\n<tr>\n<td>CLoudOpsNow.in<\/td>\n<td>Cloud operations practitioners<\/td>\n<td>Cloud ops, monitoring, reliability, operational readiness<\/td>\n<td>Check website<\/td>\n<td>https:\/\/cloudopsnow.in\/<\/td>\n<\/tr>\n<tr>\n<td>SreSchool.com<\/td>\n<td>SREs and platform teams<\/td>\n<td>SRE practices: SLIs\/SLOs, incident response, reliability engineering<\/td>\n<td>Check website<\/td>\n<td>https:\/\/sreschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>AiOpsSchool.com<\/td>\n<td>Ops\/DevOps teams adopting AIOps<\/td>\n<td>Observability, AIOps concepts, event correlation, automation<\/td>\n<td>Check website<\/td>\n<td>https:\/\/aiopsschool.com\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Platform\/Site<\/th>\n<th>Likely Specialization<\/th>\n<th>Suitable Audience<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>RajeshKumar.xyz<\/td>\n<td>DevOps\/cloud training content<\/td>\n<td>Learners looking for practical guidance<\/td>\n<td>https:\/\/rajeshkumar.xyz\/<\/td>\n<\/tr>\n<tr>\n<td>devopstrainer.in<\/td>\n<td>DevOps training and mentoring<\/td>\n<td>Beginners to intermediate DevOps engineers<\/td>\n<td>https:\/\/www.devopstrainer.in\/<\/td>\n<\/tr>\n<tr>\n<td>devopsfreelancer.com<\/td>\n<td>DevOps consulting\/training-style services<\/td>\n<td>Teams needing hands-on help<\/td>\n<td>https:\/\/www.devopsfreelancer.com\/<\/td>\n<\/tr>\n<tr>\n<td>devopssupport.in<\/td>\n<td>DevOps support and enablement<\/td>\n<td>Ops teams needing troubleshooting support<\/td>\n<td>https:\/\/www.devopssupport.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Company Name<\/th>\n<th>Likely Service Area<\/th>\n<th>Where They May Help<\/th>\n<th>Consulting Use Case Examples<\/th>\n<th>Website URL<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>cotocus.com<\/td>\n<td>Cloud\/DevOps engineering<\/td>\n<td>Architecture, implementations, automation<\/td>\n<td>Designing OCI VCN + Load Balancer patterns; IaC rollout; migration planning<\/td>\n<td>https:\/\/cotocus.com\/<\/td>\n<\/tr>\n<tr>\n<td>DevOpsSchool.com<\/td>\n<td>DevOps consulting and training<\/td>\n<td>Platform enablement, CI\/CD, reliability practices<\/td>\n<td>Building standardized ingress, observability setup, runbooks and incident processes<\/td>\n<td>https:\/\/www.devopsschool.com\/<\/td>\n<\/tr>\n<tr>\n<td>DEVOPSCONSULTING.IN<\/td>\n<td>DevOps consulting services<\/td>\n<td>DevOps transformation and delivery automation<\/td>\n<td>Implementing Terraform for OCI networking; deployment pipelines; ops readiness reviews<\/td>\n<td>https:\/\/devopsconsulting.in\/<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Load Balancer<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Networking fundamentals<\/strong>: IPs, CIDR, routing, TCP vs HTTP, DNS, TLS.<\/li>\n<li><strong>OCI core concepts<\/strong>: tenancy, compartments, IAM, regions.<\/li>\n<li><strong>VCN fundamentals<\/strong>: subnets (public\/private), route tables, gateways (IGW\/NAT\/DRG), security lists vs NSGs.<\/li>\n<li><strong>Compute basics<\/strong>: launching instances, OS firewalls, web server basics.<\/li>\n<li><strong>Observability basics<\/strong>: metrics vs logs, alerting.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Load Balancer<\/h3>\n\n\n\n<ol class=\"wp-block-list\">\n<li><strong>Network Load Balancer<\/strong> for high-performance L4 designs (if relevant).<\/li>\n<li><strong>WAF<\/strong> and edge security patterns for internet-facing workloads.<\/li>\n<li><strong>Terraform for OCI<\/strong> (or Resource Manager) to standardize deployments.<\/li>\n<li><strong>Autoscaling<\/strong> patterns for backends (instance pools, container scaling).<\/li>\n<li><strong>Multi-region DR<\/strong> using DNS steering and replicated data services.<\/li>\n<li><strong>Zero trust<\/strong> segmentation with NSGs and private endpoints.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer<\/li>\n<li>DevOps Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Network\/Cloud Network Engineer<\/li>\n<li>Platform Engineer<\/li>\n<li>Solutions Architect<\/li>\n<li>Security Engineer (for edge exposure reviews)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (if available)<\/h3>\n\n\n\n<p>Oracle offers OCI certifications (associate\/professional). Certification names and versions change over time, so verify current tracks here:<br\/>\nhttps:\/\/education.oracle.com\/<\/p>\n\n\n\n<p>A practical path:\n&#8211; OCI Foundations\n&#8211; OCI Architect Associate\n&#8211; OCI DevOps or Security specializations (depending on role)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Build a <strong>public LB<\/strong> with HTTPS and automated certificate rotation (verify your certificate management approach).<\/li>\n<li>Deploy a <strong>private LB<\/strong> for microservices inside a VCN and restrict access via NSGs.<\/li>\n<li>Implement <strong>blue\/green<\/strong> backend sets and switch traffic during deployments.<\/li>\n<li>Create Monitoring alarms and an incident runbook for \u201cunhealthy backend\u201d scenarios.<\/li>\n<li>Build a Terraform module that provisions VCN + LB + two backends consistently.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>OCI (Oracle Cloud Infrastructure)<\/strong>: Oracle\u2019s public cloud platform.<\/li>\n<li><strong>Load Balancer<\/strong>: Managed service distributing incoming traffic across backend servers.<\/li>\n<li><strong>VCN (Virtual Cloud Network)<\/strong>: Private network in OCI where you define IP ranges, subnets, and routing.<\/li>\n<li><strong>Subnet<\/strong>: A slice of a VCN CIDR range; can be public or private.<\/li>\n<li><strong>Public subnet<\/strong>: Has a route to an Internet Gateway; resources can be internet-reachable if they have public IPs and security rules allow it.<\/li>\n<li><strong>Private subnet<\/strong>: No direct route to the internet via IGW; often uses NAT for outbound-only internet access.<\/li>\n<li><strong>Listener<\/strong>: Frontend configuration (protocol\/port) on the load balancer.<\/li>\n<li><strong>Backend<\/strong>: A target server (instance IP\/port) receiving traffic from the LB.<\/li>\n<li><strong>Backend set<\/strong>: Group of backends + health check + load balancing policy.<\/li>\n<li><strong>Health check<\/strong>: Automated probe used to determine if a backend is eligible for traffic.<\/li>\n<li><strong>NSG (Network Security Group)<\/strong>: Virtual firewall rules applied to VNICs\/resources, more granular than subnet security lists.<\/li>\n<li><strong>Security list<\/strong>: Subnet-level firewall rules.<\/li>\n<li><strong>Internet Gateway (IGW)<\/strong>: Enables internet connectivity for public subnets.<\/li>\n<li><strong>NAT Gateway<\/strong>: Enables outbound internet access for private subnet resources without inbound exposure.<\/li>\n<li><strong>DRG (Dynamic Routing Gateway)<\/strong>: Connects VCNs to on-prem networks or other networks (VPN\/FastConnect).<\/li>\n<li><strong>TLS\/SSL termination<\/strong>: Ending the TLS connection at the LB so backends may receive plaintext HTTP or re-encrypted traffic.<\/li>\n<li><strong>Compartment<\/strong>: OCI logical container for resources and access control.<\/li>\n<li><strong>OCID<\/strong>: Oracle Cloud Identifier\u2014unique ID for OCI resources.<\/li>\n<li><strong>WAF (Web Application Firewall)<\/strong>: Protects web apps from common threats (SQLi, XSS, etc.) depending on rulesets.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Oracle Cloud <strong>Load Balancer<\/strong> (in the <strong>Networking, Edge, and Connectivity<\/strong> category) is a managed service that provides a stable entry point for applications and distributes traffic across healthy backends. It improves availability, supports scaling, and can centralize TLS termination and routing behaviors.<\/p>\n\n\n\n<p>Architecturally, it fits at the front of web apps and APIs inside a VCN, integrating tightly with subnets, security rules, IAM, and monitoring. Cost is typically driven by <strong>LB-hours<\/strong>, configured capacity\/bandwidth, and indirect charges such as internet egress and logging. Security success depends on least-privilege IAM, correct subnet\/NSG rules, and using private backends where possible.<\/p>\n\n\n\n<p>Use OCI Load Balancer when you want managed HA and straightforward app ingress. Consider Network Load Balancer for high-performance Layer 4 needs, and DNS steering for cross-region distribution.<\/p>\n\n\n\n<p>Next step: implement the same lab using <strong>Terraform<\/strong> (or OCI Resource Manager) and add <strong>Monitoring alarms<\/strong> for backend health and HTTP error rates so your deployment is production-operable from day one.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking, Edge, and Connectivity<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[74,62],"tags":[],"class_list":["post-946","post","type-post","status-publish","format-standard","hentry","category-networking-edge-and-connectivity","category-oracle-cloud"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/946","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=946"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/946\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=946"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=946"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=946"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}