11 min read

Learning Objectives

By the end of this module, you will be able to:

  • Decide when Layer 4 TCP pass-through is the correct load-balancing tier instead of Layer 7 content routing
  • Choose a Managed Network Load Balancer distribution algorithm and use target weighting for a controlled canary
  • Explain why end-to-end encryption and non-HTTP traffic keep the certificate on the backend and rule out TLS termination at the balancer
  • Compose a public Layer 7 edge with a private Layer 4 balancer in front of the data tier
  • Build a private Layer 4 balancer in the Data Center Designer

Unit 3.4: Load Balancing - Layer 4 (Network)

Introduction

Unit 3.3 terminated TLS at a public Layer 7 balancer because the edge needed to read HTTP and route on content. The data tier has the opposite requirement. It speaks database and other non-HTTP protocols, and FinCorp's GDPR/BSI posture wants the payload encrypted from the application tier all the way to the database, with no intermediary that can read it. A content-aware balancer cannot serve that tier, and it should not try.

This unit covers the Managed Network Load Balancer (NLB), the platform's Layer 4 TCP load balancer, and ends by building a private NLB in front of FinCorp's data tier inside the VDC you created in Unit 3.1. The design decision is deliberately narrow: distribute TCP connections across healthy targets without ever decrypting or inspecting them.

1. Layer 4 TCP Pass-Through and When It Wins

The Managed Network Load Balancer operates at TCP/IP Layer 4 of the OSI model and provides connection-based load balancing. It is a pre-configured VDC element, fully managed, deployed in a highly available setup, and integrated into the platform's software-defined networking. It serves as a single entry and exit point for client traffic: the listener accepts connections, and forwarding rules distribute the sessions across multiple compute targets for parallel processing.

The defining property is what the NLB does not do. It distributes any TCP-based traffic, including upper-layer protocols such as HTTP and HTTPS, but its forwarding rules and health checks are strictly TCP. Routing decisions based on a URL or HTTP header are not supported. The NLB never decrypts the connection, so it never terminates TLS. When a client opens an encrypted connection, the TLS session is established with the backend target, and the certificate and private key live on that backend, not on the balancer. This is exactly the behaviour the data tier wants.

Two situations make Layer 4 the mandatory choice rather than a preference:

  • End-to-end encryption. When the security model requires that the payload stay encrypted from the client (or the upstream tier) to the backend with no decrypting hop in between, a Layer 7 balancer is disqualified because terminating TLS means decrypting. The NLB passes the encrypted TCP stream through untouched, so the backend keeps the certificate and remains the only place the plaintext exists. For FinCorp's regulated data path, this removes the balancer from the set of components that handle cleartext customer data, which simplifies the data-protection assessment.
  • Non-HTTP traffic. Database protocols (PostgreSQL, MariaDB wire protocols), message brokers, and other TCP services are not HTTP, so there is nothing for a Layer 7 balancer to route on. Layer 4 is the only tier that fits.

Because the NLB cannot read application content, it also cannot do anything content-aware: no path rules, no host routing, no HTTP-aware health probing. If you need those, you are at the wrong tier and Unit 3.3 is the answer. The honest framing is that Layer 4 and Layer 7 are not ranked; they sit at different points in the architecture and solve different problems.

1.1 Address translation and the connection model

Understanding how traffic actually flows through the NLB explains several of its constraints. The NLB performs destination NAT (DNAT): client connections terminate on the load balancer, and the balancer then initiates a separate, dedicated connection to the chosen backend target. Source NAT (SNAT) is not supported, which means targets cannot initiate outbound connections through the load balancer. The NLB is an inbound distribution device, not an egress path. When private workloads need outbound internet access, that is the NAT Gateway's job (SNAT-only, covered in Unit 3.6), and the two products are complementary rather than interchangeable.

