1. Networking for Amazon WorkSpaces

It’s necessary to understand the networking requirements and network traffic flows of the WorkSpaces service.

1.1 WorkSpaces instance networking

The WorkSpaces service requires minimum two subnets to operate, each in a different AZ. This approach ensures distribution of your WorkSpaces across AZs.
Each WorkSpace has two elastic network interfaces:
• A management network interface (eth0).
• A primary network interface (eth1).

2. Traffic flow

The traffic flow for Amazon WorkSpaces can be broken into two main components:
• The traffic between the client device and the Amazon WorkSpaces instance.
• The traffic between the Amazon WorkSpaces instance and customer network.

2.1 Client device to WorkSpace

• The end-user device either running the Amazon WorkSpaces client or using Amazon WorkSpaces web access, uses the same two ports for connectivity to the service.
• The client uses HTTPS/TCP over port 443 and port 4172/TCP+UDP (PCoIP/WSP) for communications and network health checks.
• Traffic on both ports is encrypted.
• Port 443 traffic is used for authentication and session information and uses TLS for encrypting the traffic.
• Pixel streaming traffic, keystrokes, and pointer movements are encrypted using up to AES-256-bit encryption for communication between the client and eth0 of the WorkSpace, via the streaming gateway.
• Publish per-region IP ranges of our PCoIP/WSP streaming gateways and network health check endpoints.
• Outbound traffic on port 4172 can be limited from your corporate network to the AWS streaming gateway and network health check endpoints by allowing only outbound traffic on port 4172 to the specific AWS Regions.

2.2 Amazon WorkSpaces to VPC

After a connection is authenticated from a client device to a WorkSpace and streaming traffic (PCoIP/WSP) is initiated, your WorkSpaces client will display a Windows or Linux desktop that is connected to your VPC. Each WorkSpace’s primary elastic network interface, identified as eth1.

3. VPC design options

3.1 VPC designs influenced by risk

The high-level design for a VPC being used to host a WorkSpaces environment leverages a VPC in an AWS Region with at least two AZs. Within each AZ at least one subnet is created to provide the eth1 network connectivity to each WorkSpace. An example of applying segregation to different types of users is shown in Figure 1.
>>>>> Figure 1 – Full-Time vs Consultant WorkSpaces scenario <<<<<
It is recommended that network ACLs be used cautiously as they can have a significant impact on the operation of a WorkSpaces environment and it is important to note that network ACLs have no effect inside a subnet and only affect communication between subnets.
Figure 2, shows different security groups applied to each of the two sets of subnets hosting WorkSpaces, in this case trusted and the untrusted users.
>>> Figure 2 – Trusted vs Untrusted users – Differing risk profiles satisfied by security groups <<<
It is possible to have multiple and overlapping security groups within the same subnet to apply granular controls. The default security group is associated with the directory being used with Amazon WorkSpaces and this is applied to a WorkSpace when provisioning through the AWS Management Console.

3.2 VPC design influenced by placement of infrastructure, data, or user

WorkSpaces should be located where the data they need can be accessed with relatively low network latency. Therefore, it is critical to consider the location of the resources and the physical placement of WorkSpaces alongside data wherever possible. Figure 3 shows an existing VPC that has already been implemented in AWS that hosts Active Directory Domain Controllers.
>>>> Figure 3 – Managed Active Directory in an existing peered VPC <<<<
Figure 4 shows a WorkSpaces architecture with a Managed Active Directory implemented across two private subnets and WorkSpaces implemented across an additional two private subnets.
> Figure 4 – WorkSpaces and existing Active Directory in a common VPC <
The two previous VPC designs have been based on existing infrastructure already present in AWS. Figure 5 shows an existing on-premises network with Active Directory Domain Controllers and shared services connecting to a new WorkSpaces environment hosted in a VPC. The WorkSpaces VPC can provide internet connectivity through the use of an internet gateway. The VPC also ensures that AWS services that have VPC endpoints can be reached from the private WorkSpaces without the traffic having to traverse the internet.
>> Figure 5 – Existing on-premises Active Directory connected to WorkSpaces using Direct Connect/Site-to-Site VPN <<

3.3 VPC design for multi-regional WorkSpaces deployments with multiple directories

