Deploying Amazon WorkSpaces With the Right Network and VPC Configuration

Know the network specifications and Amazon Virtual Private Cloud configurations you need to deploy Amazon WorkSpaces.

Key Takeaways:

• Amazon WorkSpaces is a managed desktop cloud computing service that operates remote desktops for your organization from on-premises or external networks. 
• Successful deployment requires the right network and VPC specifications, including Amazon Virtual Private Cloud sizing and subnets, security groups, routing policies, and more. 
• Using a separate VPC for WorkSpaces deployment separates the traffic flow for added security. 
• Every client device running WorkSpaces connects using the same two ports, which you can use to encrypt traffic and limit outbound traffic. 
• The VPC connection controls ENI access to network resources based on default security groups and your preferred host-based firewall. 
• A typical WorkSpaces configuration can segment access between workers who need full access (e.g., full-time employees) and workers who need restricted access (e.g., contractors). 

Have you given enough thought to the network and security configuration of your Amazon WorkSpaces implementation? 

WorkSpaces is a managed desktop computing platform that runs cloud-based desktop environments without the need for additional hardware or software procurement. Instead of a multi-day (or week) deployment process, it’s relatively simple to implement WorkSpaces fast due to the lack of external processes needed. 

The use cases for Amazon WorkSpaces include: 

• Launching Microsoft Windows or Amazon Linux 2 desktops in minutes
• Securely accessing desktop software from on-premises or external networks 
• Manage users with AWS Directory Service 
• Enable multi-factor authentication using Active Directory Connector (an AWS Active Directory gateway) and an on-premises or remote server 
• Reducing the time spend and resources associated with deploying, transitioning to, and maintaining a managed desktop service 

Even though deployment is quick and easy, the network and Amazon Virtual Private Cloud setup require some extra-careful consideration.

Not only should you consider security questions like segmenting administrative access, but network specifications for WorkSpaces also determine the virtual desktop environment’s ability to scale. For instance, the subnets are permanently associated with an AWS Directory Service construct and can’t be scaled (or modified at all) after creation. 

Before deployment, take the time to learn the relevant network and VPC considerations for Amazon WorkSpaces: 

Requirements for Amazon WorkSpaces

Implementing Amazon WorkSpaces requires these three elements:

• A WorkSpaces-supported client device, such as Android, iPad, Linux, macOS, Windows, or PCoIP (Personal Computer Over Internet Protocol)
• An active directory service for managing users and WorkSpaces — AWS Directory Service and Microsoft Azure Active Directory are the only available options as of 2021  
• An Amazon Virtual Private Cloud environment that will run your WorkSpaces instance, along with two (or more) subnets  

Network construct considerations for Amazon WorkSpaces 

When you create your WorkSpaces, it becomes permanently associated with the AWS Directory Service construct (Simple AD, AD Connector, or Microsoft Azure AD) and Amazon VPC that you used to generate it. Changing the construct (or other parts of the framework) isn’t possible after creation. 

Every WorkSpace has the following interfaces:

• Elastic network interfaces (ENI)
• Management network interfaces (eth0)
• Primary network interfaces (eth1) 

The typical configuration has two ENIs, one eth0, and one eth1 interface, with eth0 being the primary interface for WorkSpaces management. AWS assigns a private IP address to eth0 that’s exclusive to network routing, so the eth1 and ENIs must be used on networks that communicate with the WorkSpaces VPC.  

Ask these questions before creating subnets

The subnets behind the AWS Directory Service construct must be the right size — you can’t change them to scale later. Prior to creating subnets, your team should ask these questions: 

• How many WorkSpaces will we need over X period of time? 
• How much growth do we anticipate in that time?
• How many users will we accommodate in that time?
• How many domains from Active Directory will we connect? 

Define user groups to segment access

User groups can segment and restrict access to apps and resources within WorkSpaces using: 

• AWS Directory Service
• Network access control lists
• Routing tables
• VPC security groups 

AWS Directory Service applies the same settings to every WorkSpaces instance that it launches, so a security group connected to all WorkSpaces can specify and verify multi-factor authentication, local administrator privilege, and other access permissions. 

Decide the specs for your VPC design

Your VPC design should consider factors such as scale, security, and ease of use and maintenance. Some best practices for VPC design include:

• Using a separate VPC for WorkSpaces deployment to separate traffic using security guardrails, prompting multi-factor authentication or administrative verification.
• Splitting directory service between AWS Availability Zones using two subnets within an AWS Directory Service to route by type of incoming traffic.
• Specifying a default security group that applies to all WorkSpaces that launch from an AWS Directory Service construct, ensuring consistent application of security rules.
• Planning for additional available IP addresses to accommodate future solutions for WorkSpaces management, including patch management servers and antivirus servers.

Connecting client devices to WorkSpaces

Routing a client device to WorkSpaces uses the HTTPS port (port 443) and PCoIP port (port 4172) for encrypted connectivity. The client device uses the HTTPS port for authenticating users and transmitting session-related data. The PCoIP port transmits pixel streaming data to individual WorkSpaces and conducts network health and status checks. 

Within the Amazon WorkSpaces client, there’s a constant indicator on the bottom right indicating whether the network is successfully connected to the client device, simplifying troubleshooting for all users. Users with administrative status can choose Network on the same part of the screen to get a detailed view of the connection status with the client. 

Connecting WorkSpaces to VPC

When the client authenticates the connection to a user’s WorkSpace, the network shows an established connection with the WorkSpace’s eth1 port and an assigned IP address from the Dynamic Host Configuration Protocol (DHCP) that’s attached to the WorkSpace for the entirety of its lifespan. 

The eth1 port can access any VPC resource (as well as any VPC-connected network via VPN connection, AWS Direct Connect, or VPC peering), but that access is limited by the default security group. You can add or change security groups by entering the AWS Management Console and further protect access by configuring a preferred host-based firewall. 

What a typical WorkSpaces configuration may look like

One of the most-represented use cases for WorkSpaces includes segmenting administrator access between groups of employees who need access and people (some employees, contractors, and consultants) who are excluded. 

The average full-time internal user requires full access to the internal network and the internet from WorkSpaces, as well as the on-premises network from the VPC. On the other hand, contractors may need only restricted internet access, which you can provide through a proxy and limit to specific websites or resources. 

You can accomplish this by creating user personas with different rules for access and WorkSpaces that you configure differently. Limiting contractor access requires opening ports 80 and 443, but only to the specific internal locations that are needed. 

You can do this by:

• Entering Amazon WorkSpaces Management console
• Disabling the Internet Access and Local Administrator settings 
• Adding a security group in the Security Group settings 

This prevents outbound traffic from accessing anything but HTTP or HTTPS. 

You can completely close off unauthorized access to the internet and block local administrator access, all within the WorkSpaces user persona settings, using AD Connectors for implementation. 

Build and configure WorkSpaces with an AWS Premier Consulting Partner

One of the biggest draws of WorkSpaces is its user-friendly design, but it’s still important to have a security-minded eye to oversee implementation and maintenance. It’s critical to limit the behavior of workers who aren’t part of your organization and internal workers who don’t require deep permissions — internal intelligence is potentially at stake. 

WorkSpaces can reduce operating costs and increase productivity when the deployment is ideal, but it takes a specialist to execute the perfect deployment. Organizations that lack a dedicated IT department (or have one but lack the resources to tackle WorkSpaces) should team up with an AWS Premier Consulting Partner to get an expert’s touch on your implementation. 

Call CloudHesive today at (800) 860-2040 to learn about our competitive advantage (also known as our Superpowers) and how our deployment team can apply it to your WorkSpaces environment!