Because the balancer opens its own connection to the target, the backend by default sees the balancer's address rather than the original client's. Where the backend needs the real client IP (for logging, geo-logic, or rate limiting), enable Proxy Protocol on the target so the original connection information is preserved and forwarded. The backend service (for example Apache, NGINX, or an in-cluster ingress controller) must be configured to expect and parse the Proxy Protocol header, or connections will fail.

1.2 Distribution algorithms and canary weighting

A forwarding rule carries a distribution algorithm. The NLB offers four:

  • Round Robin: distributes connections across targets in a circular, sequential order, honouring each target's weight.
  • Least Connections: sends the next connection to the target with the fewest active connections, which suits long-lived or uneven sessions.
  • Random: distributes connections randomly across the targets.
  • Source IP: maps a client consistently to the same target based on its source address.

Independently of the algorithm, the NLB keeps active sessions mapped to the same target through source-IP affinity (sticky sessions) for as long as the underlying TCP sessions stay active. Source IP affinity is what holds a connection on one backend; selecting the Source IP algorithm extends that stickiness to keep a given client on the same server across connections, which matters when backends do not share TLS state and you want to avoid renegotiation against a different node.

Each target carries a weight from 1 to 256, defaulting to 1, and traffic is distributed in proportion to a target's weight relative to the combined weight of all targets. This is the mechanism for a controlled canary. To send roughly ten percent of new connections to a candidate build, register the canary target with a low weight against higher-weighted stable targets (for example weight 1 on the canary against weight 9 on the incumbent) and watch its health and metrics before raising the weight. Weighting steers new connections only; sessions already pinned by source-IP affinity stay where they are until they close, so a weight change drains gradually rather than instantly. For FinCorp, canary weighting lets a new data-access service take a small, observable share of real traffic without a flag-day cutover.

2. Composing Public Layer 7 with Private Layer 4

The canonical layered shape from Unit 1.2 puts a public Layer 7 balancer at the edge and a private Layer 4 balancer in front of the data tier. The two are not redundant; each does what the other cannot.

The public Layer 7 balancer (Unit 3.3) lives on the public edge, terminates TLS, and routes HTTP by content to the stateless application tier. The private NLB lives entirely on a private network: its listener is exposed only to internal traffic, so it handles east-west connections within the data center rather than north-south internet traffic. The application tier opens encrypted TCP connections to the NLB's private listener, the NLB distributes them across the data-tier targets, and TLS terminates on those targets. No public IP touches the data tier, and no component between the application and the database can read the payload.

This composition also clarifies a security boundary that catches people. NIC firewalls and Network Security Groups bind to server NICs only; they do not apply to the managed load balancer (Unit 3.2). The NLB does carry basic firewall rules that are applied automatically from its forwarding rules and cannot be edited, but you cannot attach an NSG to it and there is no IP allowlist on the balancer itself. Access control for the data tier therefore belongs on the targets' own NIC firewalls and on the topology: the data LAN stays private, and the only thing that should reach it is the application tier through the NLB. Keeping the NLB private is itself a primary control, because a private listener is unreachable from the internet by construction.

A practical note on placement: in the Data Center Designer the NLB element has two interfaces. The Northern interface is the listener and connects toward the clients (an internet access element for a public NLB, or a private LAN for a private one); the Southern interface is the backend and connects to the private LAN holding the targets. For FinCorp's data tier, both the listener side and the backend side stay on private LANs.

DCD Implementation Walkthrough

You will build a private Layer 4 balancer in front of FinCorp's data tier, reusing the VDC and the three-LAN topology from Unit 3.1. The goal is a private NLB whose listener faces the application LAN and whose backend faces the private data LAN, distributing encrypted TCP connections across the data-tier targets without terminating TLS. The prerequisite is that the targets (the data-tier servers) are already provisioned on a private LAN; the NLB needs existing targets to distribute sessions to.

Build goal: Build a private Layer 4 balancer in front of the data tier.

