The alert did not say the system is down. It never does.
It said users were intermittently unable to connect. This is the most dangerous kind of failure: silent, inconsistent, and already impacting traders, operations teams, and compliance workflows.
At the center of it was a familiar suspect in large enterprise environments: the remote access gateway. In this case, VMware Horizon Unified Access Gateway was doing exactly what it was configured to do, but not what the business expected during failure.
That moment forced a hard architectural question. Is our access layer truly highly available, or just redundant on paper?
Recently, I was involved in a project for a large capital market organization in India where VMware Horizon played a critical role in enabling secure remote access. The objective was to strengthen the availability and resilience of the VMware Horizon Unified Access Gateway (UAG) layer, while keeping security and operational simplicity front and center. The organization wanted to leverage NGINX Plus to intelligently manage workload distribution across multiple UAG instances and ensure a consistent user experience, even during failures.
Business and Technical Context
In this environment, VMware Horizon was used to provide remote access to internal applications and virtual desktops. Unified Access Gateway acted as the external entry point for all users. Given the scale and sensitivity of large operations, it was clear early on that the access architecture needed to meet a few non-negotiable requirements:
- No single point of failure at the gateway layer
- Seamless failover without impacting active user sessions
- Secure exposure with a minimal public attack surface
- Support for multiple Horizon protocols, including Blast
- Centralized management and operational consistency
The existing setup did not fully meet these expectations, particularly when it came to predictable failover behavior during gateway outages.
Architecture Overview
To address these gaps, we introduced NGINX Plus as a dedicated load balancer in front of multiple VMware Horizon UAG instances. All inbound user traffic terminated at NGINX Plus, which allowed us to control how traffic was distributed and ensure that only healthy gateways were serving users.
Multiple NGINX Plus instances were deployed to avoid introducing any new single points of failure. To manage them consistently, NGINX Instance Manager was implemented centrally, giving us a single place to manage configuration, visibility and lifecycle operations across all load balancers.
Role of NGINX Plus in the Architecture
Advanced Load Balancing
NGINX Plus enabled intelligent traffic distribution across UAG instances. This ensured that traffic was always routed to healthy gateways and removed reliance on any single UAG node.
Multi-Protocol Support
One of the key considerations was support for multiple VMware Horizon protocols. The setup handled:
- HTTPS for authentication and management traffic
- VMware Horizon Blast protocol for virtual desktop access
- Additional supporting protocols required by Horizon services
NGINX Plus handled these protocols reliably, even during peak usage periods.
Session Persistence
Session stickiness was configured so that users remained connected to the same UAG instance throughout authentication and active desktop sessions. This was essential to avoid session drops and maintain a consistent user experience.
Active Health Checks
Health checks were aligned with actual UAG service behavior rather than simple port checks. When a gateway became unhealthy, it was automatically removed from traffic rotation and added back only after services fully recovered.
Security Controls
TLS termination and traffic handling were centralized at NGINX Plus. Only the required ports were exposed externally, while backend communication with UAG instances was restricted to private networks, aligning well with BFSI security expectations.
Centralized Management with NGINX Instance Manager
As the number of NGINX Plus instances grew, centralized management became increasingly important. NGINX Instance Manager provided a single control plane that enabled:
- Central visibility into all NGINX Plus instances
- Consistent configuration management across environments
- Easier upgrades and lifecycle operations
- Better governance and audit readiness
This approach reduced manual effort and helped prevent configuration drift across the environment.
Traffic Flow Summary
From a user perspective, access remained simple. Users connected through a single public URL exposed via NGINX Plus. Requests were evaluated and routed to a healthy UAG instance based on defined policies. If a UAG instance became unavailable, NGINX Plus automatically redirected traffic to another gateway without user disruption.
Outcomes and Benefits
The solution delivered tangible improvements:
- Elimination of single points of failure at the access layer
- Seamless failover during gateway outages or maintenance
- Stable handling of Horizon Blast traffic during peak usage
- Improved security posture through controlled exposure
- Centralized visibility and simpler day-to-day operations
The access platform is now resilient, scalable and significantly easier to operate.
Key Takeaways
- VMware Horizon UAG should be treated as a mission-critical access component in BFSI environments
- Enterprise-grade load balancing is essential for Horizon deployments at scale
- NGINX Plus is well suited for handling Horizon protocols, including Blast, with session awareness
- Centralized management using NGINX Instance Manager simplifies operations and governance
Conclusion
By using NGINX Plus as the load-balancing layer and NGINX Instance Manager for centralized control, I was able to deliver the availability, security, and operational consistency expected in BFSI environments.
This experience reinforced the importance of designing remote access platforms with resilience and operations in mind and showed how the right application delivery platform can make a meaningful difference in mission-critical enterprise environments.
