Deploying VMware Horizon with Amazon EC2 and Amazon Workspaces


With VMware Horizon, IT departments can run remote desktops and applications in the data center (whether it is on-premises, private corporate cloud, or public cloud) and deliver these desktops and applications to their employees. These employees, or end users, gain a familiar, personalized environment that they can access from any number of devices anywhere throughout the enterprise or from home. Administrators gain centralized control, efficiency, and security by having desktop data in the data center.

As more customers move their enterprise workloads into the public cloud, we are seeing rapid growth of Horizon being deployed in public cloud VMware SDDC (Software Defined Data Center) services such as VMware Cloud on AWS. However, there are AWS environments where VMware Cloud (VMC) on AWS services are not available, such as the AWS secret regions. Without VMware vSphere, the traditional way of deploying Horizon is unavailable.

Purpose of This Tutorial

In this document, we want to highlight a little known, but supported use case of Horizon which would enable deployment on native AWS, either Amazon Elastic Compute Cloud (EC2) or Amazon WorkSpaces Core, without the presence of VMware Cloud on AWS. Specifically, we will discuss how to deploy Horizon Manual Desktop Pools or Manual Farms in these non-vSphere AWS environments.


This document is intended for IT practitioners. It assumes working knowledge of AWS as well as Horizon. For more information on Horizon, see VMware Horizon product documentation.

Overview of Horizon Manual Desktop Pool and Farm

VMware Horizon supports two types of desktop pools and farms: automated or manual. An automated desktop pool or farm uses a vCenter virtual machine template or snapshot to create a pool of identical virtual machines. A manual pool or farm is a collection of pre-created vCenter virtual machines, physical machines, or non-vCenter virtual machines. With manual pools or farms, Horizon does not create or manage the lifecycle of the machines. These machines are created outside of Horizon and then registered with the Horizon Connection Servers. Compared to an automated desktop pool or farm, a manual pool or farm has limited features. Some examples include (but are not limited to):

  • Horizon does not manage the lifecycle of the desktops in a manual desktop pool, so therefore features such as automated provisioning or remote power policy do not apply
  • Instant clones, being a vSphere feature, is not applicable to manual pools or farms
  • App Volumes does not support manual pools or farms

The types of manual pool or farm from AWS that you can manage with Horizon include:

  • Manual pool of virtual desktops using Amazon WorkSpaces
  • Manual pool of published / RDSH desktops using native Amazon EC2 machines or Amazon WorkSpaces
  • Manual pool of Linux desktops using native Amazon EC2 machines
  • Manual pool of virtual desktops using Amazon EC2 machines. For Win 10 virtual desktops, bare metal EC2 hosts are required

This document focuses on the first two use cases in detail. Similar steps are applicable to the remaining use cases.

Why Deploy Horizon Manual Pools and Farms on AWS Native?

When you have a choice in an AWS environment, it is always preferrable to deploy Horizon on VMware Cloud on AWS to enjoy the full range of Horizon features. However, when VMware Cloud on AWS is not available, you can still deploy Horizon manual pools and farms on native AWS machines. Even with the limitations, using Horizon to deploy manual pools or farms on Amazon EC2 or WorkSpaces has the following benefits:

  • With very few exceptions, Horizon manual pools or farms enable you to use the same set of remote experience features that Horizon has for VMware Cloud on AWS virtual machines
  • You can leverage the same Horizon connection broker for all user entitlement workflows on Amazon EC2 machines or Amazon WorkSpaces, including features such as Cloud Pod Architecture (CPA)
  • If you have an existing pod of Horizon on VMware Cloud on AWS desktops running, you can extend the pod to cover the Amazon EC2 machines or Amazon WorkSpaces

Overview of native AWS Services

This section explores Amazon EC2 and Amazon WorkSpaces.

Amazon EC2

Amazon EC2 provides a self-managed secure, resizable compute capacity in the cloud. Amazon EC2 offers the broadest and deepest compute platform with the choice of processor, storage, networking, operating system, and purchase model. You can provision from 400 instance types running Windows or Linux operating systems within minutes including instances with the most powerful GPU instances.

Some of the benefits and features of using Amazon EC2

  • Compliance for HIPAA and PCI
  • Eliminate the complexity of managing hardware inventory, OS versions and patches
  • Increase storage allocation at any time per instance

Additional information about pricing, options and features can be found on the Amazon EC2 website.

Amazon WorkSpaces Core