Figure 6 shows a multi-regional WorkSpaces environment across three AWS Regions, six AZs, and an existing on-premises network. This design satisfies a geographically dispersed user base since a user within a user base that spans multiple geographies can connect to their nearest WorkSpace Region.
>> Figure 6 – Multi-Regional WorkSpaces deployments with multiple directories <<

3.4 Streaming and authentication traffic flow for Amazon WorkSpaces

Figure 7 shows the streaming and authentication traffic flow for Amazon WorkSpaces. This diagram is useful to understand a full WorkSpaces environment that is being accessed by end-users and that also has connectivity to an existing on-premises network.
>> Figure 7 – Authentication, authorization, and streaming request flow for Amazon WorkSpaces <<

1. Users are connecting to the WorkSpace service from their corporate office.
2. The credentials are used to authenticate the identity stored in the customer Active Directory.
3. If an Active Directory Connector being used, the ADC performs LDAP authentication to the AD.
4. If user successfully completes authentication, a one-time OAuth 2.0 token is provided to the client. If the user fails authentication, no further actions are possible.
5. If the client receives the OAuth 2.0 token post-authentication, the client provides the token to the WorkSpaces service over a TLS 1.2 tunnel.
6. The token is received by the WorkSpaces service.
7. The client receives information about the PCoIP/WSP Streaming gateway, and requests a session with the PCoIP/WSP gateway to initiate a session using the OAuth 2.0 token provided.
8. The OAuth 2.0 token is used by the PCoIP/WSP gateway to request information about the user’s WorkSpace from the WorkSpaces service. This request is again completed over a TLS 1.2 tunnel.
9. Once the gateway receives information about the user’s WorkSpace, a streaming session is initiated from the WorkSpace to the user/client via the PCoIP/WSP gateway. The streaming traffic, all pointer/keyboard interactions and USB traffic are encrypted using AES-256.

4. Physical network architecture

4.1 AWS Regions

The networking components considerations start with choosing one or more AWS regions in which the WorkSpaces instances will physically reside. Amazon WorkSpaces Design Considerations:
• Availability of Amazon WorkSpaces service in Region.
• Location of users.
• Location of data.
• Location of application servers.
• Business Processes.

4.2 Availability Zones

Depending on the chosen AWS Region, The decision is which AZs to use. Amazon WorkSpaces Design Considerations:
• Availability of the Amazon WorkSpaces service in the chosen AZs.
• Availability of any supporting AWS Services in the chosen AZs.
• Desired availability of WorkSpaces instances.

5. Logical network architecture

5.1 External connectivity: On-premises network to AWS

External connectivity from an on-premises network to AWS might not be relevant for all customers. External connectivity is available through two different approaches:
• Use a dedicated private network connection with AWS Direct Connect.
• Use a Site-to-Site VPN connection between the customer’s on-premises network and the customer’s VPC.
It is better to consider the use of dual Direct Connect connections to ensure that users frequently have a consistent end user experience.
AWS Direct Connect
AWS Direct Connect is a cloud service uses for establish a dedicated network connection from your on-premises network to AWS. There are two key components used for AWS Direct Connect:
• Connections.
• Virtual Interfaces.
There are two different models for AWS Direct Connect:
• A dedicated connection model.
• A hosted connection model.
Amazon WorkSpaces Design Considerations:
• Bandwidth.
• Latency.
• Jitter.
• User concurrency.
• Number of deployed WorkSpaces.
• Physical location of supporting services.
• Desired availability.
• Encryption.
AWS Site-to-Site VPN
To enable access to your remote network from your VPC by attaching a Virtual Private Gateway to the VPC, creating a custom route table, updating your security group rules, creating an AWS Site-to-Site VPN connection, and configuring routing to pass traffic through the connection. Amazon WorkSpaces Design Considerations:
The Direct Connect connection design considerations. Also, the following should be considered:
• Variable latency.
Direct Connect gateway
The Direct Connect gateway can be created in any public Region and access it from all other public Regions. You associate an AWS Direct Connect Gateway with either an AWS Transit Gateway or a Virtual Private Gateway (VGW) for a single VPC. When a Direct Connect gateway is used with a Direct Connect connection, it provides the ability to connect to multiple Transit Gateways that in turn connect to multiple Regions rather than being constrained to the Region where the Direct Connect connection terminates. Amazon WorkSpaces Design Considerations:
• Number of routes.
• Number of Virtual Private Gateways per AWS Direct Connect gateway.
• Number of Direct Connect dedicated connections per Region per account.
• Direct Connect gateway cannot be used to connect a VPC in the China Regions.

