Deploying Horizon 8 on AWS with a Hub-and-Spoke Architecture

Organizations moving virtual desktop workloads to AWS often want to retain their existing identity services, security policies, and operational controls. This design presents a scalable approach for deploying Omnissa Horizon 8 on AWS while keeping Microsoft Active Directory and DNS authoritative in the customer data center.

The architecture uses AWS Direct Connect for private hybrid connectivity, a centralized hub VPC for the Horizon management plane, and separate spoke VPCs for desktop workloads. AWS Transit Gateway provides controlled routing between the hub, the spokes, and the on-premises network. An AWS Directory Service AD Connector is deployed in each spoke VPC for compatible AWS services that must authenticate against the existing directory.

Architecture overview

The design separates management services from desktop capacity:

  • The customer data center remains the system of record for Active Directory, DNS, users, groups, computer accounts, and Group Policy.
  • AWS Direct Connect provides private connectivity from the customer network to AWS.
  • The hub VPC hosts the complete Horizon management plane and shared operational services.
  • Spoke VPCs host Horizon virtual desktops, application hosts, and an AD Connector deployed across two Availability Zones.
  • AWS Transit Gateway connects the hub and spoke VPCs and provides centralized route control.

This separation creates clear security boundaries and allows desktop capacity to scale independently of the management layer.

Customer data center and hybrid connectivity

The customer’s existing Active Directory and DNS services remain on premises. Horizon management servers and Windows desktop workloads in AWS require reliable, bidirectional access to the domain controllers for DNS, Kerberos, LDAP, domain join, Group Policy, and other Active Directory operations.

AWS Direct Connect is the primary hybrid connectivity path in this design. For a production environment, resiliency should be designed at the Direct Connect location, connection, virtual-interface, and customer-router levels according to the required availability target.

A Direct Connect gateway can be associated with a Transit Gateway through a transit virtual interface, allowing the on-premises network to reach the attached hub and spoke VPCs. Route advertisements must include the on-premises directory networks and all relevant VPC CIDR ranges. Return routing is equally important: the on-premises network must have routes back to every hub and spoke subnet that needs directory access.

Hub VPC: the Horizon management plane

The hub VPC contains the shared Horizon and operational components. These services should be distributed across at least two Availability Zones:

  • Horizon Connection Servers
  • Unified Access Gateways
  • Internal and external load balancers, as required
  • Route 53 Resolver outbound endpoints
  • Monitoring, logging, and administration services

Connection Servers broker sessions and manage desktop pools in the spoke VPCs. Unified Access Gateways provide secure edge access for external users when that access pattern is required. Load balancers distribute connections across redundant service instances.

Amazon Route 53 Resolver outbound endpoints forward queries for the customer’s Active Directory DNS namespace to the on-premises DNS servers. Resolver rules can be shared with the spoke VPCs so that desktops and supporting workloads resolve the same corporate namespace consistently.

Centralized monitoring should capture system health, authentication failures, network-flow information, Horizon service events, and infrastructure metrics. Operational access should use controlled administrative paths rather than exposing management services directly to the internet.

Spoke VPCs: desktop workload isolation

Each spoke VPC is dedicated to desktop capacity and contains:

  • Horizon virtual desktops
  • Published-application or application-host servers
  • An AD Connector across two Availability Zones

Spokes can represent different business units, environments, security classifications, or scaling domains. This model limits the effect of routing or security-policy changes and makes capacity, ownership, and cost allocation easier to manage.

Spoke-to-spoke communication should be disabled by default. A spoke needs routes only to the approved hub services and on-premises networks. Additional connectivity should be introduced only when a documented workload dependency requires it.

The role of AD Connector

AD Connector is a directory gateway that forwards authentication requests from compatible AWS applications and services to the customer’s existing Active Directory. Directory data remains on the customer’s domain controllers and is not replicated into AWS.

In this architecture, a separate AD Connector is created in each spoke VPC and deployed across two subnets in different Availability Zones. The on-premises DNS or domain-controller addresses are configured during creation, and the connector subnets must be able to reach those addresses through Transit Gateway and Direct Connect.

