e360 Blog

AWSome Virtual Apps and Desktops with Citrix MCS

Written by Shadab Jamal | Aug 14, 2025 11:15:20 PM

Because who doesn’t need another way to deploy virtual apps and desktops in the AWS Cloud?

 

Overview: Welcome to the newest way to deploy Citrix Virtual Apps and Desktops in AWS  

Let’s face it - if there’s one thing IT folks love more than solving problems, it’s being presented with multiple, viable ways to solve the same problem. 

Enter: Citrix MCS for Amazon WorkSpaces Core—yet another (actually awesome) way to spin up Citrix based virtual apps and desktops in the cloud. But this isn’t just another VDI flavor-of-the-month. It’s a legit, cost-effective, and cloud-native combo move from Citrix and AWS that makes virtual app and desktop deployments smoother, simpler, and far less likely to end in a coffee-fueled midnight panic. 

So buckle up, cloud wranglers. This is your guide to the latest deployment option you didn’t know you needed. 

 

The Great Citrix-on-AWS Showdown: Deployment Models 

Yes, there’s more than one way to deploy Citrix in AWS. And yes, each one has its quirks, benefits, and potential to either make you look like a genius—or have you Googling IAM policies at 2 a.m. 

  1. MCS for AWS EC2
  • AKA: “The OG Way” 
  • Pros: All the control you could ever want. Full access to EC2. Custom images, deep configs. 
  • Cons: You get to manage everything. Like... everything. Enjoy your new part-time job as an EC2 babysitter. 
  1. Citrix MCS for Amazon WorkSpaces Core
  • AKA: “The New Shiny Toy” 
  • Pros: Lower cost. BYOL support. Non-persistent or dedicated VDI. AWS handles the infrastructure. Fewer headaches. No need to nurture EC2 like a houseplant. 
  • Cons: You can’t tweak everything. But ask yourself: Should you be tweaking everything? 
  1. Quick Deploy for Amazon WorkSpaces Core Bundles
  • AKA: “Not a One-Click Wonder” 
  • Pros: Blink and you’re deployed (yeah right).  No good pros that I can see.  
  • Cons: Supports Persistent VMs only.  No Linux support. 

 
 
The table below breaks down all three Citrix in AWS deployment options 
 
 

 
Prerequisites: What You Need Before You Start Clicking Stuff 

Before you dive into the deep end, here’s what you’ll need to avoid creating a cloud-native mess: 
 
Citrix Cloud (DaaS) Subscription 

  • Contact e360 or your authorized Citrix reseller if you don’t already have a Citrix Cloud Subscription 

VPC (Virtual Private Cloud) configured in AWS 

  • Deploy private and public subnets along with a NAT gateway and internet gateway 
  • Private subnets default route should be out the NAT gateway while public subnets default route should be the internet gateway 
     

Cloud Connectors in AWS 

  • Deploy them in the same AWS region where your virtual apps and desktops will be hosted out of. 
  • Don’t forget to attach the custom IAM Role to your EC2 instance, or enjoy hours of “why isn’t this working?” diagnostics. 

 

IAM Setup 

  • Get an IAM Access Key or create an IAM Role within your AWS Account. 
  • Reminder: Permissions are like duct tape—apply them carefully or things will fall apart. 

Enable the AWS Service-Linked Role 

  • Because Citrix Cloud isn’t psychic—it needs permission to do its thing.  This is a one button click in the “Workspaces” console within AWS.  

Master Image Prep 

  • Deploy your image in EC2 as an instance and then convert to an AMI.  You can choose to deploy a server-based OS from the AWS Marketplace or perform Windows ISO to AMI ingestion using the EC2 Image Builder Service if you require Windows 10/11. 
  • Install the Citrix VDA on the master image with MCS/IO enabled. 
  • Bonus tip: Test it. Because nothing says “fun” like finding out your base image is broken... after provisioning 50 machines. 

 

Deployment: Now the Real Fun Begins 

Here’s where we make stuff happen. And yes, we’ll have screenshots to prove we did it and most importantly, that it actually works! 😊 
 

