Amazon Workspaces Pools , it augments the lineup by providing non-persistent desktops in the cloud. 

Amazon Workspaces Pools and FSXlogix offer a cost-effective solution for creating non-persistent virtual desktops, enabling businesses to maximise efficiency while minimising costs. 

By leveraging Workspaces Pools and FSXlogix, organisations can achieve a near-persistent VDI experience at a fraction of the cost compared to other solutions.

Why would a business select Amazon Workspaces Pools? 

There are two primary reasons:

• Cost-Effectiveness: Workspaces Pools allow businesses to share a pool of non-persistent virtual desktops across multiple users, making it an ideal choice for remote workers, task-oriented teams (such as shared service centres, finance, procurement, and HR), contact centre employees, and students.

• Increased User Density: Businesses of all sizes can benefit from advanced infrastructure that simplifies rapid desktop deployment and management whilst enhancing operational efficiency.

This approach is recommended for a consistent user experience (regardless of their access point), increased data security, flexible operating system deployment (without licensing complications and compatibility across various devices) and of course, reduced operating costs whilst increasing density. 

In terms of a price-to-value ratio, this offering greatly reduces the cost-to-serve when compared to Amazon Workspaces Personal, Amazon Workspaces Core and other VDI solutions (Citrix, , etc). 

However, there are tradeoffs, mainly because as soon as you log out, you lose everything. In this post, we will illustrate that with a bit of extra effort, we can smooth off these rough edges so that these tradeoffs aren't noticeable.

As usual, let's start with an end-to-end demo of what this post will build out.

https://youtu.be/abXCzUsUsms?v2_embed=true

I recently had the opportunity to build out a production-ready Amazon Workspaces Pools environment, and in this post, I am going to walk you through at a high level the process of setting up Amazon Workspaces Pools utilising Okta as an IdP (Identity Provider). 

This post won’t include everything you need to do to take this to production (such as Active Directory / Scaling / Monitoring / Automation / Custom Images) but will enable you to get started with the core functionality with as an IdP.

Amazon Workspaces Pools vs. any other VDI offering is complex (like many AWS offerings), but once you understand the setup and configuration process, you will find that the solution offers a level of usability-to-price ratio that is unmatched.

Pricing of Amazon Pools can be found .

I just spoke about tradeoffs, and there is no escaping the fact that these sessions are non-persistent, so as a bonus I will illustrate how you can accomplish setting persistence of user settings using Microsoft using FSXlogix, providing you extremely cost-effective partially persistent desktops in the cloud.

I will break this post down into the following steps.

• Okta Configuration - Part 1 - Application Creation & Base Configuration

• IAM - Identity Provider Creation

• Amazon Workspaces Pools - Directory Creation

• Amazon Workspaces Pools - Pool Creation

• AWS IAM - Wiring Everything Together

• Okta Configuration - Part 2 - Adding WorksSpaces Configuration

• Enabling Session Persistence

• Testing

Amazon Workspaces Pools, whilst being part of the Amazon Workspaces family, is loosely based on Amazon AppStream 2.0, and I mention this because in order to use Amazon Workspaces Pools, you need to use aSAML 2.0 authentication provider such as Okta, Auth0, Entra ID and so on. Unlike Workspaces Personal, Workspaces Pools does not support local authentication.

Okta Configuration - Part 1 - Application Creation & Base Configuration

Okta configuration will need to take place in two parts. As of now, we don't have all of our Amazon Workspaces Pools Directory configuration details, IAM roles and other data to pass into Okta, but we do need the idP MetaData that’s generated by creating a SAML 2.0 configuration which we need to import into AWS IAM so that we can build out our solution.

Sign in to your organisation’s Okta environment.

Once logged in to Okta, select Applications and Create App Integration, this will result in a pop-up. Select SAML 2.0 as the application type and click Next.

Give your App Integration a Name (I called mine Amazon Workspaces Pools) and a logo (optional) and click Next.

On the SAML 2. 0 integration page enter data in the following fields, for all other fields accept the defaults.

Click Next and then Finish

After you are returned back to the main page, scroll down to the SAML Signing Certificates section, select Actions on SHA-2 and select View IdP metadata. This will result in a new window, save the page as XML (nothing the name of the file is not important).

From here, we will pivot into AWS, but we will keep Okta open as we return.

IAM - Identity Provider Creation

Login to your AWS Account and go to IAM (Identity & Access Management). From the left-hand menu tree, under Access Management, select Identity Providers from the left-hand menu tree.

Select Add Provider, select SAML as the provider type, enter a descriptive name for the Provider Name (I chose Okta_Amazon_Workspaces) and select the xml file you saved earlier from Okta as the Metadata document. Finally, click Add Provider.

This will add the provider (for 10 years) and you can click through to see the SSO Service Location and Issuer URL, which will have a relationship to your Okta account.

Amazon Workspaces Pools - Directory Creation

A directory is a prerequisite for creating an Amazon Workspaces Pool. By setting up identity federation using SAML 2.0 with Okta we will use an IAM role and relay state URL(we need to apply this in Okta) to grant your federated users access to a WorkSpace Pool directory. 

The relay state is the WorkSpaces directory endpoint to which users are forwarded after successful authentication in Okta.

It is worth noting when authoring this post (October 2024), whilst the console makes it known that 'Active Directory Config' is optional. If you choose not to enter the Active Directory details, you can not edit this later (not even from the AWS CLI), it will require termination of the directory and re-creation (which has cascading configuration changes). 

Worth taking into consideration and something I hope Amazon will change in the future. You can not use placeholder credentials in this field, as the Workspaces Pool will fail to start if the Active Directory configuration is invalid.

