What Is Integrated NLB? Definition & Examples

Integrated NLB is UAG’s built-in network load balancing option for distributing traffic across array members. It is surfaced in the trunk settings only after a second server is added to the array. The configuration ties together the virtual IP and member IPs so the array can present a unified access point.

What Integrated NLB Does

Integrated NLB is UAG’s built-in traffic distribution feature for an array, designed to present a single access point while balancing requests across member servers. It becomes available only after a second server joins the array, because balancing needs more than one target to be meaningful.

The key design idea is that the configuration binds the virtual IP to the member IPs, so clients connect to one advertised endpoint while the array decides which member handles the session or request. That makes the feature part load balancing, part access-path design.

In practice, “integrated” means the load-balancing capability is not a separate appliance or external controller. It is surfaced inside the UAG configuration itself, which simplifies deployment but also ties availability and routing behavior closely to the array configuration.

How the Array Uses the Virtual IP

The virtual IP is the address clients see, while the member IPs are the concrete server addresses behind it. Integrated NLB uses that abstraction to hide the internal shape of the array and avoid requiring users to know which member is active at any given moment.

This model is useful when you want a stable connection entry point even as traffic shifts between servers. It also helps the array behave like one service rather than a collection of separate hosts, which is important for continuity and client experience.

The same design also creates a dependency on correct membership and health behavior. If the array is not built or maintained correctly, the unified access point can conceal uneven capacity or routing issues rather than fixing them.

Operational Trade-Offs and Reliability Considerations

Integrated NLB can reduce deployment complexity because balancing is handled within the array rather than through an external load-balancing tier. That convenience is valuable, but it also means the UAG array must be managed carefully as both access layer and traffic distribution layer.

Because the virtual IP fronts multiple members, operators need to think about failover behavior, member consistency, and how changes to the array affect the path users experience. A unified access point is only useful if the underlying members remain healthy and sufficiently synchronized.

NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because the feature sits at the intersection of access control, configuration management, and system resilience.

When Integrated NLB Is the Right Fit

Integrated NLB fits best when the goal is to expose a single front door for an array without adding another infrastructure component. It is a pragmatic choice for environments that want simpler routing and a straightforward way to scale out beyond one server.

It is less compelling when traffic engineering, advanced health checks, or broader perimeter design need to be handled by a dedicated platform. In those cases, the built-in feature may still work, but it may not be the most flexible or operationally expressive option.

NIST Cybersecurity Framework 2.0 is a useful broader reference for thinking about how availability, resilience, and configuration discipline support the service as a whole.

Risk and Threat Considerations

Integrated NLB concentrates traffic handling and access exposure behind a single virtual endpoint, so a misconfiguration can affect the whole array rather than one member. The main risk is not the balancing logic itself, but the operational trust placed in the virtual IP, member mapping, and array health.

Failure mechanism: If membership, routing, or health behavior is wrong, clients may be sent to unavailable or inconsistent members, or the array may expose a larger attack surface than intended through a shared access path.

Impact: Users can experience partial outage, uneven service behavior, or degraded failover, and defenders may lose clarity about which member is actually receiving traffic.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.IR-01 — Network Resilience and Recovery	Integrated NLB supports resilient service access through redundant array members.
Recommendation — Validate failover paths so the virtual IP continues serving traffic during member loss.
NIST SP 800-53 Rev 5	CM-2 — Baseline Configuration	Integrated NLB depends on controlled array configuration and consistent member settings.
	SC-7 — Boundary Protection	The unified access point functions as a traffic boundary that must be consistently enforced.
Recommendation — Maintain a documented baseline for the virtual IP and member routing configuration. Restrict and monitor traffic through the shared access path to preserve intended boundary behavior.
CIS Controls v8	CIS-12 — Network Infrastructure Management	This feature is part of network service delivery and routing management.
Recommendation — Inventory and manage the array’s network paths, addresses, and failover dependencies.

Practitioner Guidance

What to watch for: Treat Integrated NLB as part of the access architecture, not just a convenience setting. The important question is whether the virtual IP, member state, and failover behavior still match the intended service model after each topology change.

Practitioner takeaway: Use the built-in load-balancing option when simplicity matters, but verify that the array’s routing behavior remains predictable as members are added, removed, or recovered.

Integrated NLB