Step 1: Create a Custom IAM Role 

  • Create the IAM Role via the IAM console in your AWS account.  The permissions required are documented in the Appendix Section. 
  • This role needs just enough power to provision desktops without opening your AWS account to the entire internet. 
  • Attach the role to your Citrix Cloud Connector instances in EC2 by choosing “Modify IAM role” 
     
     
     
  • Pro tip: Use the principle of least privilege... not the principle of “just give it admin and we’ll fix it later.” 
     

Step 2: Create a Hosting Connection in Citrix Cloud (DaaS) 

  • Select Amazon WorkSpaces Core as your hosting type. 
  • Paste in your IAM Role details like a pro. 

 

 
 
Next, give your Network section a descriptive name and choose two private subnets within your AWS VPC.  
 
 
 
 
Note: If you're unsure of which subnets in your VPC are private vs. public, you can go to VPC within your AWS account and scroll down to Resource Map.  The resource map will give you a nice visual of which subnets are public and which are private along with the associated routing tables. 
 
 
 
 
Choose the default options for “Scope”.   Then, review the Summary screen and if all looks good, click Finish.  
 
 
 
 
It will take a couple of minutes for your new hosting connection to initialize but once complete, it will be displayed as shown below. 
 
 
 
 

Step 3: Create Master Image Definition and Version 

  • Select your perfect AMI (you did test it, right?). 
  • Tag it, name it, love it. This is the base of your entire deployment—don’t mess it up. 
  • An image definition is a logical grouping of image versions, carrying information such as the OS type of the master image and its support for multiple or single sessions. It defines a particular type of images. 
     
     
     
     
     
     

Here you’ll define whether or not you will be deploying Multi-Session (Server OS) or Single-Session (Desktop OS) 
 
 

Select a Machine Template.  This is the AMI (Amazon Machine Image) that you created after deploying the Citrix VDA on the master image within EC2. 
 

 

  
Select the Master Image and Machine Profile.  Verify the Machine Specification and NICs options and begin creation of the image definition. 
 

 
 
 

The image definition will take approximately 30-45 minutes to be created. 
 
 
 
 
 
 

 

While the image definition is being created, on the AWS side you will see an MCS Preparation VM being created within EC2.    
 
 

 
 
 
 
 
Once the image definition creation is complete, you should see the details in the version as shown below.  
 
 
 
 
 
 

Step 4: Create Machine Catalog and Delivery Group 

  • Tie everything together and assign users within Citrix Cloud (DaaS). 
  • Sit back and enjoy that moment where it all... just works (fingers crossed). 
     

 

Create the machine catalog and choose Citrix MCS for the provisioning technology.   Choose the AWS resources created as part of the hosting connection setup. 
 
 
 
 
Select the Image. 
 
 
 
 

Choose the image version. 
 
 
 
 
Click Next. 
 
 
 
 

Choose the Machine Specifications.  By default, it will read the specs of your master image’s instance type.   
 
 

  
Confirm the NIC ID and subnet info. 

 
 


Create new Active Directory accounts.  Specify the OU on where these computer accounts will be stored along with the machine account naming scheme. 
 
 

  
Specify credentials of an AD user that has permissions to create and reset computer accounts.  You may also choose to specify a Service Account. 

 
 

  

Click finish for your Machine Catalog to be created.  
 
 

 

 
 

  

Once the machine catalog is successfully created along with the machines in EC2, they will be powered off by default unless you manually start them or they will automatically start when you create the Delivery Group within Citrix DaaS and attempt to add Applications.    
 
Tip: I recommend manually powering on at least one VDA so that it could register with the Cloud Connector and you can add applications swiftly during the delivery group creation process.  
 
 
  
 


Create the Delivery Group. 
 
 
 

  

Assign the AD user group(s) required, add the applications ( if multi-session) and Desktops. 
 
 

 

 

After the Delivery Group creation is complete, you can right click on the Delivery Group and choose “View Machines” to ensure that the registration state of the machines displays as “registered”.  
 

 
 

 

Lessons Learned: AKA “Stuff We Broke So You Don’t Have To” 

  1. IAM Policies Are Not Optional: Don’t copy-paste from random blogs. You’ll regret it. 
  1. Clean Images = Clean Deployments: Save yourself a headache and test the AMI before using it. Twice. 
  1. Managed Instances Are a Hidden Gem: Less overhead, fewer surprises, and they’re shockingly stable. 
  1. Cost Optimization is Real: Especially if you're still running 24/7 EC2 workloads like it’s 2012. 
     

 

