AppStream fleets should limit maximum user duration to 10 hours or less

Long-lived streaming sessions increase the exposure window when a user walks away from a workstation or credentials are compromised. AppStream sessions running for 16 hours (the default) give an attacker or a forgotten session plenty of time for lateral movement, data exfiltration, or resource abuse without triggering a re-authentication prompt.

Capping sessions at 10 hours fits a standard business day and forces periodic credential revalidation. It also cuts compute costs from idle sessions that outlast any reasonable workday.

Retrofit consideration

Reducing max_user_duration_in_seconds on an existing fleet doesn't cut off active sessions. New sessions created after the change will respect the lower limit. If users regularly run long workflows, coordinate with them before applying.

Implementation

Choose the approach that matches how you manage Terraform.

Terraform resources

Use AWS provider resources directly. See docs for the resources involved: aws_appstream_fleet.

resource "aws_appstream_fleet" "this" {
  compute_capacity {
    desired_instances = 1
  }
  disconnect_timeout_in_seconds      = 300
  fleet_type                         = "ON_DEMAND"
  idle_disconnect_timeout_in_seconds = 600
  image_name                         = "AppStream-AmazonLinux2-02-11-2025"
  instance_type                      = "stream.standard.small"
  max_user_duration_in_seconds       = 28800
  name                               = "pofix-abc123"
}

What this control checks

In aws_appstream_fleet, max_user_duration_in_seconds controls the maximum length of a user streaming session. The check passes when the value is 36000 or below. Omit the argument and AWS defaults to 57600 seconds (16 hours), which fails. The minimum valid value is 600 seconds. Set it explicitly to 36000 or lower to pass; any value above 36000 fails this control.

Common pitfalls

Default value fails silently
Without an explicit max_user_duration_in_seconds in aws_appstream_fleet, Terraform applies AWS's default of 57600 seconds (16 hours) with no error or warning. That default fails this control. Set the argument explicitly.
Minimum value constraint
The argument has a minimum of 600 seconds (10 minutes); anything lower triggers an API error during apply. Pick a value that fits your users' actual session length requirements, not the lowest value that passes the check.
Disconnect timeout interaction
A high disconnect_timeout_in_seconds keeps a disconnected session alive and reconnectable for hours after the user walks away. Limiting max duration alone doesn't prevent an idle session from sitting open; cap the disconnect timeout too.

Audit evidence

An auditor expects to see MaxUserDurationInSeconds at or below 36000 for each fleet. The output of aws appstream describe-fleets, filtered to fleet names and their MaxUserDurationInSeconds values, is the primary evidence. Config rule evaluations showing all AppStream fleets as COMPLIANT provide corroboration. Console screenshots of the fleet settings page showing 'Maximum session duration' under 10 hours are acceptable supporting documentation.

Framework-specific interpretation

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

Compliance.tf Control: appstream_fleet_max_user_duration_36000_seconds
Powerpipe Control: aws_compliance.control.appstream_fleet_max_user_duration_36000_seconds
Prowler Check: appstream_fleet_maximum_session_duration

Last reviewed: 2026-03-08