AWS Workspaces Overview — Part-1
Welcome to my blog series on AWS Workspaces! In this series, I’ll be exploring the various use cases and implementation scenarios of AWS Workspaces, one step at a time. To make it easier to follow, I’ve divided the topic into multiple parts. In this first part, I’ll focus on understanding the architecture of AWS Workspaces, important design considerations, available directory options, and the choices for Multi-Factor Authentication (MFA).
Introduction:
In a simple terms, AWS workspaces is a Desktop-as-a-Service (DaaS) solution. It offers the goodness of cloud services, including simplicity, scalability, high availability, and pay-as-you-go pricing.
Architecture:
Below is the high-level AWS Workspaces Architecture diagram. At first glance, the diagram may appear overwhelming, especially if you are new to the AWS world. But don’t worry; I’ll help break it down and explain it in simpler terms.
Lets break this architecture and understand in detail;
VPC — AWS Managed
AWS Managed VPCs are not directly accessible or viewable within the customer’s AWS account. However, it’s essential to note that while you can’t see the managed VPC itself, you have visibility into the Directory Service and Workspaces components. As a customer, you won’t have visibility into the public endpoints related to these services either.
To expose these services to the customer’s VPC, AWS uses Elastic Network Interfaces (ENIs). ENIs act as a connection bridge between the AWS Managed VPC and the customer’s VPC, allowing communication while maintaining separation and security.
VPC -Customer
This is the VPC created by customer in AWS account and where directory ad workspaces are exposed through ENI. We can select which subnets the directory and workspaces should be exposed to.
Authentication/Session Gateways
The Authentication/Session Gateway is responsible for handling user authentication and managing user sessions when accessing AWS Workspaces. When an end-user logs in, the Authentication Gateway verifies user against directory services and Once the user is authenticated, the gateway establishes a secure session for them to access their virtual desktop. This session management ensures that the user’s workspace remains accessible during their active session and helps maintain session integrity and security.
If configured, the Authentication flow in AWS Workspaces can be enhanced with optional Multi-Factor Authentication (MFA) provided by a Radius instance or other third-party services using Radius integration. Additionally, you have the flexibility to configure SAML 2.0 integration with AWS Directory Services, which allows you to offload the entire authentication process.
This part of architecture uses Secure Socket Layer (SSL) with tcp protocol on port 443.
Streaming Gateways
Streaming Gateways handle the efficient delivery of audio and visual data from the AWS Workspaces to the end-user devices. When you interact with your virtual desktop, such as typing, moving the mouse, or running applications, the actions generate audio and visual data that need to be sent to your device.
Streaming Gateways use advanced compression and streaming technologies to efficiently package this data and transmit it to your device over the internet. This optimization ensures smooth and responsive user interactions with the virtual desktop, even in challenging network conditions.
This streaming services use PCoIP (PC-over-IP) or WSP (WorkSpaces Streaming Protocol) delivered over UDP (User Datagram Protocol) ports.
AWS Directory Services
AWS Workspaces leverages directory services to store and manage user information for Workspaces. See more details in supported directories section.
Architecture Conclusion
The breakdown of the architecture above should have provided you with a clear understanding of how AWS Workspaces delivers its service to end-users securely over the internet.
Supported Directories
AWS Workspaces requires a directory to store and manage user information, below are the options.
- Simple AD: This option allows you to create a directory that is compatible with Microsoft Active Directory, powered by Samba 4, and hosted on AWS. ( This Option is not supported by AWS for SAML 2.0 integration)
- AWS Managed Microsoft AD: With this option, you can create a Microsoft Active Directory that is hosted on AWS. AWS takes care of the management and maintenance of this directory
- AD Connector: You can use your existing on-premises Microsoft Active Directory. This allows users to sign into their WorkSpaces using their on-premises credentials and access resources from both their WorkSpaces and on-premises environment.
- Cross Trust: You can create a trust relationship between your AWS Managed Microsoft AD directory and your on-premises domain. This enables seamless authentication and access between the two environments. (In this scenario we
Options 3 and 4, which are AD Connector and Cross Trust, require network connectivity between AWS and the on-premises Active Directory (AD). This connectivity can be established using either AWS Direct Connect or an IPSEC VPN tunnel.
Option 3 & 4, will give organisations to extend their on-premise Active Directory to AWS cloud.
Design Considerations
Below are the some of the design consideration before deploying, its not an exhaustive list but a good starting point.
Consider evaluating if AWS Workspaces aligns with your specific requirements. Keep in mind that AWS also provides AWS AppStream, a service dedicated to application streaming over browsers. If your sole need is cloud application streaming without the full virtual desktop experience, AWS AppStream might be a more suitable option to explore.
- Directory Option Selection: Determine the appropriate directory option based on organisational security policies. Factors such as compliance requirements and user management preferences will drive this decision.
- POC and Isolated Environment: For Proof of Concept (POC) or isolated AWS sandbox environments, the most cost-effective option might be Simple AD, which provides basic Active Directory compatibility.
- AWS Account and VPC Selection: Choose the AWS account and Virtual Private Cloud (VPC) where you want to deploy Workspaces. Consider defining network zones (e.g., Dev, Test, Prod) to control access and segmentation for Workspaces.
- Workspace Volume Encryption: Evaluate the need for workspace volume encryption using AWS Key Management Service (KMS) Customer Managed Keys (CMK) to enhance data security.
- Multi-Factor Authentication (MFA): Consider enabling MFA for an extra layer of security to protect against unauthorised access.
- Workspace Bundle Selection: Select the appropriate workspace bundle that aligns with your specific requirements. AWS offers Linux, Ubuntu, Windows workspace bundles etc. with varying compute power and software configurations.
- Workspace Provision Automation: Consider automating the workspace provisioning process to streamline deployments and reduce manual overhead.
- Self-Service Permissions: Explore granting self-service permissions to users, allowing them to manage their workspaces. This empowers users while reducing administrative burden.
- Compliance and Data Governance: If your organisation operates in regulated industries, consider compliance requirements and data governance policies when designing your Workspaces environment.
- Monitoring and Performance Optimization: Set up monitoring and alerting to proactively detect and address performance bottlenecks or security issues.
- Cost consideration: Evaluate factors such as workspace bundle selection, storage usage, user count, operating hours, data transfer, directory service costs, backup and snapshot usage, region selection, network connectivity, data egress, monitoring and automation expenses, reserved instances for potential cost savings, data encryption, and support plans.
MFA Choices
As on today, AWS Workspaces does not integrate to AWS Identity Centre for workspaces (could have been a nice feature). so we have to use a directory services and none of the directory options we discussed above will give you out of the box MFA feature.
If you choose Simple AD as your workspace directory, it does not support MFA feature using Radius or SAML 2.0
There are options to achieve MFA for AWS workspaces, again below is not exhaustive list, there are different variance of these 2 options.
Using Radius Instance
To implement Multi-Factor Authentication (MFA) for AWS Workspaces, utilise either AWS Managed Microsoft Directory or AD Connector along with a RADIUS (Remote Authentication Dial-In User Service) server. T
he RADIUS server can be located on-premises, within AWS, or anywhere with connectivity to your directory. This setup enables an additional layer of security for user authentication, regardless of the RADIUS server’s location.
Using SAML 2.0 integration
This is a recently released feature from AWS, allowing you to redirect users to your Identity Provider (IDP) provider, such as Azure AD, Duo, Okta, etc., for authentication. The users are then authenticated against the Identity Provider, and upon successful authentication, they gain access to AWS Workspaces.
The architecture diagram below illustrates the components involved in setting up this process and provides a high-level overview of the authentication flow.
Conclusion:
In this first part of my AWS Workspaces blog series, we explored the architecture, design considerations, directory options, and MFA choices. Stay tuned for the next posts, where I’ll provide you through the implementation steps for integrating AWS Managed AD with AzureAD for authentication.
References
https://docs.aws.amazon.com/workspaces/latest/adminguide/amazon-workspaces.htm