Amazon WorkSpaces is a managed, secure Desktop-as-a-Service (DaaS) solution. You can use Amazon WorkSpaces Core to provision Windows  desktops in just a few minutes and quickly scale to provide thousands of desktops to workers across the globe. You can pay monthly for just for the WorkSpaces Core machines that you launch.

Some of the benefits and features of using Amazon WorkSpaces Core include:

  • Compliance for HIPAA and PCI
  • Eliminate the complexity of managing hardware inventory, OS versions, and patches
  • Range of image bundles for different hardware and software options such as Value, Standard, Performance, Power, PowerPro, Graphics, and GraphicsPro
  • Optional bundles include Microsoft Office, Trend Micro Worry-Free Business Security Services, and a utilities bundle
  • Increase storage allocation at any time per desktop
  • Bring your own Windows 10 desktop licenses to Amazon WorkSpaces Core if they meet Microsoft's licensing requirements

Additional information about pricing, options, and features can be found on the Amazon WorkSpaces website.

Choosing Between Horizon on Amazon EC2 and Amazon WorkSpaces Core

After you determine that VMware Cloud on AWS is not available to you, the next step is to consider whether to deploy Horizon on Amazon EC2 machines or Horizon on Amazon WorkSpaces Core. Which choice to make will largely depend on your use case. Amazon WorkSpaces Core does not support RDSH apps, so for this use case, deploy Horizon on Amazon EC2 machines. If you are looking to deploy Windows 10 or Linux desktops, you are able to deploy Horizon on Amazon WorkSpaces Core.

Key Horizon Features Available on AWS Native

A significant portion of Horizon features that are available for automated pools or farms (such as on VMware Cloud on AWS or running on-premises VMware SDDC) are also available for manual pools or farms on native Amazon EC2 or Amazon WorkSpaces. You can find detailed information in the following table, broken down into three sections:

  • High level product support across Horizon suite of products
  • Horizon Platform support
  • Horizon Agent, Clients, and Remote Experience support
Table 1: Horizon Product Suite Support 


Available with VMC on AWS

Available on native AWS


Horizon Connection Server



See Table 2 below for detailed feature comparisons

Horizon Agent and Clients



See table below for detailed feature comparisons




Must convert UAG virtual appliance to AMI

App Volumes



AV only supports non-persistent VMs, which are not available with Horizon on AWS native




Horizon Control Plane and SaaS Services



With native AWS, Horizon Control Plane-first gen must still be used for subscription license enforcement

Horizon Cloud Connector



With native AWS, use an AMI version of the Horizon Cloud Connector

Workspace ONE Access






Workspace ONE UEM



See KB for requirements:

Horizon Platform (Connection Server) Support

The following table shows a list of key Horizon Platform features and compares support on VMware Cloud on AWS versus AWS native. Note that not all features are listed. For details on each feature, refer to Horizon Documentation.

Table 2: Horizon Platform (Connection Server) Support 


Available with VMC on AWS

Available with native AWS



Term, Subscription

Term, Subscription

In public cloud usage, Term license is only available for government customers

Cloud Pod Architecture (CPA)



Automated pool of full clones and instant clones



Only available on vSphere-based platforms

Manual pool



Automated farm of instant clones



Only available on vSphere-based platforms

Manual farm



Windows guest OS



Linux guest OS



RBAC and Access Groups



Desktop assignment – floating and dedicated



Desktop pool state



Connection Server restrictions



Desktop pool remote machine power policies



Option to automatic logoff end-user after disconnect



Option to allow end-user to reset/restart desktop from Horizon Client



Enable automatic user assignment



Enable multi-user assignment



Ability to display assigned machine name



vSphere / vCenter related features (DRS, resource pools, access to clusters, and so on)



Specify category folder



Specify client restrictions



VM hosted apps



Pod scalability


  • 12,000 sessions per Pod
  • Up to 7 Connection Servers per Pod
  • Up to 50 Pods and 7 Sites per CPA federation


Up-to-date scalability information for VMC on AWS can be found at

Horizon Remote Experience Support

There are two Horizon Agents (one for Windows VMs and one for Linux VMs), and they support both Horizon Virtual Desktop Infrastructure (VDI) or Apps running on VMware Cloud on AWS, as well as running on Amazon EC2 or Amazon WorkSpaces machines.

There are 8 Horizon Clients (Windows, Linux, Mac, iOS, Android, ARC++, Windows 10 UWP, and Chrome). In addition, end users can also access Horizon from an Internet browser with our HTML Access support. They all support both Horizon VDI, or Apps running on VMware Cloud on AWS, as well as running on Amazon EC2 or Amazon WorkSpaces machines.

