Deploying Citrix DaaS on Amazon EC2
 

Overview

This guide will help you deploy CitrixDaaS on Amazon EC2.

Citrix DaaS

Citrix DaaS provides employees with a complete workspace from any device while leaving most of the setup, upgrades, and monitoring to Citrix. Your IT department will continue to manage and control the virtual machines, applications, and policies on the back end, while Citrix will manage all the key infrastructure, installation, setup, and upgrades needed to maintain a Citrix environment. This reduces administrative overload and ensures you have all the latest features and functionality.

By hosting Virtual Delivery Agents (VDAs) in Resource Locations managed by the customer, the amount of data and information accessible to the Citrix Cloud control plane is limited. The control plane only has access to metadata (machine names, application names, application shortcuts, and so forth).
This keeps intellectual property secure. All communication between the customer’s resource location and the Citrix Cloud control plane is encrypted using HTTPS port 443 through the TCP protocol.
All connections are outbound, and no inbound connections are accepted. Citrix collects only the necessary logs to troubleshoot potential issues.

Components Managed by Citrix: All components that Citrix manages are kept highly available.

• Studio: Management console that is used to configure your environment
• Monitor: Monitoring tool that enables IT support and help desk personnel to troubleshoot issues
• License Server: The component that manages licenses for the environment and provides usage statistics
• Workspace Configuration: The collection of settings that allows you to create configurations and customizations for your users’ workspace
• Delivery Controllers: Communicates through the Cloud connectors to load balance applications and desktops, authenticate users, and broker or prioritize connections
• SQL: Server database used to store the data from the controllers
• Cloud Connectors: Communication channel between Citrix Cloud and the customer’s resource location. These are hosted in each of the customer’s resource locations but are pushed scheduled updates from the Citrix Cloud services. (the only parts handled by the customer are Cloud Connector Windows updates and patching)

Components Managed by Customer:

• Virtual Delivery Agents: VDAs register with the Cloud Connectors to broker connections and provide users with the resources that they need to access. Citrix DaaS can use either the current release (CR) VDA or the long-term service release (LTSR) VDA (2402 or higher).
  • CR VDAs reach end of maintenance six months after they are released and end of life 18 months after they have been released. CRs are not eligible for extended support programs.
  • LTSR VDAs reach end of life five years after they are released. The end of extended support is ten years after they have been released.
  • The full lifecycle matrix can be found here.
  • An FAQ on LTSR can be found here.
• Active Directory: Used for authentication and authorization, Active Directory authenticates users and ensures that they are getting access to appropriate resources. A subscriber’s identity defines the services to which they have access in Citrix Cloud. This identity comes from Active Directory domain accounts provided from the domains within the resource location.
• Identity Provider: The final authority for the user’s identity. The following identity providers are supported: on-premises Active Directory, Active Directory plus token, Azure Active Directory, Citrix Gateway, and Okta. An in-depth look at how Citrix Workspace handles identity and authentication can be found here
• App and Desktop Workloads: The app and desktop instances published by Citrix customers can be on-prem, hosted in public clouds, or in a hybrid mixture of both. Citrix provides many tools to simplify and facilitate how these session hosts are built and maintained. By allowing customers to maintain their session hosts, intellectual property is protected.

Components that can be managed either by Citrix or by Customer:

• Citrix Gateway: Used so external users can connect to internal resources. Citrix Gateway can either be deployed and managed within the customer’s resource location or deployed and managed in Citrix Cloud.
• StoreFront: Used as the web interface for access to applications and desktops. StoreFront is an optional component installed within a customer’s data center, or the cloud-hosted Workspace can be used for more functionality.
• 

Amazon Elastic Compute Cloud (Amazon EC2)

Amazon EC2 provides on-demand and scalable computing capacity in the Amazon Cloud.

We need to deploy these features before installing Citrix DaaS:

• Virtual Private Cloud (VPC): A VPC is a virtual network containing all networking-relevant entities.
• Availibility Zone: An Availibility Zone is a logical, stand-alone datacenter in a region.