5.2 Internal connectivity: Within AWS

Customer connectivity within the AWS Cloud leverages a number of capabilities within the Amazon Virtual Private Cloud (Amazon VPC) service.
VPC (Virtual Private Cloud)
A VPC is allocated a range of IP addresses by each customer and the creation of a VPC for WorkSpaces must consider a number of factors. A VPC imposes some constraints:
Firstly, by default, it is not possible to broadcast IP traffic in an Amazon VPC.
Secondly, 5 VPCs can be created by default in a Region, but this limit can be increased by raising a SR with AWS through the AWS Management Console. Amazon WorkSpaces Design Considerations:
• Unique IP Address Range.
• Non-overlapping IP address range.
• Suitably sized CIDR block.
Subnets
After create a VPC and allocate a CIDR block to it, next is to create the subnets where the WorkSpaces instances will be provisioned and connected to. Subnets are created and associated with a single AZ and therefore align with the physical architecture of the WorkSpaces environment. Amazon WorkSpaces Design Considerations:
• IP Address Reservations.
• User segregation.
• Contactable Dependent Services.
• Private subnets.
• Public subnets.
Route table
A route table contains a set of rules, called routes, are used to determine where network traffic is directed. Each subnet in your VPC must be associated with a route table. The table controls the routing for the subnet. A subnet can only be associated with one route table at a time, but you can associate multiple subnets with the same route table. Amazon WorkSpaces Design Considerations:
• Essential Services Can Be Reached.
• Application Servers Can Be Reached.
• Internet Connectivity is Available (Optional).
Security groups
A security group acts as a virtual stateful firewall for your WorkSpaces instances to control inbound and outbound traffic. Different WorkSpaces instances can have the same or different SGs applied to them to enforce a differing degree of network control depending on your requirements. Security groups are useful to achieve a fine-grained level of control over WorkSpaces instances when user segregation is required for different types of user. Amazon WorkSpaces Design Considerations:
• Port Restrictions.
• IP Address Restrictions.
• Enable Specific Ports.
Network access control list
A network ACL is an optional layer of security for your VPC that acts as a stateless filter for controlling traffic in and out of one or more subnets. Amazon WorkSpaces Design Considerations:
• Coarse-Grained Control.
• Open by Default.
• Mandatory.
• One to Many.
• Stateless.
DNS
When WorkSpaces instances are launched in a VPC, a hostname is automatically created and assigned to them. These names must be resolvable via DNS in order for Kerberos authentication to work with your Active Directory. Amazon WorkSpaces Design Considerations:
• Use of existing on-premises DNS.
• Extend existing on-premises DNS into AWS.
• Use of the AWS provided DNS.
DHCP options sets
When you create a VPC, automatically create a set of DHCP options and associate them with the VPC. This set includes two options:
a. domain-name-servers=AmazonProvidedDNS.
b. domain-name=domain-name-for-your-Region.
It is an Amazon DNS server, and this option enables DNS for instances that need to communicate over the VPC's internet gateway. The string AmazonProvidedDNS maps to a DNS server running on a reserved IP address at the base of the VPC IPv4 network range, plus two. Amazon WorkSpaces Design Considerations:
• Correct Configuration of the DHCP Options Set.
• DNS Filtering.
VPC endpoints and endpoint services
Endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components that allow communication between your instances in your VPC and services without imposing availability risks or bandwidth constraints on your network traffic (Figure 6).
Traffic between your VPC and the VPC endpoints configured for AWS services do not leave the Amazon network. Amazon WorkSpaces Design Considerations:
• Use VPC endpoints where possible.
• Use the Amazon WorkSpaces AWS PrivateLink endpoint.
Elastic network interface
Each WorkSpaces instance is provisioned with two elastic network interfaces (eth0 and eth1). Amazon WorkSpaces Design Considerations:
• Ensure that sufficient elastic network interface capacity is available.
• Do not modify the elastic network interface associated with a WorkSpaces instance.
VPC peering
It is a network connection between two VPCs that enables you to route traffic between them using private IPv4 or IPv6 addresses (Figure 3). To send private IPv4 traffic from your WorkSpaces instances to instances in a peer VPC, you must add a route to the route table that is associated with your subnet in which your WorkSpaces instances reside. The owner of the peered VPC must also add a route to their subnet’s route table to direct traffic back to the WorkSpaces instances in your VPC. Blackhole state must be undertaken while a peering connection is in the pending-acceptance state. Blackhole state have no effect until the VPC peering connection is in the active state. Amazon WorkSpaces Design Considerations:
• CIDR blocks cannot overlap.
• Partial overlapping CIDR blocks cannot exist.
• Transitive routing is not possible.
• Name Resolution.
• Update Route Tables.
AWS Transit Gateway
An AWS Transit Gateway is a network transit hub that you can use to interconnect your VPCs and on-premises networks. It is acts as a regional virtual router for traffic flowing between your VPC and VPN/Direct Connect connections. An AWS Transit Gateway. AWS Transit Gateway can be employed in a multi-regional WorkSpaces design to provide network connectivity between Regions and also back to an on-premises network (Figure 6). Amazon WorkSpaces Design Considerations:
• Transitive routing through the AWS Transit Gateway is possible.

