Key considerations for single versus multi-session fleets on Amazon AppStream 2.0

With Amazon AppStream 2.0, users securely stream their applications and/or selectively persistent desktops. As an administrator, you provide each user with their own instance for their streaming session, or share those resources and host multiple users per instance. When using well-architected principles, AppStream 2.0 multi-session fleets can help you substantially reduce costs. However, there are several key aspects you should consider when deciding on single versus multi-session fleets.

In this blog, you read about the major high-level characteristics of user density you should consider when designing your AppStream 2.0 environment. You learn which types of use cases lend themselves better to single versus multi-session fleets. You also learn how this decision impacts the cost, security, and performance of your environment.

Consideration 1: Use Case

Different use cases, usage patterns, and user personas lend themselves better to different user densities. Single-session fleets excel in hosting resource-intensive applications or mission-critical workloads that demand full system utilization, as well as workloads with unknown or unpredictable utilization. Moreover, single-session configurations accommodate applications which are incompatible with multi-user environments.

Multi-session fleets work best for predictable, extremely light, or sporadically spikey workloads, efficiently sharing resources amongst multiple users. With well understood resource consumption, you can accurately calculate how much processing power and memory each user will consume and can set the user density accordingly. Some applications require a large amount of memory to launch or run a function, and then release those resources back to the system once complete. In these cases, it is more cost effective to host several users on a single instance instead of overprovision to support those resource bursts individually.

Applications that benefit from the presence of a physical graphics processing unit (GPU), such as video conferencing and intensive web applications, are another area where the efficiencies of a multi-user environment shine. A typical back-office worker will experience increased performance simply when using Microsoft Windows with a discrete GPU available. While giving each user their own GPU-backed instance for these use cases is often cost prohibitive, they are prime scenarios for sharing GPU resources across multiple users.

Independent Software Vendors (ISVs) have unique needs, as their workloads often serve end-users belonging to different organizations. Depending on needs of their applications and users, ISVs can achieve the proper level of security and isolation in several ways. For workloads where there is no risk from users across organizations sharing resources, a multi-session fleet is cost effective. If separating users per organization is a requirement, and the application fits a multi-session use case, then hosting a multi-session fleet per customer is ideal. If the application does not fit a multi-session use case, then a single-session fleet makes the most sense.

Another dimension to consider is the type of usage patterns you expect with your user population. Having groups of users that work similar hours versus sporadic usage throughout a 24-hour day will have an impact on cost, which is covered in the following section.

Consideration 2: Cost

When comparing costs between single-session and multi-session fleets on AppStream 2.0, several factors come into play. For many administrators, the immediate thought is that by sharing host resources across several users, you drive down the costs of running your AppStream 2.0 environment. Each additional instance hosting users comes with its own resource consumption overhead, including the operating system as well as security tools and other software agents. By hosting several users on an instance, you reduce that overhead. In an ideal situation, with fully utilized hosts, this often leads to considerable cost savings over hosting a single user per instance.

One thing to consider when calculating your cost savings is to understand the usage patterns of your users. Single-session fleets offer granular scaling, allowing instance scaling to occur per concurrent user. Your fleet scales out and in based on individual users logging out and in. On the other hand, multi-session fleets can only be scaled as granular as your user density. When you add a host to support an additional user, you add a host to the fleet that is sized to host several users. Until additional users log in and consume a slot on that instance, you are effectively underutilizing the host. When users log off, you cannot scale-in and remove an instance until all the user sessions on that instance are gone. Large, multi-session hosts are most cost effective when fully populated with users. Each user slot below max capacity that is not utilized diminishes the cost effectiveness of sharing the resources.

Minimizing underutilized instances is the main reason that in the previous section, you learned that use cases with defined working hours or known usage patterns lend themselves better to multi-session fleets. If your user population is known to all log off within a similar timeframe each day, your instances will empty and can be scaled-in efficiently. If your users log out sporadically, with new users logging in at all hours, you end up with a fragmented user distribution on underutilized instances that cannot scale-in. This skews the cost savings calculation. Balancing these factors is crucial in determining the most cost-efficient configuration based on your workload characteristics and usage patterns.

Consideration 3: Security

When evaluating the security implications of single-session and multi-session configurations on AppStream 2.0, consider how user segregation and access control differ. Single-session fleets offer instance-level segregation as each user is on their own instance. This eliminates the possibility that a user with elevated or administrator level privileges on a shared instance could see what others are doing. Furthermore, each instance within your VPC has security group rules that can prevent communication between instances. This is particularly advantageous for scenarios involving ISVs or environments with highly sensitive usage requirements.