• Subnets: A Subnet is a range of IP addresses in your VPC. Each Subnet can only be deployed in a single Availability Zone, it cannot be deployed over multiple Availability Zones.
• Gateways: A Gateway connects your VPC to another network.
  An Internet Gateway connects your VPC to the Internet.
  A NAT Gateway connects your Private Subnets to the Internet, to other VPCs, or to on-premises networks.

• Instances: Instances are Virtual Machines running your payload.
• Amazon Machine Images (AMIs): AMIs are preconfigured Virtual Machine templates for your instances.
• Instance types: You can choose various Instance configurations e.g. different CPUs, different amounts of memory, storage, and networking configurations.
• Key pairs: Key pairs are needed to secure your Instances' login information.
• Security groups: Security groups act like virtual firewalls.
  You can allow or reject Network traffic by specifying protocols, ports, source IP- and destination IP ranges.

We will provide a more detailed description when we deploy each needed feature.

The following diagram shows an example VPC:
The VPC has one Subnet in each of the Availability Zones in the Region, EC2 Instances in each Subnet, and an Internet Gateway to allow communication between the resources in your VPC and the Internet.

Prerequisites for deploying Citrix DaaS on Amazon EC2

Before we can deploy Citrix DaaS on Amazon EC2, we need to create and configure all needed prerequisites on Amazon EC2:

We assume you already have a Citrix Cloud tenant with an active trial or a paid subscription to the Citrix DaaS service and an active AWS account.
 

Deploy an Amazon VPC

An Amazon Virtual Private Cloud (VPC) enables you to launch AWS resources into a virtual network that you have defined.

1. Log on to your AWS console and open the VPC service dashboard (enter VPC in the Search bar on the top of the page).
   
2. No VPCs are defined, so we need to create one.
3. Choose the AWS region where you want to create your VPC.
   
4. Fill out the VPC settings according to your needs (example screenshot).
   
   
   
5. After completing all settings, click filling out all settings and click Create VPC to start creation. It will take some moments before the VPC is ready. 
6. 

You have successfully created a VPC.
 

Deploy Subnets, Internet Gateways, NAT Gateways, Route Tables and Security Groups

After creating the VPC, we deploy all needed network components, such as Subnets, Internet Gateways, NAT Gateways, and Router Tables.

Deploying the Subnets

A Subnet is a range of IP addresses in your VPC.
You can create AWS resources in specific subnets, such as EC2 instances.
Each Subnet can only be deployed in a single Availability Zone.
You can protect your infrastructure by deploying multiple Subnets in different Availability Zones.
You specify its IP addresses depending on the configuration of the VPC.

The Subnet type is determined by how you configure routing for your Subnets:

• Public Subnet: The Subnet has a direct route to an Internet Gateway.
  Resources in a Public Subnet can directly access the Internet.
• Private Subnet: The Subnet does not have a direct route to an Internet Gateway.
  Resources in a Private Subnet require a NAT device to access the Internet.

1. Log on to your AWS console, open the VPC service dashboard (enter VPC in the Search bar on top of the page), and choose the Subnets option:
2. In this guide, we create 3 different Subnets:
   1. A Public Subnet containing the Jump Host VM
   2. A Private Subnet for the Cloud Connector VMs and other Infrastructure-related VMs
   3. A Private Subnet for all Worker VMs/VDAs
      
      
      
      
3. Remember to disable the Auto-assign setting.
   

After creating the Subnets, you must create an Internet Gateway to enable the Public Subnet and the Jump Host-VM to connect to the Internet.
 

Deploying an Internet Gateway

An Internet Gateway allows communication between your VPC and the Internet. It supports IPv4 and IPv6 traffic and provides a target in your VPC Route Tables.
Resources in your Public Subnets can connect to the Internet if they have a public IPv4 address or an IPv6 address. The communication flow is two-way—the resources can also be contacted from the Internet.
For communication using IPv4, the Internet Gateway also performs Network Address Translation (NAT).

1. Log on to your AWS console, open the VPC service dashboard (enter VPC in the Search bar at the top of the page), and choose the Internet Gateways option.
2. Give it a comprehensive name and click Create internet gateway.
   
