
Key Persistence Considerations for Choosing Between Amazon WorkSpaces and AppStream 2.0
Deciding whether a persistent or non-persistent AWS end user computing service is required to deliver a set of applications is challenging. This post walks through some of the key considerations needed to determine which AWS end user computing service to choose for a specific workload.
Mark Homer
Amazon Employee
Published Oct 25, 2024
Customers often ask what the key considerations are to choose between the End User Computing (EUC) services Amazon Web Services (AWS) offers. The EUC services have been designed with some inherently providing persistence of user settings and data using instance storage between user sessions (Persistent) and others providing persistence of user settings and data outside of instance storage (Non-Persistent).
Services within the EUC portfolio align to be either non-persistent and persistent with Amazon AppStream 2.0, WorkSpaces Pools and WorkSpaces Secure Browser being non-persistent services and Amazon WorkSpaces Personal being persistent. From an architectural perspective, a challenge arises because of this binary choice whereby a decision needs to be taken for each use case whether to use or not to use a persistent service.
This post covers some important considerations when determining if an end user application workload requires persistence by considering each of the pillars of the well architected framework.
Applications running on AWS EUC services decompose to require four basic elements to be successfully delivered. These are: the application binaries, data being accessed by the application, application configuration settings specific to the machine and lastly application configuration settings specific to the user. These can be provided in different ways, and for many applications the following holds true:
- Application binaries can be installed in an image or delivered on-demand (e.g. App-Blocks in AppStream 2.0).
- Machine configuration settings are frequently applied to the image where applications have been installed.
- User configuration settings for applications should roam with users to provide a consistent user experience.
- Data accessed or manipulated by applications can reside in a remote or local location. Applications that require their data to reside locally are the most challenging for non-persistent services.

Figure 1 shows a simplified decomposition of the 4 components of an application required for application delivery.
Applications on non-persistent services that require local application data must achieve the above result prior to launch. For non-persistent services, it is not possible to include application data and user specific configurations within the image. However, application binaries and machine configuration settings not specific to each machine can be included. Due to the need to separate these components, we must consider how we manage these over the lifespan of each non-persistent service.

