A Bevy of AWS Announcements!!
AWS re:Invent is next week….it’s almost hard to believe I’ll be leaving in just a few days. What’s been equality hard to believe is the speed of announcements about new features/services coming from AWS just this week, including but certainly not limited to:
• Amazon Athena adds support for running SQL queries across relational, non-relational, object, and custom data sources
• Enhancements to Load Balancing – to quote Jeff Barr’s recent post on the AWS News Blog, there is a “healthy list of new features for ALB and NLB, all driven by customer requests.”
• Encrypt your Amazon DynamoDB data by using your own encryption keys
• Amazon VPC Traffic Mirroring now Supports Amazon CloudWatch Metrics
• AWS launches Tag Policies
• New Partner Integrations Available for Security Hub
When looking at these announcements, one may wonder, “What are they saving for re:Invent? What announcements will they make next week?!?!” If these announcements are simply appetizers to whet your appetite for what’s coming next week at re:Invent 2019, I can’t wait to hear what’s announced during the keynotes! In the midst of all this excitement, there have been several recent EUC related releases as well:
• Amazon WorkSpaces introduces WorkSpaces Directory APIs
• Application Auto Scaling now supports Target Tracking for AppStream 2.0 fleets
• Introducing Amazon WorkSpaces Streaming Protocol (beta)
Introducing Amazon WorkSpaces Streaming Protocol
In this post, I’d like to dig just a little further into the introduction of Amazon WorkSpaces Streaming Protocol (WSP), released just yesterday, 11-26-2019. To use language directly from AWS, WSP “is a cloud-native streaming protocol that enables a consistent user experience when accessing your WorkSpaces across global distances and unreliable networks. WSP also enables additional features such as bi-directional video.”
All EUC vendors including VMware (Blast Extreme), Citrix (HDX), and Teradici (PCoIP) have been diligently working to improve their display/streaming protocols in order to ensure a consistent, LAN-like virtual desktop experience over slow and unpredictable networks. Why? Because end user experience is king, that’s why! It doesn’t necessarily matter if you’re VDI infrastructure is easiest to install, the easiest to manage, or requires the fewest back-end servers or storage space to support. What’s has become increasingly important over the years, and is of paramount importance today, is end user experience. Gone are the days where IT could simply to the end user population, “You are going to use this and like it!” In the last few years even, we’ve seen an incredible change in how and where workers work. A single end user may connect to a VDI platform using any number of devices from any number of physical places and they expect, perhaps it’s right to even say DEMAND, a LAN-like experience from the VDI platform.
EUC vendors understand that ensuring an excellent end user experience is vital to the ongoing success of their VDI solution. Thus, a streaming protocol that is capable of automatically adapting or optimizing itself to changing network conditions to provide the best end user experience can be a key competitive advantage. As VDI protocols have progressed, an area of innovation has been enabling the support for multiple codecs inside the stream. Let me quote once again from the AWS WSP (beta) page:
“Today, streaming protocols run as applications on users’ hosted desktops. These protocols analyze the hosted desktop, network, and user’s device to select compression and decompression algorithms (codecs) that encode a rendering of the user’s desktop and transmit it as a pixel stream to the user’s device. Streaming protocols use many different codecs to deliver an interactive experience, because codecs are optimized for different scenarios. For example, some codecs are better at showing motion than displaying text, and others are better over low-bandwidth networks.”
A virtual desktop is a dynamic environment. Take a Windows-based desktop for instance….there will likely be multiple applications running concurrently. A user could be working with Word on one application window while watching an AWS re:Invent session via YouTube in Chrome in another. Now, in writing on the importance of codecs, I pray you forgive this simplification for easy explanation purposes but if a single “text” codec was available to the virtual desktop, Word may perform great, but Chrome would likely be sluggish. Conversely, if a single “video” codec were available, the user may not see a problem with Word or Chrome initially but the streaming protocol would use more bandwidth than is necessary to support the text portion of the display. The most likely outcome for this virtual desktop would be a performance decrease as additional applications were launched or network latency increased. Neither outcome will have a positive effect on the end user experience.
Herein lies the beauty of WSP for AWS WorkSpaces, again quoting from the AWS WSP (beta) page:
“WSP decouples the streaming protocol from the WorkSpace by offloading metric analysis, codec selection, and encoding to microservices that run natively on AWS. This lets WSP apply a better understanding of each user’s session that adapts its industry-standard and purpose-built codecs in real-time to provide a consistent user experience across challenging network conditions.
Each user’s session starts by reporting metrics on the user’s device and network conditions. There metrics are analyzed with the actions taken on the user’s WorkSpace to select the appropriate codecs. WSP processes the codecs to compress and transmit a pixel stream of the WorkSpace down to the user’s device. WSP then reports the performance of the pixel stream, network conditions, and user’s device back to WSP to maintain consistent performance across the user’s session.”
With WSP, AWS has brought WorkSpaces a cloud-native and highly adaptable streaming protocol to maximize the user experience by ensuring optimal performance no matter the underlying network connectivity.
Points to Consider from the FAQs When Testing WSP
- WSP is available today in the following regions:
- US East (N. Virginia)
- US West (Oregon)
- EU (Ireland)
- Asia Pacific (Tokyo)
- AWS recommends setting up WSP users in a separate directory for the duration of the beta for two reasons. First, as its name indicates, WSP is currently beta meaning it is to be used for internal testing only, not for production workloads. Once the beta period concludes, you’ll likely need to terminate existing WSP-based WorkSpaces so keep that in mind. Second, though a single directory CAN have a mix of both PCoIP and WSP-based WorkSpace users, a single user CANNOT have a PCoIP and a WSP WorkSpace in the same directory.
- During the WSP beta period, there will be weekly maintenance during which all participants will be upgraded to the latest version of the beta. The maintenance tasks will require a reboot of the WSP beta WorkSpace. Additionally, at the next log in, the WSP client will prompt the end user to install an update. The user will not be able to login to their WSP-based WorkSpace until the upgrades are complete. The maintenance windows for the currently supported regions are as follows:
- US East: Wednesdays – 8PM EST
- US West: Wednesdays – 5PM PST
- EU (Ireland): Wednesdays – 10PM GMT
- Asia Pacific (Tokyo): Thursdays – 4AM JST
- To access WSP WorkSpaces, UDP and TCP port 4172 must be open. If you are using PCoIP WorkSpaces today, this probably allowed already. However, there are WSP gateway servers with public IPs to facilitate WSP connectivity and your security policy may dictate that you whitelist the WSP gateway servers to allow connectivity. If that is the case, the public IP ranges for the WSP gateway servers are displayed below:
- US East: 3.227.4.0/22
- US West: 34.223.96.0/22
- EU (Ireland): 3.248.176.0/22
- Asia Pacific (Tokyo): 3.114.164.0/22
- Once a WorkSpace has been created, the streaming protocol (PCoIP or WSP) cannot be changed
Creating and Connecting to a WSP-Beta WorkSpace
1. The process to deploy a WSP-Beta WorkSpace is really no different than deploying a standard WorkSpace. The only requirement is that you select a WSP-Beta bundle, as shown below, when proceeding through the Launch WorkSpaces process. As a tidbit, I enabled encryption of my root and user volumes and the desktop was available within 22 minutes.
2. Download and install the WSP Windows Client (beta). The client can be downloaded from the AWS WSP (beta) page and like the deployment of the WorkSpace itself, there is no difference in deploying this client as opposed to the “regular” client. Once the installation completed, I was NOT prompted to reboot. Also, the Beta client allows you to connect to either WSP or PCoIP, so you need not worry about this client affecting your ability to connect to PCoIP WorkSpaces.
3. This client does provide a new Network button in the upper-right hand corner. Clicking it will provide basic network information as shown below:
4. Once logged into to your WSP WorkSpace, you’ll see a second button in the upper-right hand corner (highlighted below). This button allows you to select on which device to use your webcam. For the second screenshot, I enabled my webcam on the WorkSpace and launched a Webex meeting….the camera window came right up.
Final Thoughts…for now
To date, AWS has proven itself as an innovator with its seemingly unending service and feature updates. Like other EUC vendors, AWS must continue to innovate within WorkSpaces to ensure its relevance as a viable VDI platform. WSP, in my opinion, proves that AWS understands that an excellent end user experience is vital to the success of WorkSpaces and it will be interesting to see how AWS continues to innovate within the EUC space.
Oh, and Happy Thanksgiving everyone!
Very interesting – I am experimenting with Workspaces and Dell PCoIP thin clients (ThinOS).
Have you heard anything about Dell or other vendors developing support for that new streaming protocol by any chance? Thank you.
Hey Ted, I personally have not heard anything specifically but at re:Invent this week this question was asked and a standard “we’re working with vendors” answer was given. Thus I’d say yes, that AWS is working with vendors to get the protocol supported by the time AWS ends the Beta program.
I like the way you explain stuff. Very helpful!
Any word on when the streaming protocol will support Windows Server 2019? We are anxiously awaiting this and trying to decide if we should dive in now or wait. Any thoughts or insight would be greatly appreciated!