Introduction

As of February 2020, businesses globally started realising they needed to be ready to allow their workforce to work from home, using remote technologies and at scale. COVID-19 is not just a scare, it’s the real thing.

My colleagues at Contino have highlighted the value of cloud-enabled remote working in these blogs (here and here).

In this blog, I intend to demonstrate a step by step, technical setup of a simple AWS Workspace and show a reference architecture for virtual desktop.

If you're interested in reading more about how Contino can help your business set up a full scale virtual desktop solution, in 2 weeks, and scale your enterprise roll-out using integration with service-now, consider starting here

But first, let’s familiarise ourselves with what Amazon WorkSpaces is.

What Is Amazon WorkSpaces?

Amazon WorkSpaces is virtualisation for the desktop, otherwise known as Desktop-as-a-Service. You can think of it as your employees’ entire desktop layout and functionality from their office computer, but hosted in the Amazon cloud, and pipe the pixels to the employee’s personal computer or tablet.

With WorkSpaces, you create either Windows or Linux desktop configurations for users, which includes all the software your team uses in the office, plus your regular comms tools, email, and access to your file systems.

Instead of having your users download and install software to continue work at home, their personal device simply has the office desktop available via WorkSpaces. Compute and graphics calculations are done in the cloud, which means the only important thing employees need is a working desktop, laptop, or tablet, and a strong enough internet connection - to do all of their work, with zero self-configuration (only an easy enrolment), all from home.

You can also use WorkSpaces in the office, to give employees the same working environment at work, at home, or on the road.

Features 

Scale up or down

Up to thousands of desktops can be launched in seconds.

Doesn’t require many resources on the user’s side

The heavy work is done in the cloud.

Secure

Data isn’t sent to or stored on the user’s device, data is encrypted in transit and at rest.

Sandboxed environment

WorkSpaces runs in a secure, sandboxed environment, from the cloud so that your employees’ underlying system processes cannot access your company resources.

Responsive

With a strong network connection, response time is near-instant when used in WorkSpaces regions.

Active Directory integration 

For fast user grouping strategies and access control.

BYO Windows licensing

You can use your Windows enterprise licensing on each of your Amazon WorkSpaces.

Can be used across almost any device

This includes Windows and Mac desktops, laptops, and tablets (including iPads), Chromebooks, Android tablets, Fire tablet, and even simply through Chrome or Firefox on another device (although this experience may be less responsive/laggy).

Use Cases 

Anyone working outside of the office

Speaks for itself here!

Businesses looking to spend less on physical machines for employees

Whether we are talking about physical machines in the office or at home, Amazon WorkSpaces doesn’t require anything heavy-duty. You may like to do a cost-benefit analysis to see whether WorkSpaces could be a better fit than expensive office machines.

Remote-work data security

These devices don’t store any company data on the device itself so you can feel more comfortable about your business’s data security. Make sure to install antivirus software etc.

Employees who need to compute or graphics-heavy work remotely but don’t have powerful machines

Because the compute and graphics work is done by Amazon’s machines, remote employees don’t need to worry about a home upgrade (and employers don’t need to worry about buying/loaning new, expensive kit). GPU bundles are available specifically for people who need to do operations like CAD or video work.

Pricing

Currently, Amazon is offering WorkSpaces for up to 50 users for free for all new WorkSpaces customers (until June 30th), with “80 GB Root and 50 GB User Volumes, running in AutoStop mode for up to 10,000 hours of combined use per month.”

Usually, pricing is either charged monthly or hourly, based on the bundle type and the number of WorkSpaces launched. Monthly rates are fixed price with unlimited usage for end-users, whereas hourly is only when WorkSpaces is launched. For employees doing their full-time hours (or close to) using WorkSpaces, a monthly plan is a better option.

Integrations 

Pair with solutions like:

You can also take a look at the other integrations available for WorkSpaces on the AWS Marketplace.

How to Deploy WorkSpaces

The Amazon WorkSpaces Administration Guide provides a solid overview of how to create and manage WorkSpaces.

You can use Quick Setup (available in US East (N. Virginia), US West (Oregon), Europe (Ireland), Asia Pacific (Singapore), Asia Pacific (Sydney), and Asia Pacific (Tokyo) regions) to easily choose WorkSpaces bundles, then get a user connected to launch them.

However, for a full working environment, you will need to configure applications, file systems, networking and access controls, etc.

Setting Up a Simple AWS WorkSpace: Key Considerations