Steps (in the Data Center Designer):

  1. Open the FinCorp VDC from Unit 3.1 in the Data Center Designer.
  2. Drag the Network Load Balancer element into the workspace.
  3. Connect the NLB's two interfaces. Link the Northern interface (the listener) to the private application LAN, so the balancer faces internal clients rather than the internet. Link the Southern interface (the backend) to the private LAN that holds the data-tier targets. Keeping both sides on private LANs is what makes this a private, east-west balancer.
  4. In the Inspector, open the Settings tab and configure the listener IP. A private NLB takes a private IP; assign it from the application LAN so the application tier has a stable address to connect to.
  5. Open the Forwarding rules tab and select Add forwarding rule. Name the rule, choose the distribution algorithm (for example Least Connections for database connections, or Source IP where you need a client pinned to one node), and confirm the Protocol field, which is preset to TCP. Set the Listener IP and Listener Port the balancer will accept connections on (for example the database port).
  6. Within the rule, select Add target for each data-tier server. Provide the Target IP and Target port, and set the Weight (1 to 256, default 1); use unequal weights to stage a canary. Enable Proxy Protocol on the target if the backend needs the original client IP, and configure the backend to parse it.
  7. Configure the Health Check settings for the forwarding rule. The checks are TCP-based. The defaults are a client timeout of 50000 ms, a connection timeout of 5000 ms, and a target timeout of 50000 ms; tune the connection timeout to how quickly you want an unresponsive target marked unhealthy and pulled from rotation.
  8. Provision the changes. The balancer becomes active according to the settings, routing only to targets that pass the health check.

Common mistakes:

  • Expecting the NLB to terminate TLS. It does not. The certificate and private key stay on the backend targets; do not plan a cert-on-the-balancer design at Layer 4.
  • Trying to route on URL or HTTP path. Forwarding rules and health checks are strictly TCP; content routing is a Layer 7 job (Unit 3.3).
  • Trying to attach a Network Security Group or an IP allowlist to the NLB. There is none. The NLB's auto-generated firewall rules cannot be edited; put filtering on the targets' NIC firewalls and keep the listener private.
  • Assuming the NLB gives targets outbound internet. It is DNAT inbound only; SNAT is not supported. Provision a NAT Gateway (Unit 3.6) for private egress.
  • Forgetting that the backend sees the balancer's address. If the application needs the real client IP, enable Proxy Protocol on the target and configure the backend to expect it, or connections break.
  • Pointing the NLB at targets that do not exist yet. The targets must be provisioned on their private LAN before the balancer has anything to distribute to.

Summary

The Managed Network Load Balancer is the platform's Layer 4 TCP balancer: it distributes connections across healthy targets using Round Robin, Least Connections, Random, or Source IP, weights targets from 1 to 256 for canary control, and performs DNAT so client connections terminate on the balancer and a fresh connection opens to the target. It never decrypts traffic, so it never terminates TLS, which is precisely why it fits non-HTTP protocols and end-to-end-encrypted data paths where the certificate must stay on the backend. Placed privately in front of FinCorp's data tier, behind the public Layer 7 edge, it completes the layered shape from Unit 1.2 with no public exposure and no readable hop between application and database.

Key Points:

  • Layer 4 is TCP pass-through: any TCP traffic is distributed, but rules and health checks are strictly TCP, so there is no content routing.
  • The NLB does not terminate TLS; the backend keeps the certificate, which is what makes end-to-end encryption and non-HTTP traffic feasible.
  • Algorithms are Round Robin, Least Connections, Random, and Source IP; sticky sessions are source-IP affinity held while TCP sessions stay active.
  • Target weights (1 to 256, default 1) distribute traffic proportionally and are the canary mechanism; weighting steers new connections only.
  • DNAT inbound only, no SNAT; the NLB does not provide egress (use a NAT Gateway). No NSG or IP allowlist binds to the managed balancer, so filtering belongs on targets.
  • Compose a public Layer 7 edge with a private Layer 4 balancer in front of a private-only data tier.