Streaming Applications Using AWS AppStream 2.0


Most IT engineers have tried to log in to a remote desktop and use a virtual machine for specific applications, which your laptop may not be able to run.

This often requires you to create a new AWS EC2 (Elastic Compute Cloud) instance or create an Amazon WorkSpace, if we only talk AWS. There is a simpler way to achieve a similar outcome, which is through streaming the applications. All you need is an URL.

This blog post is a deep-dive about streaming applications with the use of an AWS service, called AppStream 2.0, and how we use it at The LEGO Group. I intend to have you, as a reader, following along, so we end up streaming an application at the end.

AWS AppStream 2.0

So the basics… Amazon AppStream 2.0 (AppStream) runs your applications on virtual machines called streaming instances, which provide the GPU, CPU, memory, storage, and networking capacity you need. It is a fully managed service and has the purpose of giving users access to desktop applications from any browser or OS. You select which applications you wish to stream and provide access to your colleagues.

It sounds really simple, but is it?

The Step-By-Step Architecture

The architecture visualizes the process, we will go through when creating a streaming instance. We will begin with the ‘Image builder’ and finish with a stack that has related URL’s, which you can share with colleagues afterwards.

Step 1 — Image Builder

The first step for creating a streaming instance is to use an image builder, which is the majority of your workload. The limitation is that you can only select Windows Server (2012, 2016 or 2019) as OS.

Go into AppStream 2.0 on your AWS account and locate ‘Image’, here you will find ‘Image Builder’
Launch the image builder and filter your search by choosing the operating system ‘Windows Server 2019 Base’ and Instance Family ‘General Purpose’. Now select the ‘AppStream-WinServer2019–04–22–2020 (or whichever newest version you find). Configure the image with your default network settings. Using your default VPC and security groups will make it easier to control, so select those or create your own.

Now launch the image builder and remote desktop (connect) into it, and now the fun begins! The purpose of the image builder is to create what some call a ‘golden image’, which is where you can customize the image.

Step 2 — Image(s)

Now connect to your image builder instance from the console and locate the ‘Image Assistant’ application that will guide you through the process of adding applications. Optional: You can install and configure your applications on this image, so you can add the .exe, .bat, or .lnk file to the ‘Image Assistant’.

I have added a Firefox application to keep it simple, as it is already installed on the instance (laziness for the win!).

We have previously installed complex Planning Software and configured it with license servers across multiple VPC’s. You can install whatever software you want.

Inside the Image Assistant — Adding apps

A cool feature is that you can easily install different versions of the same software. This is what a team at The LEGO Group is currently using AppStream for, as running multiple versions or legacy software can sometimes be a pain to run on your local machine.

After adding the application to the ‘Image Assistant’, you can test how the application works by switching to a test-user. AD integration is also a possibility.

Inside the Image Assistant — Testing

If the application runs as intended, then the last step is to create a new image based on your configuration. This is similar to running an EC2 instance and creating a snapshot of the instance, which then can be used to launch a new image (AMI).

Inside the Image Assistant — Create image

Step 3 — Fleet

Creating/snapshotting the image can take some time (approx. 20–30 minutes), so time for coffee…

My new Firefox image is now available, so it is time to create a fleet. This is where you select your newly created image, so your end-users can stream your installed applications. You can also specify the minimum and maximum fleet size, which should be according to your end-users. In AWS terms, this has some similarities to EC2 auto-scaling. Remember to add an IAM role if your application needs to communicate with other AWS services.

Important note about ‘Fleet Type’: If you select ‘On-Demand’, then the streaming instance will take 1–2 minutes before running, whereas ‘Always-on’ will… you guessed it, always be on.

Step 4 — Stack

The last step is creating a stack, which is where you associate your fleet, configure storage, and user settings. It is possible to enable storage for your users, so your users can e.g. use OneDrive to access and save files into folders.

Step 5 — Time to stream!

If your stack is active, then it is time to stream an application. Do this by creating a streaming URL. AD integration is excluded in this example, so in the user ID, you can write whatever you want.

How to create a streaming URL inside the Stack

The streaming instance is now running, and I can select my installed application, Firefox, which basically runs a browser inside another browser — meta! Now you can create a new streaming URL and share it with anybody, and they will have access to the same application.

That’s it, congratulations, you are now a streamer! 😊

What your streaming URL should end up showing you

Use cases (pros)

The strong use case is obviously not to use this for Firefox, but to run other applications that can be difficult to run on a local machine. Our team has used AppStream for a legacy Planning Software, which had some pretty strict software requirements. As we are basically configuring an EC2 instance in the image builder, we can specify everything and adjust versions and dependencies accordingly.

So why not just create an EC2 instance instead?
If you have business users that cannot SSH/RDP into instances, then this works great, as they only need an URL to access the applications. Furthermore, they may not have the proper computer for running heavy applications locally. Another reason is that we have configured our Fleet, which scales accordingly to our users, so there is no need to spin up EC2 instances manually.

Admin rights and security
You may have business users that need certain applications not found in IT Toolbox, and you do not wish to give them admin rights. If you set up the application in AppStream, you will have full control regarding networking and access.

Multiple versions & legacy software
Most applications have dependencies, which can be a pain point if another application has other dependencies on other versions of the same piece of software. This is likely if you are running legacy software that requires certain packages. You can install multiple versions on the image and avoid having the dependencies installed locally on your computer.

Challenges using AppStream (cons)

If you have created an image, and it does not work as expected, when you are streaming the application, then you need to edit the applications inside the image builder again. This can be a time-consuming task, as creating a new snapshot/image takes around 20–30 minutes. Remember to use the test-user that the ‘Image Assistant’ provides since this can save you some time.

Applications with too many pop-up windows can cause a bad user experience, as you are limited to one main window, while you are streaming the application.

The experience can be a bit laggy when you try it. We have made a comparison between AppStream and EC2 when we are testing the Planning software, and the experience was the same. So, it might relate to which application you intend to run.


Overall, AWS AppStream 2.0 is a super cool service, and you can run any application whenever and wherever you want. It could be a service your team could benefit from, especially if you have business users that do not require a fully functional virtual machine, but only a few apps.

The aspect of streaming applications instead of running a complete virtual machine, adds another perspective to how we can give access to our end-users in a more controlled and shareable way.

At The LEGO Group, we have so far had success with using AWS AppStream 2.0 to solve some of these challenges — hopefully, I have now inspired ‘streamers of tomorrow’ to do the same!

By Kasper Therkildsen Søndergaard
Junior IT Engineer, The LEGO Group

About me

I am working as a Jr. IT engineer and Scrum Master at a team called Technology Incubation. Our purpose is to explore, assess, and demonstrate new technologies, which can be used within the manufacturing sphere at the LEGO group. We do our best to share and assist other teams by developing and testing new technologies, which hopefully reduces some of their workloads.