Amazon AppStream 2.0 Fleet
Does ZopNight manage Amazon AppStream 2.0 Fleet?
Amazon AppStream 2.0 bills for provisioned streaming capacity: always-on fleets meter every instance-hour around the clock, on-demand fleets meter running hours plus a small stopped-instance fee. ZopNight discovers fleets on the 6-hour cycle, reads 90 days of AppStream CloudWatch metrics, and recommends capacity corrections where utilization runs low.
Rules that fire on Amazon AppStream 2.0 Fleet
No active rule family targets Amazon AppStream 2.0 Fleet today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery, metrics, and cost tracking only. |
Amazon AppStream 2.0 streams desktop applications from managed fleets of streaming instances. Fleets bill for provisioned streaming capacity, so fleets sized for peak usage but left running off-peak waste money.
Streaming seats, metered like servers
AppStream’s cost is the fleet: a pool of streaming instances provisioned to serve user sessions. Always-on fleets bill every instance-hour whether anyone streams or not. That is the price of instant session start. On-demand fleets bill full instance rates only for running instances, with a reduced stopped-instance fee for the provisioned remainder, trading a couple of minutes of session start latency for a much lower idle rate. Image builders bill like instances while they run, and Windows-based fleets carry user-license fees on top. Capacity, not usage, is what the invoice reflects.
Fleet utilization through a 90-day lens
ZopNight discovers AppStream fleets automatically on the 6-hour cycle and pulls hourly CloudWatch metrics from the AppStream namespace with a 90-day lookback, alongside per-resource cost from Cost Explorer or CUR 2.0. The metrics make the capacity-versus-sessions gap measurable: available capacity that never hosts a session is the recommendation target. Findings typically point at converting always-on fleets to on-demand, shrinking minimum capacity, or tightening the scaling policy’s schedule to the hours users actually stream.
Where streaming fleets overspend
The peak-sizing trap dominates: a fleet sized for month-end reporting load runs that capacity all month. Time zones compound it: a fleet serving one region’s business hours idles for the other 16 hours at full provision. And pilot programs leave residue: proof-of-concept stacks with an image builder still running and a minimum capacity of a few instances, streaming to nobody since the pilot ended.
Reviewing fleets and scaling policies
The AppStream console lists fleets with type, instance type, and capacity bounds; Fleet usage graphs show sessions against capacity directly. The scaling policy attached to each fleet is where the fix lands. Set minimum capacity to real concurrent sessions, and add scheduled scaling for predictable working hours.