Final Thoughts: Welcome to Your Cloud-First Era 

Citrix MCS for Amazon WorkSpaces Core isn’t just a shiny new toy, it’s a serious evolution in how we deliver Citrix virtual apps and desktops from the AWS cloud. It brings Citrix control together with AWS simplicity and cost efficiency, creating a solution that makes sense. 

So if you’ve been putting off your cloud VDI strategy because it was “too complicated,” well… time’s up. You’ve got a new option. It works. It scales. And it might just make you look like a rockstar in your next ops review. 
 



 

Appendix:  
 
Minimal IAM Permissions: 
{ 

    "Version": "2012-10-17", 

    "Statement": [ 

        { 

            "Action": [ 

                "ec2:AttachVolume", 

                "ec2:AssociateIamInstanceProfile", 

                "ec2:AuthorizeSecurityGroupEgress", 

                "ec2:AuthorizeSecurityGroupIngress", 

                "ec2:CreateImage", 

                "ec2:CreateLaunchTemplate", 

                "ec2:CreateNetworkInterface", 

                "ec2:CreateTags", 

                "ec2:CreateVolume", 

                "ec2:DeleteLaunchTemplate", 

                "ec2:DeleteNetworkInterface", 

                "ec2:DeleteSecurityGroup", 

                "ec2:DeleteSnapshot", 

                "ec2:DeleteTags", 

                "ec2:DeleteVolume", 

                "ec2:DeregisterImage", 

                "ec2:DescribeAccountAttributes", 

                "ec2:DescribeAvailabilityZones", 

                "ec2:DescribeIamInstanceProfileAssociations", 

                "ec2:DescribeImages", 

                "ec2:DescribeInstances", 

                "ec2:DescribeInstanceTypes", 

                "ec2:DescribeInstanceStatus",  

                "ec2:DescribeLaunchTemplates", 

                "ec2:DescribeLaunchTemplateVersions", 

                "ec2:DescribeNetworkInterfaces", 

                "ec2:DescribeRegions", 

                "ec2:DescribeSecurityGroups", 

                "ec2:DescribeSnapshots", 

                "ec2:DescribeSubnets", 

                "ec2:DescribeTags", 

                "ec2:DescribeSpotInstanceRequests", 

                "ec2:DescribeInstanceCreditSpecifications", 

                "ec2:DescribeInstanceAttribute", 

                "ec2:GetLaunchTemplateData", 

                "ec2:DescribeVolumes", 

                "ec2:DescribeVpcs", 

                "ec2:DetachVolume", 

                "ec2:DisassociateIamInstanceProfile", 

                "ec2:RebootInstances", 

  

                "ec2:RunInstances", 

                "ec2:StartInstances", 

                "ec2:StopInstances", 

                "ec2:TerminateInstances" 

            ], 

            "Effect": "Allow", 

            "Resource": "*" 

        }, 

        { 

            "Action": [ 

                "ec2:CreateSecurityGroup", 

                "ec2:DeleteSecurityGroup" 

            ], 

            "Effect": "Allow", 

            "Resource": "*" 

        }, 

        { 

            "Action": [ 

                "ebs:StartSnapshot", 

                "ebs:GetSnapshotBlock", 

                "ebs:PutSnapshotBlock", 

                "ebs:CompleteSnapshot", 

                "ebs:ListSnapshotBlocks", 

                "ebs:ListChangedBlocks", 

                "ec2:CreateSnapshot" 

            ], 

            "Effect": "Allow", 

            "Resource": "*" 

        }, 

        { 

            "Effect": "Allow", 

            "Action": [ 

                "kms:CreateGrant", 

                "kms:Decrypt", 

                "kms:DescribeKey", 

                "kms:GenerateDataKeyWithoutPlainText", 

                "kms:GenerateDataKey", 

                "kms:ReEncryptTo", 

                "kms:ReEncryptFrom" 

            ], 

            "Resource": "*" 

        }, 

        { 

            "Effect": "Allow", 

            "Action": "iam:PassRole", 

            "Resource": "arn:aws:iam::*:role/*" 

        }, 

        { 

            "Effect": "Allow", 

            "Action": [ 

                "workspaces-instances:*" 

            ], 

            "Resource": "*" 

        } 

    ] 

} 
View full post