No streaming resources are available when connecting to an Appstream streaming url

In this situation we would have expected that if after a while there are no instances available the streaming url generated will expired after the time value configured for url validity 60 seconds but it's not, users can retry even when the url should have expired.

Can someone confirms that url validity doesn't take effect in this situation? if so, what's the max time the user can use that given url after is invalidated if he remains clicking retry periodically?

The streaming URL validity, and ability to generate streaming URLs, are not related to the capacity in the fleet at any given time. The streaming URL authorizes a user to access a specific stack, and the URL remains active only for the validity period that was entered (if 60 seconds, then the user has 60 seconds from URL generation to access the stack). Once the user lands on the AppStream 2.0 application catalog, they can attempt to access an instance, or continue retrying (I think for 16 hours). However, they will not be able to use the streaming URL to access the application catalog page again.

We already know that the recommended approach is ensuring that there are enough instances for incoming users but we can't predict our usage patterns accurately and we end up reaching this more than desired affecting to our user experience.

You will need to ensure sufficient capacity for your users to access to avoid having them see that URL. We generally recommend customers over provision their fleets for a duration to understand what the utilization pattern will look like, then use a combination of target tracking and scheduled scaling to meet that demand. Eg: use scheduled scaling to set a higher minimum during business hours, then use scheduled scaling to reduce the minimum outside business hours - and target tracking will grow/shrink within those boundaries.

If your application can be made portable, you could consider using Elastic fleets. Elastic fleets eliminates the need to predict usage patterns or create/manage scaling policies entirely. As long as your application can be delivered to the streaming instance on the fly, this might be a good option. Elastic fleets also bill per second, with a minimum duration of 15 minutes, so may reduce your costs, too.

I see thanks, summarizing:

• max time for the url generated for the streaming app (https://appstream2.eu-west-1.aws.amazon.com/authenticate?parameters=foobar) is tied to max url validity time
• when the user get access to the fleet by the previous step, the url is something like (https://73f7571060c9b77b111bd783c61dc4da4d6fd249afb0b49dd5b05a21.appstream2.eu-west-1.aws.amazon.com/#/catalogs?reference=fleet%2Ffoo) waiting for a fleet, then the max time this session could last is the one configured for max user session

is this right?