As part of a rebrand, AWS has consolidated its end-user computing services under a single WorkSpaces family name in an effort to consolidate complementary end-user computing capabilities into a unified Amazon WorkSpaces service. I can’t necessarily speak to any level of confusion this rebrand has resulted, but as of right now, there are 5 solutions within the WorkSpaces service family and maybe folks wonder why? I won’t dive into every service in this post, but I will focus on WorkSpaces Personal and WorkSpaces Applications.
WorkSpaces was the term I used whenever I was deploying persistent virtual desktops, that is now WorkSpaces Personal. What I used to call AppStream, is now WorkSpaces Applications. When I talk about these services, I find myself referring to these products by their old names, WorkSpaces and AppStream. Don’t be ashamed if you do the same thing! I’ve been on calls with AWS engineers and they do the same, so that makes it right, doesn’t it?
Naming etiquette aside, the core question underneath the products hasn’t changed. “We have x problem, should we use WorkSpaces Personal or WorkSpaces Applications to resolve it?” The honest answer is, of course, it depends. It depends entirely on the problem you’re trying to solve. WorkSpaces Personal and Applications are built for different situations and picking the wrong one can lead to overspending on infrastructure you don’t need and/or frustration if the service fails to resolve the problem you actually have.
Rather than walk through feature comparisons, I want to share two recent projects where each service was the clear answer. Before doing so however, here’s a summary of what each service delivers:
- WorkSpaces Personal (the standard, persistent virtual desktop offering) provisions a full persistent virtual desktop. The user gets an entire OS instance, their own files, their own installed applications, and their own session state that persists between logins.
- WorkSpaces Applications (formerly Amazon AppStream 2.0) streams applications to the user’s existing device. Though WorkSpaces Applications can be used to stream a full, non-persistent desktop as an application, in my own experience however, it has been primarily used to stream individual applications.
That distinction sounds simple, but it drives two very different sets of use cases: one is about providing a persistent virtual desktop, the other is about application delivery.
For the rest of this post, I’ll refer to WorkSpaces Applications by its more familiar name, AppStream. Old habits die hard, and it’s still the term most of us reach for day to day.
Case 1: AppStream 2.0 — Solving a Global Latency Problem
The first project involved a global organization running production operations around the clock and the around the globe and dependent on an application hosted from a single location in the US. This wasn’t a convenience application, but a critical one, needed by users on several continents, at all hours.
The existing setup had users running the application client locally on their corporate devices, connecting back to the application server over VPN. For users in the US, or reasonably close to the hosting region, this worked fine. But for users thousands of miles away, particularly across Europe and the Asia-Pacific region, the experience was far less than ideal. A locally installed client sending every request, every screen redraw, and every bit of application logic back and forth over a long-haul VPN connection meant login times of 12 to 20 minutes. That’s the time it took to get logged in and to a usable screen…now imagine queries or report generation.
For an application supporting round-the-clock production work, that’s not sustainable for productive performance. This resulted in a direct hit to operational output. Every minute a user spends waiting to log in is a minute production is compromised.
The Fix
Instead of trying to optimize the VPN path itself (more tunnels, better routing), we published the application using AppStream. Instead of shipping raw application traffic over the VPN to a locally installed client, AppStream renders the application in the same region as the application server and streams only the pixels and input events to the user.
The user’s actual round-trip distance didn’t change. What changed is what was traveling that distance. Instead of application traffic, sensitive to every bit of latency and packet loss, the connection now only had to carry a video stream and keystrokes/mouse input.
The Result
Login time for users across the globe dropped dramatically, dropping from 12–20 minutes down to just over sixty seconds.
That’s not a marginal improvement, it’s close to a 15x reduction! It turned a genuinely painful daily experience into a non-issue. For an around-the-clock production dependency, that kind of consistency matters more than almost any other metric. The application became infinitely, or at least 15x, more usable across this organizations long-haul, high-latency scenarios.
Why AppStream Was the Right Call Here (Not WorkSpaces)
It’s worth stating this wasn’t a WorkSpaces solution because the users didn’t need a full desktop. All they needed, at this time, was a single application to behave well over large geographical distances. Giving each of them a persistent full virtual desktop would have added licensing cost, patching overhead, and management complexity for a problem that was really about one app’s delivery mechanism. AppStream’s session-based, app-only model was a much tighter fit, and notably cheaper per user for this specific need.
Case 2: WorkSpaces — Solving a Logistics Problem
The second project had nothing to do with latency. We needed a solution to quickly onboard developers, many for short-term and temporary project work. Additionally, we wanted to avoid the operational overhead of procuring, imaging, shipping, and eventually reclaiming and reimaging physical laptops when the project was over.
Anyone who’s managed hardware logistics for a distributed or contract-heavy workforce knows the pain points: lead time to procure and imaging a laptop before a new hire’s start date, shipping delays, IT tickets when the wrong software is missing, and then the reverse process of getting hardware back (or writing it off) when the engagement ends. For predictable, long-term staff, that overhead is annoying but manageable. For a rotating cast of temporary developers, it becomes a real drag on onboarding speed and a real cost in idle or lost equipment.
The Fix
This is where WorkSpaces fit very well. Instead of shipping physical hardware, new developers were provisioned an Ubuntu WorkSpace which included common development tools. A new hire could be productive on day one without waiting on a laptop shipment, and when a temporary project wrapped up, the WorkSpace could simply be deprovisioned…no hardware to track down, wipe, reimage, or write off.
The Ubuntu customization mattered here too. Rather than a generic desktop image, the organization allowed developers to tailor the WorkSpace to their specific needs.
Why WorkSpaces Was the Right Call Here (Not AppStream)
This is the inverse of our first case. AppStream’s single-app streaming model didn’t map well in this case. These developers didn’t need one streamed application, they needed a full, persistent, and customizable development environment. Thus, WorkSpaces was the right tool for the job. A WorkSpaces-based solution maximized developer productivity and enabled them to “hit the ground running”. Additionally, the procurement and hardware lifecycle logistics burden for the organization was eased considerably.
The Decision Framework
Putting these two projects side by side surfaces a sharper way to think about the choice than a generic feature checklist:
- What does the user actually need? → One application / A full desktop environment
- What’s the underlying problem? → App performance/latency over distance / Hardware procurement/logistics
- How long is state expected to persist? → Session-based, little to no persistence needed / Persistent files, settings, tools across logins
- What’s driving the request? → Users are far from the app’s hosting location / Avoiding physical hardware overhead for transient staff
- Workforce pattern → Broad, possibly external user base needing one tool / Known staff (even if temporary) needing a full toolchain
The pattern worth remembering: AppStream tends to win when the problem is about how one application is delivered over distance. WorkSpaces tends to win when the problem is about avoiding physical hardware for a full desktop’s worth of needs.
Takeaway
There’s a common assumption that WorkSpaces is the default “remote desktop” answer and AppStream is a niche option for specific app streaming needs. In practice, the two projects above show why that assumption doesn’t hold up. AppStream solved a genuine, high-stakes operational problem (a 24/7 production dependency crippled by VPN latency over long-distance connections) far better than a full desktop ever would have. WorkSpaces, on the other hand, solved a completely different problem (developer onboarding without a hardware logistics chain) that AppStream isn’t built for.
The real question isn’t “which service is generally better”, it’s “what problem am I actually trying to solve: application delivery, or desktop replacement?” Get that question right, and the choice between WorkSpaces and AppStream tends to answer itself.
Have a great day everybody!