Before you enter values, switch back to Okta, as we need to extract the User Access URL for our directory. To do this, edit your application. Click Sign On and then View SAML setup instructions.

Copy the Identity Provider Single Sign-On URL and Identity Provider Issuer values to a text editor and switch back to the AWS Workspaces Directory (Pooled) in your browser.

Whilst some fields are optional, the following require values.

After your directory is created, copy the Directory ID and Registration code to your text editor.

Amazon Workspaces Pools - Pool Creation

After creating your directory, select Pools from the left menu and Create Workspace. This article will not cover scaling policies for Workspaces Pools as this is already well documented. If you’re interested, you can read about it . The only values you need to enter are as follows:

Worth noting there is a 1:1 mapping between pools and directories at this point in time, meaning that if you have multiple Workspaces Pools, you will also need multiple Workspaces Pools Directories (even if you have the same users in them - feature request Amazon).

Click through your pool details, and there are a lot of settings you can modify, from scaling to timeouts and more.

AWS IAM - Wiring Everything Together

AWS IAM is the glue to ensuring Okta, your Amazon Workspaces Directory and the Amazon Workspaces Pools all are able to communicate for authorisation and authentication in the least privileged manner.

In this step we will create a Role, Policy and a Permissions Policy

In the AWS Console go to IAM. Choose Roles in the navigation panel.
Choose Create role.
Choose SAML 2.0 federation for the trusted entity type.
For the SAML 2.0-based provider, choose the identity provider you created earlier, it should be in the drop-down box. Choose Allow programmatic access only for the access to be allowed.

Choose SAML:aud for the attribute. For Value, enter https://signin.aws.amazon.com/saml. This value restricts role access to SAML user streaming requests that include a SAML subject type assertion with a value of persistent.

Choose Next to continue. Don't make changes or selections in the Add Permissions page.

Enter a name and a description for the role.

Choose Create role. In the Roles page, choose the role you must created. Choose the Trust Relationships tab. Choose Edit Trust Policy.

In the Edit Trust Policy JSON text box, add the sts:TagSession action to the trust policy. When finished your trust policy should look similar to this.

Choose Update Policy.

We now need to craft a permissions policy.
Choose the Permissions tab.
In the Permissions policies section of the page, choose Add Permissions and then choose Create Inline Policy.

In the Policy Editor section of the page, choose JSON. In the Policy Editor JSON text box, enter the following policy. Be sure to replace:

• <region-code> with the code of the AWS Region in which you created your WorkSpace Pool directory

• <account-id> with the AWS account ID.<directory-id> with the ID of the directory you created earlier.

Choose Next.

Enter a name for the policy, and then choose Create Policy.

Phew, that’s a lot to take in and that’s all we need to do in AWS IAM, we will now need to pivot back to Okta.

Okta Configuration - Part 2 - Adding WorksSpaces Configuration

Having configured Amazon Workspaces Pools our Amazon Workspaces Pools Directory and IAM, we are now armed with configuration data that we can use to complete Okta configuration.

Log back into your Okta account and edit the application you created in Part 1 of our Okta configuration.

Edit SAML Settings

Click Next to move to Configure SAML. Edit SAML Settings so that they read as follows. Worth noting

• Default Relay State - replace the region end point, you can find them along with your AWS Workspaces Directory registration code when editing the table below

You will also need to add in SAML Attribute Statements, whilst listed as optional, they are required. Worth noting

• The first statement will require you to gather the ARN's of both the IAM role that was created along with your Okta identity provider. These values will be a string separated by a comma.

• Values are sensitive (userName & user.email)

Finally add your assignments to this application.

Enabling Session Persistence

Session persistence is not supported with Amazon Workspaces Pools, because of this, it really reduces the viability of offering virtual desktops in the cloud using just Amazon Workspaces Pools. 

If one is to use Amazon Workspaces Personal, the cost-to-serve will increase by many factors. Just like one would externalise the session state to a persistence store (Dynamo DB / Amazon S3) in web applications, we can redirect our session state and other key functions using Microsoft FSLoigix.

enhances and enables a consistent experience for Windows user profiles in virtual desktop computing environments. 

FSLogix isn't limited to Azure, it works on Amazon Workspaces Pools by redirecting folders that you specify to a SMB share. Using Group Policy we can apply this to user profiles, effectively redirecting folders to a SMB share.

This way, on session login user settings are copied back over. This guide will not go into detail on how to setup FSLogix but you can see the setup instructions at along with the Group Policy Templates at I suggest redirecting %USERPROFILE% and any other folder on the Workspaces instances pertaining to user state.

Testing

If you have followed this guide, you are now ready to test. Go to your end-user dashboard in Okta and select your Amazon Workspaces Pools Application. This should invoke Amazon Workspaces Pools, connecting to the relay state you defined in Okta.

If you have the Amazon Workspaces client installed you will notice that the registration key has been passed in.

Just note, that if this is the first time you have logged in, there will be a cold start of a few minutes while the underlying infrastructure is being created.

Summary

Amazon Workspaces Pools provides a powerful, flexible, and secure virtual desktop solution that drives business value by significantly reducing costs whilst increasing user density, improving user experience and optimising resource utilisation.

It provides a cost-effective VDI solution, but in its standard form, it can be quite hard to operationalise with very few use cases (kiosks, labs, etc).

Whilst we’ve covered a lot in this beginner’s guide, there is still so much more to do (Active Directory, Group Policy, Scaling and more), but this should be a helpful guide to get you started.

Learn from our experience and let me walk you through the process of Okta integration, along with illustrating how you can add session persistence in the form of Microsoft FSLogix to make Workspaces Pools really usable.