AMAZON WORKSPACES – BEST PRACTICES
AMAZON WORKSPACES: Core best practices for deploying Amazon Workspaces
Amazon WorkSpaces is a managed desktop computing service in the cloud. With WorkSpaces, you don’t have to buy additional hardware, and it eliminates the need of installing complex software. In addition, Workspaces delivers a desktop experience with either a few clicks on the AWS Management Console. Furthermore, with WorkSpaces, you can easily launch a Microsoft Windows or Amazon Linux desktop within minutes. Hence, it it enables you to connect to and access your desktop software securely, reliably, and quickly from anywhere. Hence, a pretty powerful solution.
Thus,
You can automate the provisioning of Amazon WorkSpaces by using the CLI or API, which enables you to integrate it into your existing provisioning workflows
Amazon Workspaces Requirements
Amazon WorkSpaces service basically requires three components to deploy successfully
1. WorkSpaces client application
2. A directory service to authenticate users and provide access to their WorkSpace
3. Amazon Virtual Private Cloud (Amazon VPC) in which to run your Amazon WorkSpaces
Amazon Workspaces Architecture
Network Considerations
Each WorkSpace is associated with the specific Amazon VPC and AWS Directory Service construct that you used to create it. All AWS Directory Service constructs (Simple AD, AD Connector, and Microsoft AD) require two subnets to operate, each in different Availability Zones (AZs). Subnets are permanently
affiliated with a Directory Service construct and can’t be modified after it is created. Because of this, it’s imperative that you determine the right subnet sizes before you create the Directory Services construct.
Therefore, carefully consider the following before you create the subnets:
How many WorkSpaces will you need over time?
What is the expected growth?
What types of users will you need to accommodate?
How many AD domains will you connect?
Where do your enterprise user accounts reside?
VPC Design
Here are a few things to consider when designing the VPC, subnets, security groups, routing policies, and network access control lists (ACLs) for your Amazon WorkSpaces so that you can build your WorkSpaces environment for scale, security, and ease of management
VPC — AWS recommends using a separate VPC specifically for your WorkSpaces deployment. With a separate VPC, you can specify the necessary governance and security guardrails for your WorkSpaces by creating traffic separation.
Directory Services — Each AWS Directory Service construct requires a pair of subnets that provides a highly available directory service split between Amazon AZs.
Subnet size — WorkSpaces deployments are tied to a directory construct and reside in the same VPC subnets as your chosen AWS Directory Service. Keep in mind that subnets size are permanent in nature and cannot change.
Network Interfaces
Above all, each WorkSpace has two elastic network interfaces (ENIs), a management network interface (eth0), and a primary network interface (eth1). Thus, AWS uses the management network interface to manage the WorkSpace. Basically, it’s the interface on which your client connection terminates. Therefore, AWS uses a private IP address range for this interface. In addition, for network routing to work properly, you can’t use this private address space on any network that can communicate with your Amazon WorkSpaces VPC.
Traffic Flow
You can break down Amazon WorkSpaces traffic into two main components:
First, the traffic between the client device and the Amazon WorkSpaces service
Second, the traffic between the Amazon WorkSpaces service and customer network traffic
Client Device to WorkSpace
So, regardless of its location (on premises or remote), the device running the Amazon WorkSpaces client uses the same two ports for connectivity to the Amazon WorkSpaces service. In other words, the client uses port 443 (HTTPS port) for all authentication and session-related information, and port 4172 (PCoIP port). In addition, to both Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).
Thus, it is for pixel streaming to a given WorkSpace and network health checks. Hence, traffic on both ports is encrypted. Port 443 traffic is used for authentication and session information and uses TLS for encrypting the traffic. Above all, pixel streaming traffic uses AES-256-bit encryption for communication between the client and eth0 of the WorkSpace, via the streaming gateway
VPC Service
So, first the connection is authenticated from a client to a WorkSpace and streaming traffic starts. Thus, as the next step, your WorkSpaces client will display either a Windows or Linux desktop. In addition, it must connected to your virtual private cloud (VPC), and your network should show that you have established that connection. Thus, the WorkSpace’s primary ENI, identified as eth1, will have an IP address assigned to it from the Dynamic Host Configuration Protocol (DHCP) service. Subsequently, the IP address stays with the WorkSpace for the duration of the life of the WorkSpace.
Example of VPC Configuration
How to configure two types of Amazon Workspaces
First Type
First type is to configure WorkSpaces for full-time employees as follows:
1. In the Amazon WorkSpaces Management Console, choose the Directories option on the menu bar
2. Choose the directory that hosts your full-time employees
3. Choose Local Administrator Setting
By enabling this option, any newly created WorkSpace will have local administrator privileges. To grant internet access, configure NAT for outbound internet access from your VPC. To enable MFA, you need to specify a RADIUS server, server IPs, ports, and a pre-shared key.
For full-time employees’ WorkSpaces, inbound traffic to the WorkSpace can be limited to Remote Desktop Protocol (RDP) from the Helpdesk subnet by applying a default security group via the AD Connector settings.
Second Type
Second type is to configure WorkSpaces for contractors and consultants:
1. In the Amazon WorkSpaces Management Console, disable the Internet Access and the Local Administrator setting.
2. Add a security group under the Security Group settings section to enforce a security group for all new WorkSpaces created under that directory.
For consultants’ WorkSpaces, limit outbound and inbound traffic to the WorkSpaces by applying a default Security group via the AD Connector settings to all WorkSpaces associated with the AD Connector. The security group prevents outbound access from the WorkSpaces to anything other than HTTP and HTTPS traffic, and inbound traffic to RDP from the Helpdesk subnet in the on-premises network.
After all, there is a strategic shift in end-user computing, as organizations strive to be more agile, better protect their data, and help their workers be more productive. Thus, many of the benefits already realized with cloud computing also apply to end user computing. Furthermore, with Amazon WorkSpaces organizations can quickly scale as they add workers and improve their security posture. Finally, you can offer workers a portable desktop, with access from anywhere, using the device of their choice.
