Appstream2.0 url login page

You can have as many Stacks (and URLs) as you require, but that would also increase the number of Fleets, so there is a cost component to optimize there. Depending upon how you authenticate users (SAML 2.0 or custom Identity Provider), the configuration varies but you would entitle the users from the Identity Provider to the Stack.

Hi -

There's two parts to your question: 1/ is authentication, entitlement, and access to the service, and 2/ is how to configure different applications/application settings for different user groups.

For 1/ IAM users are intended to be administrative users, and you can't (easily) entitle access to AppStream 2.0 to IAM users. The recommendation is to instead leverage your existing SAML2.0 identity provider directly. With SAML2.0 integration, you can either create a single SAML application for AppStream 2.0 and use the attribute-based application entitlement feature to manage what stacks and applications the user has access to, or create a SAML application per stack, then entitle your user to that SAML application. SAML2.0 aligns to your second scenario - entitling users (and providing unique links/access) to each stack.

It is not recommended to try providing IAM users access to AppStream 2.0. IAM users are intended only for admin actions. The streaming URL capability within the console allows users who have permissions to call that API to provide a username different than the one they are logged in as - it's only intended for very quick tests or for when you have a custom identity provider that is not SAML 2.0 compliant.

For 2/ how to configure different applications/application settings for different user groups, it depends on what uniqueness per user group you have, and level of visibility to other groups you're OK with. For example, if you want to provide different sets of applications to users, you could use a single image that has all applications installed on it, then use the application entitlements feature to limit what the user sees. Here's an example in practice: https://aws.amazon.com/blogs/desktop-and-application-streaming/use-amazon-appstream-2-0-application-entitlements-with-azure-ad/.

However, if your user groups need different application settings, it'll be a little bit more challenging. You can create an image per user group that has the settings baked in, but that'll also require a fleet per user group. You can use Session Scripts to customize the experience on the fly when the user logs in. Or, if you just need to provide parameters at run time, you can use the SAML SessionContext attribute to pass information in to the first application that launches.

Hope this helps.