3. After creating the Internet Gateway, you must attach it to the VPC by clicking the Attach to a VPC button. Choose the correct VPC.
   

To give the Public Subnet connection to the Internet, you need to adjust the adjacent Route Table. A Route Table contains a set of routes directing the network traffic from your Subnet or Gateway.

1. Log on to your AWS console, open the VPC service dashboard (enter VPC in the Search bar at the top of the page), and choose the Route Tables option.
2. Choose Create Route Table and set the values according to your needs.
   
3. Create the Route Table by clicking the adjacent button.
4. After creation, choose the Route Table that has just been created and edit the route.
   
5. Enter 0.0.0.0/0 into the Destination field and choose the Internet Gateway you created as the Target. Click Add route to save the route to the Route Table.

The Public Subnet now has a connection to the Internet.
 

Deploying a NAT Gateway

After creating the Internet Gateway, you need to create a NAT Gateway in the Private Subnet(s) to enable the Private Subnet(s) to connect to the Internet.

A NAT Gateway is a Network Address Translation (NAT) device.

When you create a NAT Gateway, you specify one of the following connectivity types:

• Public – (Default) Instances in Private Subnets can connect to the Internet.
• Private – Instances in Private Subnets can connect to other VPCs or your on-premises network but not to the Internet.

1. Log on to your AWS console, open the VPC service dashboard (enter VPC in the Search bar at the top of the page), and choose the NAT gateways Tables option.
2. Choose the settings according to your needs and click on Create NAT gateway to create it.
   
3. After creation, you need to add a Route Table and change the Route Table for the NAT Gateway as you did before for the Internet Gateway.
   
4. Add the correct settings and click on Add route.
5. After changing the Route Table, you must edit the Subnet settings by choosing Subnet associations. Select the Internal Subnet and click on Save associations.
   

All instances in the Internal Subnet should be able to connect to the Internet.
 

Set the IAM Permissions

After creating all needed Network components, we must set all required IAM permissions.

Identity and Access Management (IAM) allows control of access to AWS resources.
IAM controls who can be authenticated (signed in) and authorized (have permissions) to use Amazon VPC resources.
 

Deploying the initial IAM Policy

You can control access by attaching policies and attaching them to identities or resources.
A Policy defines the permissions associated with it. Policies are evaluated when a user or a root user wants to access a resource.
Permissions in the Policies determine whether the request is allowed or denied.
Most Policies are stored in AWS as JSON documents.

1. Log on to your AWS console, enter IAM in the Search bar at the top of the page, and choose the IAM option.
2. Click on Policies on the Dashboard.
   
3. Click on Create policy.
   
4. Click JSON and copy the JSON-code provided later into the Policy editor.
   
5. Click Next to name, review, and save the Policy.
   

You can find the current recommendations for the IAM settings in the Citrix Product Documentation.

More information about IAM JSON-based policies can be found in the IAM JSON policy reference.

You can see the JSON-defined policy we used in this guide here:

You have successfully created the IAM Policy.
 

Deploying an IAM User Group

An IAM User Group is a collection of IAM Users. You can specify permissions for multiple users. Any user in that user group automatically has Admins group permissions.

You can attach an Identity-based Policy to an IAM User Group so that all users in the user group receive the policy's permissions.

1. Log on to your AWS console, enter IAM in the Search bar at the top of the page, and choose the IAM option.
2. Click on Groups on the Dashboard.
   
3. Enter and choose all needed information, such as the group name, before clicking Create user group. Add the AWS account root user and the previously created Policy here.
   
4. After creation, you can review the settings.

You have successfully created the IAM User Group and associated the previously created Policy.
 

Deploying an IAM User

An IAM User represents a user or workload who uses the IAM User to interact with AWS resources. An IAM User consists of a name and credentials.

The IAM User can access AWS in different ways depending on its credentials – these are the relevant ones for this guide:

