Amazon WorkSpaces: Overview, Use Cases and a Guide to Deployment
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.
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.
Data isn’t sent to or stored on the user’s device, data is encrypted in transit and at rest.
WorkSpaces runs in a secure, sandboxed environment, from the cloud so that your employees’ underlying system processes cannot access your company resources.
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).
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.
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.
Pair with solutions like:
- Amazon WorkSpaces Application Manager - to deploy any desktop applications to your users
- Amazon WorkSpaces Cost Optimizer - to auto-optimize your billing based on usage
- Amazon WorkDocs - Like Google Drive/OneDrive/DropBox for secure cloud business file storage
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.
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.
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.
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.
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.