Availability Zones

An Availability Zone (AZ) is one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region. Availability Zones are more highly available, fault tolerant, and scalable than traditional single or multiple data center infrastructures.

Amazon WorkSpaces Applications requires only one subnet for a fleet to launch in. The best practice is to configure a minimum of two Availability Zones, one subnet per unique Availability Zone. To optimize fleet auto scaling, use more than two Availability Zones. Scaling horizontally has the added benefit of adding IP space in subnets for growth, which is covered in the following Subnet sizing section of this document. The AWS Management Console provides for only two subnets to be specified during the creation of a fleet. Use the AWS Command Line Interface (AWS CLI) or AWS CloudFormation to allow for more than two subnet IDs.

Subnet sizing

Dedicate subnets to WorkSpaces Applications fleets to allow for flexibility in routing policies, and Network Access Control List. Stacks will likely have separate resource requirements. For example, WorkSpaces Applications Stacks can have isolation requirements giving way to separate rule sets. When several Amazon WorkSpaces Applications fleets use the same subnets, ensure the sum of all fleets’ Maximum Capacity doesn’t exceed the total number of IP addresses available.

If the maximum capacity for all fleets in the same subnet could, or has, exceeded the total number of IP addresses available, migrate fleets to dedicated subnets. This prevents automatic scaling events from exhausting allocated IP space. If the total capacity for a fleet exceeds the allocated IP space of the subnets assigned, use the API, or AWS CLI “update fleet” to assign more subnets. For more information, refer to Amazon VPC quotas, and how to increase them.

It is a best practice to scale out the number of subnets, sizing subnets accordingly while reserving capacity to grow in your VPC. Additionally, ensure that WorkSpaces Applications fleet maximums do not exceed the total IP space allocated by subnets. For every subnet in AWS, five IP addresses are reserved when calculating the total amount of IP space. Using more than two subnets and scaling horizontally offers several benefits, such as:

When sizing subnets for Amazon WorkSpaces Applications, consider the total number of subnets, and the expected peak concurrency during peak utilization. This can be monitored using (InUseCapacity) plus reserved capacity (AvailableCapacity) for a fleet. In Amazon WorkSpaces Applications, the sum of consumed and available-to-be-consumed WorkSpaces Applications fleet instances is labeled ActualCapacity. To properly size total IP space, forecast the required ActualCapacity, and divide by the number of subnets, minus one subnet for resilience, assigned to the fleet.

For example, if the anticipated maximum number of fleet instances at peak is 1000, and the business requirement is to be resilient in one Availability Zone failure, 3 x/23 subnets satisfy the technical and business requirements.

Subnet sizing example

While 2 x /22 subnets would also satisfy resiliency, consider the following:

Subnet routing

It is a best practice to create private subnets for WorkSpaces Applications instances, routing to the public internet through a centralized VPC for outbound traffic. Inbound traffic for the WorkSpaces Applications session streaming is handled through Amazon WorkSpaces Applications service via Streaming Gateways: you do not need to configure public subnets for this.

Intra-Region connectivity

For WorkSpaces Applications fleet instances joined to an Active Directory Domain, configure Active Directory Domain Controllers in a Shared Services VPC in each AWS Region. Sources for Active Directory can be either Amazon EC2-based Domain Controllers or AWS Microsoft Managed AD. Routing between the shared services and WorkSpaces Applications VPCs can be either through a VPC peering connection or a transit gateway. Although transit gateways solve the complexity of routing at scale, there are a number of reasons why VPC peering is preferable in most settings:

This is especially true if WorkSpaces Applications instances connect to application infrastructure and/or file servers with large datasets in a shared service VPC. By optimizing the path to these commonly accessed resources, VPC peering connection is preferred, even in designs where all other VPC and internet routing are performed via transit gateway.

Outbound internet traffic

While routing directly to shared services is mostly optimized through a peering connection, outbound traffic for WorkSpaces Applications can be designed by creating a single internet exit point from multiple VPCs using AWS Transit Gateway. In a multi-VPC design, it is a standard practice to have a dedicated VPC that controls all outgoing internet traffic. With this configuration, Transit Gateways have greater flexibility, and control of routing over standard routing tables attached to subnets. This design also supports transitive routing without additional complexity, and removes the need for redundant network address translation (NAT) gateways, or NAT instances in each VPC.

Once all outbound internet traffic is centralized into a singular VPC, NAT gateways or NAT instances are a common design choice. To determine which is best for your organization, view the administration guide for comparing NAT gateways and NAT instances. AWS Network Firewall can extend protection beyond security group and network access control levels by protecting at the route level and offering stateless and stateful rules from layers 3 through 7 in the OSI model. For more information, refer to Deployment models for AWS Network Firewall. If your organization has chosen a third-party product that performs advanced features such as URL filtering, deploy the service into your outbound internet VPC. This can replace NAT gateways or NAT instances. Follow the guidelines provided by the third-party vendor.

On-premises

When connectivity to on-premises resources is required, especially for WorkSpaces Applications instances joined to Active Directory, establish a highly resilient connection through AWS Direct Connect.