VMware KB 80386 details the specific features that are supported on Horizon automated pools or farms deployed in a vSphere environment such as VMware Cloud on AWS. Majority of these features are also supported for manual pools or farms on AWS EC2 or AWS WorkSpaces Core machines. The few exceptions are listed below:

Table 3: Horizon Remote Experience Support


Available with VMC on AWS

Available with AWS Native

PCoIP, PCoIP IP roaming


Yes. Check Teradici’s licensing policy for AWS

Number of displays supported

6 (Horizon Client on Windows)

4 (Horizon Clients on Linux and Mac)

2 (Horizon Clients on Android, ARC++, Chrome, and HTML Access)

1 (Horizon Client on iOS)

4 (Horizon Client for Windows)

1 (Horizon Clients for iOS and Windows 10 UWP)

2 (All other Horizon Clients)

Max resolution supported

7680x4320 (Horizon Client on Windows)

2732x2048 (Horizon Client on iOS)

3840x2160 (All other Horizon Clients)

2732x2048 (Horizon Client for iOS)

3840x2160 (All other Horizon Clients)

vDGA, vSGA, Intel vDGA, AMD vGPU


N/A (these are vSphere-specific technologies)



Select a vGPU enabled Amazon EC2 or WorkSpaces Core instance

Deployment Architecture Options

This section describes three high-level architectural options you have for deploying Horizon 8 with Amazon native EC2 or WorkSpaces Core.

Option 1 - Horizon Remote Agent

In this model you extend an existing Horizon pod, running in a private datacenter, to broker virtual machines running on native EC2 or WorkSpaces Core. Horizon infrastructure components remain in your existing datacenter, and the Horizon Agent is added to your AWS virtual machines. This option makes it easy to realize a hybrid Horizon 8 deployment using AWS capacity. See the description of Use Case 2 in this KB article Remote Agent Support for Horizon Enterprise for additional details. Be sure to read the caveats section.  


Option 2 – Hybrid Cloud Deployment using Cloud Pod Architecture

In this model you start with a Horizon pod in a private datacenter and create an additional Horizon pod on AWS capacity. The pods are federated using Cloud Pod Architecture. See Cloud Pod Architecture in Horizon for more information on CPA.


Option 3 – Horizon 8 in the Cloud

If you don’t have an existing Horizon 8 pod in a private datacenter, or would like to transition purely to the cloud, you have several options with Amazon. Deploying Horizon 8 infrastructure components to EC2 enables you to create manual desktop pools with Amazon WorkSpaces Core, or manual RDSH farms with native EC2. Horizon on VMware Cloud on AWS provides additional Horizon functionality such as Instant Clones and App Volumes, on a managed, vSphere-based SDDC.


Setting up and Configuring an Amazon Account

Amazon Web Services (AWS) is a secure cloud services platform, offering compute power, database storage, content delivery, and other functionality to help businesses scale and grow.

If you do not have an account, you can create an account on the Amazon Web Services home page.

Alternatively, you can use your existing Amazon account.

When using the Horizon Agent with Amazon WorkSpaces or WorkSpaces Core, make sure the instances are configured for AlwaysOn. AlwaysOn is the default running mode for WorkSpaces Core instances. With AlwaysOn, the WorkSpaces service will ensure that instances are always powered on and ready to be accessed by the Horizon Client. If an end user powers the instance down via Windows, the WorkSpaces service will automatically power it back on.

Deploying Horizon Infrastructure on Amazon EC2 Machines

Before you can use Horizon to manage Amazon EC2 machines or Amazon WorkSpaces Core, you must first deploy Horizon infrastructure components on Amazon EC2 machines:

  1. Set up and configure an AWS Account.
  2. Create the desired EC2 instance type and quantity that meet the recommended requirement of the Horizon infrastructure in your AWS account.
    1. Deploy Horizon Infrastructure Components in the Amazon EC2 machines you created in Step 2.
  3. Deploy any additional infrastructure components needed for Horizon, such as events database, Active Directory domain controllers, or file shares.

Deploying Horizon components on Amazon EC2 Environment

Regardless of whether you have chosen to deploy Horizon on Amazon EC2 machines or Horizon on Amazon WorkSpaces, you need to deploy the Horizon infrastructure components on Amazon EC2 instances.

Note: The exception is that if you already have a Horizon pod deployed in a private datacenter or a managed SDDC environment such as VMware Cloud on AWS, you can extend the infrastructure components of the existing Horizon Pod to manage your Amazon EC2 machines or Amazon WorkSpaces Core machines using the Horizon Remote Agent method described above.  

