An important area in which cloud can add value to your organization is in End-User Computing; this is because you are able to quickly and easily provision virtual desktops, streaming applications, without the need of purchasing expensive hardware and making a long-term financial commitment. There are two specific End-User Computing AWS services which we will focus on, Amazon WorkSpaces and Amazon AppStream 2.0. These services provide users access to their documents, applications, and other resources, from anywhere and anytime, as long as they, users, are on a supported device. These services both provide a pay-as-you-go model and also give you the flexibility to always have the resources running or run them when you need them.
Amazon WorkSpaces is a cloud-based virtual desktop service, which offers both Windows and Linux desktop environments. These virtual desktops can be accessed from any supported client, downloadable from AWS or your favorite mobile app store. Benefits of the service include centralized management, repeatability, and flexibility, as well as the ability to publish or install application packages, with various licensing options.
Amazon AppStream 2.0 is also an End-User Computing service, but unlike Amazon WorkSpaces, there is no need to deploy a desktop environment to grant your users access to your applications. The applications can be imported to AWS and published, made accessible via your favorite HTML5-compatible browser. There are also security benefits for using AppStream 2.0, because data is not stored on the end-user devices.
Amazon WorkSpaces Architecture
We will begin with Amazon WorkSpaces by provisioning virtual desktops via PowerShell. In order to move forward, there are certain things that we need to determine, such as the region and the operating system to use, Windows or Amazon Linux desktops are available. Once we have selected the right region and operating system, we will need to determine the right hardware resource configuration, as this will directly impact the performance of the desktop’s user experience.
Once the user experience configuration options have been identified, the next thing to determine is whether Simple AD, AD Connector, or AWS Managed Microsoft AD will be used for authentication and resource management services. Depending on the directory being used, the configuration and management options may vary.
Client Requirements
The Amazon WorkSpaces virtual desktop service is accessible via client application that is available for various supported devices.
Windows computers
Mac computers
Chromebooks
iPads
Android tables
Fire tables
Zero client devices
Chrome 53 and later
Firefox 49 and later
Managing Amazon WorkSpaces
In order to get started with launching Amazon WorkSpaces, we have to go to the WorkSpaces console to complete this task. Once the WorkSpaces service has been deployed, the management of the resources can be performed via PowerShell.
Basic Setup
- 1.
From the Amazon WorkSpaces Console, click the Get Started Now link.
- 2.
Once on the Get Started with Amazon WorkSpaces page, there will be an option for selecting either a Quick Setup or an Advanced Setup. See Figure 13-2.
- a.
IAM role, workspaces_DefaultRole, with permissions to create Elastic Network Interfaces and also list WorkSpaces directories.
- b.
Creates a VPC.
- c.
Sets up and configures Simple AD, which will be used to store user and WorkSpaces resources objects.
- d.
A service account will be created to add WorkSpaces to the directory.
- e.
Creates WorkSpace desktop environments with a public IP address.
- f.
Sends e-mail communications to the designated WorkSpaces users.
On the other hand, if the Advanced Setup is selected, you will have the flexibility to configure the setup that meets your business needs, including having the ability to determine whether to use an AD Connector, a Simple AD, or a Managed Microsoft AD domain, with or without the use of a Trusted Domain. If the latter option is selected, then you will need to make sure the VPC, subnets, and availability zones, as well as the directory components, are properly configured.
- 3.The next thing in the Quick Setup option is to select a Bundle, as shown in Figure 13-3, which is a package that is optimized for a particular use case, and comes with a set of predetermined resources (e.g., CPU and Memory) and applications (e.g., Microsoft Office).
- 4.Once a bundle is selected, the next step will allow you to create an Amazon WorkSpaces user in the Simple AD directory previously created, as well as notify the user about the availability of their WorkSpaces instance. See Figure 13-4.
- 5.
The last step is to select the Launch WorkSpaces button to launch the instance.
Connecting to Your WorkSpaces
- 1.
In the invitation e-mail, there will be instructions included to set up credentials. Follow the instructions to set up your credentials.
- 2.
Once the credentials have been set up, you will be prompted to download the client.
- 3.
After downloading and installing the WorkSpaces client, start it. At the prompt, enter the registration code included in the e-mail and select Register.
- 4.
In the sign-in prompt, enter your username and password, and click Sign In.
Advanced Setup
As previously mentioned, the Advanced Setup option offers the flexibility to be explicit on the networking and directory configurations.
Creating WorkSpaces with Microsoft AD
- 1.
To create a Microsoft AD, follow the instructions provided in Chapter 12.
- 2.Go to the WorkSpaces Console, and click the Directories link (Figure 13-5).
- 3.
The Directories list should include the list of available directories, including any directory using Microsoft AD, AD Connector, or Simple AD. Select the Microsoft AD directory to be used with WorkSpaces, then click the Actions link, and finally select the Register.
- 4.When prompted, confirm directory registration by selecting Register (Figure 13-6).
- 5.The registration will take a few minutes, wait until the registration is complete, as shown in Figure 13-7.
- 6.
Once the registration is complete, we will be able to launch WorkSpaces via PowerShell. See the next section for detailed instructions.
Creating WorkSpaces with AD Connector
- 1.
Follow the instructions provided in Chapter 12 to create an AD Connector.
- 2.Go to the WorkSpaces Console, and click the Directories link (Figure 13-8).
- 3.
The Directories list should include the list of available directories, including any directory using Microsoft AD, AD Connector, or Simple AD. Select the AD Connector to be used with WorkSpaces, then click the Actions link, and finally select the Register.
- 4.When prompted, confirm directory registration by selecting Register (Figure 13-9).
- 5.The registration will take a few minutes, wait until the registration is complete. See Figure 13-10.
- 6.
Once the registration is complete, we will be able to launch WorkSpaces via PowerShell. See the next section for detailed instructions.
Launching New WorkSpace
In order to launch a new WorkSpace, we will store required parameters for deploying a virtual desktop into variables.
Note
If there are multiple Microsoft AD directories, it would be recommended to filter for a directory ID, instead of filtering by a directory type. See the following example.
$WKSManagedAD_Id = Get-WKSWorkspaceDirectory | where-object {($_.DirectoryId -eq 'd-XXXXXXX')}
Note
Since multiple components need to be created and configured to launch a WorkSpace (e.g., ENI, security groups, etc.), the creation process may take some time.
Managing WorkSpace
Once the WorkSpace is fully launched, we can begin managing it.
Another example of modifying a workstation is changing the resources associated with the bundle that was selected during deployment. In this example, the command provided as follows can be used to change the compute type from its current value to something that better meets a customer’s business needs.
Note
WorkSpace’s properties can’t be changed within 6 hours of creation (i.e., 21,600 seconds).
Modify Compute Type
Graphics – Includes 8 vCPUs, 15GiB of Memory, 1 vGPU, 4GiB of Video Memory, and 100GB of SSD Root Volume and also User Storage
Performance – Includes 2 vCPUs, 7.5GiB of Memory, and 175GB of SSD Root Volume and 100GB of User Storage
Power – Includes 4 vCPUs, 16GiB of Memory, and 80GB of SSD Root Volume and 100GB of User Storage
Standard – Includes 2 vCPUs, 4GiB of Memory, and 80GB of SSD Root Volume and 75GB of User Storage
Value – Includes 1 vCPU, 2GiB of Memory, and 80GB of SSD Root Volume and 10GB of User Storage
WorkspaceProperties_RootVolumeSizeGib – Specifies the size of the root volume, in Gib
WorkspaceProperties_RunningMode – Sets the attribute between ALWAYS_ON and AUTO_STOP
WorkspaceProperties_RunningModeAutoStopTimeoutInMinute – Provides the ability to set the auto stop time, in 60 minutes increments
WorkspaceProperties_UserVolumeSizeGib – Sets the attribute for the user volume, in GiB
Tagging a WorkSpace
Typical administrator and end-user tasks are starting, stopping, or restarting a WorkSpace.
Starting a WorkSpace
Stopping a WorkSpace
Restarting a WorkSpace
Rebuilding a WorkSpace
Deleting a WorkSpace
Note
When a WorkSpace is deleted, all of the user data is destroyed. If data persistence is required, a backup of the user data must be performed to an external destination, such as S3.
Amazon AppStream 2.0
Imagine having the ability to run your enterprise applications, without needing to download or install any application files to your workstation. With Amazon AppStream 2.0, you have the ability to do just that. The service is a HTML5 compatible and can stream applications from AWS to any client globally, in a pay-as-you-go model. As typical with AWS managed services, it can easily scale to offer expected performance while at the same time eliminating the need to store any user or application files locally, thus increasing the security posture of your application.
Amazon AppStream 2.0 Architecture
Image – In a similar vein to the way Amazon Machine Images (AMIs) work, AppStream images contain applications that users can stream. Customers can choose to use custom images or base images provided by AWS. Images are region specific, but can be copied across regions. Also, images can’t be changed once they are created. If changes are required, a new image needs to be created. To familiarize yourself with the images available, it is recommended you review the AppStream 2.0 Base Image Version History documentation page ( https://docs.aws.amazon.com/appstream2/latest/developerguide/base-image-version-history.html ).
Image Builder – The images described earlier can be created with an Image Builder, which is a virtual machine used to install and test your applications.
Fleet – The instances streaming your application make up a Fleet, which can either be static or elastic in nature. There is a requirement to have one user per instance.
Stack – The streaming application makes up the stack, which is comprised of a fleet, access policies, and storage configurations.
User Pool – A User Pool is used to manage users and associates Stacks (i.e., streaming applications) to users.
Requirements
Amazon AppStream 2.0 has requirements for publishing applications and for accessing applications that have been published. In this section, we will discuss both sets of requirements.
Publishing Requirements
The first set of requirements for publishing applications are networking requirements, as the streaming instances and Image Builders need to be accessible, and should also be able to access network resources (e.g., databases, network shares, etc.) and the Internet. When deploying fleet instances in a VPC, it is recommended that these instances are deployed in multiple availability zones for high availability and redundancy reasons. One thing to keep in mind is that every instance in your fleet will require an Elastic Network Interface (ENI), so it is important that service limits are reviewed prior to making your application available to your users.
If the streaming application requires domain authentication or resources in a domain, the standard domain port connectivity access is required. The streaming instances must also be able to communicate with the EC2 metadata service, via http://169.254.169.254.
Note
The AppStream service uses two network interfaces, one for local VPC resource access and the Internet and the second one for management (port 8443) and streaming to client devices (port 8300). The management interface uses the IP range of 192.19.0.0/16, so it is critical to prevent conflicts with this network range.
Client Requirements
In order for client devices to connect to the AppStream 2.0 service, port 443 and port 53 are required from the client connectivity. Additionally, in order for both Session Gateway and CloudFront can be accessed correctly, domains *.amazonappstream.com and *.cloudfront.net must be whitelisted, respectively.
Getting Started with AppStream 2.0
In order to get started, we will first go to the AppStream 2.0 Console; once in the console, we will explore the two options for publishing applications. If you’re a new customer and need to get familiar with the service, a user-friendly way of starting is by using the Quick Links screen and deploying a stack with sample applications. The second deployment option and the one recommended for production environments is a deployment of a custom stack.
Deploying a Sample Applications Stack
Launching Sample Applications
- 1.
To get started with sample apps, we will click the Setup with sample apps button.
- 2.Enter Name, Display Name, Description, and optional Redirect and Feedback URLs. Click Next once all the fields have been populated. See Figure 13-15.
- 3.
On the next screen, scroll down and select the Amazon-AppStream2-Sample-Image-06-20-2017 image. Click Next.
- 4.From the Configure fleet page, select the following settings:
Instance type: General purpose – stream.standard.medium, 2 vCPUs, 4 Memory (GiB)
Fleet type: On-Demand
- User session details:
Maximum session duration: 15 minutes
Disconnect timeout: 15 minutes
- Fleet capacity:
Minimum capacity: 1
Maximum capacity: 2
Scaling details: Leave default
- 5.
On the Configure network page, select the default settings and click Next.
- 6.
From the Enable Storage page, leave the default settings and click Next.
- 7.
Click Review, to leave the defaults, on the User Settings page.
- 8.
On the Review page, click Create.
- 9.When prompted, click the check box to acknowledge the charges, and click Create. See Figure 13-16.
- 10.
From the Stacks page, select the ExampleStack stack and click Actions, then click Create streaming URL.
- 11.
For the User ID, enter a user ID, and then select an expiration to set the duration of the generated URL.
- 12.When prompted, click the Copy Link button. See Figure 13-17.
- 13.Go to your favorite HTML5-compatible browser and paste and go to the URL. The URL should render a page with the sample applications published with the package. See Figure 13-18.
Deploying Custom Applications Stack
When deploying a custom application stack, the first thing to identify is whether the applications being streamed will reside in a new or existing VPC. If the applications will interact with some existing network resources, then it will likely reside in an existing VPC.
If a new VPC is required, one can be created with the instructions provided in the VPC chapter of this book. In order to have high availability and redundancy, it is recommended that streaming instances are placed in at least two availability zones, which means that these will also need to be created in the newly created VPC. The subnets associated with the availability zones must be public, as AppStream 2.0 requires Internet access via an Internet gateway.
If you want to leverage advanced networking configuration, you can also configure the AppStream 2.0 resources to reside in a private subnet, behind a NAT gateway.
The AppStream 2.0 and Active Directory authenticated and SAML 2.0 Single Sign-On Federated implementations have so many layers, that each would require a separate chapter on their own, if covered in depth. For brevity, we will cover a some of the Active Directory integration options, mainly because Active Directory should be used for production implementations of the AppStream 2.0 service.
Creating Directory Configuration
When domain resources are required for the AppStream 2.0 applications, one of the required settings is to create a directory configuration, which will associate a service account with the service. The following commands will create an AppStream directory configuration. If you don’t have an Active Directory domain available, one can be created following the instructions provided in Chapter 12.
If the streaming applications will leverage Active Directory domain-based resources, it is important to ensure the connectivity between steaming instances and image builders is available and open to the directory services. This means that networking between the subnets that have both AppStream 2.0 resources and Active Directory is configured and security groups are configured to allow port connectivity.
TCP/UDP 53 – DNS
TCP/UDP 88 – Kerberos authentication
UDP 123 – NTP
TCP 135 – RPC
UDP 137–138 – Netlogon
TCP 139 – Netlogon
TCP/UDP 389 – LDAP
TCP/UDP 445 – SMB
TCP 1024–65535 – Dynamic ports for RPC
Note
The service account used in the Directory Configuration must have the following minimum permissions to the Organizational Unit (OU) within Active Directory: Create Computer Object, Change Password, Reset Password, and Write Description.
Getting Directory Config List
If you are unsure about the Directory Configurations that have been made, you can run the Get-APSDirectoryConfigList cmdlet to get the list of available configurations.
Launching an Image Builder
The first step to publishing and AppStream 2.0 application is to create an application builder, which will be used to customize an image for the custom application.
While the image builder is being created, the Status will be set to pending until the image builder is ready.
Once the $NonDomainImageBuilder is deployed, it should come online with a status set to running. Other status states include pending, snapshotting, stopping, starting, and deleting.
Starting Image Builder
Start-APSImageBuilder is for starting the image builder.
Name specifies the name of the image builder to start.
AppstreamAgentVersion is for specifying the AppStream agent version; using LATEST is recommended (optional).
Force overrides confirmation prompts to continue operation (optional).
Stopping Image Builder
Stop-APSImageBuilder is for stopping the image builder.
Name specifies the name of the image builder to stop.
Force overrides confirmation prompts to continue operation (optional).
AccessKey is for the AWS access key for the user account.
Credential AWSCredentials object instance containing access and secret key details.
ProfileLocation specifies the name and location of the ini-format credential file.
ProfileName is the user-defined name (optional).
NetworkCredential is the profile name of the SAML role profile.
SecretKey AWS secret key for the user account.
SessionToken is for the session token if the access and secret keys are used for temporary session-based credentials.
Region is for the AWS region.
EndpointURL specifies the endpoint.
Connecting to the Image Builder
Creating an AppStream 2.0 Application Catalog
To begin, click the Image Assistant icon on the desktop.
Image Builder must be used to recreate a new Image .
Note
Launch performance can be optimized by specifying the files that need to be included Pre-warm configuration file. To do this, run the following command: dir -path "C:PathFolderFileToOptimize" -Recurse -ErrorAction SilentlyContinue | %{$_.FullName} | Out-File "C:ProgramDataAmazonPhotonPrewarmPrewarmManifest.txt" -encoding UTF8 -append
Creating Images
Once the previous process is completed, the Images created using the preceding process will be listed in the Image Registry as shown in Figure 13-34. Once an image is created, the settings and configuration are permanent. If a change needs to be made, the Image Builder must be used to recreate a new Image.
Note
If an Image Builder has been deleted, a new Image Builder can be deployed using the Image that was created using the deleted Image Builder.
Images in the Image Registry can be categorized as either Private, as when once is built and published using the Image Builder; other categories include Public or Shared, with the later shared from another AWS account.
AppStream 2.0 Agent is the software running on the stream instances and is used to stream published applications. There are various versions of this software that can be installed. Ideally, the latest version should be installed; however, you can also customize the version that will be used by redeploying the Image Builder with the appropriate agent version.
Getting Image Builder List
Get-APSImageBuilderList specifies the list of a single or more Image Builders.
Name is the string name of the Image Builders to describe.
MaxResult is the max integer size of each page results.
NextToken provides string pagination options.
Tagging Image Builder List
Add-APSResourceTag is used to add or replace one or many tags.
Tag is the hashable key pair combination for a tag.
ResourceArn is to specify the Image Builder ARN.
PassThru returns passed value (optional).
Force overrides confirmation prompts to continue operation.
Getting Images List
Get-APSImageList specifies the list of a single or more Images.
Name is the string name of the Image Builders to describe.
Arn is for the ARNs of the images to describe.
Type is the type of image to describe (e.g., private, public, or shared).
MaxResult is the max integer size of each page results.
NextToken provides string pagination options.
Copying Images
Copy-APSImage is for copying an image.
DestinationImageDescription is for specifying a description of the new image.
DestinationImageName is for specifying the name of the new image.
DestinationRegion specifies a region for the new image.
SourceImageName is for specifying the source image.
Force overrides confirmation prompts to continue operation.
Note
An Image can be shared with other AWS accounts by using the AppStream 2.0 Console, selecting the image to share, and going to the Permissions tab.
Removing Images
Remove-APSImage deletes a specified image.
Name is for the image name.
Force overrides confirmation prompts to continue operation.
Creating Fleets
Always On – Instances run all the time and allow users to access their applications immediately.
On-Demand – Instances run when applications are being streamed, when idle they go to a stopped state. If stopped, there is an estimated 1–2-minute hydration time for the instances to become available.
When selecting a Fleet, it is also important to understand the Instance Families available, because the selection made will directly impact the performance of your application; the same is true for the image selected at launch. The following list summarizes the Instance Families available for selection; the selection should match the use case of your application, as well as an appropriate application image.
General Purpose – Basic use cases for common business applications
Memory Optimized – Suitable for memory intensive applications
Compute Optimized – Intended for use with compute intensive applications
Graphics Design – AMD FirePro S7150x2 GPU-optimized instances for use with DirectX, OpenGL, or OpenCL
Graphics Desktop – NVIDIA GRID K520 GPU-optimized instances for use with DirectX, OpenGL, or OpenCL
Graphics Pro – NVIDIA Tesla M60 GPU optimized for graphic applications that use DirectX, OpenGL, or OpenCL
New-APSFleet creates a fleet of streaming instances that run on a specific image.
Name sets the fleet name.
Description sets a description for the fleet.
ComputeCapacity_DesiredInstance sets the number of instances for the fleet.
DomainJoinInfo_DirectoryName is for the fully qualified domain name of the directory (e.g., example.com)(optional).
DisconnectTimeoutInSecond sets the amount of time for a session to be considered to have ended. If a user reconnects within the timeout period, then they will reconnect to the previous session. Value can be between 60 to 57,600 seconds.
DisplayName is for the display name for a fleet.
EnableDefaultInternetAccess enables or disables Internet access for a fleet.
FleetType sets the fleet as either ALWAYS_ON or ON_DEMAND.
ImageArn is for the ARN for the image to use.
ImageName is for the name of the image used to create the fleet.
InstanceType sets the instance to one of the available instance types (e.g., stream.standard.medium).
MaxUserDurationInSecond sets the max time a session can last.
DomainJoinInfo_OrganizationalUnitDistinguishedName sets the distinguished name of the Organizational Unit for the computer objects (optional).
VpcConfig_SecurityGroupId is for setting security group for a fleet.
VpcConfig_SubnetId is for the subnet where the network interfaces will be placed.
Force overrides confirmation prompts to continue operation.
Getting Fleet List
There are cases in which you will need to get a list of one or many Fleets. In order to get the list, you can run the Get-APSFleetList cmdlet or apply a filter to only get the details for one Fleet.
Starting a Fleet
Start-APSFleet starts a Fleet.
Name specifies the name of the Fleet to start.
PassThru returns the value passed to the Name parameter.
Force overrides confirmation prompts to continue operation.
Stopping a Fleet
Stop-APSFleet starts a Fleet.
Name specifies the name of the Fleet to start.
PassThru returns the value passed to the Name parameter.
Force overrides confirmation prompts to continue operation.
Creating Stacks
New-APSStack creates a stack to associate fleet, user access policies, and storage configurations.
Name sets the name of the stack.
Description sets the description of the stack.
DisplayName sets the display name for the stack.
ApplicationSettings_Enabled sets the path prefix for the S3 bucket to use for persistency of application settings.
FeedbackURL is for providing a URL where feedback can be provided (optional).
RedirectURL is for the redirect to send a user after a session ends (optional).
ApplicationSettings_SettingsGroup is for enabling or disabling persistent application settings.
StorageConnector identifies the storage connectors to enable. Connectors include Home Folders which stores persistent user data in S3, Google Drive for G suite that stores data in Google Drive, and OneDrive for Business which saves all users data in OneDrive.
UserSetting sets the actions that are enabled or disabled during streaming sessions, enabled by default. These settings include enabling a clipboard, ability to perform file transfers, and printing to a local device.
Force overrides confirmation prompts to continue operation.
Getting Stack List
If you need to get a list of Stacks configured in your account, the Get-APSStackList cmdlet can be used to get a list of all Stacks or a filter can be used to only retrieve a single Stack.
Configuring Persistent Storage
One important setting to identify, which will significantly impact user experience, is whether to have persistent storage (e.g., Home Folders) for your users. There are three options for this setting, which include Google Drive for G Suite, OneDrive for Business, and Home Folders, which is an AWS native solution.
If the latter option is selected, the data stored in the fleet’s Home Folders (i.e., C:UsersPhotonUserMy FilesHome Folder for non-domain instances or C:Users\%username%My FilesHome Folder for domain joined instances), then all files stored in this location will be automatically backed up to an S3 bucket that gets created the first time a Stack is created; bucket is in the same region as the stack. The data in transit and at rest will be encrypted, using Amazon S3-managed keys.
By detail the AppStream service creates and attaches a secure S3 bucket policy to the bucket on which persistent files will be saved. For support or security hardening purposes, bucket polices can be further customized to ensure users other than the primary user and the admins can access the files in the S3 bucket. Useful details on how to perform these actions can be found in the “Controlling Access to AppStream 2.0 with IAM Policies and Service Roles” documentation page ( https://docs.aws.amazon.com/appstream2/latest/developerguide/controlling-access.html#s3-iam-policy ).
Registering Fleet with Stack
Register-APSFleet associates a fleet with a specified stack.
StackName is to set the Stack name.
FleetName is to set the Fleet name.
PassThru returns the value passed to the StackName parameter.
Force overrides confirmation prompts to continue operation.
Granting Users Access
Once all the previous steps have been completed, including creating a Stack, users can be granted to the AppStream 2.0 service. Ways in which users can access the service include using a User Pool, Single Sign-On via SAML 2.0 federation, and the AppStream 2.0 API.
Note
AppStream 2.0 User Pool users can’t be assigned to Stacks with Fleets that are joined to Active Directory.
Adding AppStream 2.0 User Pool Users
New-APSUser creates a new user in the user pool.
AuthenticationType is to set the authentication type, which can be API, SAML, or USERPOOL.
FirstName is for the user’s first name.
LastName is for the user’s last name.
MessageAction specifies whether the welcome e-mail will be sent, resent, or suppressed. If sent, welcome e-mail has a temporary password valid for 7 days.
UserName sets the username.
Force overrides confirmation prompts to continue operation.
In this example, we will create a user for Bob in the AppStream 2.0 User Pool.
Disabling AppStream 2.0 User Pool Users
Disable-APSUser disables a user.
AuthenticationType is to set the authentication type, which can be API, SAML, or USERPOOL.
UserName specifies the user to disable.
Force overrides confirmation prompts to continue operation.
Enabling AppStream 2.0 User Pool Users
Enable-APSUser disables a user.
AuthenticationType is to set the authentication type, which can be API, SAML, or USERPOOL.
UserName specifies the user to disable.
Force overrides confirmation prompts to continue operation.
Assigning AppStream 2.0 User Pool Users to Stacks
Register-APSUserStackBatch associates a user to a specified Stack.
UserStackAssociation lists the user stack association.
Force overrides confirmation prompts to continue operation.
Exercise 13.1: Launch Custom Stack, Fleet, and Image
In this exercise, we will create an Image, launch a Fleet, create a Stack, and associate a non-domain user with an application.
Go to the AppStream 2.0 Console connect to the Image Builder and follow the instructions provided in this section to publish a streaming application and Image.
Summary
In this chapter, we saw the Amazon Desktop and Application Streaming services, which provide organizations the ability to deliver their workforce secure, centrally managed desktops and applications, at a global scale. Although we spent a lot of time learning about the AppStream Service 2.0 functionality without domain authentication, we also learned how to leverage AWS Directory Services to provide access control to these services, which can help you increase the security posture of your portfolio, by leveraging existing user credentials.
Each section also included a step-by-step walkthrough to help you get started with setting up both Amazon WorkSpaces and Amazon AppStream 2.0. The goal of the step through is to give you a jump start to begin delivering these services to customers within your organization.