Amazon AppStream 2.0 – Increase Size of the Application Settings VHD

When we enable application settings persistence, the users’ Windows settings and application customizations are to a VHD file and is stored in a S3 bucket the same account we created the AppStream 2.0 stack. For every AWS Region, AppStream 2.0 creates a bucket in that account that is unique to the account and the Region. All application settings configured by the users are stored in the bucket for that Region.

There are no special configuration tasks needed to manage these S3 buckets as they are fully managed by the AppStream 2.0 service. The VHD file that is stored in each bucket is encrypted in transit using S3’s SSL endpoints and at rest using AWS Managed keys.

The buckets are named in a specific format:


The path for the folder where the settings VHD is stored in the S3 bucket uses the following structure:

  • bucket-name = Name of the S3 bucket in which users’ application settings are stored
  • prefix = Windows version-specific prefix. Example v6 for Server-2016, Server-2019
  • settings-group = The settings group value from when we create the stack
  • access-mode = Identity method of the user
    • custom for the AppStream 2.0 API or CLI
    • federated for SAML
    • userpool for user pool users
  • user-id-SHA-256-hash = The user-specific folder name. Created using a SHA-256 hash hexadecimal string generated from the user ID

I use Notepad++ to determine the SHA-256 hash for a given user. When you have more than 1 user(😁) you’ll need to determine the user’s folder and this is an extra step that you need to go through.

To determine a user’s SHA-256 Hash using Notepad++:

  1. Click on Tools and SHA-256
  2. Click Generate

I leave the Treat each line as a separate string checked when I add multiple users. For a domain user, make sure the type the user ID in the UPN format,

Note: This is case-sensitive. See screenshot for example.

The default VHD maximum size is 1 GB. There will be scenarios where the user requires additional space for application settings, we can download the users’ VHD to a Windows computer to expand it. Then, replace the current VHD in the S3 bucket with the expanded one.

Note: Don’t do this when the user has an active streaming session.

I have the TestUser01’s VHD that I’m going to download, expand and upload back to the S3 bucket.

  1. Locate and select the folder that contains the VHD
    • I used the SHA-256 hash generated earlier, copied it from Notepad++ to my clipboard and while in the S3 folder, I did a search or browser’s ctrl+f also works
  2. Download the Profile.vhdx file to a directory onto a Windows computer
    • Do not close the browser after the download completes
      • Easier to use the same session to upload the file back
  1. Open the command prompt as an administrator, and diskpart
  2. Type the following commands to select the vhd file and expand it
    • I’ve stored the VHDX file in C:\tmp\VHDs
select vdisk file="C:\tmp\VHDs\profile.vhdx"
expand vdisk maximum=2000
  1. Type the following Diskpart commands to find and attach the VHD, and display the list of volumes:
select vdisk file="C:\tmp\VHDs\profile.vhdx"
attach vdisk
list volume

The volume gets mounted as a drive and as you may notice, it is easier to determine the VHD with the volume label.

  1. Type the following command:
    • Corresponds to the number in the list volume output
    • In my case Volume 7
select volume ##
  1. Type the following command:
  1. To confirm that the size of the partition on the VHD increased as expected
select vdisk file="C:\tmp\VHDs\profile.vhdx"
list volume
  1. To detach the VHD so that it can be uploaded
detach vdisk
  1. Return to the browser with the Amazon S3 console, choose Upload, Add files, and then select the enlarged VHD in file explorer
  2. Click Upload

The page shows upload progress,

Next time the user starts a streaming session from a fleet on which application settings persistence is enabled with the applicable settings group, the larger application settings VHD is available.

Kind of a related note that I learned while working with application settings persistence is, disabling application settings persistence or deleting the stack does not delete any VHDs stored in the S3 bucket. These VHDs must be deleted manually from the Amazon S3 console or API.

Hope you found this post useful in increasing the size of the application settings VHD in AppStream 2.0.

Thank you for stopping by.✌

AWS – AppStream 2.0 Implementation Guide – Part II – Updated

This is a continuation of my earlier post here – AWS – AppStream 2.0 Implementation Guide – Part I – Updated

In this post, I’ll cover the steps that come in after creating an image in AppStream 2.0.

Provision a fleet

A fleet defines the streaming instances which is the underlying hardware, network, Active Directory (if applicable), and scaling configuration for the application streaming infrastructure we are going to deploy.