Horizon Connection Server

Horizon Connection Servers are enterprise-class desktop management servers that securely broker and connect users to desktops and RDSH-published applications running on VMs, physical PCs, blade PCs, or RDSH servers. Connection Servers authenticate users through Windows Active Directory, and direct the request to the appropriate, entitled resource.

Connection Servers provide the following management capabilities:

  • Authenticating users
  • Entitling users to specific remote desktops and application pools
  • Assigning applications packaged with VMware ThinApp® to specific desktops and pools
  • Managing remote desktop and application sessions
  • Establishing secure connections between users and remote desktops and applications
  • Enabling single sign-on
  • Setting and applying policies

Connection Servers (up to 7) from a single data center can be grouped into a pod.

VMware Unified Access Gateway Appliance

VMware Unified Access Gateway virtual appliances enable secure remote access from an external network to a variety of internal resources without the need for a VPN. These appliances direct authentication requests to the appropriate server and discard any unauthenticated requests. Users can access only the resources that they are authorized to access.

Unified Access Gateway also ensures that the traffic for an authenticated user can be directed only to the desktop and application resources to which the user is actually entitled. This level of protection involves specific inspection of desktop protocols and coordination of potentially rapid changing policies and network addresses, to accurately control access.

VMware Horizon Cloud Connector

The VMware Horizon® Cloud Connector is a virtual appliance that connects a Horizon pod with VMware Horizon® Control Plane. During deployment of the virtual appliance, a pairing process connects the specified Connection Server to Horizon Cloud Service so that you can manage the Horizon subscription licenses.

If you are using a Horizon Term License, this component does not need to be installed.

While Horizon Cloud Connector can also enable additional SaaS services of Horizon Control Plane to be consumed, these services are currently only available for vSphere-based deployment.

VMware Dynamic Environment Manager

VMware Dynamic Environment Manager offers personalization and dynamic policy configuration across any virtual, physical, or cloud-based environment.

  • Simplify end-user profile management by providing organizations with a single and scalable solution that leverages existing infrastructure.
  • Provide end users with quick access to a Windows workspace and applications, with a personalized and consistent experience across devices and locations.

VMware User Environment Manager provides profile management by capturing user settings for the operating system and applications. Unlike traditional application profile management solutions, User Environment Manager does not manage the entire profile. Instead, it captures settings that the administrator specifies. This reduces login and logout time because less data needs to be loaded. User data is managed through folder redirection.

VMware Workspace ONE Access

VMware Workspace ONE Access is an identity-as-a-service (IDaaS) offering. Workspace ONE Access acts as an identity provider by syncing with Active Directory to provide single sign-on (SSO) for SaaS, web, cloud, and native mobile applications. It supports access to applications and desktops running Microsoft Windows Remote Desktop Services, XenApp 5.0 and later, ThinApp, SAML-based applications, and virtual desktops with Horizon. Workspace ONE Access is also responsible for enforcing authentication policy based on networks, applications, or platforms.

While Workspace ONE Access can be used to provide access to Horizon Manual Pools and Manual Farms running on Amazon EC2, Workspace ONE Access cannot be directly installed in Amazon EC2 machines.

Horizon Deployment Architecture on Amazon EC2

A typical Horizon architecture design uses a pod strategy. A pod is a unit of organization determined by Horizon scalability limits (which is up to 7 Connection Servers at the current time). Each pod has a separate management UI and therefore the typical design is to minimize the number of pods.

For this particular use case, you can deploy an AWS Virtual Private Cloud (VPC) within an AWS Region, spanning two Availability Zones (AZ). For a proof of concept this could be a single AZ. This VPC holds AWS services shown in orange and basic components, Amazon Elastic Compute Cloud (EC2) VMs for Horizon infrastructure components shown in green and Elastic Network Interfaces (ENI) installed on EC2 bare metal hardware.


Description automatically generated

Figure 1: Horizon Deployment Architecture on Amazon EC2

For the customer-managed VPC, a /20 CIDR is taken which is carved up in 4 subnets on both Availability Zones.

  • Two /22 Orange subnets for private AWS components that use DHCP, like ENI and Directory Service
  • Two /23 Green subnets for private Horizon components that use static addresses
  • Two /24 Yellow subnets for public AWS components that use DHCP, like the public load balancer
  • Two /25 Red networks for public Unified Access Gateway static addresses which also leverage a public Elastic IPv4 address

