Monitoring

Using dashboards

Monitoring fleet utilization is a regular activity that can be performed through CloudWatch metrics and creating a dashboard. Alternatively, from the AppStream 2.0 console, use the Fleet Usage tab. Regularly monitor your fleet usage, as user behavior is not always predictable, and demand can exceed even first-rate upfront planning. A full listing of AppStream 2.0 metrics and dimensions for CloudWatch can be found in the AppStream 2.0 administration guide under Monitoring Resources.

Anticipating growth

Whenever there is a large jump in PendingCapacity, an auto scaling event has occurred. It is important to confirm that AvailableCapacity and PendingCapacity have an inverse relationship while new AppStream 2.0 fleet instances become available to host user sessions. Create a CloudWatch Alarm for InsufficientCapacityError for each AppStream 2.0 fleet to notify administrators to ensure automatic scaling is not falling behind demand.

If demand exceeds capacity and InsufficientCapacityError metric values are common, consider raising the minimum capacity through a Scheduled Scaling policy for the start of the work day. In addition, have a second Scheduled Scaling policy to lower the minimum capacity after the demand has been satisfied. Keep in mind that lowering the value for minimum capacity does not impact existing sessions. Lowering the minimum capacity prior to the end of the work day effectively enables scale to function as intended by lowering the value for ActualCapacity. This optimizes cost.

If demand is consistently unpredictable, use Target Tracking scaling policy to ensure that there is adequate AvailableCapacity in the AppStream 2.0 fleet to meet demand while determining usage patterns. Continue to monitor as Target Tracking uses a percentage of fleet consumption. As the total number of fleet instances grows, the total number of unused fleet instances multiplies. This can become wasteful unless the maximum capacity is set to a conservative value. Use multiple types of scaling policies (for example, Scheduled and Target Tracking) to balance reliability with cost optimization.

Monitoring user usage

Monitoring unique users, as there is a cost associated for that in the form of user fees. This user fee cost is due to Image Assistant (RDS) subscriber access licenses (SAL). Evaluating unique users can either be performed through reporting from the IdP where authentication is performed, or through usage reports.

Usage reports are stored as separate .csv files in your S3 bucket, which you can download and analyze using third-party business intelligence (BI) tools. You can analyze your usage data in AWS without downloading your reports or create reports over custom date ranges without concatenating multiple .csv files. For example, you can use Amazon Athena and Amazon QuickSight to create custom reports and visualizations of your AppStream 2.0 usage data.

Persisting application and Windows event logs

When an AppStream 2.0 instance session is complete, the instance is ended. This means all application and Windows event logs used in the session are lost. If there is a requirement to persist these application and Windows event logs, one method is to use Amazon Data Firehose to deliver them in real-time to S3 and search with Amazon OpenSearch Service (OpenSearch Service). If queries are not anticipated to be frequent, to optimize on cost, use Amazon Athena to search as opposed to running Amazon OpenSearch Service.

Auditing network and administrative activity

If not already set up, it is a best practice to configure AWS CloudTrail for the AWS account with Amazon AppStream 2.0. To audit AppStream 2.0 API calls specifically, use the filter event source with a value of appstream.amazonaws.com.

Enable VPC flow logs to audit access into customer-managed resources. VPC flow logs can be published to CloudWatch Logs to perform queries when auditing is required.

Monitoring subnet IP allocation is important as AppStream 2.0 fleets grow. Report on IP assignment by running the describe-subnets CLI to report the available IP addresses in each subnet assigned to fleets. Ensure that your organization has sufficient IP address capacity to meet the demand of all fleets running at maximum capacity.