• Console password: The IAM User can type a password to sign in to interactive sessions such as the AWS Management Console.
• Access keys: These are used to make programmatic calls to AWS. If the IAM User has active access keys, they continue to function and allow access through the AWS CLI, Tools for Windows PowerShell, AWS API, or the AWS Console Mobile Application.

For this guide, we create an IAM User with assigned Access keys.

1. Log on to your AWS console, enter IAM in the Search bar at the top of the page, and choose the IAM option.
2. Click on Users on the Dashboard.
   
3. You will see the IAM Root User listed. Click on Create user to continue.
   
4. Enter the name of the IAM User and click Next to continue.
   
5. Choose Add user to group and select the previously created IAM User Group.
   Click Next to review and create the IAM User.
   
6. As we need an IAM User with assigned Access Keys, we must create the needed keys.
7. Open the just created IAM user and click on Create access key.
   
8. Choose Third-party service and click Next.
   
9. The Access Keys are now created. You can download them as a CSV file and store them in a safe place.
   
10. Click Done to complete this step.
     

Deploying Security Groups on the Network Entities

A Security Group acts like a virtual firewall.
If you associate a Security Group with an EC2 instance, it controls the instance's inbound and outbound traffic.

When you create a VPC, it comes with a default Security Group.
You can create additional Security Groups for a VPC, each with their own inbound and outbound rules:

• You can specify each inbound rule's source, port range, and protocol.
• You can specify each outbound rule's destination, port range, and protocol.

The following diagram shows a VPC with a Subnet, an Internet Gateway, and a Security Group.
The Subnet contains an EC2 instance. The Security Group is assigned to the instance and acts as a virtual firewall. The only traffic that reaches the instance is the traffic allowed by the Security Group rules.

1. Log on to your AWS console, enter VPC in the Search bar at the top of the page, and choose the Security option. Click on Security Groups on the Dashboard.
   
2. Create a new Security Group by clicking on Create security group.
   
3. Fill out all relevant fields and add the Inbound Rules by clicking Add rule on the Inbound Rules part.
   For the Security Group bound to the Instances in the Public Subnet, use the following rules:

Type: HTTP
Protocol: TCP
Port range: 80
Source: Custom 0.0.0.0/0

Type: HTTPS
Protocol: TCP
Port range: 443
Source: Custom 0.0.0.0/0

Type: RDP
Protocol: TCP
Port range: 3389
Source: MyIP – your current external IP should be entered automatically

Create more Inbound Rules according to your needs.

After creating all the needed rules, click on Create security group to create it.

For the Security Group bound to the Instances in the Private Subnet, use the following rules:

Type: HTTP
Protocol: TCP
Port range: 80
Source: Custom 0.0.0.0/0

Type: HTTPS
Protocol: TCP
Port range: 443
Source: Custom 0.0.0.0/0

Type: RDP
Protocol: TCP
Port range: 3389
Source: Custom 0.0.0.0/0

Type: Custom TCP
Protocol: TCP
Port range: 1494
Source: Custom 0.0.0.0/0

Type: Custom UDP
Protocol: UDP
Port range: 1494
Source: Custom 0.0.0.0/0

Type: Custom TCP
Protocol: TCP
Port range: 2598
Source: Custom 0.0.0.0/0

Type: Custom UDP
Protocol: UDP
Port range: 2598
Source: Custom 0.0.0.0/0

Create more Inbound Rules according to your needs.

4. After creating all the needed rules, click on Create security group to create it.

You have successfully created all needed Security Groups. All necessary Network-related prerequisites have been created.
 

Deploy all needed Instances in your VPC

An Amazon EC2 Instance is a Virtual Machine in the AWS Cloud environment. Amazon EC2 provides a wide range of Instance types. You can choose an Instance type that provides the compute resources, memory, storage, and network configurations that meet your needs.

In this section, we will initially deploy the following Instances:

• (1) Jump Host for accessing the environment over the Internet using RDP
• (1) Domain Controller for providing all needed Active Directory functionalities
• (2) Cloud Connectors
• (1) Master Image from which the Machine Catalog(s) will be deployed

Further Instances will be created automatically during the Machine Catalog creation.