The public subnets have a default route towards the internet gateway, but the private subnets all point to the same NAT Gateway. On failure of the primary Availability Zone an administrator will have to adjust the main route table to point to the NAT Gateway of the secondary Availability Zone to maintain certificate revocation checking and enable Identity Manager to synchronize changes.

For load balancing Unified Access Gateway and Horizon by default AWS Classic Load Balancers are used, which work with Cloud Password Identity Manager deployments. For more advanced deployments or when leveraging certificates/smartcards these can be replaced by a 3rd party load balancer such as F5 or KEMP.

By default, two Unified Access Gateways with the c5.large instance type are deployed, one on each AZ, capable of handling 1,000 sessions. For every extra 2,000 sessions two extra Unified Access Gateways should be deployed, one on each AZ, this also requires raising the EIP soft limit (default is 5, but 2 are taken by NAT gateways and 2 by the existing UAGs) through the Amazon VPC limits.

By default, four Horizon Connection Servers with the t3.xlarge instance type are deployed, two on each AZ, capable of handling 4,000 sessions on each AZ. For every extra 4,000 sessions two extra Connection Servers should be deployed, one on each AZ. One Cloud Connector with the t3.xlarge instance type is deployed.

Two Identity Manager Connectors with the t3.xlarge instance type should be deployed manually, which are capable of handling the AZ maximum of 10 pods or 100.000 users.

For VMware Dynamic Environment Manager and user profiles at least two file servers (t3.xlarge with 5 General Purpose SSD EBS Volumes suggested per pod) should be deployed manually (or leveraging Amazon FSx for Windows File Server if available in the region) across the AZs.

When using multiple sites or regions a Global Service Load Balancer (GSLB) like Amazon Route 53 should be leveraged.

Deploying and Configuring Horizon Infrastructure Components

Deploying Horizon 8 infrastructure components on EC2 follows the same principles as installing Horizon 8 on a traditional vSphere-based, private datacenter. There are some differences, called out in specific links to product documentation found below. 

There are 3 different options for deploying the Horizon agents to virtual machines in EC2 or Amazon WorkSpaces:

Option 1:   Install the Horizon Agent manually on individual Amazon WorkSpaces Core instances. You must first prepare your VM for Horizon 8 Management.  Then install the Horizon 8 Agent on your VM. You may also install the Horizon Agent silently. See the Horizon Agent documentation for details. This is a good option for testing the Horizon Agent on a small number of WorkSpaces instances.   

Option 2:   Use a PowerShell script developed by Amazon and VMware documented in this KB article to automate the deployment of the Horizon Agent. This method embeds a PowerShell script in your WorkSpaces Core base image to enable automated Horizon Agent installation on each WorkSpaces Core instance created from that base image. This is suitable for use in most environments and is a good option for installing the Horizon Agent on a large number of WorkSpaces Core instances during creation.  

Option 3:   VMware and Amazon collaborated to create the VMDS Fling, which streamlines the process of installing the Horizon Agent and registering AWS machines to your Horizon Connection Server.   This Fling is not supported, nor is it currently under new development, but may still be used by customers who have used it in the past.  We encourage the use of Options 1 or 2 for new installations.  

Example Configuration

The following illustrates a sample configuration for Horizon infrastructure components deployed on EC2.

  1. VPC: In the AWS services console, under Services, navigate to and click VPC. In the VPC Dashboard, click Your VPCs. You should be able to view your newly created VPC in this window.
    Graphical user interface, text, application

Description automatically generated 
  2. Subnets: In the VPC dashboard, select Subnets and search for the name you provided during parameters section. This should search all the subnets which are in this deployment.
    Graphical user interface, text, application, email

Description automatically generated 
  3. RouteTables: You should notice two route tables with EXTERNAL and INTERNAL in their names. INTERNAL route table should say Yes in the Main column.
    Graphical user interface, text, application, email

Description automatically generated 
  4. Directory Services: In the AWS services console, search for directory, and select Directory Services. In the directory services window, you should be able to view the domain name of the directory deployed using the template.
    A screenshot of a computer

Description automatically generated 
  5. AWS RDS MS SQL: In the AWS services console, select RDS. In the Amazon RDS window, click Databases, and you should be able to view your database in the DB identifier column.
    A screenshot of a computer

Description automatically generated 
  6. Horizon Connection Server: In the list of EC2 Instances, you will find two connections servers. You can identify these by the names you provided during deployment, or check for CS logical ID in the tag name of the EC2 Instance.
    1. CS01: Master Connection Server
      Graphical user interface, text, application

