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
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
Auditing network and administrative activity
If not already set up, it is a best practice to configure
AWS CloudTrailappstream.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