AD Connector does not replace the Active Directory connectivity required by Horizon. Horizon Connection Servers, domain-joined desktops, and application hosts still communicate directly with the appropriate domain controllers and DNS servers. The connector is used only by AWS services that explicitly support AWS Directory Service integration.

Traffic flows

The architecture has three primary traffic categories:

  1. Network connectivity: Direct Connect carries traffic between the customer network and AWS. Transit Gateway routes approved traffic among the hub, spokes, and on-premises prefixes.
  2. Directory and DNS traffic: Horizon management servers, desktops, application hosts, Route 53 Resolver endpoints, and AD Connectors reach the on-premises DNS servers and domain controllers.
  3. Horizon control traffic: Connection Servers in the hub communicate with Horizon agents and workloads in the spoke VPCs. User display-protocol traffic follows the Horizon design selected for internal and external access.

Security groups, network ACLs, on-premises firewalls, and Transit Gateway route tables must permit the required flows in both directions. Port rules should be based on the exact Horizon version, display protocol, Active Directory requirements, and management tools in use rather than a broad allow-list.

Transit Gateway routing and segmentation

AWS Transit Gateway acts as the central network transit hub. Separate Transit Gateway route tables can enforce segmentation:

  • The hub route table contains routes to approved spoke CIDRs and the on-premises networks.
  • Each spoke route table contains routes to required hub services and on-premises directory networks.
  • Direct spoke-to-spoke routes are omitted unless explicitly required.
  • Routes learned or advertised through Direct Connect are filtered to the minimum necessary prefixes.

This model avoids a growing mesh of VPC peering relationships and gives the network team one place to manage connectivity policy.

Availability and operational considerations

Production implementations should address the following:

  • Deploy Horizon management components and load-balancer targets across multiple Availability Zones.
  • Use redundant Direct Connect connectivity appropriate to the business recovery objective.
  • Validate latency, packet loss, DNS resolution, Kerberos, LDAP, domain join, and Group Policy processing before rollout.
  • Define every AWS subnet used by directory clients in the appropriate Active Directory Sites and Services site.
  • Use a dedicated AD Connector service account and establish a credential-rotation procedure.
  • Test AD Connector capacity with representative authentication demand.
  • Monitor Transit Gateway routes, Direct Connect BGP sessions, Resolver health, Horizon services, and desktop-agent availability.
  • Use least-privilege security rules and prevent unapproved lateral traffic between desktop spokes.

Deployment sequence

  1. Plan non-overlapping CIDR ranges for the hub, spokes, and on-premises networks.
  2. Establish resilient Direct Connect connectivity and validate bidirectional routing.
  3. Create Transit Gateway attachments and segmented route tables.
  4. Configure Route 53 Resolver forwarding for the Active Directory DNS namespace.
  5. Validate directory and DNS connectivity from every planned hub and spoke subnet.
  6. Deploy the Horizon management plane across two Availability Zones in the hub VPC.
  7. Deploy an AD Connector across two Availability Zones in each spoke VPC.
  8. Deploy and domain-join the desktop and application-host workloads.
  9. Apply security controls, monitoring, backup, and operational procedures.
  10. Run authentication, brokering, failover, performance, and recovery tests before production release.

Conclusion

This hub-and-spoke design provides a strong foundation for Horizon 8 on AWS. Centralizing the management plane simplifies administration and security control, while isolated spoke VPCs allow desktop capacity to scale by organizational or workload boundary. Direct Connect and Transit Gateway provide private, centralized connectivity to the customer’s existing Active Directory, preserving established identities and policies.

The most important design principle is to treat AD Connector as an integration point for supported AWS services—not as a replacement for the direct DNS and Active Directory connectivity required by Horizon servers and Windows desktops. With resilient hybrid networking, deliberate routing, Multi-AZ deployment, and tested directory dependencies, the architecture can support a secure and scalable enterprise Horizon environment.

References