Creating the EC2 Key Pair

Before deploying Windows Instances, you must create a Key Pair to gain access to the Instance after it is created.

1. Log on to your AWS console, enter EC2 in the Search bar at the top of the page, and choose the Network & Security option. Click on Key Pairs on the Dashboard. If no Key Pair was already created, click Create key pair.
   
2. Choose the needed settings and click Create key pair.
   

Deploying the Jump Host Instance

For security reasons, our environment will be completely shielded and deployed in the already-created Private Subnet.
Administrative access to the Instances is only possible using a dedicated Jump Host Instance in the Public Subnet.

Select all Instance types according to your needs - you can find a detailed overview of all available Instance types on AWS product documentation:

 

1. Log on to your AWS console, enter EC2 in the Search bar at the top of the page, and choose the Instances option. Click on Launch instance on the Dashboard.
   
2. Choose all relevant settings for the new Instance, such as Name and Tags, AMI Type and AMI Image, Instance Type, Key Pair to log in, Security Group to which this Instance will be bound, and Storage configuration.
   Set advanced details according to your needs.
3. After choosing and setting all the needed information, click Launch instance to create the Instance.
   
   
   
4. After successful creation, the Jump Host Instance is listed on the Instances tab.
   

Connecting to the Jump Host Instance Instance

For security reasons, the Jump Host Instance is not Domain-joined. You need to log on to it using local administrator credentials.

As mentioned in the Key Pair section, you need an EC2 Key Pair to decrypt the administrator password.

1. To log on to the Instance, open the AWS console, enter EC2 in the Search bar at the top of the page, and choose the Instances option.
2. Mark the Instance you want to connect to and click on Connect.
   
3. Choose RDP client as the connection method and click Get password.
   
4. Now upload the mentioned Key Pair using Upload private key file. Click Decrypt password after uploading to get the administrator credentials.
   
5. Now you have the decrypted login information and can log on to the Jump Host Instance using RDP.
   

Deploying the Domain Controller Instance

We followed our standard deployment type for Domain Controllers in this environment.
The AD deployment consists of a Hub-and-Spoke model. Each Resource Location running on a Hypervisor/Hyperscaler is connected to the primary Domain Controller using IPSec-based Site-to-Site VPNs. Each Resource Location can have its subdomain if needed.

After the successful creation of the Domain Controller Instance, you can access it by:

1. Connect to the Jump Host Instance using RDP and log on using the Key Pair
2. Connect to the Domain Controller Instance using RDP from the Jump Host Instance

The Domain Controller and Replication Configuration is out of this guide's scope.
 

Deploying and Configuring the Cloud Connector Instances

At least two (2) Cloud Connectors are required to create a highly available connection between Citrix Cloud and your resource location. Depending on your environment and the workloads you support, you might need more Cloud Connectors to ensure the best user experience.

As a best practice, Citrix recommends using the N+1 redundancy model when determining the number of Cloud Connectors you need to deploy. Determine the number of Cloud Connectors you need in a resource location based on your environment, workloads, Active Directory configuration, and services.

After the successful creation of the Cloud Connector Instances, you can access them by:

1. Connecting to the Jump Host Instance using RDP and log on using the Key Pair
2. Connecting to the Cloud Connector Instances using RDP from the Jump Host Instance

Before deploying the Cloud Connector software, you must add the Cloud Connector Instances to the Domain. This step is outside the scope of this guide.

The Cloud Connector Instance is successfully registered in the Domain:

1. Log on to your Citrix Cloud Account.
   
2. Add a new Resource Location dedicated to your AWS deployment.
   
   
   
3. After creating the Resource Location, you must add the Cloud Connector Instances.
   Click the + to add the current Instance and download the Cloud Connector software installer.
   
   
   
4. After successfully downloading it, start it using administrative rights.
   Run the Advanced Connectivity Check. If the check completes, start the installation.
   
5. Sign in to Citrix Cloud and continue with the installation.
   
6. The installer asks in which Resource Location you want to put this Cloud Connector Instance. Choose the AWS-related Resource Location you just created.
   
