Pros and Cons of Amazon Workspaces
And how to try out Workspaces for free!
Command Palette
Search for a command to run...
Comments
Join the discussionNo comments yet. Be the first to comment.
Search for a command to run...
And how to try out Workspaces for free!
No comments yet. Be the first to comment.
Welcome to my blog again, and this article will focus on the pros and cons of Amazon's DAAS platform: Amazon (AWS) Workspaces. I've used Workspaces as my primary desktop at work for over 1.5 years and you can consider this post as a long-term review / list of pros-cons.
Workspaces is the Amazon / AWS answer to Citrix, VMWare and other VDI solutions. Launched in 2014, this service was useful to us as we were looking for a replacement to traditional desktops as we were bootstrapping ourselves in the midst of the pandemic (early/mid 2020). With all of us working from home, it made sense to try out Workspaces, as we were an AWS shop otherwise as well. Remote work is touted as one of the main benefits on the homepage , and I would agree.
Amazon offers both Linux and Windows workspaces. Our primary use case was with Linux, though we've tried Windows based workspaces as well for certain use cases.
I've included a section on how to get started with a free workspace for experiments towards the end of this article, but let's jump straight to the pros of Workspaces.
The point-and-click (or API / CLI driven) interface to create a new workspace for users is dead simple. All you need is an email address of the end user. Although there is a user directory underneath (via AWS Directory Service ), the quick setup offered sets up this directory automatically. Especially for the Windows world, although you have BYOL options, I'm sure you'd appreciate not having to worry about Windows licensing.
This is IMO the killer feature especially if you're already on AWS for the most part. When you set up your workspaces infrastructure, you can host workspaces exactly as you would with EC2 instances. That is, workspaces can live within your private VPC, and be exposed to the internet via usual NAT gateways. Not just that, you can choose to have workspaces in the same VPC that hosts your dev infrastructure - meaning workspaces can access other EC2 instances, your DNS, private Route53 hosted zones and all other infrastructure conveniently. You can also add extra security groups to your Workspaces. For example, I've added an extra group that allows developers to access webapps of each other on certain HTTP ports.
For both Linux and Windows workspaces, I've found the performance to be good enough (not talking about network latency etc. here) and representative of the class of machines you select while setting up your workspace (Standard / Power / Performance etc.).
root accessWith a configuration switch, it is possible to enable root access for Workspaces users. While it is possible to do a lot these days without it, true-blue Linux developers always appreciate having the ability to run services as root - and this has helped folks learn more about Linux, systemd, docker etc. Because, like EC2 instances, your Workspaces are still isolated units, you can be reasonably confident that developers won't / cannot mess with other shared resources.
As with other VDI solutions, you can create your own images (AMI equivalents) including your favorite development tools etc. However, do note that the base image is Amazon Linux 2 (which I find to be quite stable) and some users may prefer Ubuntu flavors. If your poison of choice is Windows, AWS also includes the Workspaces Application Manager ( WAM ) that enables you to push Windows applications to Workspaces.
Workspaces allow a decent set of self-service options. Depending on how much freedom is warranted, you may even give permissions to change the type (performance) of the instance. I'd recommend to at least allow the ability to restart / rebuild the Workspace for attempting self-repairs.
Workspaces land has some cons that you should be aware of before going all in.
By far the biggest complaint with Workspaces will evidently be one not in your control - latency issues and lag. On most occasions, the round-trip-time (RTT) from the user desktop to his/her workspace is what matters the most. Amazon offers this helpful page to check the best performing regions - but of course you already may have a region selected.
As shown above, I'd always recommend regions with latency < 100ms. Do note that even if you're thinking of multiple workspaces regions for your users, there may be extra complexities with respect to user directories.
AWS provides the extremely useful AWS SSO service that many firms use to single-sign-on employees / developers. However, unfortunately, you cannot use this to sign in to Workspaces. Instead you need to set up a directory (either Simple AD - free but present in a few regions, or AWS managed Microsoft AD - the behemoth) and authenticate with that. If you use Azure AD, you can connect to it, but the setup isn't simple and requires VPN connectivity between AWS and Azure. Similarly MFA is possible, but the setup isn't simple.
Unlike the MacOS and Windows clients, the Linux client is sub-par. Notably, copy-pasting to-from the workspace does not work. In addition, Amazon has implemented a new protocol known as WSP (instead of the older Teradici PCOIP protocol) - which unfortunately is supported only in Windows workspaces.
Workspaces can be used in two modes:
The AutoStop workspaces may be shut down after some inactivity, and requires a couple of minutes to boot up. In contrast, the AlwaysOn workspaces are immediately available. No matter which one you choose, Amazon Workspaces do tend to be slightly expensive if you compare with outright purchase of a laptop over a long duration. Unfortunately compute savings plans or other volume discounts don't apply.
However, do keep in mind the indirect costs of maintaining your own laptop policies, server infra, the ease of OS updates in your calculation. It may or may not make sense for you given the size and geographical distribution for your users.
In certain cases, I was not too satisfied with the restore capabilities of Workspaces. You cannot restore to a somewhat older state (say, a week/month back) - but only to a "last known good config" sort-of state. One common problem that occurs is users filling up their home partitions, and the only way is to revert to older versions.
Slight nitpicking here 😀. By far one of my favorite lesser-known hodge-podge of services is AWS Systems Manager or SSM. One cool feature in SSM is the ability to trigger commands across a fleet of instances. These commands could be one-off shell scripts or full blown Ansible playbooks. Unfortunately, while SSM works well with EC2 instances, setting them up with Workspaces is a bit of a pain. I expect this to be a single feature toggle.
Anyway, don't take my word for it. You can try Workspaces for free - some instance types are part of the Free Tier. Create an AWS account, login and simply create a new Workspace in your preferred region - the wizard is trivial to follow.
Use the "Quick Setup" button:
Then simply select a bundle that says "Free Tier", enter your user details and hit the blue button!
It usually takes about 20 minutes for AWS to provision the workspace. Once this is done, you'll get an email with instructions to authenticate and login.
One nicety that was present in the past is Amazon's Work From Home offer that allowed up to 50 workspaces for free for a limited time. Unfortunately this seems to have expired (I think).
Overall, I'd definitely recommend individuals or small startups to try Workspaces for a month and see if it works for you. It is a solid offering and we've rarely faced any major issues. However, ensure that your users are close to the region where you're setting up Workspaces and have a decent internet connection.