Description automatically generated 
    2. CS02: Replica Connection Server
      Graphical user interface, text, application

Description automatically generated 
  7. ELB for Connection Server: You will see a classic load balancer for connection servers deployed across two availability zones. The following screenshot shows the contents of the Description tab:
    Graphical user interface, text, application, email

Description automatically generated
    The following screenshot shows the contents of the Instances tab:
    A screenshot of a computer

Description automatically generated 
  8. Cloud Connector: A cloud connector instance will have a logical ID in the Instance tag, such as CloudConnectorInstance.
    A screenshot of a computer

Description automatically generated 
  9. UAG: Two UAG instances will be deployed.
    Graphical user interface, text, application

Description automatically generated 

Post Deployment Configuration

After the ELB deployment is successful, you need to make the following changes in the ELB settings for successfully connecting this ELB to selected connection servers.

  • Security Group: Allow the 80,443 HTTP inbound traffic from Anywhere for the time being
  • Stickiness: AppCookieStickinessPolicy, cookieName='JSESSIONID'
  • HEALTH CHECK condition to HTTPS: 443/favicon.ico
  • LISTENER: HTTPS 443 -> HTTPS 443
  • For more information, see Set Up Photon OS on EC2

Data Encryption

Refer to SSE-S3 or SSE-KMS encryption for Amazon S3 and Amazon EBS encryption.


For details on how to monitor the various Horizon system health components, see Horizon support documentation:

Backup and Restore

For more information on how to backup and restore the Horizon configuration data and Connection server configuration data, see Maintaining Horizon Components.

Upgrades and Patching

Refer to Horizon support documentation:


The process to contact support is available at VMware Support Offerings and Services.

VMware support policies and tiers are available at Support Policies.

Deploying Horizon Manual Pools or Farms using Amazon Workspaces Core Desktops

After you have deployed and configured your Horizon infrastructure components, you are ready to deploy your first manual pool of Amazon WorkSpaces Core. Similar to other non-vSphere virtual machines, Amazon WorkSpaces Core are registered with Connection Server as part of the Horizon Agent installation process. Hence these machines are also referred to as registered non-vSphere virtual machines.


  1. Prepare the non-vSphere virtual machine to deliver remote desktop access. Before you add this virtual machine to a manual desktop pool, you must prepare each machine individually.
  2. Install Horizon Agent into these Amazon WorkSpaces Core machines. As part of the installation process, these WorkSpaces Core machines  are now registered with Horizon. These machines are also referred to as registered virtual machines. To prepare non-vSphere virtual machines, see Prepare a non-vSphere Machine for Horizon 8 Management.
  3. Gather the configuration information that you must provide to create the pool. See Worksheet for Creating a Manual Desktop Pool.
    1. Power policies are not supported for manual desktop pools that contain registered non-vSphere virtual machines because these machines are not directly managed by vSphere.
    2. 3D rendering options are not applicable for manual desktop pools that contain registered non-vSphere virtual machines. However, these virtual machines can directly leverage GPU capability available to the Horizon Agent operating system. Verify the graphics support with the third-party virtualization platform vendor.
  4. Create the manual desktop pool and select the Other sources option to select the registered non-vSphere virtual machine as the desktop pool source. See Create a Manual Desktop Pool.
  5. Entitle users to access the manual desktop pool. See Entitling Users and Groups in the Horizon Administration document.
  6. Perform management tasks on non-vSphere registered machines. See Managing non-vSphere Registered Machines.

Preparing Amazon WorkSpaces Core

After the Amazon WorkSpaces Core machines have been created, you must perform certain tasks to prepare the virtual machines to be managed by Horizon.


  • Verify that you have administrative rights on the WorkSpaces Core machine(s).
  • To make sure that remote desktop users are added to the local Remote Desktop Users group of WorkSpaces Core machine(s), create a restricted Remote Desktop Users group in Active Directory. See the Horizon Installation document for more information.


  1. Power on the WorkSpaces Core machine(s) and verify that it is accessible to the Connection Server instance.
  2. Join the WorkSpaces Core machines to the Active Directory domain for your remote desktops.
  3. Configure the Windows firewall to allow Remote Desktop connections to the WorkSpaces Core machines.

Installing Horizon Agent

You must install Horizon Agent on all of the WorkSpaces Core machines  in order for Horizon to manage them.


Creating a Manual Pool of Amazon Workspaces Machines