7. The installation process takes several minutes, and after completion, the installer runs a thorough communication check.
   
   
   
   
   
8. After the installation completes, the Cloud Connector Instances can be seen registered in the adjacent Resource Location.
   

Deploying and Configuring the Master Image Instance

Image Management is an approach of creating a Master or Golden Image that contains the operating systems and all the required applications to deliver that single virtual image to multiple target virtual machines.
The key concepts behind this are reusability and simplified management, which allow the Citrix administrator to deliver the operating systems with the required set of applications to appropriate users based on their needs.

This guide uses Citrix Machine Creation Services (MCS) for Image Management. MCS connects Using Hosting Connections. In conjunction with the underlying hypervisor or cloud provider, MCS builds intelligent linked clones from a Master Image to provide multiple virtual desktops. The clones include a differencing disk and an identity disk linked from a base disk.

MCS configures, starts, stops, and deletes virtual machines using the Hosting Connections.

Machine Creation Services is a disk-based provisioning approach that works with major hypervisors and leading cloud platforms.

The Master Image Instance is a domain-joined Instance that requires all the software and applications mentioned above to deploy the Master Image Instance, but we recommend choosing another instance type, such as a t3.large installed, before deploying target machines.

Depending on the Master Image Instance’s operating system, you must download the suitable Virtual Desktop Agent (VDA) from the Citrix Homepage or install it from the Citrix Virtual Apps and Desktops-ISO file. If you use a Desktop OS, you must install the Workstation-type VDA. If you use a Server OS, you must install the Server-type VDA.
 

1. After downloading/mounting the installer, start the installation.  During the installation, the installer asks for configuration information – select the needed parts/configurations according to your needs.
   
2. As this installation runs on the Master Image Instance, select Create a Master MCS image and click Next.
   
3. Select all additional components to be installed according to your needs, and click Next.
   
4. During the creation of the Worker VMs, MCS will automatically register the Worker VMs on the Cloud Connector Instances, so select Let Machine Creation Services do it automatically.
   
5. As the Worker VMs are deployed on AWS, select "Is this VDA installed on a VM in the Cloud?" and click Next.
   
6. Select further components according to your needs. Click Next.
7. Now, the Installer takes a while to install the VDA. After completion, do not forget to run Citrix Optimizer – the Installer provides the link to more information.
8. Download Citrix Optimizer to the Master Image Instance. Click Finish.
9. Before running Citrix Optimizer, install the required software and components for the Worker VMs. In this example, the Worker VMs will provide LibreOffice as the primary Office suite for the users.
   
10. After installation of all software that is needed further, run the Citrix Optimizer tool.
    
11. Choose the correct Operating System to check all supported optimizations. Citrix Optimizer presents you with various optimizations – select/unselect these according to your needs and click on Optimize to start the process:
    
    
    
12. Optimization is complete.
    

Creating an Amazon Machine Image (AMI) based on the Master Image Instance

An Amazon Machine Image (AMI) is an image that provides the software that is required to set up and boot an Amazon EC2 instance. Each AMI also contains a block device mapping specifying the block devices to attach to the instances you launch. The AMI must be compatible with the instance type that you chose for your instance.

You can create an AMI from your Amazon EC2 instances and then use it to launch instances with the same configuration. You can copy an AMI to another AWS Region and then use it to launch instances in that Region.

1. The first step in creating the AMI is to set the Amazon EC2Launch settings according to your needs.
   
2. Choose the settings according to your needs, but click Shutdown without Sysprep.
   
3. Ensure the Master Image Instance is in a Stopped state before continuing.
4. Select the Master Image Instance in the dashboard. In the Actions pane, select Images and templates and click on Create image to convert the Master Image Instance into an AMI.
   
5. Set the AMI's configuration according to your needs, then click on Create image to start the creation process.
   
6. After successful completion, the new AMI is shown and can be used as the reference image for the Worker VMs. The Machine Creation Services will look for such AMIs to use.
   

All required prerequisites for deploying Citrix DaaS are completed.
 

Configure Citrix DaaS

