Network considerations - Best Practices for Deploying WorkSpaces

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. 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?

Amazon recommends defining user groups, or personas, based on the type of access and the user authentication you require as part of your planning process. Answers to these questions are helpful when you need to limit access to certain applications or resources. Defined user personas can help you segment and restrict access using AWS Directory Service, network access control lists, routing tables, and VPC security groups. Each AWS Directory Service construct uses two subnets and applies the same settings to all WorkSpaces that launch from that construct. For example, you can use a security group that applies to all WorkSpaces attached to an AD Connector to specify whether MFA is required, or whether an end-user can have local administrator access on their WorkSpace.


Each AD Connector connects to your existing Enterprise Microsoft AD. To take advantage of this capability and specify an Organizational Unit (OU), you must construct your Directory Service to take your user personas into consideration.