Figure 2 shows how we can manage these four components across the lifespan of Amazon WorkSpaces Pools or AppStream 2.0 instances. For non-persistent services we use persistent storage for the components of the application prior to the creation and after the termination of the instance.
Now that we understand the high-level mechanisms we can use to persist data, user, and machine configuration settings between sessions, we can examine architectural considerations for non-persistence across all 6 pillars of the well architected framework.
This pillar ensures the structured and streamlined allocation of IT and compute resources. There are three aspects to consider for performance efficiency.
- Determine the applications that need to be included in the image. The applications that need to be delivered help to inform the choice of service. The number of applications and the size of the applications’ binaries in terms of disk space decide whether a third-party application delivery tool set can be used in addition to an AWS EUC service to deliver applications to instances on a Just-In-Time (JIT) basis. Note: this topic is explored in more detail in the "It’s Time to Evolve: End User Windows Application Delivery In the 2020s" whitepaper. If application binaries are large (1GB+), then they need to be included within images due to the impact on user experience that will be caused by delivering large amounts of application binaries JIT on-demand when a user logs in. A blend of applications installed in the image and a JIT tool set can provide benefits by allowing a common baseline image to be used for many use cases.
- Determine the volume of application data that needs to reside locally on the instances.Applications can use different types of local files such as local databases, and locally cached data to function. If the disk footprint of this data is large (1GB+), then the applications are unlikely to be good candidates to be delivered using a non-persistent service.Some applications can be configured to allow the data to be stored outside of the instance storage. This can be achieved using operating system capabilities such as network drives in Windows or NFS mounts in Linux to allow the data to be stored on a remote file server. If an application is still performant with this configuration, then these applications are good candidates to be delivered using a non-persistent service.
- Determine the usage pattern of the compute resources consumed by applications.Non-persistent AWS EUC services have configuration settings that influence the duration of user sessions. These either determine a maximum overall session duration or detect an idle session and then disconnect users once the disconnect timeout has been breached. Some applications are long running tasks due to the need to process large amounts of data, the need to consume large amounts of CPU or both. In these instances, users can log into an instance and leave a task running for a long period of time to allow it to complete. If the task duration exceeds the maximum session duration or results in a timeout being breached, then the use of a non-persistent service for the task is unsuitable. The maximum session durations for Amazon WorkSpaces Pools and AppStream 2.0 are described at: WorkSpaces Pools Maximum Session Duration and AppStream 2.0 Maximum Session Duration.
The operational excellence pillar includes the ability to continuously improve supporting processes and procedures to deliver business value.
Applications should be decomposed into the 4 components outlined above in Figure 1. Efficient delivery of configuration settings is essential to ensure optimum user experience. The following three areas specific to configuration settings should be explored and understood for each application.
- Determine the configuration settings that need to be available.Applications frequently require a set of configuration settings or data residing locally on the instance to operate successfully, where these are small (<200MB) and low in complexity they can be placed on an instance prior to the launch. In other cases, where there is a large volume of application settings or a large amount of data (10GB+), a persistent service should be utilized.
- Determine the location of the configuration settings.The location, complexity, and permissions for settings and data also needs to be considered. If settings are concentrated in a single file or folder or in the case of Windows a single registry value or key, then an application is typically a good candidate for a non-persistent service. Applications with a distributed footprint across a file system or Windows registry are better candidates for a persistent service.
- Determine the complexity and uniqueness of the configuration settings. Complex application settings generated by application installers unique to instances such as per user license keys, GUIDs, values based on instances' System Management BIOS (SMBIOS) data or MAC addresses for example are not good candidates to be delivered using a non-persistent service.
The cost optimization pillar includes the ability to run applications to deliver business value at the lowest price point.
Workloads that are suitable for both non-persistent and persistent EUC services are more cost efficiently delivered using a non-persistent service. This is due to the overall lower hourly cost associated with the service.
The ability to host single or multi-sessions per instance is another cost factor. Persistent services hosting multi-sessions need to be architected to persist user data and application settings outside of instances.
EUC service costs are equivalent to the capacity required to deliver the applications. Non-persistent service can scale both vertically (up and down) and horizontally (in and out) to satisfy the demands of users and their application portfolios. Delivery at the lowest cost requires instances to be rightsized. The number of instances provisioned should align with the business usage pattern. Ideally instances would always align precisely with the number of users, however, additional capacity to provide sufficient headroom should be considered to handle unexpected peaks in demand.
This section focuses on two of the pillar’s principles, "Automatically recover from failure" and "Scale horizontally to increase aggregate workload availability".
Non-persistent EUC services provide inherent fail over and recovery into an alternative instance, Availability Zone or Region through the provision of additional instances. Highly available and replicated persistent storage for user data and application configuration settings provide reliability and recoverability. Applications on instances can be quickly recovered if the data and other dependencies are available.
A persistent EUC service can benefit from the same replication as non-persistent services when failing over a Personal WorkSpace using Multi-Region Resilience. If one-way data replication has been turned on for standby WorkSpaces, then any user data stored in the user volume may be up to 12 hours old and therefore a RPO target <12 hours cannot be satisfied.
The main areas to consider from the Security pillar are explored below.
- Persistent services require instances to be a member of an Active Directory or Cloud Directory. However, non-persistent instances do not. Active Directory domain joined instances need to consider how computer objects are recycled in a pool or fleet.
- For non-persistent services not using an Active Directory, permissions management can be challenging since there is no centralized security infrastructure providing security principles to apply to instances. Consequently, baseline images must include all the security configuration due to the inability to influence the security of the image post-deployment.
- Detection within non-persistent services requires specific consideration due to the frequent termination and recycling of instances. Logging on instances should be forwarded into a centralized persistent store using event agents such as the Amazon CloudWatch agent or Amazon Kinesis Agent for Microsoft Windows. This allows security events to be recorded and analyzed over the long term. The load balancing of user sessions by the WorkSpaces Pools and AppStream 2.0 services leads to user to instance mapping changing over time. Consequently, users should not be associated with specific instances for detection purposes.
- Infrastructure protection of compute resources through ongoing vulnerability management is essential for both non-persistent and persistent services. Amazon AppStream 2.0 and WorkSpaces Pools require regular updates and patches to be applied to the golden images associated with the fleet or Pool. Operationally this provides an advantage due to the ability to apply updates to a golden image and update an entire fleet or pool at the same time.
- Data protection and specifically data classification is a key area of consideration. Customers or applications that have specific data classification requirements that mandate that all data at rest is encrypted will need to consider how non-persistent services store data. The AWS EUC services providing non-persistence (AppStream 2.0 and WorkSpaces Pools) do not provide the ability to encrypt the disk volumes on the instances whilst user sessions are active. However, as a mitigating factor it must be considered that instances do not persist beyond the maximum session duration and at the end of the session the instances are terminated with no instance data being persisted.
- The necessity to apply per user configuration settings on non-persistent instances after they have started means that any security tools or products that require a per-user application specific security configuration are more challenging to implement. Products that require a simple per user configuration setting can be implemented easily using session scripts. However, more complex configuration settings that require multiple changes can be more challenging to implement and take longer to apply at logon due to longer script run times.
- For non-persistent service, security agents that update patterns and signatures stored locally at start-up need to be configured to prevent this behavior. Rather than downloading new patterns and signatures at start-up, the golden images should be updated on a frequent basis to include the latest pattern and signature versions.
- Another consideration is application licensing. Some application vendors do not support or license the use of their software for use on non-persistent instances. In these circumstances the respective vendors should be contacted for a discussion in relation to if and how software licensing can be achieved on a non-persistent service such as Amazon AppStream 2.0 or WorkSpaces Pools.
Non-persistent AWS EUC services are more efficient in their use of compute resource over time in comparison to persistent services. This is due to persistent instances either being powered on all the time (e.g. Always-On Personal WorkSpaces) or due to them consuming disk space even when in a non-running state (e.g. AppStream 2.0 On-Demand Fleets, Auto-Stop Personal WorkSpaces). Non-persistent EUC services (e.g. Amazon WorkSpaces Pools or AppStream 2.0 Elastic Fleets) are therefore more sustainable in comparison to persistent services.
To adopt the most sustainable stance it is important that instances are rightsized. This helps to ensure that users enjoy a good user experience but also that too much compute is not being utilized to deliver the applications to users. Capacity management and the scaling of instances to align with the pattern of demand being generated by the users needing to use the service also needs to be considered. Over-provisioning of resources is wasteful from a cost and sustainability perspective.
The performance and utilization of resources by installed applications used on instances also needs be considered. Applications that have been poorly written to consume too much resource can be costly to deliver but also have a larger impact on the overall assessment of the sustainability of the end user computing service.
Comprehensive planning and testing are imperative when undertaking any type of determination as to the optimal choice of end user computing service to use for delivering a set of applications. Customers should plan to consider all elements of the applications being delivered and the users consuming them, including fail back processes for unanticipated outcomes. AWS makes this process easier by providing different end user computing services, and the ability to leverage other supporting services to optimize delivery.
For further information about how to consider the delivery of application binaries for both persistent and non-persistent end user computing workloads, see the whitepaper: It’s Time to Evolve: End User Windows Application Delivery In the 2020s.
Reach out to your AWS contact and support team if you have questions about non-persistent and persistent end user computing workloads. See our contact page for details.
Mark Homer - Mark is an AWS Go To Market Specialist based in London, UK. Mark has been working with AWS cloud computing services for over seven years and with infrastructure and end user computing for over twenty five. Mark helps customers from all industries across Europe, the Middle East and Africa on their journeys to the cloud.
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.