Disaster recovery

Amazon AppStream 2.0 has built in redundancy across up to three availability zones. This means that if a user has an active session in an availability zone that becomes degraded, they can simply disconnect and reconnect which will reserve them a session in a healthy availability zone assuming you have capacity. While this provides high availability within the Region, it does not provide a disaster recovery solution if the service experiences issues at a regional level.

To provide a disaster recovery plan for your AppStream 2.0 users, you will first need to build out an AppStream 2.0 environment in your secondary Region. From a design perspective, this environment should have redundant connections to your on-premises environment, if applicable, and should have no dependency on the primary Region. For example, if your AppStream 2.0 fleet is domain joined, you should have additional domain controllers in the secondary Region with Sites and Services configured. From an AppStream 2.0 perspective, this environment should consist of the same fleet and stack settings that you have in your primary Region. The fleet itself should run your same base image, which can be copied to your secondary Region via the console or programmatically. If the applications that run within your AppStream 2.0 sessions have a backend dependency tied to your primary Region, that too should have regional redundancy to ensure the users can still access the application’s backend if the primary Region goes down. Your service level limits in your destination Region should match your primary Region.

Identity routing

There are two distinct methods to providing access to applications in a DR scenario. At a high level, the two methods differ by how the users are directed to the failover Region. The first method is performed with a single AppStream 2.0 application configuration in your IdP and the second method is having two separate application configurations.

Method 1: Changing the relay state of your application

When users login to AppStream 2.0 from an Identity Provider (IdP), following their authentication they are relayed to a specific URL that aligns to the Region and stack they are intended to have access to. For more information around the Relay State URL, refer to the Amazon AppStream 2.0 Administration Guide. The administrator can configure a cross-Region stack built on the same AppStream 2.0 image as the primary Region for users to failover to. The administrator can control this failover by simply updating the Relay State URL to point to the failover stack. For this method to operate properly, the associated IAM policies will need to reflect access to both stacks; primary and failover. For more details on how these IAM policies should be configured, see the following example policy.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "appstream:Stream",
            "Resource": [
            "arn:aws:appstream:PrimaryRegion:190836837966:stack/StackName",
            "arn:aws:appstream:FailoverRegion:190836837966:stack/StackName"
            ],
            "Condition": {
                "StringEquals": {
                    "appstream:userId": "${saml:sub}"
                }
            }
        }
    ]
}

Method 2: Configuring two AppStream 2.0 applications within your IdP

This method requires the administrator to build out two separate applications for AppStream 2.0 within the IdP. They then can either present both applications and let the user choose where to go, or they lock/hide an application until it’s time to failover. This method is better aligned to the use case of having global users that move around often. Those users should be streaming from the closest endpoint, therefore having both applications assigned gives them the option to choose the application that is configured for their nearest Region. This can also be automated, for more information see this blog post.

Storage persistance

When leveraging the included data persistence features of AppStream 2.0, such as Application Persistence and Home Folder Synchronization, you will need to replicate that data to your failover region. These features store the persistent data in an Amazon S3 bucket in the given AppStream 2.0 region. To have the data persist cross region, you will need to replicate all changes on the source bucket to the failover regions AppStream 2.0 bucket. This can be done with native Amazon S3 features, such as Amazon S3 cross region replication. Each users persistent data will reside under a folder of their hashed username. Since the username will be hashed the same cross region, simply replicating the data will provide data persistence in your secondary region. For more information about the Amazon S3 buckets used by AppStream 2.0, see this guide.