There are some key considerations we need to look at when attempting to provide employees with Virtual Desktops (cloud or otherwise):

  • How do I connect to them?
  • How do I authenticate to those desktops?
  • What applications are they going to be hosting? Do they need to connect to an application using a browser? Or, do I need to package applications?
  • Do they need internet access?
  • How do I secure them?

To answer all considerations, AWS provides best practice setup papers. In this instance, the workspaces best practices are defined here and would generally look like this from an architecture perspective. 

The reference architecture provided by AWS below, enables private, secure and reliable access to Workspaces provisioned in an AWS account, which has connectivity to an on-premise Active Directory. Such architecture is compliant with the AWS well architected framework.

Assumptions

In this blog, I will make some assumptions to deploy a quick workspaces. Those assumptions are as below:

  • Connectivity: You are looking at accessing your workspaces over the internet. 
  • Authentication: A directory services is already available in your AWS environment and registered. If not, there’s a quick code snippet below on how to set this up. You will need to create your own users in the directory service. The alternative is, an AWS AD connector pointing to on-premise AD is already deployed.
  • Application packaging: This blog covers deployment of a vanilla Windows 10 on WorkSpaces. If you are looking for application packaging, reach out to me on LinkedIn or refer to Workspaces Application Manager.
  • Internet Access: I am deploying workspaces into a public subnet for the purposes of this blog. Best practices mandates you use a NAT gateway and deploy your Virtual Desktops into private subnets.
  • Security: the typical sandwich model applies when it comes to service security, with a slight amendment. AWS Workspaces are configured by default to receive updates automatically. Users have the ability to re-configure that. For more information on the security model in AWS, you can read a previous blog I’ve published on the topic.

Directory Service

What happens if I don’t have a directory service in AWS, or an AD connector to authenticate me against my on-prem domain controllers? 

In this case, I need to deploy a Directory service into my AWS account. There are two types of AWS hosted directory services (excluding the connector) that can be used to store user accounts and be associated with WorkSpaces. Those are: Simple-AD and Microsoft-AD. I’ve created the below CloudFormation template to deploy a Simple-AD. The repo url can be found here.

When deployed into your Primary VPC, you should see this


Now, let's associate that Directory with AWS WorkSpaces to authenticate users. The process can be found here, and as of now, I only found a terraform module to access it programmatically. 

To register using the console, go to Amazon Workspaces in your AWS Console, select the directory you just created and click register, then next. You should see the directory status reflected as “Registered”. 


Another way to create a directory service in addition to a VPC, two public subnets and as well as perform the registration programmatically, is to use Terraform. I’ve also cobbled together a terraform snippet that does all of the above for you in one easy file.


Users

To authenticate to workspaces, if you're using an AWS greenfield deployed directory services for this purpose and you have not set up trust with your local Domain, you need to add users. 

Adding users into the directory service is not available programmatically through AWS native automation, such as CloudFormation. 

You can do that through the console or through your Active Directory tools. In this exercise, you can use the default “administrator” user to launch a workspace.

Workspaces

Now that we’ve covered connectivity and the authentication process and connectivity, let’s provision a workspace and connect to it. 

I’m using another CloudFormation template for that (surprise surprise). Below is the template and the GitHub gist for it. In this template, I am picking a Windows 10 bundle with one core and 2GB of ram (free tier). I am also allocating that to the username “administrator”. The template is found in this repo. 

The bundle id is: wsb-bh8rsxt14


Now we have a Virtual Desktop running in AWS that we can access over the Internet. But we still need some additional details to connect to it.

First, we need a registration code, then, we need the workspaces client. Luckily, those details are easy to get hold of. The registration code is presented for each workspace in it’s details window, while the client can be obtained from https://clients.amazonworkspaces.com/ 


Once downloaded and installed, the client will first require the registration code. Post registration, you will need the credential of the user designated for the workspace, in this case, Administrator.


And just like that, we have provisioned a workspace and connected to it.

Ta-DA!

x

SIGN UP TO OUR UPDATES

DevOps Insights Directly to Your Inbox!

Join thousands of your peers and subscribe to our best content, news, services and events.

Marwan Kansoh

Technical Principal

Marwan Kansoh is a Technical Principal at Contino. During his 18 year engineering career, Marwan has worked on enterprise cloud migration and transformation programs within telco, fintech and consulting industries. Marwan’s technical expertise lies in security, infrastructure, cloud and DevOps.