Announcing new larger instance types for Amazon WorkSpaces Web

This week we announced larger instance types for Amazon WorkSpaces Web, a cloud-native hosted browser service that enables users to securely access private websites and software-as-a-service (SaaS) web applications, interact with online resources, and anonymously browse the internet. These larger instance types enable customers to support more resource-intensive use cases like streaming audio or video, real-time collaboration, screen sharing, video conferencing, or processing large files. This blog reviews and discusses all available WorkSpaces Web instance types, use cases, and best practices for monitoring WorkSpaces Web portal performance to help guide instance sizing decisions.

Instance Types

Standard.regular – This is the original WorkSpaces Web instance type, appropriate for users accessing websites composed primarily of static text and images (e.g.: internal Wikis or documentation, company directories, web-based email). Common users of this instance type include customer service agents and remote users who need to access a curated list of private websites or software-as-a-service (SaaS) applications. Standard.regular instances enable you to provide users with secure access to private websites through employee owned devices, rapidly onboard new users, or to provide contractors and partners with browser-based access to private company data. Standard.regular instances are the lowest-cost instance type available.

Standard.large – This new instance type provides double the amount of memory compared to standard.regular instances. More memory can improve performance for sites that process queries from remote datasets, and offers a better user experience for use cases that require switching between numerous open tabs or browser windows. Standard.large instances are ideal for users like data scientists using web-based data science notebooks, or business users who need access to document-editing tools from employee-owned devices. This instance type can also provide an overall performance boost when compared with standard.regular instances.

Standard.xlarge – This new instance type provides twice the CPU and four times the amount of memory compared to standard.regular instances, and is ideal for use cases that support real-time video or audio streaming, where CPU performance is critical. Without enough CPU, users may observe synchronization issues with audio/video streams. Standard.xlarge instances are appropriate for contact center agents (where audio is streamed through the virtual browser) or business process outsourcing agents who scan and process files that consume multiple gigabytes of memory. Overall, standard.xlarge instances provide the best support for use cases that require low-latency audio and/or video streaming, real-time collaboration, screen sharing, and web-based virtual conferencing tools (e.g.: Zoom, Microsoft Teams, Google Meet).

Service Limit Updates

With the launch of the new instance types, we have also improved the service quota management experience. You now have an account-level concurrent user quota for each instance type, which you can divide via a self-service mechanism across multiple portals in the same region. Previously, you would need to contact support for assistance increasing the number of concurrent users per portal. See the WorkSpaces Web administrator guide for more details.

Selecting instance type

In this section, we’ll describe how to select an instance type for your portal, whether you’re starting from scratch or updating an existing portal.

Selecting instance type when creating a new portal

Using the AWS Console, select the instance size while configuring your initial portal settings.

First, for Instance type, choose the desired instance type from the drop down.

Next, enter the Maximum concurrent sessions for your web portal. This is the maximum number of users that can use the portal at the same time. The amount you set here is subtracted from your account-level maximum for this instance type. The following screen shot shows your selection compared with your remaining quota.

In the screen shot, portal creation is blocked due to setting a maximum concurrent sessions value that is greater than the remaining account level quota for this instance type . See Managing Service Quotas to increase your available concurrent sessions quota.

Changing instance type of an existing portal

To edit an existing portal, under Web portals select the portal, then choose Edit.

Next, choose Edit instance type settings.

For Instance type settings, select the instance type for your portal.

Next, enter the Maximum concurrent sessions for your web portal. This is the maximum number of users that can use the portal at the same time. The amount you set here is subtracted from your account-level maximum for this instance type. The following screen shot shows your selection compared with your remaining quota.

In the screen shot, portal creation is blocked due to setting a maximum concurrent sessions value that is greater than the remaining account level quota for this instance type . See Managing Service Quotas to increase your available concurrent sessions quota.

Monitoring performance

This section provides an overview of how to monitor instance performance with Amazon CloudWatch. However, it’s important to fully test the portal, including any private web content and any relevant workflows that could be impacted by browser policy (e.g.: file transfer, clipboard access) before distributing the URL to users. Thorough testing before deployment ensures you won’t be surprised by web content or policies behaving unexpectedly. Once you deploy, monitor feedback from users to refine portal settings.