The successful configuration of Citrix DaaS relies on many entities. You need to configure at least the following entities in the correct order to get a working DaaS environment:

1. A Host Connection and a Host Connection Resource Pool connect DaaS to a host (hypervisor or cloud service) in a Resource Location. Creating Host Connections and Host Connection Resource Pools is required to create and manage Worker VMs on Hosts or to power manage existing Worker VMs.
2. A Machine Catalog is a collection of identical Worker VMs, which can be virtual or physical, depending on your needs.
3. A Delivery Group: This contains machines from Machine Catalogs.
   It also specifies which users can use those Worker VMs and which Applications and Desktops are available to those users.
4. Citrix Policies: Citrix Policies are a collection of settings that define how sessions, bandwidth, and security are managed for a group of users, devices, or connection types.

Creating a Host Connection and a Host Connection Resource Pool

Configuring a Host Connection and a Host Connection Resource Pool involves selecting the connection type from the list of supported hypervisors and cloud services and choosing the appropriate storage and network resources.

1. Log on to Citrix Cloud WebStudio and open My Services -> DaaS.
   
2. Choose Hosting to configure a Hosting Connection and a Hosting Connection Resource Pool. Click on Add Connection and Resources.
   
3. Select Create a new Connection.
4. Choose the correct Zone – it should have the same name as the Resource Location you created earlier in this guide.
5. Choose the correct Connection type – Amazon EC2.
6. Enter the EC2 API key and the EC2 API secret you created earlier in this guide.
7. Enter a meaningful name and click Next to proceed.
   
8. Choose the correct AWS Cloud Region. Click Next.
   
9. Look at the EC2 Dashboard in which Region and Availability Zone the Instances are deployed.
   
10. Select the correct Availability Zone. Click Next.
    
11. Select the correct Subnet. Click Next.
    
12. Review your settings on the Summary page. Click Next.
    
13. The Host Connection and the Host Connection Resource Pool should now be deployed.
    It will take a while until the newly created entities are shown in the Hosting Dashboard.
    
14. To ensure both entities work fine, click More and choose Test the connection.
    Afterward, Test Resources will be used to run some tests.
    
    
    

Both entities were successfully deployed and worked as intended.
 

Creating a Machine Catalog

Collections of physical or virtual machines are managed as a single entity called a Machine Catalog. Within a Machine Catalog, all machines share a common operating system type, which can be either multi-session or single-session OS, such as Windows or Linux-based systems.

1. Log on to Citrix Cloud WebStudio and open My Services -> DaaS. Choose Machine Catalogs to create a Machine Catalog. Click on Create a Machine Catalog.
   
2. Click Next.
   
3. Choose the correct Machine Type based on your Master Image Instance.  Click Next.
   
4. Choose Machines that are power managed and choose MCS as provisioning technology.
   Select the correct Host Connection Resource Pool. Click Next.
   
5. Choose the Desktop Experience according to your needs. Click Next.
   
6. Choose the correct Image Type – in this case, we select Master Image.
   You can find more information about Prepared Image in our Citrix Tech Zone guide Image Management - A new way of deploying Machine Catalogs and reducing Master Image Complexity.
   
7. Select a Machine Template enables you to select the Master Image – Select the AMI you created earlier. Click Done.
   
8. If suitable, choose the Master Image Instance as a Machine Profile. A Machine Profile enables you to build all Worker Machines using the same hardware configuration. Click Done.
   
9. Choose the minimum functional level of the VDA – using the latest level supported by the VDA is recommended.
   Depending on your needs, apply Machine Tags. Click Next.
   
10. Choose the Number of VMs to create and select the Machine Specification. Click Next.
    
11. Choose the correct AWS Security Group and how the VMs should be deployed. Click Next.
    
12. Choose the correct AWS Subnet. Click Next.
    
13. Fill out all needed Active Directory-related settings according to your needs. Click Next.
    
14. Enter administrative credentials for Active Directory-related operations according to your needs. Click Done.
    
15. Click Next to proceed until reaching the Summary page.
    
