AWS Local Zones are a great way to get low-latency connectivity to AWS, even when you’re not close to a larger regional datacenter cluster. This is a great benefit for high-resolution or graphic intensive apps or apps that require data from an on-prem source! New Local Zones are being added with increased frequency as they grow in popularity. Because these zones are new, they’re based on the AWS Nitro architecture for enhanced efficiency and scalability.

Want to keep your data closer to home? Worried about performance with CPU intensive apps? You can deploy Citrix Virtual Apps and Desktops on AWS Local Zones, bringing your compute and storage closer to the user, with just a few simple steps.

When setting up a Citrix deployment in a Nitro-based Local Zone, there are a few things you’ll need to consider. (For more information on each of these steps, check out my previous blog posts.)

Make Sure the Zone You Choose Is the Right One for You

In AWS Local Zones, the instance types and services vary by zone.  Be sure to check AWS documentation as you begin your design to make sure that your chosen zone accommodates the instance types and services that you require. Depending on the instance types available, you may need to adjust your InstanceTypes.xml file and the instance type of the MCS volume worker. Additionally, if you are planning to use AWS services such as FSx, EBS, or RDS in your Citrix implementation, double check that they are available in your Local Zone.

  • Instance types can be updated by modifying the InstanceTypes.xml file in the C:\ProgramFiles\Common Files\Citrix\HCLPlugins\Hypervisor\2.27.0.0\AWS\AWS Configuration\InstanceTypes.xml location. Please note, t3 instance types are in each of the Local Zones at the time of this writing and were used for the testing that led to this blog post.

  • To change the instance type of the volume worker to a Nitro-based instance, set this value in the Advanced Configurations of the host connection, but make sure that the instance type you choose is available in your Local Zone.

VolumeWorkerInstanceType=t3.xlarge

Creating an App or Desktop Image

When you create an app or desktop image, you must first:

  1. Enable the Local Zone from the EC2 Dashboard, under “Account attributes,” choose “Zones.”
  2. Choose your Local Zone, and click “Manage” to enable it.
  3. Create a host connection with the Local Zone resource.
  4. In the AWS console, create a subnet in your VPC that corresponds to your Local Zone. (VPCs used will need to be in the same region as the desired Local Zone.)
  5. Create an instance in the Local Zone and install the VDA and all required apps, etc.
  6. Convert the gold image instance into an AMI.

Changing the MCS Volume Worker Template

EBS volumes on Nitro-based instances are exposed as Non-Volatile Memory Express (NVMe). For Local Zones, you have to change the MCS volume worker template to account for the drive mappings. Here’s how you can create a new volume worker and configure MCS to use that AMI as the default volume worker. The region name will be the parent region.

Choose an Amazon Linux AMI that is EBS-backed from the AWS Marketplace and launch it in the Local Zone. Log in to the instance with PuTTY using the public IP address and your AWS private key that the instance was made with, in .ppk format. At the key prompt, click the “Yes” button.  When the CLI comes up, enter the username as “ec2-user” and you’re in!

We need to modify the rc.local file with the new drive mappings for NVMe block storage by creating symbolic links at boot:

sudo vi /etc/rc.d/rc.local

Click “I” to edit the file. Use the d-pad or down arrow key to move down past the “touch /var/lock/subsys/local” line and add the following:

ln -snf /dev/nvme1n1 /dev/nvmf
ln -snf /dev/nvme1n1p1 /dev/nvmf1
ln -snf /dev/nvme2n1 /dev/nvmg
ln -snf /dev/nvme2n1p1 /dev/nvmg1
ln -snf /dev/nvme3n1 /dev/nvmh
ln -snf /dev/nvme3n1p1 /dev/nvmh1
ln -snf /dev/nvme4n1 /dev/nvmi
ln -snf /dev/nvme4n1p1 /dev/nvmi1
ln -snf /dev/nvme5n1 /dev/nvmj
ln -snf /dev/nvme5n1p1 /dev/nvmj1
ln -snf /dev/nvme6n1 /dev/nvmk
ln -snf /dev/nvme6n1p1 /dev/nvmk
ln -snf /dev/nvme7n1 /dev/nvml
ln -snf /dev/nvme7n1p1 /dev/nvml
ln -snf /dev/nvme8n1 /dev/nvmm
ln -snf /dev/nvme8n1p1 /dev/nvmm1
ln -snf /dev/nvme9n1 /dev/nvmn
ln -snf /dev/nvme9n1p1 /dev/nvmn1
ln -snf /dev/nvme10n1 /dev/nvmo
ln -snf /dev/nvme10n1p1 /dev/nvmo1
ln -snf /dev/nvme11n1 /dev/nvmp
ln -snf /dev/nvme11n1p1 /dev/nvmp1

Once you have entered the required text, press “Escape” and the type “:wq!” (no quotes) and “Enter.”

Once you’ve exited vi, change the permissions on this file to ensure that it will run at boot:

sudo chmod +x /etc/rc.d/rc.local

Reboot the machine and ensure that these changes have persisted (just enter the vi command again once the machine comes back up).

Power down the instance and create an AMI from it. Then just substitute your new AMI ID for the one above and run the PoSh command on the Delivery Controller.

Set-HypVolumeServiceConfiguration -VolumeServiceConfigurationName SiteDefault -ConnectionType AWS -RegionName us-east-1 -BaseLinuxTemplateId ami-xxxxxx

Once you’ve completed these simple steps, you can kick off your Machine Catalog build as normal.

Now, you’re all set to run your high-intensity apps in the cloud or keep your data close to your users with Citrix Virtual Apps and Desktops on AWS Local Zones! If you are using AWS Local Zones for data residency purposes, always be sure to consult with compliance and security teams, as data residency requirements vary by jurisdiction. Have more questions about AWS Local Zones? Be sure to check out the FAQ.