Last month, we announced two new Amazon CloudWatch metrics for customers to use for monitoring portal performance. These metrics allow administrators to conveniently monitor performance across web portals from the CloudWatch console. They provide administrators with greater insight into the in-session experience and can be useful for selecting the appropriate instance type for your use case.

Accessing performance Metrics

To access performance metrics, visit the CloudWatch console. Select All metrics under the Metrics menu.

Select the WorkSpacesWeb tile from the Metrics section. This will lead you to all metrics for your resources.

Choose Portal metrics.

The metrics for each portal with recently active sessions are listed under Metrics.

Filter for your portal and choose the following metrics:

• GlobalCpuPercent: Displays CPU usage as a percentage of the instance type.
• GlobalMemoryPercent: Displays memory (RAM) usage as a percentage of the instance type.

The metrics aggregate data points from all the concurrent sessions currently running on your portal. Once selected, the dashboard will display all available data points. Apply a time range to the dashboard. Then, go to Graphed Metrics, and select Statistics. Set P90 for your portal metrics. In the next section, you will review this metric.

Metrics best practices

Here are some best practices for utilizing these metrics and making instance-type sizing decisions.

1. Optimizing Memory Utilization
   1. Monitor GlobalMemoryPercent for spikes above 80%.  More memory provides a smoother user experience during multi-tab or multi-window browsing, and can provide a more responsive experience on interactive websites. If you observe consistent memory usage above 80% you may need to consider sizing up to a larger instance type to provide an optimal experience.
   2. If you are running a workload that demands more memory than your instance can provide, you will observe the P90 for GlobalMemoryPercent is consistently high.
   3. Each instance has limited amount of memory. You can increase it by upgrading from standard.regular to a larger instance type.
2. Optimizing CPU Utilization
   1. Monitor GlobalCpuPercent for spikes above 70%. More compute makes web pages load faster, and improves the experience with streaming audio-video. If you observe consistent CPU utilization above 70% you may need to consider sizing up to a larger instance type to provide an optimal experience.
   2. Each instance type has limited amount of CPU. standard.xlarge instances offer the maximum compute capacity.

Example

To illustrate these best practices, we will launch a sessions on each instance type, execute the same workflow (i.e.: sign in, browse a few websites, stream some videos), and compare the CloudWatch performance metrics.

standard.regular:

The metrics show high CPU utilization on this portal, and the RAM usage was also above 70%, with a few spikes above 80%.

standard.large:

Running on standard.large, the memory consumption metric is significantly lower. With more memory available, the browser is likely to be more responsive (when compared with this workload on standard.regular). The CPU spikes and dives are still above our target.

standard.xlarge:

On a standard.xlarge instance type, the same workload is showing significant improvement with CPU utilization. This makes CPU available for other real time tasks, which contributes to a more responsive session experience, especially when working with streaming audio and video. The memory utilization metric is hovering around 20%. Standard.xlarge instances have 4x the memory as standard.regular.

Summary

In this blog we reviewed and discussed all available WorkSpaces Web instance types, use cases, and best practices for monitoring portal performance to help guide instance sizing decisions. These larger instance types enable customers to support more resource-intensive use cases like streaming audio or video, real-time collaboration, screen sharing, video conferencing, or processing large files. For new customers, you can get started by adding the Free Trial offer for WorkSpaces Web to your AWS account, visiting the Amazon WorkSpaces Web Console, and creating your first web portal. During portal creation consider the user persona and types of sites you are enabling to select the appropriate instance type, and use CloudWatch performance metrics to monitor. If you’ve already created a web portal, visit the Amazon CloudWatch console and follow the steps above to review the performance of your portal.

	Rich Burkett joined Amazon Web Services (AWS) in 2011 and joined the End User Computing team in 2017. Most recently he led Product Management for the launch of Amazon WorkSpaces Web at re:Invent in 2021. He is currently a Principal Product Manager on the AWS End User Computing team.
	Pranay Garg joined Amazon Web Services (AWS) in 2021 and is a software development engineer on the WorkSpaces Web team at AWS. He was a member of the launch team for initial service release at re:Invent in 2021, and was the tech lead for releasing larger instances. He specializes in system software and security.