Since we launched Amazon WorkSpaces in March 2014, customers have been migrating their traditional Virtual Desktop Infrastructure or deploying new VDI workloads to the service, enabling them to build scalable, secure and cost-effective cloud-based desktops. This service enables them to pay either monthly or hourly, just for the WorkSpaces they launch, which helps saving money when compared to traditional desktops and on-premises VDI solutions while offloading to AWS all the complexity of managing and maintaining this type of environment. It is designed to provide users with access to their documents, applications, and resources wherever they are, anytime, and from any supported device.

Customers using Amazon WorkSpaces, usually start with specific use cases, for example, providing a corporate connected desktop to employees and external contractors. This approach helps enterprises with leveraging Bring Your Own Device (BYOD) strategies as well as with providing users with a powerful desktop, that could even be GPU enabled, without having to purchase and manage expensive physical hardware.

As customers get comfortable with Amazon WorkSpaces, they start noticing that they can take advantage of the service benefits for virtually any corporate desktop use case. Soon, Amazon WorkSpaces begins to be used at all corporate levels, from engineers and developers to executives and directors.

Amazon WorkSpaces is designed to provide high levels of availability, although you can consider a DR (Disaster Recovery) strategy that can help maintaining the WorkSpaces available for your key users, in an unlikely event of an AWS region or the WorkSpaces service becomes unavailable for a period of time.

In this article, I am going to share a “warm standby” DR strategy that I helped one of my customers architect and code, therefore this is a real-life example.

This strategy helped this customer maintaining the Recovery Time Objectives (RTO) and Recovery Point Objectives (RTO) required by their business, while keeping costs low.

Scenario Architecture

The architectural design bellow describes this scenario.

In this scenario we can find:

• A connection between the corporate on-premises environment and AWS through VPN or AWS Direct Connect.
• Amazon WorkSpaces is provisioned with credentials from a corporate domain connected to AWS through AWS Directory Service with AD Connector, pointed to a EC2 based Domain Controller or from a domain based on AWS Directory Service Managed AD with an EC2 instance joined to it.
• The company provides WorkSpaces for their existing Active Directory users. The AD infrastructure is extended into AWS with a member Domain Controller or a Windows instance joined to the domain, running on Amazon EC2.

Solution Overview

This solution is designed to create your WorkSpaces instances in a DR region, in the same or a different AWS account, in “AutoStop” running mode, and continuously check if users are created or removed from the Active Directory Organizational Unity (OU) that you chose to keep your WorkSpaces users. This way, if users are moved or deleted from the OU, the solution will terminate or create their respective WorkSpace and keep existing WorkSpaces instances only for active users in the DR region.

In case the AWS region or Amazon WorkSpaces becomes unavailable in your production environment, users can be directed to use the registration code, in the Amazon WorkSpaces client, to connect to the DR region WorkSpaces instances and continue to work normally.

You can choose to place only your key users in the OU you specify for this solution. In this way you can have a reduced cost and keep your most important users always productive at the same time.

Deploying this solution builds the components highlighted in red and integrates them with the resources shown below:

This solution uses AWS CloudFormation to automate the deployment of the following components in the DR region:

• An Amazon S3 bucket to store the CSV files containing an updated list of the Amazon WorkSpaces users, extracted from the Organizational Unity (OU) you specify when instantiating the CloudFormation template.
• A Systems Manager – Maintenance Window, with an associated Task, that runs every 5 minutes. The task has a PowerShell script that extracts the username of the users in the specified OU, into a CSV file, and upload it to the Amazon S3 bucket.
• An AWS Lambda function, triggered once a new CSV file is uploaded. It will read the CSV file containing the AD user list, and compare with the current WorkSpaces instances. If a user that exists in the AD user list does not have a WorkSpace, it will create one for it. In case a WorkSpace is created for a user that does not exist in the AD user list, it will be terminated. In this way it will keep WorkSpaces only for active users.
• All necessary IAM Roles and Policies needed to make the solution work, following least privilege principles.