This section describes the process for creating a manual pool of Amazon WorkSpaces machines.


  • Prepare the machines to deliver remote desktop access.
  • In a manual pool, you must prepare each machine individually.
  • Horizon Agent must be installed and running on each machine.
  • To prepare non-vSphere virtual machines or physical computers, see Managing non-vSphere Registered Machines.


  1. In Horizon Console, select Inventory > Desktops.
  2. Click Add to pull up the Add Pool wizard.
  3. In the Type pane, select Manual Desktop Pool.
  4. In the Machine Source panel, choose Other sources.
  5. In the User Assignment panel:
    • Choose the type of User Assignment:
      • In a dedicated-assignment pool, each dedicated user is assigned to a machine. After a user is assigned a desktop, no other user can use the desktop. Users receive the same machine each time they log in.
      • In a floating-assignment pool, users receive different machines each time they log in.
      • For details, see Assign a Machine to a User in a Dedicated-Assignment Pool.
    • Choose Enable Automatic Assignment if using a dedicated-assignment pool. For floating-assignment pools, this is automatically enabled for you. When enabled, a machine is assigned to a user when the user first logs in to the pool. If you do not enable Automatic Assignment, you must explicitly assign a machine to each user. You can assign machines manually even when Automatic Assignment is enabled.
    • Choose Enable Multi-User Assignment if using a dedicated-assignment pool. For floating-assignment pools, this option is not available. When this option is enabled, you can assign multiple users to each machine in the pool. However, only one user is able to log in to the machine at any given time. If an assigned user has a connected or disconnected session on a multi-user assignment machine, other assigned users will be unable to launch a session on that machine. Multi-user assignment is not supported for automatic user assignment desktop pools.
  6. In the Desktop Pool ID panel:
    • ID. Type the desired ID for the pool you are creating. This is the pool name that users see when they log in to their desktop in Horizon Client. This ID is the unique identifier for the pool. If you have a vCenter running separately in your Horizon pod, make sure that vCenter Server is not using the same pool ID.
    • Display Name. Optionally, you can add a Display Name. This is the name of the desktop that end-users will see when they connect to the Horizon Client. If this field is left blank, the ID will be shown to the end-users.
    • Access Group. Optionally, you can specify an Access Group for the pool. If you use an access group, you can delegate managing the pool to an administrator who has a specific role. If you do not specify an Access Group for this pool, you are leaving the pool in the default root access group. Most customers do not use Access Group.
    • Description. Optionally, you can specify a description for the pool. This is only visible to administrators.
  7. In the Desktop Pool Settings panel:
    1. Specify State.
      • Enabled. After being created, the desktop pool is enabled and ready for immediate use.
      • Disabled. After being created, the desktop pool is disabled and unavailable for use. This is an appropriate setting if you want to conduct activities such as testing or other forms of baseline maintenance. When this state is in effect, remote desktops are unavailable for use.
    2. Optionally, you can specify Connection Server Restrictions. This capability allows you to restrict or segregate incoming end user connection requests by connection server for security purpose.
      • None. The desktop pool can be accessed by any Connection Server instance.
      • With tags. Select one or more Connection Server tags to make the desktop pool accessible only to Connection Server instances that have those tags. You can use the check boxes to select multiple tags.
      • If you intend to provide access to your desktops through VMware Workspace ONE Access, and you configure Connection Server restrictions, the VMware Workspace ONE Access app might display desktops to users when those desktops are actually restricted. VMware Workspace ONE Access users will be unable to launch these desktops.
    3. Optionally, you can specify Category Folder. This specifies the name of the category folder that contains a Start menu shortcut for the desktop pool entitlement on Windows client devices.
    4. Optionally, you can enable Client Restrictions. Select whether to restrict access to entitled desktop pools from certain client computers. You must add the names of the computers that are allowed to access the desktop pool in an Active Directory security group. You can select this security group when you add users or groups to the desktop pool entitlement.
    5. Specify Logoff After Disconnect setting:
      1. Immediately. Users are logged off as soon as they disconnect.
      2. Never. Users are never logged off.
      3. After. The time after which users are logged off when they disconnect. Type the duration in minutes. The log off time applies to future disconnections. If a desktop session was already disconnected when you set a log off time, the log off duration for that user starts when you set the log off time, not when the session was originally disconnected. For example, if you set this value to five minutes, and a session was disconnected 10 minutes earlier, Horizon will log off that session five minutes after you set the value.
    6. Optionally select Show Assigned Machine Name. This is only available for Dedicated Assignment desktops. This displays the host name of the assigned machine instead of pool display name when the user logs into their Horizon Client to launch their desktop. If the machine is assigned, then Display Name (Machine not assigned) will be displayed.
    7. Optionally select Show Machine Alias Name. This is only available for Dedicated Assignment desktops. Show the machine alias name in Horizon Client launch items for assigned users. If this option is not selected, but Show Assigned Machine Name is selected, the machine hostname is shown.
    8. If neither Show Assigned Machine Name or Show Machine Alias Name are selected, then the pool name is displayed to the user in their Horizon Client.
  8. In the Remote Display Protocol panel:
    1. Select Default Display Protocol. You can choose VMware Blast, PCoIP, or Microsoft RDP.
      1. VMware Blast. The VMware Blast Extreme protocol is built on the H.264 protocol and supports the broadest range of client devices, including smart phones, tablets, ultra-low-cost PCs, and Macs, across any network.
      2. PCoIP. PCoIP is supported as the display protocol for virtual and physical machines that have Teradici hardware. PCoIP provides an optimized PC experience for the delivery of images, audio, and video content for a wide range of users on the LAN or across the WAN.
      3. Microsoft RDP. Microsoft Remote Desktop Connection (RDC) uses RDP to transmit data. RDP is a multichannel protocol that allows a user to connect to a computer remotely.
    2. Select whether to Allow Users to Choose Protocol. When selected, this allows users to override the default display protocol for their desktops in Horizon Client.
    3. Optionally enable Allow Session Collaboration. When enabled, this allows users of the pool to invite other users to join their remote desktop sessions. Session owners and session collaborators must use the VMware Blast display protocol.
      1. In the Machines panel, you can select one or more EC2 machines or WorkSpaces to add to this manual pool.
      2. In the Ready to Complete panel, confirm your selections and then press Finish.