On the other hand, multi-session fleets allow users to simultaneously log into the same instance and rely on operating system (OS) level segregation for isolation. By default, users may observe artifacts or aspects of other user’s presence on the system. This includes the usernames of other users, their running processes, and data saved in shared common locations. These risks can be mitigated with a tightly locked down system that prevents users from writing to shared locations or running sensitive OS utilities. By default, AppStream 2.0 sessions have standard user permissions. However, elevated users and processes can circumvent any security policies and could access private information from other user sessions.

An OS-level approach to isolation is typically sufficient for users within a common organization or trusted environment. ISVs or those with mixed user community should carefully evaluate their setup to ensure compliance with security standards and adequately address any potential risks associated with shared resources.

Balancing these considerations is essential in selecting the appropriate fleet type and security measures to meet the specific needs and risk profiles of the environment.

Consideration 4: Performance

When evaluating between single-session and multi-session fleets, system performance is another factor to consider. In single-session setups, there is a 1:1 mapping between users and instances, ensuring that all allocated resources are exclusively available to each user. This dedicated resource allocation typically results in consistent and predictable performance for each user. Conversely, in multi-session fleets, resource sharing introduces the possibility of one user impacting the performance of another—a phenomenon referred to as the “noisy neighbor” effect. Since resources are shared amongst multiple users within a single instance, spikes in resource utilization by one user can potentially degrade the performance experienced by others.

Implementing robust monitoring tools to track resource utilization at the instance level is essential to mitigating the impacts of noisy neighbors. When using multi-session fleets, AppStream 2.0 collects performance metrics in Amazon CloudWatch. Set thresholds and alerts to detect and respond to instances experiencing unusually high resource consumption, potentially indicating a noisy neighbor situation. With third party solutions, you can proactively implement dynamic resource allocation mechanisms to redistribute resources as needed to ensure fair access for all users. Optimize system configurations and application settings to reduce resource usage and improve performance efficiency. This includes tuning application parameters and optimizing configurations to reduce the overall load on shared systems.

Consideration 5: Additional factors

While not common, some applications do not support multi-user environments for a variety of reasons. Some applications are not designed to handle concurrent access by multiple users on the same system. They may rely on local state or session-specific configurations that could conflict or interfere with each other when accessed simultaneously by different users. Some application store sensitive data in a shared location. In other cases, the application simply may not allow two instances of the same executable to run simultaneously on the system. Another factor to consider is if your application’s licensing is allowed on a multi-user system. Some software licenses may restrict the number of concurrent users per installation. Applications that are not licensed for multi-user deployment might encounter licensing violations if deployed on a multi-user desktop environment. Conversely, hosting third-party software with device-based licensing on a multi-session fleet results in a lower number of licenses required and the possibility for cost savings. As an administrator, you should test and validate your applications support for secure execution in a multi-session scenario.

From a management perspective, multi-session adds another dimension, session-density, for to manage and balance. The added benefit is a smaller fleet size with less frequent scaling required and fewer individual instances to manage and monitor.

Conclusion

In this blog, you learned several key characteristics of single versus multi-session configurations in AppStream 2.0. You explored their implications across various aspects such as use case, cost, security, and performance. Single-session fleets offer dedicated resources and granular scaling, making them suitable for ISVs and resource-intensive applications. Multi-session fleets provide efficiency benefits through resource consolidation, but introduce challenges such as the noisy neighbor effect. Additional considerations, such as security and cost-effectiveness, must be weighed when selecting the appropriate configuration for your users. Ultimately, the optimal choice depends on several factors. For additional information on multi-session fleets with Amazon AppStream 2.0, please see the relevant section in the administration guide. If you are interested in discussing how to best design and build your AppStream 2.0 environment, reach out to your account team to get in touch with an AWS End User Computing specialist.

	Justin Grego is a Senior End User Computing Specialist Solutions Architect. As part of the EUC Service Aligned SA Team, he helps enable both customers and fellow SAs get up to speed on and be successful with new AWS EUC features and services.
	Manav Verma is a Senior Product Manager for Amazon AppStream 2.0. In this role he is responsible for outlining the product’s vision and direction and ensuring that the right products, features, and services are provided to best satisfy the demands of our customers.