Introduction

In this blog, we show you how you can architect your Amazon AppStream 2.0 environment for disaster recovery (DR). Part of architecting a resilient, highly available AppStream 2.0 solution is the consideration that failures do occur. These failures can be caused by natural disasters, technical failures, and human interactions resulting in a regional outage. Depending on the workload being provided by AppStream 2.0 you may have a recovery time objective (RTO) of minutes or hours to get your end users back to a productive state. A common DR use case is a contact center. Administrators want to ensure that their contact center employees are able to work in the event of a disaster scenario.

Walkthrough

Prerequisites

• Knowledge of AppStream 2.0
• Understanding of AWS IAM and Amazon S3

Before you begin building out your DR environment, you must take these resources into consideration.

• Determine your DR Strategy – When evaluating your business objectives, you will want to consider the following strategies to meet your recovery objectives and utilize your organizations business continuity plan (BCP) to address other business impacting components, such as core infrastructure.
• AppStream 2.0 Images – When creating your AppStream 2.0 fleet you must select an image to use. If you are using a custom image, you need copy the image to your DR region.
• AppStream 2.0 Fleets and Stacks – In the DR region, ensure you configure your fleet and stacks based on your DR strategy.
• Account Service Quotas for AppStream 2.0 – Once you have determined the region you will use for DR, ensure you request a Service Limit Increase for AppStream 2.0. Make sure the quotas in that region are high enough to provide capacity for your users. See Amazon AppStream 2.0 Service Quotas for more information.
• (Optional) AppStream 2.0 related S3 buckets – AppStream 2.0 utilizes S3 buckets for Home Folders, Application Settings Persistence, and App Blocks for Elastic fleets. If you are using these features and want the data to be available to the users in the DR region(s), ensure you have replicated these buckets between your primary and DR region.
• (Optional) Windows Active Directory (AD) Domain Join – If you are using domain joined fleets, you need to ensure that the Active Directory infrastructure are built out and properly configured in the region you select for DR.

Architecture Diagram

General AppStream 2.0 Considerations

Images

AppStream 2.0 is a regional service. When implementing a DR region, you want to evaluate your DR requirements and ensure applicable settings are in place to conform to your business’s RTO objectives. Some key items to consider are copying of the AppStream 2.0 Images and keeping them in sync. This can be automated using the CopyImage API from the production region to the proposed DR region. This should not be a one-time process, automation should be implemented to develop a pipeline to copy the image anytime the production image has been updated or replaced. As your images should be synced between the regions, the AppStream 2.0 Fleets and Stacks should also be replicated. These can be standardized and built out in multiple regions by utilizing CloudFormation to build the Stacks and Fleets.

Scaling Limits

Several factors beyond automation of images, fleets, stacks, and user data will also need to be considered. One of these are scaling limits per account. In a DR event, if you have hundreds or thousands of AppStream 2.0 instances running in a region and need to fail over to your DR region, you need to be aware of scaling limits. If you have not built out your AppStream Fleets in the DR region, you will run into limits. For a detailed example, see the Amazon AppStream 2.0 Best Practices Guide.

• For a single fleet, AppStream 2.0 provisions at a maximum rate of 20 instances per minute.
• For a single AWS account, AppStream 2.0 provisions at a rate of rate of 60 instances per minute (with a burst of 100 instances per minute) combined across all regions.

Authentication

The next consideration is authentication. In order to redirect users to a DR region you must deploy with either SAML or custom authentication. When using SAML, users are directed to the stack and fleet based on the relay state specified on the SAML application within your IDP. If you failover to a DR region you will need to update the SAML applications to point to the stack(s) in the DR region. If you have already configured, cross-region redirection, or latency based routing for AppStream 2.0, you will need to update that configuration instead of the configuration of the SAML application.

User persona persistence

If you are using any of the optional features within Amazon AppStream 2.0, such as application settings persistence, home folders, or Elastic fleets, you need to ensure those resources are available in the DR region when you failover. These resources reside in S3 buckets specific to the feature. S3 has a built-in replication feature for S3 buckets. You can setup replication to a bucket in another region. For more detailed instructions, see the “Optional – Enable” section on the Cross-Region redirection with Geo Targetly and Amazon AppStream 2.0 blog. For Elastic fleets, you will also need to create an app block and the application in the DR region.

Windows AD

If you are using domain joined fleets, you need to ensure that the Active Directory infrastructure is built out and properly configured in the region you choose for DR. This includes Active Directory Federation services unless you are leveraging an alternative SAML federated Identity product or using Amazon Cognito. If you are using AWS Managed Microsoft AD, you can enable multi-region replication.

Conclusion

In this blog we discussed ways to architect your Amazon AppStream 2.0 environment for DR. Your use case will dictate the type of DR setup you deploy. We discussed all the considerations you need to take into account when building out your DR environment.

Did this blog help with your DR strategy with AppStream 2.0? Leave a comment on how you and your organization solved DR with AppStream 2.0 architecture.

Sam Goad is a Sr Solutions Architect at AWS. At AWS he works with Healthcare customers to adopt cloud services. In his free time Sam can be found playing golf or enjoying water sports.

Asriel Agronin is a Sr End User Compute Solutions Architect at AWS. He enjoys helping customers adopt AWS services. Asriel can be found scuba diving in his free time.