Note: Horizon Manual Pool with WorkSpaces can directly leverage GPU capabilities available to those machines. Ensure that you have the appropriate GPU-enabled AWS instances before adding them to the Horizon Manual Pool.

In Horizon Console, you can view the machines as they are added to the pool by selecting Inventory > Desktops. Now you can entitle users to access the pool. See Entitling Users and Groups in the Horizon Administration document.

You can also view the individual EC2 machines and Amazon WorkSpaces that have been registered with Horizon (for example, has Horizon Agent installed) by navigating to Settings > Registered Machines > Others.

Managing a Manual Pool or Farm Created from Amazon WorkSpaces

Remove a Registered Machine from a Manual Desktop Pool

You can reduce the size of a desktop pool by removing registered machines from the pool.


  1. In Horizon Console, select Inventory > Machines.
  2. Select the Others tab.
  3. Select the unmanaged machines to remove.
  4. Click Remove.
  5. Click OK.

Remove Registered Machines From Horizon

If you do not plan to use a registered machine again, you can remove it from Horizon.

After you remove a registered machine, it becomes unavailable in Horizon. To make the machine available again, you must reinstall Horizon Agent.


Verify that the registered machines that you want to remove are not being used in any desktop pool.


  1. In Horizon Console, select Settings > Registered Machines.
  2. Click the RDS Hosts tab.
  3. Select one or more machines and click Remove.
    You can select only machines that are not being used by a desktop pool.
  4. Click OK to confirm.

Summary and Additional Resources

This operational tutorial explored several options to deploy Horizon 8 with AWS. Whether you want to deploy in a hybrid cloud or pure cloud model, extend an existing or expand with a new Horizon pod to AWS, leverage manual desktops and farms or the complete Horizon stack, there is an architecture available to support you.

Procedures included:

  • Deploying Horizon infrastructure on Amazon EC2 devices
  • Deploying Horizon Manual Pool or Farm using Amazon EC2 devices
  • Managing Manual Pools or Farms created from Amazon WorkSpaces

Additional Resources

For more information, you can explore the following resources:


The following updates were made to this guide:


Description of Changes


  • Added additional Horizon agent deployment options.


  • Guide was published.

About the Author and Contributors

This document was written by the following collaborators:

  • Mike Erb, Staff EUC Architect, EUC Technical Marketing, VMware
  • Josh Spencer, Group Product Line Manager, Horizon Product  Managament, VMware
  • Angela Ge, Director,  Horizon Product Management VMware
  • Jim Yanik, Director, EUC Technical Marketing, VMware


Your feedback is valuable.

To comment on this paper, contact VMware End-User-Computing Technical Marketing at

Filter Tags

Horizon Horizon Document Operational Tutorial Intermediate Linux