To create a fleet:

  1. Login to AppStream 2.0 console (
  2. In the left navigation pane, choose Fleets, Create Fleet
Create Fleet
  1. In Step 1: Provide Fleet Details, fill the below information and choose Next
    • Name = Unique name identifier for the fleet
    • Display Name = A friendly name displayed in the console
    • Description = An optional description for the fleet
    • Tags = Provide necessary tags
Step 1: Provide Fleet Details
  1. In Step 2: Choose an image, I’m picking the image I created in my earlier post. I filter it by Private to make it easier. and then choose Next
Choose an image – filter by private
  1. For Step 3: Configure fleet,
    • In Choose instance type, we define the hardware configuration for each of the instances that make up your fleet. Because I created the image by using the Graphics Design family, that instance type is already populated
    • Assuming I had picked General Purpose family while creating the image, other instance type options will also be presented
      • Instance Type = Pick the instance type. I’m picking for this exercise
      • Fleet Type details = Always-on or On-Demand. I’m picking On-Demand
        • Always-on
          • Instances run all the time, even when no users are streaming applications. When this option is selected, instances are immediately available for the next user to connect to immediately
          • All instances that are running are charged the applicable running instance fee, based on the instance type and size, even when users aren’t connected
        • On-Demand: Instances run only when users are streaming applications. Idle instances that are available for streaming are in a stopped state. When this option is selected, a user must wait for one to two minutes for an instance to start up
          • Instances are charged applicable running instance fee, based on the instance type and size, only when the instances are used for streaming sessions
          • Instances in On-Demand fleets that are not being used for streaming sessions are charged a small hourly stopped instance fee that is the same for all instance types and sizes
      • User session details = I’m sticking to the default values but in a production environment, you should determine this after discussing with your IT Security and Compliance team. Or maybe you have a organizational policy defined for this
        • Maximum session duration = how long user streaming sessions can remain active
        • Disconnect timeout = how long user streaming sessions can remain active after users are disconnected
        • Idle disconnect timeout in minutes = how long user can be idle (inactive) before they are disconnected from their streaming session
      • Fleet Capacity = For this exercise, I’m defining Minimum capacity to 1 and Maximum Capacity to 2
        • Minimum capacity = The minimum number of users who are expected to be streaming at the same time
        • Maximum capacity = The maximum number of users who are expected to be streaming at the same time
Step 3: Configure fleet
  • Stream view = I’m choosing Application
    • Application = Displays only the windows of applications opened by users
    • Desktop = Displays the standard desktop that is provided by OS
  • Scaling details (Advanced) = I’m adding 1 instance when the capacity reaches 75% and removing 1 instance when the capacity goes down to 25%
    • Specify the scaling policies that AppStream 2.0 uses to increase and decrease the capacity of your fleet
    • Remember that the size of the fleet is limited by the minimum and maximum capacity we’ve specified earlier
Stream view and Scaling details (Advanced)
  • IAM role (Advanced) = I haven’t created an IAM role and I’m leaving this option as is
  1. Click Next
  1. In Step 4: Configure Network,
    • Default Internet Access = I’m leaving this option checked for this exercise
      • Important Note: You wouldn’t want this in a production environment. Depending on how your network infrastructure is configured, it is preferred either to route the traffic via a NAT gateway or through a web filtering system
    • VPC = I’ve picked the default VPC
    • Subnet 1 = The first available subnet
    • Subnet 2 = The second available subnet
    • Security group(s) = I’ve picked the default
      • This wouldn’t be recommended in a production environment. You’ll access which resources needs access to which ports and services if you have direct connect or if the resources in this VPC are connecting to resources that live on other VPCs
    • Active Directory Domain (Optional) = I don’t have an AD domain to integrate but I’m planning to cover this in a later post
  2. Click Next

  1. In Step 5: Review, Confirm the fleet configuration details. To change settings for any section, choose Edit, and make the needed changes. After you finish reviewing the configuration details, choose Create
  2. In the pricing acknowledgement dialog box, select the acknowledgement check box, and Click Create to begin provisioning your fleet with the initial set of running instances
pricing acknowledgement dialog box

Note: If an error message that you don’t have sufficient limits to create the fleet, don’t panic it’s not you, it’s them. 😁 Submit a limit increase request to the AWS Support Center.

You can check your allocated quota for AppStream of other AWS services in Service Quotas and clicking on AWS Services and searching for the service

AWS services in Service Quotas

In the AWS support center, to request quota increase,

AWS support center

If all goes well, you’ll see a success prompt that your fleet is bein created,

fleet creation success

Fleet provisioning usually takes 10 minutes to finish. While your fleet is being created and fleet instances are provisioned, the status of your fleet displays as Starting in the Fleets list. Choose the Refresh icon periodically to update the fleet status until the status is Running

fleet running

Create a stack and a streaming URL

A stack consists of a fleet, user access policies, and storage configurations. We create a stack to start streaming applications to users.

To create a stack:

  1. Login to AppStream 2.0 console (
  2. In the left navigation pane, choose Stacks, Create Stack
Create Stack
  1. In Step1: Stack Details, provide below information and Click Next
    • Name = unique name identifier for the stack
    • Display Name = name displayed in the console
    • Description = Option description text
    • Redirect URL = An optional URL redirect users at end of their streaming session
    • Fleet = Fleet we created earlier
    • Tags = Choose Add Tag and add necessary tags
    • VPC Endpoints (Advanced) = Internet. We can create a private link, which is an interface VPC endpoint, in our virtual private cloud
    • Embed AppStream 2.0 (Optional) = optional webpage option to embed AppStream session

  1. In Step 2: Enable Storage, pick an option that suits you and click Next
    • For this exercise I’m not picking any of these options
    • Persistent storage can be provided for our users by choosing on of these options
      • Home Folders = A S3 bucket is provisioned where users can save their files to their home folder and access it during application streaming sessions
      • Google Drive for G Suite = Users can link their Google Drive for G Suite account to AppStream 2.0. During application streaming sessions, they can sign in to their Google Drive account, save files to Google Drive, and access their existing files in Google Drive. Personal Gmail accounts not allowed
      • OneDrive for Business = Users can link their OneDrive for Business account to AppStream 2.0. During application streaming sessions, they can sign in to their OneDrive account, save files to OneDrive, and access their existing files in OneDrive. Personal OneDrive accounts not allowed

  1. In Step 3: User Settings, configure the following settings. When you’re done, click Review
    • For this exercise, I’m picking the most restrictive options but these will usually depend on your DLP policies. Would be a good idea to consult with your IT security and compliance team on this
      • Clipboard, file transfer, print to local device, and authentication permissions
        • Clipboard = By default, users can copy and paste data between their local device and streaming applications
        • File transfer = By default, users can upload and download files between their local device and streaming session
        • Print to local device = By default, users can print to their local device from within a streaming application
        • Password sign in for Active Directory = Users can enter their AD domain password to sign in to an AppStream 2.0 streaming instance that is joined to an AD domain
        • Smart card sign in for Active Directory = Users can use a smart card reader and smart card connected to their local computer to sign in to an AppStream 2.0 streaming instance that is joined to an AD domain
      • Application settings persistence options
        • Enable Application Settings Persistence = Users’ application customizations and Windows settings are automatically saved after each streaming session and applied during the next session. These settings are saved to an Amazon S3 bucket
        • Settings Group = The settings group determines which saved application settings are used for a streaming session from this stack. Let’s say we apply this same settings group to another stack, both stacks use the same application settings
User Settings
  1. In Step 4: Review, Confirm the stack configuration details. To change the settings for any section, choose Edit and make the necessary changes. After reviewing the configuration details, Click Create

Create a Streaming URL

To test application streaming without setting up users, we can create a temporary URL that can be pasted into a browser window.

  1. In the left navigation pane, choose Stacks
  2. For Stacks, select the stack we just created
  3. Choose Actions, Create streaming URL
Create Streaming URL
  1. In the Create streaming URL dialog box, provide User id and URL expiration, Click Get URL
    • This streaming URL is purely for testing purposes
    • In a production environment, we usually have other authentication and authorization methods to allow access to our users to the designated resources. I’ll cover the steps for enabling Federation with Azure AD Single SSO and AppStream 2.0 in an upcoming post
create test user
  1. In a browser, browse to the streaming URL. AppStream 2.0 displays an application catalog page that lists the applications that you have configured for streaming
App Catalog in browser

Here is Blender via AppStream in a browser,

Blender via AppStream in a browser

and here is Blender via the AppStream client,

Blender via AppStream client

Manage user access

AppStream 2.0 user pool is a built-in identity management feature that we can use to enable users to access their streamed applications.

Note: Like I mentioned earlier, in a production environment, we’d use SAML 2.0 to federate through AD or any other custom identity solution provider(Example: Azure AD) that supports SAML 2.0

To enable users in the user pool to open applications after they sign in to the AppStream 2.0 user portal, we must assign each user to at least one stack that contains applications. After we assign the user to a stack, AppStream 2.0 sends an optional notification email to the user with instructions about how to access the stack and a URL. The user can access the stack by using the URL until we delete the stack or unassign the user from the stack.

Add users

To add users:

  1. Login to AppStream 2.0 console (
  2. In the left navigation pane, choose User Pool, Create User

Note: Remember, along with fee on the instances, there is an Users fee charged monthly. For each end user who launches a streaming session on a fleet instance there is a fee of $4.19 for the month in which the streaming session occurred.

Create User
  1. In the Create User dialog box, provide Email, First Name & Last Name information and choose Create User
  2. The User Pool list refreshes, and the user we added is listed and enabled

Assign a stack to the user

  1. In the left navigation pane, choose User Pool, and select the user we created
  2. Choose Actions, Assign Stack
  3. In the Assign Stack dialog box, for Stack, I’ve selected the stack that I created earlier
  4. I’m leaving the Send email notification to user option selected
  5. Choose Assign Stack
  6. AppStream 2.0 sends an email to the address we specified for the user
  7. User can open the Login Page link in the notification email to login and access applications via AppStream 2.0

I’m aware this was a lengthy post but I hope this helped you out in your AppStream 2.0 deployment. As I mentioned earlier, I’ll add another post on how to enable federation with Azure AD SSO and Amazon AppStream 2.0.

If you were following along and if it is a test environment, remember to stop your fleet. Else, you’ll incur charges.

Thank you for stopping by. ✌

AWS – AppStream 2.0 Implementation Guide – Part I – Updated

Amazon AppStream 2.0 lets us easily add existing desktop applications to AWS and enable users to instantly stream them. AppStream 2.0 offers pay-as-you-go pricing, with no upfront investment and no infrastructure to maintain. Also allows us to scale instantly and given the scenario, globally to our users.

With the expanding global workforce for many organizations, AppStream provides some very useful features which are worth exploring. Windows users can easily connect to AppStream 2.0 applications using any HTML5-capable web browser or the AppStream client.

In the ever expanding work from home/anywhere model, user’s laptops may not connect to enterprise network very often and installing new applications or updating them can be an uphill battle. Updating applications and rolling out changes are easier with AppStream comparing the traditional model.

I’ll explore AppStream 2.0 implementation in the next couple blog posts. On a high level, a typical AppStream 2.0 implementation process goes like the process diagram below:

AppStream 2.0 Deployment steps

In this post, I’ll cover the what is involved in the Build AppStream 2.0 Image step,

AppStream Image creation process

Create an image builder

AppStream uses EC2 instances to stream applications to the users. To create a custom image, we need to connect to an image builder, install, configure and customize the applications for streaming and then create a image by creating a snapshot.

To create an image builder instance:

  1. Login to AppStream console (
  2. If this is the first time you are launching AppStream, ‘The AppStream 2.0 first experience page’ appears, Click Get Started and in the next screen choose skip
    • We’re just telling AWS, we’ll figure it out and we don’t need their handholding. πŸ˜‰
  3. In the navigation pane on the left, choose Images, Image Builder, Launch Image Builder
Launch Image Builder
  1. In Step 1: Choose Image window, in the list of images, select the image builder with the name Base-Image-Builder-mm-dd-yyyy, where mm-dd-yyyy represents the most recent date
    • I’m choosing Windows 2016 and an instance in Graphics design. As I’m planning to publish applications that’ll require GPU. For a full list of instances, the sizes and pricing, refer this link – Amazon AppStream 2.0 Pricing
    • If you are simply trying out AppStream to get a feel of it, General purpose instances are more than enough
  1. In Step 2: Configure Image Builder, give the instance an unique name depending on your organizational naming conventions and standards, Pick a Instance Type, Streaming Endpoint as Internet and the IAM role need not be created.
    • The VPC endpoints allows users to stream from AppStream through your VPC. This can be helpful in scenarios where you want to keep the traffic within your VPC. But By default, AppStream uses a streaming endpoint that requires the user to have access to the internet
    • The IAM role part is a much more comprehensive topic and that’s why I’m leaving it with default value
Configure Image Builder
  1. In Step 3: Network access, I’m selecting Default Internet Access, my VPC, the subnet and the default security group
    • As this is purely for testing here, I’m going through with default options but when you are rolling out this in production, you’ll probably end up creating a separate VPC and if you have services like Direct connect to connect to your on-premise, your network administrator will carve up a segment which you can use to configure
    • It is not recommended to chose Default Internet Access, here is how you can decide. If your deployment must support,
      • More than 100 concurrent users, configure a VPC with private subnets and a NAT gateway
      • Fewer than 100 concurrent users, you can configure a new or existing VPC with a public subnet (the default option does this)
    • The AD domain configuration is optional
      • It comes into play when you have AWS Direct Connect and you have a line of sight with your AD domain.
      • Also is needed when your applications need to be authenticated to your AD domain and/or your application’s backend(file shares, etc) live on-premise. More on Authentication in a later post
Configure Image Builder – Network
  1. Click Review and Launch
    • It takes around 15-20 minutes for this process to complete and displays pending in the meantime
    • The image builder instance will accumulate charges even when no one is connected. It ain’t cheap, so please keep an eye on it
    • Pricing info in this link – Amazon AppStream 2.0 Pricing

Install Applications in image builder

  1. In the left navigation pane within AppStream 2.0, choose Images, Image Builder
  2. Select the image builder instance that you created earlier
    • If the status is Stopped, select the instance, and choose Actions, Start
  3. A new browser tab opens, displaying options for logging into the image builder instance. Choose Local User, Administrator
Login to Image Builder as Administrator
  1. Once connected to Image builder, I used Firefox to download the needed software files and installed them like I would do on a server connected via RDP
Applications I installed on Image Builder Instance
  1. Once the applications are installed, we are ready for the next steps

Configure applications

I’m including this section because as we all know, custom built applications which run on-premise or applications that your organization may have customized will need certain steps to be configured or worked on by your application administrators. This where you bring them in or even in the earlier step while you install the applications.

They’ll know what the customizations are, adding xml files in certain file path, IP addresses of DB servers and so on. Let them do their thing and as an AppStream administrator, we’ll take notes. 😁

Use Image Assistant to create an image

Now that we have installed and configured the applications, we are ready to create an image. The following steps will prepare the application for streaming, optimize it for performance, and create an image:

  1. On the image builder desktop, open Image Assistant
  2. On the Add Apps tab, choose Add App
    • To add Blender, I’m navigating to the installed path and selecting the exe
  3. Chose the exe and click Open
Image Assistant – ADD APPS
  1. In the next window,
    • Name = A unique identifier for the app
    • Display name = Name of the app that is displayed to end users
    • Launch Path = Location app’s executable (Change it only if your app requires it)
    • Icon Path = Location of your app’s icon (Your organization might have certain standard on app icons, this is where you pick your icon)
    • Launch Parameters = Command line arguments that need to be passed to your app (Check with your application’s admin)
    • Working Directory = Ok to leave blank (Check with your application’s admin)
  2. Click Save
App Launch Settings
  1. Repeat the above steps for other applications you’ll need on the image
  2. Once done adding, click Next
Image Assistant – Apps
  1. On Configure Apps tab, click on Switch user
Image Assistant – CONFIGURE APPS

and select Template User in the login screen

Login as Template User
  1. As Template User, launch Image Assistant and click on the applications to make sure they open as desired. Once done, click on Switch User and then choose Administrator to login
  2. In the Administrator login, you’ll be back in the Configure Apps tab, click Save settings
    • If you need to redo any of the saved settings, you can simply delete the user’s profile and do the steps again
    • To remove user profile, open Windows System properties(cmd –> sysdm.cpl), Advanced tab, Settings under User profiles and click to select the DefaultProfileUser and click Delete
Image Assistant – CONFIGURE APPS – Save Settings
  1. On the Test tab, Click Switch User and then choose Test User to login
    • Image builder includes a test user account that enables you to test your applications by using the same policies and permissions as your users
  2. As Test User, launch Image Assistant and click on the applications to make sure they open as desired. Once done, click on Switch User and then choose Administrator to login
  3. In the Administrator login, you’ll be back in the Test tab, click Next
  4. On the Optimize tab, clicking Launch will launch each application and after the application launches, verify that it functions as expected, choose Continue
Image Assistant – OPTIMIZE
  1. On the Configure Image tab, enter the following information and click Next
    • Name = Unique name
    • Display Name = A user friendly name
    • Description = What’s included in the image and notes that’ll make sense to you and the other admins
    • Always use latest agent version = I leave this check box selected so that streaming instances launched our image always include the latest AppStream 2.0 features, performance improvements, and security updates
Image Assistant – CONFIGURE IMAGE
  1. On the Review tab, make sure you got it all correct and then choose Disconnect and Create Image
    • The remote session disconnects within a few moments. When the Lost Connectivity message appears, it is safe to close the browser tab
Image Assistant – REVIEW
  1. Return to the Amazon AppStream 2.0 console and choose Images, Image Registry
    • I set the filter to Private and shared with others to make it easier to view the image I created
    • While the image is being created,
      • the image status in the image registry of the console appears as Pending
      • we cannot connect to it
Filter images by ‘Private and shared with others’

The image creation process takes 20-30 minutes to complete.

I’ll update this post with the next steps on I’ve completed them – Link to Part II

Thank you for stopping by. ✌

Enable Federation with Azure AD SSO and Amazon AppStream 2.0

We can enable users to sign in to AppStream 2.0 by using their existing Azure AD credentials, and start streaming applications. To accomplish this, we use an IAM role and a relay state URL to configure Azure AD and enable AWS to permit users to access an AppStream 2.0 stack. The IAM role grants users the permissions to access the stack. The relay state is the stack portal to which users are forwarded after successful authentication by AWS.

In this post, I’ll go over steps on how to configure federated user access for Amazon AppStream 2.0 using Azure AD SSO for Enterprise Apps.

The below diagram illustrates the authentication flow between AppStream 2.0 and Azure AD as identity provider (IdP).

Authentication Workflow

From a user’s perspective, this above process happens seamlessly. The user starts at and is automatically redirected to an AppStream 2.0 application portal without being required to enter AWS credentials.

The setup process goes like in this diagram below,

Create an Azure AD SSO application

  1. Login to Azure AD Admin Center (
  2. Click on the Enterprise applications tab
  3. To add new application, Click New application
Enterprise applications
  1. Click Create your own application
Azure AD – New Application
  1. Provide a name for your application
    • I’ve named my application AppStream-DesignUsers
  2. Select Integrate any other application you don’t find in the gallery (Non-gallery) and click Create
Create your own application
  1. Once the application is added, from the left navigation menu, Click on Single sign-on, and choose SAML
SSO method – SAML
  1. Click Edit in the Basic SAML Configuration
Basic SAML Configuration
  1. Provide the Identifier (Entity ID) and Reply URL (Assertion Consumer Service URL), then click Save
    • Identifier (Entity ID) = URN:AMAZON:WEBSERVICES
    • Reply URL (Assertion Consumer Service URL) =
    • Sign on URL (Optional) = <leave it blank>
    • Relay State (Optional) = <leave it blank>, We will revisit this later in this post
      • The entity ID is passed during the SAML exchange
      • Azure AD requires this value to be unique for each application
      • When we add more AppStream 2.0 stacks, we can append a number to the string; for example, URN:AMAZON:WEBSERVICES1,URN:AMAZON:WEBSERVICES2
Basic SAML Configuration – Continued
  1. In the SAML Signing Certificate section, click Download next to the Federation Metadata XML and save the .xml file to your computer
Download Federation Metadata XML

Create the SAML identity provider

Now, we need to create the SAML provider in AWS IAM console.

  1. In AWS console, search and open IAM
  2. In the left navigation window, click Identity providers, and the Add provider
AWS IAM – Add provider
  1. On the Configure Provider page, for the Provider Type, select SAML
  2. For Provider name, I’ve named it AzureAD-SSO
  3. Click Choose File to upload the metadata document that previously downloaded from Azure AD, and click Add provider
Configure identity provider
  1. Click on the identity provider we just created
Identity provider added
  1. Copy the value for the Provider ARN
    • The ARN is in the following format: arn:aws:iam::AccountID:saml-provider/Provider Name
Copy Identity provider ARN

Configure an IAM policy

We need to create a policy with permissions to the AppStream 2.0 stack. This way we can ensure that users have only the permission to stream applications from a specific stack.

  1. In the IAM console, choose Policies, click Create Policy
  2. In Create policy page, choose the JSON tab
  3. Copy and paste the following JSON policy into the JSON window
    • Modify the resource by entering your AWS Region Code, account ID, and stack name
      • AWS Region Code = Determine AWS region code here
      • account ID = In AWS console, click on your user name in the top right of the window and your account ID is there
      • Stack name = AppStream stack name which we want to grant access to users to
  "Version": "2012-10-17",
  "Statement": [
      "Effect": "Allow",
      "Action": "appstream:Stream",
      "Resource": "arn:aws:appstream:REGION-CODE:ACCOUNT-ID-WITHOUT-HYPHENS:stack/STACK-NAME",
      "Condition": {
          "StringEquals": {
              "appstream:userId": "${saml:sub}"           
AWS IAM – Policy
  1. In the Review policy page, provide Name, Description and click Create policy
Review and create policy
  1. You should see the following notification once the policy is created,

Create an IAM Role

In this step, we will create a role that our Azure AD users will assume when federating to AppStream 2.0

  1. In the IAM console, choose Roles, click Create role
  2. For the Trusted entity type, select SAML 2.0 federation
  3. Under SAML 2.0-based provider, choose the SAML IdP that we created earlier
  4. For the Attribute, pick SAML:aud and type
  5. Do not add any conditions and click Next
AWS IAM – Role
  1. In Add permissions, select the IAM policy we created earlier and click Next
Add permissions
  1. Provide a Role Name and Description that identifies the role, and click Create Role
  2. Once created, locate and click on the role we just created
  3. Copy the Role ARN
    • The ARN is required to configure claims rules later
    • The ARN is in the following format: arn:aws:iam::AccountID:role/Role Name
Copy role ARN

Configure the Azure AD SSO Application

Now we are ready to finish configuring the Azure AD application we started working on earlier

  1. Login to Azure AD Admin Center (
  2. Click on the Enterprise applications tab
  3. Choose the application we created earlier, from the left navigation menu, Click on Single sign-on
  4. Click Edit in the Basic SAML Configuration, Provide Relay State URL and click Save
    • Relay State = The Relay State is unique to the account, AWS Region, and AppStream 2.0 stack
    • Format is,
      • https://relay-state-region-endpoint?stack=stackname&accountId=aws-account-id-without-hyphens
    • Below table has a list of AppStream 2.0 Relay State Region Endpoints
Region Relay state endpoint
US East (N. Virginia)
US West (Oregon)
Asia Pacific (Mumbai)
Asia Pacific (Seoul)
Asia Pacific (Singapore)
Asia Pacific (Sydney)
Asia Pacific (Tokyo)
Canada (Central)
Europe (Frankfurt)
Europe (Ireland)
Europe (London)
AWS GovCloud (US-West)
AppStream 2.0 Relay State Region Endpoints
Azure AD – Add Relay State
  1. Click Edit in the Attributes & Claims section
Azure AD – Attributes & Claims
  1. In Required claim,
    • Unique User Identifier (Name ID) = Key used to identify users in the SAML assertion
    • I generally stick with user.userprincipalname
    • Usually user.mail or user.userprincipalname works
  2. Click + Add new claim and add the below claims
    • By default, Azure AD populates several SAML attributes for all new applications
    • These attributes are not needed for the federation to AppStream 2.0
    • We can remove them by choosing the three dots next to each, and choosing Delete
      • If you decide to leave them as is, it doesn’t do any harm

Name = Role
Namespace =
Source = Attribute
Source Attribute = This is the Role ARN from earlier in this post, followed by a comma and then the Provider ARN

Role attribute

Name = RoleSessionName
Namespace =
Source = Attribute
Source Attribute = We can provide any string value. I’m going with user.mail

RoleSessionName attribute

Namespace =
Source = Attribute
Source Attribute = We can provide any string value. I’m going with user.displayname

SAML_SUBJECT attribute

If the user intend to use the AppStream 2.0 client, sessions will default to a 60 minute timeout. This setting will determine the duration.

Name = SessionDuration
Namespace =
Source = Attribute
Source Attribute = Value in seconds between 900 (15 minutes) and 43200 (12 Hours). I’m going with 28800 (8 Hours)

SessionDuration attribute

Assign Azure AD groups in Application

  1. In the left navigation menu, click Users and groups, click + Add user/group
  2. In Add Assignment, click Users and groups
  3. In the Users and groups dialog box, select the Azure AD group to provide access the AppStream 2.0 stack
  4. Click Assign
Assign Group

Also click on the Properties tab in the left navigation menu to check the following,

  • Enabled for users to sign-in? = Yes
  • Assignment required? = Yes
  • Visible to users? = Yes

I also uploaded an icon file for the app to look nicer.πŸ˜‰

Test Application

With a Azure AD security group assigned to the application and the other setting configured, we’re ready to test this with a user account. I’ve already added the user account to the assigned Azure AD group. To test this,

  1. User logs into myapps portal ( with their Azure AD credentials
  2. User is presented with the AppStream stack,
User’s myapps portal view
User redirected to AppStream 2.0 app catalog

I also created a second fleet and stack, associated the fleet to the stack to demonstrate how we can assign different users to stacks. IMO, the myapps portal is a really cool feature and we can it to present AppStream to our users.

As I mentioned earlier in this post, adding more stack will require adding additional Azure AD applications and assigning AD group(s) to it.

All Stacks
All Fleets

This below is a different user logging into the myapps portal ( with their Azure AD credentials and I’ve assigned the ‘DeveloperUsers-Stack-0323’ stack to them.

User’s myapps portal view

The user gets redirected to the AppStream 2.0 portal

User redirected to AppStream 2.0 app catalog

Issues you may encounter and How to fix it

Error: RoleSessionName is required in AuthnResponse (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)

Fix: I encountered this error with the second stack I had created. When is saw this error, my obvious first step is to make sure I didn’t miss the RoleSessionName attribute in the Azure AD app I created. And it was there with the expected value.

I then decided to go back over the AWS IAM role and policy I created and realized that in the I had picked the wrong identity provider and once I picked the correct one, this issue was resolved.

RoleSessionName is required in AuthnResponse (service: AWSSecurityTokenService; status code: 400; error code: InvalidIdentityToken)

Error: Unable to authorize the session. (Error Code: INVALID_AUTH_POLICY);Status Code:401

Fix: This error message occurs when the IAM policy does not permit access to the AppStream 2.0 stack or when the stack name is not entered into the policy. Similar mess up on my part.

I had mistyped the stack’s name while creating/typing in the JSON window during the policy creation step.

Unable to authorize the session. (Error Code: INVALID_AUTH_POLICY);Status Code:401

In my experience, the SAML-tracer for Chrome and Firefox comes in handy to help identify SAML related issues. It has certainly helped me in several instances.

Hope this post helped you to setup Azure AD SSO for your AppStream 2.0 stacks.

Thank you for stopping by.✌

AWS – Enable IAM Users Billing Information access

AWS root account has access to the billing information by default and the root user can allow IAM users to access the billing information. In this post I will go through the steps on how to allow IAM users to be able to access billing information.

Below are the steps on the workflow to enable access,

When an IAM user tries to access the Billing Dashboard, this below error is displayed.

Activate access to billing data

  1. Sign in to the AWS Management Console using root account credentials
  2. On the top right of the window, choose account name, and then click Account
  3. In the IAM User and Role Access to Billing Information section, click Edit
  4. Select the Activate IAM Access check box to activate access to the Billing and Cost Management console pages
  5. Click Update

With these above steps, we have activated IAM user access.

Create IAM policies to grant permissions to billing data

  1. Open IAM console (
  2. In the left navigation menu, choose Policies and click Create Policy
  3. In the Visual editor tab, click Choose a service to get started, Select Billing
  4. In this step, I’ll show steps to create two different policies,
    • Full Access Policy
      • In Actions, Under Specify the actions allowed in Billing select the check box next to All Billing actions (aws-portal:*)
      • No need to select a resource or condition for this policy
      • Click Next:Tags to add necessary tags, click Review policy
      • On the Review page, provide name as BillingFullAccess, and then click Create policy
  • Read-only access Policy
    • In Actions, Under Specify the actions allowed in Billing select the check box next to Read
    • No need to select a resource or condition for this policy
    • Click Next:Tags to add necessary tags, click Review policy
    • On the Review page, provide name as BillingViewAccess, and then click Create policy

Create groups and attach billing policies

It is possible to attach policies directly to users or roles but it is best practice to attach polices to groups. I will create two groups and attach the policies created in the previous step.

  1. Open IAM console (
  2. In the left navigation menu, choose User groups and click Create group
  1. In this step, I’ll create the two groups and attach the policy,
    • BillingFullAccessGroup
      • In the User group name, provide name as BillingFullAccessGroup
      • Under Attach permissions policies, select BillingFullAccess policy which we created in earlier step
      • Click Create group
    • BillingViewAccessGroup
      • In the User group name, provide name as BillingViewAccessGroup
      • Under Attach permissions policies, select BillingViewAccess policy which we created in earlier step
      • Click Create group
  1. If you already have IAM users created, you can add them while creating the groups as you can see in the user group creation window. I didn’t have any users yet and I chose not to add any but that’s fairly easy step.

Test access

It is recommended to test the billing access with some test users to make sure the access works as intended.

IAM users can login to the AWS console, On the top right of the window, choose account name, and then click My Billing Dashboard to view the billing information.

Hope this post helped you set up billing access for your users.

Thank you for stopping by.✌