The cost of this solution is composed by AWS Systems Manager comes with no additional cost, files stored in Amazon S3, which in this case are pretty small, and AWS Lambda, which is very cost-effective in this scenario.

Regarding preexisting resources, you may consider the cost of the Domain Controller or member server, running on EC2, which will depend on the instance type chosen.

AD Connector cost will depend on the directory size.

If you use AD Connector, as long as you have at least one active WorkSpaces attached to small directories or at least 100 active users for large directories each month, AD connector will have no additional cost.

In case you use Microsoft AD, pricing will depend on the size of the directory and region.

The WorkSpaces cost will depend on the bundle size and number of WorkSpaces provisioned. As the running mode utilized in this solution is “AutoStop”, the cost will be reduced from that aspect as well.

Prerequisites

The following components are prerequisites in the DR region:

• A Domain Controller or member server, on-premises or on Amazon EC2, joined to your Active Directory domain, on-premises or on AWS Directory Services. This instance has to be managed by AWS Systems Manager.
• An AD Connector or Managed AD registered for WorkSpaces. These components must be configured with subnets in Availability Zones supported by Amazon WorkSpaces in the region as well as with enough capacity to support the number of instances you intend creating. If you are unsure on which Availability Zones to use, please open a Support Ticket and AWS Support can confirm help confirming that information.
• Your AWS account must have its limits set to the Bundle type and number of WorkSpaces you intend creating in the DR region. Please open a Support Ticket in order to set these limits accordingly.
• A WorkSpaces image and bundle configured with the expected corporate image characteristics, available in the DR region. If you have a custom image that you use in your production AWS region, you can copy a custom WorkSpaces image within or across AWS Regions using the console.
• Your Active Directory should contain your Amazon WorkSpaces users in a separated Organizational Unity (OU).

If run your own images on Amazon WorkSpaces, please work with AWS Support and your AWS account team to make sure you have enough dedicated capacity in the DR region.

Deployment Process 

1. Sign in to the AWS Management Console and choose the region you would like to use for the DR environment.
2. Click the button below to view the AWS CloudFormation template and launch the WorkSpaces multi-region DR solution through the AWS CloudFormation console.

3. Save the contents of the file ws-dr-template.yml locally and deploy it through the AWS CloudFormation console by clicking Create Stack, Upload a template file, Choose file and, after selecting the file, choose Next.

4. Under Parameters, review the parameters for the template and enter them accordingly. This solution uses the following parameters:

Once the parameters are entered, choose Next.

5. On the Options page, choose Next.
6. On the Review page, review and confirm the settings. Be sure to check the box acknowledging that the template will create AWS Identity and Access Management (IAM) resources.
7. Choose Create to deploy the stack.

Once the solution is deployed, after 5 minutes, you should start seeing the CSV file in the S3 bucket.

At this point, the solution will keep track of the users you have in the specified OU and maintain WorkSpaces in the DR region.

DR Activation Process

In the rare cases where Amazon WorkSpaces is unavailable in your production AWS region, all you need to do is to direct your users to change the Registration Code to connect to WorkSpaces in the DR region.

You could pre-configure that registration code in the user’s WorkSpaces clients, in advance, and just instruct users to just change to it, if they need to use the DR WorkSpaces instances.

Alternatively, you could create a system, using AWS Lambda, to monitor AWS Health using its APIs to detect if Amazon WorkSpaces service becomes unavailable in your production region and then send a notification to your users to use the registration code of the DR region to connect.

The following architecture shows the DR activation process in case the production region becomes unavailable.

Conclusion

As Amazon.com Chief Technology Officer, Werner Vogels once said, “Everything fails all the time”. Because of that simple true, we need to architect systems so that they can be resilient to failure. I hope this solution can help you implement a cost-effective DR strategy for your Amazon WorkSpaces environment and keep your users productive, even under adverse circumstances.

About the Author

João Paulo (JP) Santana is a Senior Solutions Architect for AWS. He spent most of his life in São Paulo, Brazil and now lives in Atlanta, GA where he works with our customers in the Southeast region of the US. In his spare time, he enjoys spending time with his family, grilling a good Brazilian steak and working out at the gym.