Dev, Test, Prod Separation for Amazon EUC Services
Methods for separating Dev, Test and Production workloads without over complicating, for Amazon WorkSpaces Personal, Pools and AppStream 2.0.
Richard Spaven
Amazon Employee
Published Jun 2, 2025
Release management methodologies and change testing involve the use of isolated environments that vary in degrees of separation e.g. whole separate infrastructure including the AWS Account, or a small logical separation e.g. a test machine in a test AD OU.
The objectives of separation include data leakage prevention, blast radius minimization , as well as providing a environment where changes can be made to prove production readiness as part of change management.
This blog covers the different ways EUC Workloads can be separated whilst meeting organizational objectives and minimizing complexity, and costs.
The following methods of separation will be looked at:-
- Account
- VPC
- Subnet
- Active Directory Connector
- Amazon AppStream 2.0
- Fleets
- Stacks
- Active Directory
- Forest and Domain
- Organizational Unit (OU)
- Groups
- Device Management
- Identity and Authentication
The most frequent items that change requiring a release methodology are:-
- Group Policies (GPOs)
- Application packages
- Operating system updates
- Image changes
- Network Changes
- Active Directory Changes
- Active Directory Connector Changes
- Identity and Authentication Changes
A DevOps practice for Dev, Test, Prod separation is to have a repeatable Infrastructure as Code (IaC) build that includes the automate deletion and recreation of services to ensure that there is absolute data and security segregation. For EUC Purposes, this would require not only different accounts and networks, but also copies of directories and management environments. The time and cost of this can be consumed by highly regulated industries and secure environments e.g. in banking and government. Account Separation allows RBAC separation protecting production from changes by the teams making the changes. Whilst full account separation meets governance goals, the efforts involved in automating the many elements in the cloud make account separation suitable for demanding use cases.
Account separation is recommend in the following limited scenarios:-
- Where there is a governance requirement for absolute separation of workloads
- Licensing and availability for integration points is available e.g. IDPs etc
- The skills to implement full IaC are available
VPC Separation allows absolute networking separation of environments as well as the ability to create and delete new environments as code. Separate VPCs may be required for testing the following scenarios:-
- AD domain migrations
Subnet separation is useful in the following scenarios to enable testing without impacting production devices e.g. to prevent IP address depletion, to separate instances at network layer 3.
Directory Connectors contain specific settings, which if being tested, should be done in isolation before going to production. The following configurations can be tested in a separate Directory Connector before moving to the production connector:-
- SAML 2.0 Settings
- IP Whitelist Addresses
- WorkSpaces Security Groups
- Amazon Global Accelerator Configuration
- Access Control Options
- Allowed Platforms
- IP Access Control Groups
- Maintenance Mode
- Self Service Permission
- AD Connector Account
- SAML 2.0 Configuration
- MFA Config (with Radius)
- Connect Audio Optimization
- Active Directory OU
Amazon AppStream and WorkSpaces Pools allow you to create and manage new images to be hydrated into use very quickly. The new images can contain application changes, security updates or other items that are in an image. For repeatability and consistency, Amazon AppStream 2.0 provides automation to generate new builds. Once a new image for testing is ready, then a separate Fleet and Stack are required if the test is to happen without impact to production. Other items that can be tested on a separate Fleet and Stack include:-
- Different Subnet
- Security Groups
- OU Configs e.g. GPOs
- Instance Types
- Running Mode
- Scaling rules
- Timeouts
- IAM Roles (AppStream Only)
- SAML 2.0 Integration
- Redirect URLs (AppStream Only)
- Fleet attachment
- Storage
- Setting Persistence
- Clipboard, Printing and File upload/download restrictions (AppStream Only)
- Branding
- Streaming Experience Settings (AppStream Only)
- VPC Endpoint Settings. (AppStream Only)
Active Directory provides the following logical and physical separation.
- Forest and Domain
- Organizational Unit
- Groups
- Users
Testing in a separate Active Directory Forest and or Domain is suitable for configurations that cannot be changed in isolation e.g. domain functional levels. Most organizations find maintaining configuration parity a challenge and only test in a separate domain in the rare cases it is required e.g. a functional level change.
Group Policy changes are a common occurrence and can present significant risks to organizations. Amazon WorkSpaces and AppStream 2.0 can facilitate the change management by having separate WorkSpaces Active Directory Connectors, or AppStream Fleets that places instances in a test or pilot OU. Once tested, the GPO can be linked to a production OU.
Device management testing is another topic separate to the content of this blog, however, testing the deployment of applications, updates and configurations from a device management system is a common operational activity. A common practice is to create deployment rings of devices starting with a small number of test devices and then increasing in size depending on the risk of change. Due to the persistent nature of Amazon WorkSpaces Personal, it is down to how the device management solution groups instances e.g. with SCCM Collections.
Changes to Directories, Radius and SAML 2.0 Providers require change to either the WorkSpaces Personal Directory or IAM Integration with an AppStream 2.0 stack. A misconfiguration can cause an outage. Testing can be done on a separate WorkSpaces Directory, or with AppStream a Stack and Fleet to minimize production outage risks.
Environment separation should reflect the governance requirements, risk impact and the effort to build, maintain and operate another environment along with the potential for configuration drift. IaC is desirable, however, the efforts and costs to implement need to be weighed against the need to be agile and cost optimal.
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.