5.3 Internet connectivity

Internet connectivity can be provided to WorkSpaces in a variety of ways.
Internet gateway
An internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows for communication between instances in your VPC and the internet. An internet gateway serves two purposes:
a. To provide a target in your VPC route tables for internet-routable traffic
b. To perform NAT for instances that have been assigned public IPv4 addresses.
When determining whether to provision an internet gateway for your WorkSpaces environment it should be determined whether there is an existing on-premises proxy that must be used. In some scenarios, it may be permissible for a new proxy service to be created in AWS to prevent all internet traffic flowing back to the on-premises network. In other scenarios a proxy server may not be required at all. Amazon WorkSpaces Design Considerations:
• Will users need access to browse the internet from AWS and not via the on-premises network?
• Will operating system patches and application updates need to be obtained directly via the internet using AWS internet connectivity or will they be provided using existing on-premises infrastructure?
If one or both of the answers to these questions is true, then an internet gateway will be required.
NAT Gateway
A NAT Gateway can be used to enable instances in a private subnet to connect to the internet or other AWS service, but prevent the internet from initiating a connection with those instances. Amazon WorkSpaces Design Considerations:
• When permitted by policy, use a NAT Gateway and do not use public subnets for WorkSpaces.
• A NAT Gateway can only be deployed in a public subnet.
• Each NAT Gateway is deployed in a specific Availability Zone.
• A NAT Gateway can simplify the provisioning of internet connectivity.
• Do not “Enable Internet Access” on your WorkSpaces directory when using a NAT Gateway.

5.4 Monitoring

The monitoring of the network infrastructure that underpins your WorkSpaces environment is critical to ensure that users are not being impacted when there is a degradation of service or potential impact to end users because of the loss of a network link.
Internet access monitoring
If existing on-premises internet proxies are employed within your design, then these should be monitored for availability and response times to ensure that users have a consistent experience. If a NAT Gateway has been employed as an alternative, then the AWS NAT Gateway provides both CloudWatch Alarms and Metrics.
Connectivity monitoring
General connectivity of your WorkSpaces environment to Amazon VPC networking components can be monitored by using VPC Flow Logs. In addition, Amazon CloudWatch Alarms and AWS CloudTrail Log Monitoring is available for AWS Direct Connect and Site-to-Site VPN connections back to your on-premises environment.

6. WorkSpaces service networking controls

The WorkSpaces service also provides a native networking capability that can control access to the streaming interface (eth1) of your WorkSpaces environment from the internet.

6.1 IP access control groups

An IP access control group acts as a virtual firewall that controls the IP of which users are allowed to access their WorkSpaces. You can create up to 100 IP access control groups per AWS account and associate each IP access control group with one or more directories. However, you can only associate up to 25 IP access control groups with a single directory. Amazon WorkSpaces Design Considerations:
• All IP address ranges from where clients connect from must be known.
• PCoIP Connection Manager cannot be used.