In the first article of this two-part series, we explained the architecture and benefits of Amazon WorkSpaces. In this post, we’ll review the best practices for deploying WorkSpaces and to get you started with this managed Desktop-as-a-Service offering.
Consider Zero Clients
AWS WorkSpaces provides the flexibility of using PCoIP Zero Clients as endpoints. Zero clients are dumb devices without any OS and can be an alternative to the traditional desktop. They’re equipped with a monitor, mouse, keyboard, and other peripherals. On the client end, there’s a PCoIP chipset that is used to decompress and decode transmitted data. Also, the power consumption of these zero clients is minimal compared to a physical desktop. A common dilemma organizations face is the decision of whether to continue using the existing endpoints (i.e. local desktop) or to replace them with a zero client. Usually, the price of the thin clients is nearly the same as a desktop’s. This means the decision comes down to your preference: you ’ll pay for the maintenance of the existing desktops running the AWS WorkSpaces clients, or you’d rather invest in a new set of zero clients. It’s a difficult tradeoff that should be based on your unique needs.
Amazon Workspaces Security
AWS WorkSpaces can be secured by encrypting data and using security groups.
Encryption
In Amazon WorkSpaces, data is encrypted in transit at different communication stages, or at rest in the form of encrypted workspaces using cryptography. All the communication in various transit stages happens over the HTTPS and PCoIP protocols using AES 128 or 256 ciphers, along with the use of Kerberos protocol for authentication. Similarly, you can encrypt one or all the logical drives of Amazon WorkSpaces. Pay attention, you must specify whether a particular drive needs to be encrypted or not at the time of deployment —it can’t be changed later on! Volume encryption occurs through a customer master key (CMK). You have the option to choose the default CMK or the custom CMK that’s in your AWS Key Management Service (KMS). You should always encrypt AWS WorkSpaces while they’re being deployed.
WorkSpaces Security Groups
A security group is created by default with the establishment of an AWS Directory Service and is then attached to all workspaces that use the same directory. You can attach the security groups to the primary elastic network interface (ENI), but you can’t control the management ENI through security groups. For Management ENI, you can set up a host-based firewall and keep specific health and accessibility-related ports open. However, you shouldn’t apply restrictions on the management interface.
Selecting the Right Bundle for Your Workload
As per the workload, AWS WorkSpaces gives you the flexibility to choose from multiple bundles. If you’re a power user, you can choose a virtual desktop with 16GB RAM. If you’re a user whose workload isn’t as significant, even 2GB RAM is enough. It’s also important to select a suitable billing cycle for users. If you’re using AWS WorkSpaces as your primary desktop, a monthly plan is ideal. If your WorkSpaces usage is limited to a few days per month, you can opt for an hourly billing plan. With an hourly billing plan, there’s a small, monthly infrastructure cost in addition to the hourly costs.
Networking Considerations
Amazon Virtual Private Cloud (VPC) is a virtual network that is associated with each AWS WorkSpace. For user management, each AWS WorkSpace requires an Amazon Directory Service construct: either an AD connector, a simple AD, or a Microsoft AD. A minimum of two subnets spread across different availability zones are required by each Directory Service construct, which can’t be modified once created. Make sure you define user groups and authentication properly as part of the deployment planning. Doing so will help you segment and restrict user access.
VPC Design
It’s recommended to have a separate VPC for the AWS WorkSpaces deployment, so you can set the guidelines for security and governance by separating traffic. Since WorkSpaces deployments and the Directory Service construct are present in the same VPC subnets, subnets should be carefully designed to accommodate future growth.
Active Directory Design Considerations
There are three scenarios in which directory services can be deployed for Amazon WorkSpaces:
- Microsoft AD: directory service for Microsoft Active Directory running on AWS.
- Simple AD: AWS-managed directory service that is Microsoft AD-compatible and is running with Samba4.
- AD connector: acts as a proxy for authentication requests to your existing Microsoft AD in your data center.
In the first two scenarios, the directory services are in the AWS Cloud and they’re fully managed by AWS. In the third scenario, the directory services are in the customer’s data center, and all requests coming from AWS WorkSpaces are routed to it through the AD connector. Here, the AD connector acts as a proxy and doesn’t store any user credentials.
Summary
With AWS WorkSpaces, organizations gain the benefits of cloud computing for end-user computing. By following the guidelines and best practices for network design, active directory design and security, you can scale your business in a hassle-free and efficient manner.
