Deployment Environments

The standard procedure to install the WorkSpaces Manager Appliance is as one AMI with all elements deployed via CloudFormation from the AWS Marketplace. This will deploy one EC2 instance containing all the required services for WSM to connect to AD and WorkSpace, including IIS, MS SQL Express and the .NET application.

WorkSpaces Manager requires access to an existing Active Directory Forest/Domain and can also work in a Multi-Domain and Multi-Forest scenario.

Alternative deployment scenarios may include:

1) Internal Network Load Balancer for presentation and SSL Offloading: this would take a DNS name eg “wsm.example.com” that would present the portal to users and admins. The DNS record must be resolved internally at least, and the service is not accessible through the Internet

2) External Network Load Balancer for presentation and SSL Offloading: this would take a DNS name eg. “wsm.example.com” that would present the portal to users and admins. The DNS record must be resolved externally at least, and the service is reachable through the Internet (not recommended without a proper security analysis)

3) A combination of Internal and External Network Load Balancer with different DNS resolvers or different DNS names (“wsm.example.com” and “wsm.internal.example.com”)

4) An independent MS SQL database joined or not to domain and reachable from the WSM Appliance: even that we recommend MS SQL Express, the service also runs on different versions of the Microsoft SQL Database Server, which, at the same time, can support different types of scenarios, like single availability zone or read-only replicas in a different availability zone

5) Any combination of the previous 4 scenarios, for example, dividing the 3 tiers into 3 different services: EC2, RDS and Load Balancer

Below is a diagram for the first scenario with all the tiers on the same EC2 instance without a NLB or segregated database:

If we divide the Presentation tier into a Network Load Balancer, with a SSL Certificate offload, the schematic will look as follows (please, note that the NLB can be in the private or public subnets, depending upon the requirements, but our recommendation is to place it within the private segment). This is the most common implementation we see with our clients.

Thirdly, to decouple all three tiers, we could separate the data tier into an RDS database backend, so that the EC2 instance would hold only the .NET application. Database can also be deployed in different forms, like with read-only replicas. This would be a single RDS example:

WorkSpaces Manager can also work with the Enterprise version of RDS for greater redundancy and reporting.