16. Review the Summary and start the creation process.
    
17. Creating the Machine Catalog can take a long while depending on various parameters. You can see the progress in the pop-up window.
18. After successful creation, the newly created Machine Catalog is visible on the Dashboard.
    
19. Selecting the Machine Catalog and clicking on More enables you to get more details – e.g., for the VMs in the catalog, etc.
    
20. You should test all functions of the Machine Catalog by choosing Test Machine Catalog in the More pane.
    

A new Machine Catalog and new Worker VMs were successfully deployed and work as intended.
 

Creating a Delivery Group

A Delivery Group is a collection of machines selected from one or more machine catalogs.
The Delivery Group specifies which users can use those machines and the available applications and desktops.

1. Log on to Citrix Cloud WebStudio and open My Services -> DaaS. Choose Delivery Groups to create a Delivery Group. Click on Create Delivery Group.
   
2. Click Next.
   
3. You must choose how many unassigned VMs from which Machine Catalog should be assigned to this Delivery Group. Click Next.
   
4. Choose further settings according to your needs in the next pop-up windows and click Next to proceed.
   
   
   
5. You now can select if and which Applications can be published – click on Add if you want to publish Applications.
   
   
   
6. You can review your selection and add more Applications. Click OK.
   
7. You can also publish the entire Desktop of the Master Image Instance if needed. Click on Add if you want to publish the Desktop.
   
   
   
8. Enter all needed information for publishing according to your needs. Click Add to add AD users or groups.
   
9. Click Done.
10. In the next step, you can select more restrictive Security Features. Select them according to your needs, then click Next.
    
11. If you want to assign Scopes to this Delivery Group, choose the Scope according to your needs. Click Next.
    
12. Choose the correct License Assignment. Click Next.
    
13. Review all settings in the Summary pop-up. Add a comprehensive name and description for this Delivery Group. Click Next.
    
14. The Delivery Group is created. After successful creation, you can find the newly created Delivery Group in the Dashboard. Click on the tabs shown below the Dashboard to get more information.
    
    
15. Click on More to run the recommended tests.
    

You successfully deployed a Delivery Group, which works as intended.

That completes the mandatory steps for deploying Citrix DaaS on Amazon EC2.
 

Setting AutoScale for the Delivery Group

AutoScale provides a consistent, high-performance solution to power manage your machines proactively. It aims to balance costs and user experience. AutoScale incorporates the deprecated Smart Scale technology into Studio’s power management solution.
AutoScale enables proactive Power Management of all registered single-session and multi-session OS machines in a Delivery Group.

1. Log on to Citrix Cloud WebStudio and open My Services -> DaaS. ChooseDelivery Groups. Select the Delivery Group you want to configure and click Manage AutoScale. Click on the General tab for initial configuration.
2. Click on Enable AutoScale to enable it. Set all further configurations according to your needs.
   
    
3. By adjusting the Schedule(s) and Peak Times, you can configure when and how many Worker VMs will be pre-started and kept running.
   Adjust the settings according to your needs.
   
4. Defining the Load-based Settings ensures that spare Worker VMs are pre-started and kept running idle so that users can immediately start a session without waiting until a new Worker VM needs to be started. Adjust the settings according to your needs.
   
5. Remember to configure the User Logoff Notifications. AutoScale can start Worker VMs automatically and shut them down if necessary to reduce cost.
   Adjust the settings according to your needs.
   

Test User Access to this Environment

1. It is vital to test User connectivity before enrolling Users. Log on to your environment using Citrix Workspace App using User credentials assigned to this environment.
2. Check if all assigned Applications and Desktops are available, and launch your desktop.

Summary

Deploying Citrix DaaS on Amazon EC2 is straightforward. However, all prerequisites must be fulfilled on both the Amazon EC2 and Citrix DaaS sides.

We have shown examples of creating all the needed entities and configurations to deploy a working Citrix DaaS environment running on Amazon EC2.

For further DaaS configurations, such as creating Policies, creating Delegated Administration, enabling Configuration Logging, etc., please consult the corresponding parts of the Product documentation.